Although this breaks compatibility with playlist control
file versions 3-5, i.e. control files generated by any RB
build between Jan 29 2023 (commit 25bd3bc) and Oct 26 2024
(commit 7592d2c), compatibility with v2 of the control file
that was in use from 2003 to 2023 is maintained.
Change-Id: I7fd3394e31131bb0563e41d921bcaf940dd999bc
Offer new options to show elegantly your entries in any playlist/dynamic playlist viewer. This is especially important if you dual boot an iPod with Stock OS and want to sync with iTunes; with this very popular setup, file names are obfuscated which results in any Rockbox playlist viewer difficult to enjoy, and it was a long standing issue reported by several Rockbox users over the years. The only way to show the title was to open a contextual menu on each song to get infos about the selected song, which is a very long and anti-ergonomic process to understand what is on your current playlist/randomized playlist. The idea of this patch is to provide new alternatives that the user can select. I personally selected the Title & Album view which provides excellent readability.
This patch was built with performance in mind using lazy loading to load one by one the tags then cache a string and use the little cache as much as possible to make scrolling in the same area as smooth as possible. Performance remains very acceptable even on an iPod 4G with its original hard drive. Using a real compact flash with my iPod Mini 2G reduces the latency even more.
Those new options are disabled by default because they impact noticeably the scrolling performance and are less relevant if your files are decently properly named.
Unfortunately, the search feature in a playlist will need to continue to use the raw filename because reading the tags for a whole playlist is a performance disaster. This works decently while viewing just because I made a code that load those one by one as much as possible.
I focused also on testing that the opening of the playlist viewer UI remained fast, and loading one by one with lazy loading allows to get very little overhead in this regard.
Change-Id: I00d9c802e29f8372447813b035bbae207a016467
Track Info can now be displayed for the set of
all tracks contained in a playlist. This lets
you calculate a playlist's length, for example,
even if it is not currently playing.
This functionality can be accessed from the
existing "Properties" screen for a selected
playlist file. A line has been added at the
very bottom to show Track Info.
Change-Id: I311532b7cfa9e29d46c0cd5623ba4c06c1dd5b5f
add_track_to_playlist_unlocked only increased a playlist's
first index as necessary when its position parameter was
negative (i.e. one of the special insert positions was
specified).
A negative value was not stored in the control file, but
was always converted into an absolute position. Thus, any
adjustments to first_index weren't repeated when resuming
from the control file.
In particular, shuffled playlists were affected (in case of
first_index > 0), when inserting at positions <= first_index,
including appending a track to the end of a playlist. This
works by inserting at first_index and increasing first_index
by 1 afterwards.
Similarly, adding tracks in a shuffled fashion could increase
first index, whenever that was the value randomly calculated
for a track position, effectively appending it (I assume this
is on purpose).
To make sure that first_index adjustments are recovered when
resuming from the control file, and to be able to differentiate
between a prepended or appended track, store the special value
PLAYLIST_INSERT_LAST_ROTATED as the insert position in the
control file whenever first_index would have been used before,
and a special position (other than PLAYLIST_PREPEND) was
provided to the function.
Change-Id: I31f26796627fb136daeddd046cb1892bdf1b4014
+ update misleading comment for catalog_add_to_a_playlist's
m3u8name parameter (the keyboard picker will be shown even
if it's not NULL)
Change-Id: I7576a83fd40cdcdb7a912c90d8c1d9a8f25e277c
playlist_save() was a poorly thought out mess. This fixes the
glaring issues and hopefully ensures that saving the playlist
never loses state (such as queued tracks or modified status)
after save+resume.
Indices are now updated on the fly, which is faster and needs
no extra memory. But if an error occurs, the playlist will be
corrupted. There is currently no attempt to handle this since
errors should be unlikely, but some error handling needs to be
added in the future.
Change-Id: If8a5dbd6a596460be08ee0b7bab9f24337886ea4
The bookmark menu with the option to create a bookmark
was inadvertently displayed for new dynamic playlists,
that had no associated folder or playlist file on disk.
(e.g. after selecting some track from the database for
playback), until the playlist was modified by the user.
Change-Id: I9d6809e4d03603c651459415327f28e38162ad53
The modified state is now an explicit flag that has to be
set whenever a user-triggered modification occurs. This is
recorded in the control file to ensure it doesn't get lost
after resume. There may be some places I missed where the
modified flag should be set/cleared, but it seems to work
well enough right now.
Change-Id: I3bdba358fc495b4ca84e389ac6e7bcbef820c219
open an insert context
add tracks using the opened context
release opened context and sync the playlist
Change-Id: Idea700ffcf42a38dc23e131c92a6c5d325833170
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
Control cache entries cost 24 bytes per command, but cacheable
commands are always less than that when written out to the file.
We can actually cache *more* data by writing commands directly
to the fd (native Rockbox has a 512-byte cache per fd) and it's
much simpler.
Change-Id: Ibb1b9ffa56ef17431b281419a04082e14d0cbd85
Use the playlist control file for directory playback instead of
storing filenames in RAM. The implementation of that feature is
very iffy and probably responsible for random crashes that may
occur when skipping through directories rapidly.
Change-Id: I3863940cd4542410d8046a3ca47508b5d97309a1
Any modifications to the playlist (insert, delete, shuffle, etc)
will cause the modified flag to be set. The flag is cleared when
the playlist is saved. Code that generates playlists can manually
clear the modified flag if appropriate; there is now a proper API
for this so the tagcache and pictureflow don't need to resort to
hacks.
Change-Id: I8d3c723265a41db07a13de3f1d2abb0444528d57
This was insanely slow for large playlists. Implement it as a
constant-time operation to avoid the O(N!) blowup, and add a
new "clear" command to the control file to avoid flooding it
with individual delete commands.
Change-Id: Ied82d1cba015591edd583f2a2ff6772108f4e176
This is not necessary. Volatile doesn't create a memory barrier
wrt. non-volatile accesses and there are no interrupts involved,
so there's no reason to use it here.
Change-Id: I78299e2f318e68735364601b3bc2aa036e71130e
dircache_search() can yield, which would lead to memory corruption
if the playlist dcfrefs buffer is moved at that point. Prevent this
from happening by storing the buflib handle and pinning the buffer
while scanning the dircache.
Change-Id: I28b122de283953dd6d54c1d00598759f5bdcbe93
dc_thread_playlist was asking for invalid indices
since previously the name buffer would have been valid
it just got whatever junk data was left over
add dc_discard_playlist_pointers for HAVE_DIRCACHE targets
this allows the dc_playlist_thread to stop its current lookup loop
Change-Id: I6f25b97b8c4e314d27c5e1e6ff0925b5a3e93f26
This reverts commit 89c021fbfa.
Reason for revert: crash when playing on disk playlist then playing a directory as an in-ram playlist
Change-Id: Ia5cf5da9f46f8c10c5c0f3707e7978c05664b8a4
mutexes are in just trying to refactor the rest and make it a smaller
and more robust system
--Done
Change-Id: If64807c3e0ee1966f7593795f26f1f538caf831b
'swcodec' is now always set (and recording_swcodec for recording-capable
units) in feature.txt so the manual and language strings don't need to
all be fixed up.
Change-Id: Ib2c9d5d157af8d33653e2d4b4a12881b9aa6ddb0
While playing a track the playlist viewer may not
have a big enough temporary buffer to load and display
'max_files_in_playlist' entries
This patch attempts to load as many entries as possible
If tracks were already playing (dynamic playlist or otherwise)
The original code only gave half the plugin buffer to a playlist
loaded from file
On some targets half the plugin buffer is not enough to load all entries…
Now we attempt to get as many entries possible while at least leaving a
small buffer (MAX_PATH) for the name buffer
Change-Id: Ic06eaabc4e2550f076d625957d6d073790852743
Playlist dircache references should be back in working order.
Reenabling dircache references in the database ramcache is not
yet done as it requires quite a bit of rework. Otherwise, the
database in RAM is functional again.
Some buffer compatibility changes have been made for database
commit because the dircache buffer can no longer be stolen, only
freed by an API call.
Change-Id: Ib57c3e98cb23e798d4439e9da7ebd73826e733a4
The plugin buffer was used only to avoid reparsing the playlist, so non-essential.
But when it was used it conflicted with the playlist viewer which already uses
the plugin buffer for playlist purposes simultaneously. It only works by
accident.
Since the reparse avoidance is non-essential don't do it for now. A temp buffer
can be passed to playlist_save() to enable it but the only caller (as of now)
does not do that.
Change-Id: I3f75f89d8551e1ec38800268b273105faba0efbf
This complements offset-based resume and playback start funcionality.
The implementation is global on both HWCODEC and SWCODEC.
Basically, if either the specified elapsed or offset are non-zero,
it indicates a mid-track resume.
To resume by time only, set elapsed to nonzero and offset to zero.
To resume by offset only, set offset to nonzero and elapsed to zero.
Which one the codec uses and which has priority is up to the codec;
however, using an elapsed time covers more cases:
* Codecs not able to use an offset such as VGM or other atomic
formats
* Starting playback at a nonzero elapsed time from a source that
contains no offset, such as a cuesheet
The change re-versions pretty much everything from tagcache to nvram.
Change-Id: Ic7aebb24e99a03ae99585c5e236eba960d163f38
Reviewed-on: http://gerrit.rockbox.org/516
Reviewed-by: Michael Sevakis <jethead71@rockbox.org>
Tested: Michael Sevakis <jethead71@rockbox.org>
As well as using an index, which breaks when a file is added or
removed, use the crc32 of the filename. When the crc32 check passes the
index is used directly. When it fails, the slow path is taken checking
each file name in the playlist until the right crc is found. If that fails
the playlist is started from the beginning.
See http://www.rockbox.org/tracker/6411
Bump plugin API and nvram version numbers
Change-Id: I156f61a9f1ac428b4a682bc680379cb6b60b1b10
Reviewed-on: http://gerrit.rockbox.org/372
Tested-by: Jonathan Gordon <rockbox@jdgordon.info>
Reviewed-by: Jonathan Gordon <rockbox@jdgordon.info>
This enables the ability to allocate (and free) memory dynamically
without fragmentation, through compaction. This means allocations can move
and fragmentation be reduced. Most changes are preparing Rockbox for this,
which many times means adding a move callback which can temporarily disable
movement when the corresponding code is in a critical section.
For now, the audio buffer allocation has a central role, because it's the one
having allocated most. This buffer is able to shrink itself, for which it
needs to stop playback for a very short moment. For this,
audio_buffer_available() returns the size of the audio buffer which can
possibly be used by other allocations because the audio buffer can shrink.
lastfm scrobbling and timestretch can now be toggled at runtime without
requiring a reboot.
git-svn-id: svn://svn.rockbox.org/rockbox/trunk@30381 a1c6a512-1295-4272-9138-f99709370657
The buflib memory allocator is handle based and can free and
compact, move or resize memory on demand. This allows to effeciently
allocate memory dynamically without an MMU, by avoiding fragmentation
through memory compaction.
This patch adds the buflib library to the core, along with
convinience wrappers to omit the context parameter. Compaction is
not yet enabled, but will be in a later patch. Therefore, this acts as a
replacement for buffer_alloc/buffer_get_buffer() with the benifit of a debug
menu.
See buflib.h for some API documentation.
git-svn-id: svn://svn.rockbox.org/rockbox/trunk@30380 a1c6a512-1295-4272-9138-f99709370657
Only integer IDs are exposed from dircache with this. This way the cache is isolated from other modules.
This is needed for my buflib gsoc project.
git-svn-id: svn://svn.rockbox.org/rockbox/trunk@30038 a1c6a512-1295-4272-9138-f99709370657
Introduce a new .init section for initialisation code, so that it can be copied to an area which is later overwritten before calling. The stack/bss can then overwrite that code, effectively freeing the code size that the initialisation routines need. Gives a few kB ram usage back.
Only implemented for PP and as3525 so far. More targets could be added, as well as more functions.
git-svn-id: svn://svn.rockbox.org/rockbox/trunk@25013 a1c6a512-1295-4272-9138-f99709370657
