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
Still having problems with determining the type of track change
lets try just watching the audio_next/prev functions
Change-Id: Ie4233ff4d4bf49792a6549d7bcd169ff4b1afd20
I recently added track skipping while REPEAT_ONE was set
currently by registering a track skip callback
I'm not entirely happy with the additional constant overhead
of the event callback
Instead I went looking for a way to distinguish
a pending track skip from some limited testing
it appears to work just as well to compare
playback's skip_pending == TRACK_SKIP_AUTO
but the lack of lifetime control worries me slightly
Change-Id: Ic71b4c3925e991f5a1216d16ecd3af6cc777ef1e
open an insert context
add tracks using the opened context
release opened context and sync the playlist
Change-Id: Idea700ffcf42a38dc23e131c92a6c5d325833170
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
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
The intent behind the check is to only do this if the filename
comes from an on-disk file. With the RAM buffer is gone this is
now "always" the case.
Change-Id: I4c26e32c482dde176b69a6071e9562e9955d7171
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
Distinguish read locks from write locks to aid converting the
mutex to an MRSW lock at some point in the future. Everything
is a write lock for now and a mutex is still used, so there's
no change in behavior.
Change-Id: I25aeed580580bdb0c3048fc7e1eaad1c32c30159
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
Fix deadlocks in the dircache scan thread caused by incorrect
lock ordering. Mutating operations need to stop the thread to
prevent it from accessing invalid data; this must always be
done before taking the playlist lock to avoid deadlocking the
scan thread.
Change-Id: If719a8b28ed0b0b3eac068073581e606c4a5f58a
Make background control file flushing work on non-dircache targets.
It has nothing to do with dircache and doesn't belong in the dircache
scan thread.
Change-Id: I3f39261ccaebb5dce69e7db3d2e0c0c0c54f640b
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
Apparently queue_send() silently falls back to queue_post()
if sending isn't enabled. Doesn't seem like a good idea, as
post and send are definitely *not* interchangeable!
The playlist code relies on queue_send()'s blocking behavior
to prevent the dircache thread from using potentially stale
pointers.
Change-Id: Ibf4b0def3bf9c96cb2fe80cd75043b7ce1dcf250
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
dc_playlist_thread may continue loading pointers even while
underlying indices are changing instead stop the loop by marking
pointers as clean and rebuild later
Change-Id: If154f673b4af8d6e9c364499d58f1321834a76a4
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
give user option to load playlist from disk when
namebuffer is too small -- max_playlist size still
limits the total entries but filename length
won't stop them from playing the directory
Change-Id: I1787689417661ea670a211f575f2c52e84465869
mutexes are in just trying to refactor the rest and make it a smaller
and more robust system
--Done
Change-Id: If64807c3e0ee1966f7593795f26f1f538caf831b
get_filename() changes the seek pos with out restoring it
seek back to the beginning or after the BOM if utf8
--
the other option is to open our own file descriptor this will
remove the need for the mutex but it would no longer block get_filename
from getting potential stale / bad data
Change-Id: I0d2b8a1a297c7aaf453b3bc558b2b5b53dbe591b
I'm pretty sure this is a very old bug I traced it down to the
current_playlist getting changed out from under add_indices_to_playlist
causing myriad of issues from buffer full to invalid control file to shifting indices
this only appears to happen with the dircache on
I still get an incorrect resume state with the wrong song very rarely -- turns out get_filename seeks the file FIXED
Some debugging left in for now till we can verify there are no other instances
Change-Id: I289a775462eddfe93da4a326dc9e38605af06816
There's probably little benefit to using core_alloc_maximum() for
loading playlists since they are parsed incrementally. I/O speed
does not increase with increased read sizes beyond a certain point.
Read by 32 KiB chunks since that is what the buffering thread does.
Fall back to core_alloc_maximum() if a small allocation fails so
that buflib will try harder to free up space.
Change-Id: I08b94317d12b98af09ef2bd84aa1195c4c51d1b1
replace applicable calls to strlcpy with calls to strmemccpy
which null terminates on truncation
in theory the strmemccpy calls should be slightly faster since they
don't traverse the rest of the source string on truncation
but I seriously doubt there is too much of that going on in the code base
Change-Id: Ia0251514e36a6242bbf3f03c5e0df123aba60ed2
the loading track splash flashes and is ugly
add a function to display a progressbar along with the splash message
spruce up database commit message as well
Change-Id: I2749b958c1ee5dad2631a5f999a4b00ddca7f225
Shuffle and Unshuffle commands are not flushed to
disk when control data is updated. The same applies
to Delete and Reset commands, unless HAVE_DIRCACHE
is undefined (see update_control() function in playlist.c)
playlist_resume() discards cached control data.
This resulted in a bug where (e.g.) removed tracks
from the current playlist would reappear if you stopped
and resumed playing immediately afterwards (instead of
restarting in between).
Change-Id: I273f61e823a1d99426a18079b81aa07915620f30
A couple of places use sizeof(int) for allocations and copying but
the indices are longs, which causes bugs in the simulator on 64-bit.
Change-Id: Ie101ac57d44217c4b1657cf0152c97e276bd7043
The comment regarding Windows paths was fairly confusing as to
its intent. What the code is trying to do is replace the drive
letter with the volume containing the playlist, which appears
reasonable. The middle of the comment was devoted to explaining
why the code below was potentially incorrect which only served
to add to the confusion.
AFAICT the last volume specifier in a path will cause search to
start from the root of that volume, so any incorrect result can
be avoided by using the new function path_strip_last_volume().
Finally, add a comment at the top of the function that explains
what it does.
Change-Id: If4e4938801f2f81eb52f5d32b5461872995e5e83
