| Commit message (Collapse) | Author | Files | Lines |
|---|
|
Sorting songs by file name does not make much sense. Most of the
time, users want to add songs in track order to the playlist.
|
|
Path names in the directory and song structs are always encoded in
UTF-8. Don't use strcmp(), it cannot handle UTF-8 characters
properly. Use GLib's UTF-8 aware g_utf8_collate() function for that.
|
|
|
|
|
|
|
|
{song,dir}vec_for_each each failed to gracefully handle deleted
files when iterating through. While we were thread-safe, we
were not safe within the calling thread. If a callback we
passed caused sv->nr to shring, our index would still increment;
causing files to stay in the database.
A way to test this is to remove 10 or so contiguous songs from a
>10 song directory.
|
|
We definitely don't modify them here.
|
|
Found by Valgrind while looking for another bug...
Hmm.. I should really just make this code generic since
they're duplicated...
|
|
We only need to lock sv->nr changes to prevent traversals ( why
it's called "nr_lock"). free(3) is a "slow" function on my
system; so we can avoid unnecessarily holding a lock long for
longer than needed.
|
|
When there are standardized headers, use these instead of the bloated
os_compat.h.
|
|
Again, a data type which can be forward-declared.
|
|
Pass const songvec pointers to songvec_find() and songvec_for_each().
|
|
Only one lock is used for all songvec traversals since
they're rarely changed. Also, minimize lock time and
release it before calling iterator functions since they
may block (updateSongInfo => stat/open/seek/read).
This lock only protects songvecs (and all of them) during
traversals; not the individual song structures themselves.
|
|
This is so we can more consistently deal with locking
needed for thread-safety in iterator functions.
|
|
We don't modify the Song when we delete it
|
|
"free" implies the songvec structure itself is freed,
which is not the case.
|
|
Potentially broken free() implementations don't like it
|
|
Any pruned files will be noticed during update and pruned
from the live database, so this inefficient function can
go away and never come back.
|
|
Our linked-list implementation is wasteful and the
SongList isn't modified enough to benefit from being a linked
list. So use a more compact array of song pointers which
saves ~200K on a library with ~9K songs (on x86-32).
|
