pretty unlikely but I think in a memory exaustion scenario
you might roll the uint8 over to zero and crash
Change-Id: If73dc64484f2d363446be068aa7bf8025407a2a7
moves the callback to settings_list
audio_set_playback_frequency now accepts an actual frequency
44100 192000 etc rather than an index
Change-Id: Ieb3fc79a7fe3f1ff050465c8cd8061027e4572ff
Recently I added F_CB_ON_SELECT_ONLY_IF_CHANGED in conjunction
with the shuffle and repeat settings
instead it makes more sense to make F_CB_ONLY_IF_CHANGED
and apply to all callbacks (F_CB_ON_SELECT_ONLY or on_exit)
Change-Id: I4376557d479aceb419f7b4b4e0998afc249c87ec
shuffle and sort were called on startup before playlist_init
and also on setting switch even without select
repeat is also now handled in settings_list as well
after moving the callbacks to settings_list.c
there was then a problem of unintended callbacks on exit of the menus
fixed that with F_CB_ON_SELECT_ONLY
since the callback was called regardless of the setting being changed
on F_CB_ON_SELECT_ONLY which is preferable in some circumstances
I co-opted F_TEMPVAR to allow the callback only when the setting was changed
with the flag F_CB_ON_SELECT_ONLY_IF_CHANGED
Change-Id: I5265233bbb556dc06c45273e742be5d78510a806
Setting in shortcut was not being handled as it had no callback.
In the settings menu it looks like the event is handled separately.
Added a shuffle callback to the setting so it is called when changed
from the shortcut.
Edit: move callback to within settings_list so playlist interface is
unchanged.
Change-Id: I3691acac1c73a80bf67c0b8b334009ef1655fdb0
add_indices_to_playlist() wrongly assumes playlist->utf8 means
the playlist has a UTF-8 BOM. It only means the file is UTF-8
encoded, and says nothing about the presence of a BOM.
Trying to seek past a BOM when there is none mangles the first
filename in the playlist. Avoid this by closing & reopening the
playlist, which ensures the BOM (or lack of it) gets detected
properly.
Change-Id: I222fa6fc31e941d0252f1895b393a51694b93b7c
Have get_track_filename() read track seek offset & insert type
itself to avoid duplicating code. Most callers are not interested
in that information, and only use it to call get_track_filename().
Change-Id: I46d50fda10e515f74e27eebdded8e281bbf4456f
It was only used in filetree.c. It's still implemented in Lua so
scripts using rb.playlist_add() won't break, but has been removed
from the Lua API "backend".
Change-Id: I5625a47f0692456008c6b10dee14755151d22f29
The file name for a track in the database has been
retrieved already, before its context menu is displayed,
or a hotkey is executed, see:
8a22d2678a/apps/tree.c (L811)
So, skip over tagtree_current_playlist_insert and instead
use playlist_insert_track() directly, when user selects
something from the "Playing Next" menu or uses a hotkey.
Change-Id: Ie0789d8314949e9872bf261634d81b96432ccda3
Playlist Viewer, when quitting, should not ask
you to save a playlist that hasn't been modified
since it was last saved.
Change-Id: Ia401239392ba5f2d66562a991ba49b01c6c2d452
When saving a playlist to an existing file on disk,
warn user, unless the playlist's file name remains
unchanged.
Change-Id: I10d82667de5fadb5323be4f981bea9263849f07a
Properly update displayed playlist index and all available
metadata for the currently playing track. Also exit screen
when playlist has finished to prevent nonsense data from
being displayed.
Change-Id: Iecc53c0eda5cbd374b51827a25916ee4e2c6456f
Backdrop images loaded using %X(filename) already had
dithering enabled, but images loaded using the %x tag
in viewports annotated with %VB did not.
Change-Id: I9c6d11d8e7ab41a53eb9e453d78ae0dc58cb947b
If "Show Queue Options" was set to "in Submenu",
the queue options would incorrectly appear at
the top level after you had queued a track, at
least until you entered and exited the submenu
again without selecting an option.
Change-Id: I59abd73de7e3634bc8701aa2288b56bde7552513
On all players, it should be possible to return from the Main Menu
by pressing the Back or Menu key. Unless I'm missing something...
"Clear Playlist" has hopefully become superfluous after the "Playing Next"
context menu was added, which offers similar functionality.
Change-Id: I741544978fb7936b8d5a34dfc656472e20c1737e
After launch, PictureFlow always goes to the currently playing
album, or to a selected album, if applicable. Which is probably
a useful default, but not always wanted. You can now get back
to the album you were looking at when PictureFlow was last
closed, or when the sorting was last changed.
Change-Id: Iba3e0d5388f6b49534d09fe0224b0dbfa65d5f1d
This lets players that can't spare any keys scroll through
albums without leaving the track listing first, which was
only possible on the M3K before.
Enter mode from Main Menu. While active, the gradient
highlighting an album's selected track will not appear,
and context menu options apply to the whole album
instead of to a single track.
Exit mode by pressing buttons for Select/Back, or by
quitting PictureFlow.
NB: Be sure to enable "Database in RAM" for a good
experience, as the loading time for each album can
become quite annoying otherwise.
Change-Id: Id6c9a8cc49e4cfb2aea958610b95a19887f496b6
Apparently _most_ targets have a dbtool built as a simulator variant,
but _some_ are built as an application target. This commit fixes
simulator-based targets, which weren't ever broken.
(Prior commits fixed things for _app_ targets, which haven't worked
since at least 2020, maybe never..)
Change-Id: I7fef2b10e5128059b293118617701630bf3dc1fb
This makes it far more useful, as before it insisted on scanning from
the root directory and putting the generated db files in /.rockbox
Change-Id: I0d0e3c6c6c7ee1fc5473185482fbfb9a2a2be29f
This was introduced by adding multivolume support to the hibyplayer units,
and might affect other things, if so a more general fix might be needed.
Change-Id: Ia9c1b6b1eb50e67221ce440d30d6770daaeac74e
Three separate problems:
1) Make 4.4 defaults to a named pipe for jobserver control, this
was incompatible with how glibc did recursive makes
2) Make 4.4 passed long arguments ( --foo ) into MAKEFLAGS and this
broke stuff that wasn't expecting it
3) Circular dependency in a header generation due do make 4.4 being
stricter/more consistent in how it orders rules vs which makefiles
they came from. This one was the real !@#!@ to deal with.
This patch set fixes the hosted arm (glibc 2.19) and mips (glibc 2.25)
toolchains.
Change-Id: Ie6d6a0ab7e1b36f24c43e524fee4afc0bd3a14d6
eg, our current toolchian generates this:
GNU ld (GNU Binutils) 2.26.1
But the system toolchain on the buildserver generates this:
GNU ld version 2.37-37.fc36
Change-Id: I0166f12d660654c1456289954fb256db98213618
NO_CROSSREFS_TO() was first introduced in binutils 2.27.
It is used to have the linker report errors when symbols
from a list of sections refer to a specified section,
which is useful for verifying that normal code does not
refer to INIT_ATTR code.
Note this doesn't actually start using NO_CROSSREFS_TO()
for builds -- that will have to wait until the toolchain
upgrade when we'll have a new enough binutils -- it just
detects support for the feature so it can be conditionally
enabled in linker scripts.
Change-Id: If1553eaa671fcbbdfe6af357a6331931e7c4f997
Previously, it was hardcoded to the english convention of units-last, so
"100%" would be voiced as "one hundred percent". This adds a new
language flag that makes the units be voiced first, ie "100%" will be
voiced as "percent one hundred".
So far only the Chinese-traditional and Chinese-simplified languages
utilize this feature (taken from an old ticket, FS#10340) but I'm sure
others would want this feature too.
Change-Id: Idf825ec9299dc0ed09921cf67aec61b1ab262fc6
Notes:
* Currently limited to 32-bit sector addresses due to internal Rockbox
APIs. So this means a practical limit of 2TiB per drive.
* Only 'General Data' GPT partition type is recognised, as that's
what SD cards seem to use for exFAT/FAT32.
Note that _booting_ off GPT-partitioned drive will require rebuilding
the various rockbox bootloaders, and even then there may be platform
limitations that preclude this.
Change-Id: Ibfaae1960adcb1e81976d4b60dd596c6d16318e4
I couldn't seem to reproduce the issue here:
https://forums.rockbox.org/index.php/topic,54165.msg252081.html#msg252081
but I figure its probably a threading issue
so we now have a mutex on the cache
and to top it all off each cached entry has a crc and length that are
checked before writing the entry to the file otherwise it is prepended
with # FAILED - so hopefully scrobbler 'parsers?' don't barf on the log
Other changes:
there is now a MRU table for tracks this should help prevent duplicates
it is configurable..
the cache buffer now no longer uses fixed chunks allowing more tracks
to be written between flushes
Change-Id: Iaab7e3f6a76abfc61130f3233379a51c9a6d12e5
