| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
| |
commands should really not behave differently if they're issued
inside a command list or not; so stop having special handler
functions to deal with them. "update" was the only command
that used this functionality and I changed that in the last
commit to serialize access.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Now the "update" command can be issued multiple times regardless
of whether the client is in list mode or not.
We serialize the update tasks to prevent updates from trampling
over each other and will spawn another update task
once the current one is finished updating and reaped.
Right now we cap the queue size to 32 which is probably enough (I
bet most people usually run update with no argument anyways);
but we can make it grow/shrink dynamically if needed. There'll
still be a hard-coded limit to prevent DoS attacks, though.
|
|
|
|
|
| |
It'll be easier to keep track of what code runs in what
task/thread this way.
|
|
|
|
|
| |
Instead of relying on the shortname, just pass the song pointer
to prevent redundant lookups during deletes.
|
|
|
|
|
|
|
| |
We already sanitize and duplicated our paths before calling
updateInit() to get pre-pthread_create() error-checking along
with heap allocation reduction because we don't have to redupe
because our parent stack went away.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Remove yet another use of our old malloc-happy linked list
implementation and replace it with a simple array of strings.
This also implements more eager error handling of invalid
paths (still centralized in updateInit) so we can filter out
bad paths before we spawn a thread.
This also does its part to fix the "update" command inside list mode
which lost its static variable in
ada24f9a921ff95d874195acf253b5a9dd12213d (although it was broken and
requires the fix in 769939b62f7557f8e7c483223d68a8b39af43e37, too).
|
|
|
|
|
| |
Move error reporting to command.c so directory.c does not deal
with client error handling any more.
|
|
|
|
| |
Improving the signal to noise ratio...
|
|
|
|
|
| |
If a write failed, it's a good sign subsequent writes will fail,
too, so propgate errors all the way up the stack.
|
|
|
|
| |
A long time ago in an mpd far away...
|
|
|
|
|
| |
MPD has supported more audio formats than just MP3
for over five years...
|
|
|
|
| |
We don't change the song pointer there, either.
|
|
|
|
| |
We don't modify the Song when we delete it
|
|
|
|
|
|
| |
It was a huge confusing mess of parameter passing around
and around. Add a few extra assertions to ensure we're
handling parent/child relationships properly.
|
|
|
|
|
|
|
| |
This is like basename(3) but with predictable semantics independent
of C library or build options used. This is also much more strict
and does not account for trailing slashes (mpd should never deal with
trailing slashes on internal functions).
|
|
|
|
|
| |
We no longer fork for directory updates, so we
no longer have children to reap.
|
|
|
|
|
| |
Small memory reduction compared to songvec since most users have
much fewer dirs than songs, but still nice to have.
|
|
|
|
| |
We no longer for for updates
|
|
|
|
|
| |
"free" implies the songvec structure itself is freed,
which is not the case.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
If we updated the mpd metadata database; then there's a chance
some of those songs in the playlist will have updated metadata.
So be on the safe side and increment the playlist version number
if _any_ song changed (this is how all released versions of mpd
did it, too).
This bug was introduced recently when making "update" threaded.
Thanks to stonecrest for the bug report.
|
|
|
|
|
|
|
|
|
|
| |
We forgot to update the playlist.queued marker if
playlist.current changed.
Additionally, if the queue cleared in any other mode,
attempt to requeue (as it's a harmless no-op otherwise).
Thanks to stonecrest for the bug report.
|
|
|
|
|
| |
If repeat is off, we reset (and reshuffle in random mode)
the playlist.
|
|
|
|
|
|
| |
Fix this regression introduced in the core rewrite so that we
now skip to the next song when we encounter an error with the
song we tried to decode.
|
|
|
|
|
|
| |
* spaces => tabs
* long lines wrapped
* trailing whitespace killed
|
| |
|
| |
|
|
|
|
| |
SongList has been superseded by struct songvec.
|
| |
|
|
|
|
|
|
| |
With patch 8d2830b3, I broke "addid": it did not return the id of the
new song, because of a typo in the return condition (== instead of
!=).
|
|
|
|
|
| |
Add information about the M4 macro dir ./m4/ to both configure.ac and
Makefile.am.
|
|
|
|
|
|
|
|
| |
This reverts commit efefaee1f9535012be2fbfea8f0f870904daad5d.
Conflicts:
src/directory.c
|
|
|
|
| |
Potentially broken free() implementations don't like it
|
| |
|
|
|
|
|
| |
Use freeList() instead of free() to free all elements in
the list.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It's possible the playlist will be accessing a song that is to
be freed in the update thread. Rather than going through the
complexity (and potential to make mistakes) of locking the
playlist (as well as losing CPU cycles/pipelining due to
barriers with mutexes), we'll just line up all songs to
be freed in the main thread.
It's relatively uncommon to call freeSong() heavily (as it is to
update); so the extra, temporary memory usage won't be very
noticeable.
Additionally, if a song is renamed and it contains unique tag
item; this has the additional side effect of preventing
unnecessary fragmentation where an item is freed and shortly
reallocated.
|
|
|
|
| |
The umask calls were remants of when we used fopen().
|
|
|
|
| |
open(2) should only interrupt on "slow" devices, afaik...
|
| |
|
|\
| |
| |
| |
| |
| |
| | |
* ew/directory:
songvec: remove songvec_prune
directory: update do its work inside a thread
directory: use enum update_return for return values
|
| |
| |
| |
| |
| |
| | |
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.
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
A lot of the preparation was needed (and done in previous
months) in making update thread-safe, but here it is.
This was the first thing I made work inside a thread when I
started mpd-uclinux many years ago, and also the last thing I've
done in mainline mpd to work inside a thread, go figure.
|
| |
| |
| |
| | |
This way we avoid having to document -1, 0, 1
|
|\|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
* ew/directory:
Don't try to prune unless we're updating
workaround race condition on updates with broken signal blocking
Replace SongList with struct songvec
directory: remove unused updateMp3Directory() function
start using prefixcmp()
Add prefixcmp() (stol^H^H^H^Hborrowed from git)
|
| |
| |
| |
| |
| |
| | |
Pruning is very expensive and we won't need it in the future
anyways. This brings startup back to previous speeds (before
songvec changes).
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
pthreads with our existing signal blocking/handling is broken,
for now just sleep a bit in the child to prevent the CHLD handler
from being called too early. Also, improve error reporting when
handling SIGCHLD by storing the status to be called in the main
task (which can be logged, since we can't do logging inside the
sig handler).
|
| |
| |
| |
| |
| |
| |
| | |
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).
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
It hasn't been used in many years
commit 3a89afdd80f228139554372a83a9d74486acf691
Author: Warren Dukes <warren.dukes@gmail.com>
Date: Sat Nov 20 20:28:32 2004 +0000
remove --update-db option
(SVN r2719)
|
| |
| |
| |
| |
| | |
LOC reduction and less noise makes things easier for
tired old folks to follow.
|
| |
| |
| |
| |
| |
| |
| | |
This allows us to avoid the nasty repetition in strncmp(foo,
bar, strlen(foo)). We'll miss out on the compiler optimizing
strlen() into sizeof() - 1 for string literals for this; but we
don't use this it for performance-critical functions anyways...
|