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
with root redirect and even relative paths eventually we need the dircache
to get files from the disk
Change-Id: Ia443f473f09dd534674d5fdb71251214ce01eed7
I ocassionally see Playlist Invalid messages but which part is failing?
eventually it works so its probably a race
Change-Id: Ib2b09ab13ce09a55130430a2e94bc0498443b6ec
There are various allocations that can't be moved or shrunk.
Provide a global callback struct for this use case instead of
making each caller declare its own dummy struct.
Also fixed ROLO and x1000 installer code which incorrectly
used movable allocations.
Change-Id: I00088396b9826e02e69a4a33477fe1a7816374f1
the splash suffices as warning let the calling code decide what to do with it
everything I saw calling expected failure with a -1 return so it shouldn't
cause any issue removing the panic
Change-Id: Idc1fba91c3ab4f1fd78e1d6a07dc2e6a0bfd8970
failure to close file handles
reading memory prior to buffer on error
loop variable integer overflow on error
Change-Id: I2893c34cd041d085fd7f56a88cb4cb14131cea11
