| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
| |
Since flacSendChunk() is a trivial function and is only used in one
location, move the code there. The advantage is that calling
decoder_data() directly returns the decoder_command value, so we can
eliminate one decoder_get_command() call.
[ew: using the terser API in the main branch, it always
eliminated the dc_intr()/dc_seek() call, but I agree that
killing a camel, err.. camelCase function is a good thing]
|
|
|
|
|
|
|
|
| |
Support for bit rates except 16 bits (and 8 bits on little endian) has
always been broken. Since we added optimized functions for 8, 16,
24/32 bits, we can remove the generic flac_convert() function.
Instead of removing it, convert it to a wrapper function for
flac_convert_*().
|
|
|
|
|
| |
Same optimization for 8 and 32 bit files, like the previous patch for
16 bit. Along the way, this patch adds 24 bit FLAC support!
|
|
|
|
|
|
| |
flac_convert_16() runs a lot faster than the generic (and quite buggy)
function flac_convert(). flac_convert_16() is only used for
non-stereo files, since there is already flac_convert_stereo16().
|
|
|
|
|
|
| |
By mistake, I casted the sample value to uint16_t, which is wrong.
This patch simplifies the code by using a int16_t pointer instead of
casting to int16_t* every time.
|
|
|
|
|
|
|
| |
There is still a lot of duplicated code in flac_plugin.c and
oggflac_plugin.c. Move code from flac_plugin.c to _flac_common.c, and
use the new function flac_common_write() also in oggflac_plugin.c,
porting lots of optimizations over to it.
|
|
|
|
|
| |
The previous patch on this topic was incomplete: it still added
data->chunk_length when calling flac_convert(). Remove this, too.
|
|
|
|
|
|
|
|
|
|
|
|
| |
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...
|
| |
| |
| |
| | |
Respect the user's umask (and the number of the beast!)
|
| | |
|
|/
|
|
| |
Noticed-by: Courtney Cavin
|
|
|
|
|
|
|
|
|
| |
I have serious trust issues when using stdio to write to the FS.
So it's best to clean this code out so I can start figuring out
what's wrong with Rasi's box not updating...
None of these writes take place in a performance-critical
setting anyways...
|
| |
|
|
|
|
|
|
|
| |
This should save a few thousand ops. Not worth it to malloc
for such a small (3-words on 32-bit ARM and x86) structures.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
|
| |
|
|
|
|
|
|
|
| |
The function decodeFirstFrame() allocates memory based on data from
the mp3 header. This can make the buffer size allocation overflow, or
lead to a DoS attack with a very large buffer. Cap this buffer at 8
million frames, which should really be enough for reasonable files.
|
|
|
|
|
|
| |
The assertion on "!client_is_expired(client)" was wrong, because
writing the command response may cause the client to become expired.
Replace that assertion with a check.
|
|
|
|
|
|
|
|
|
|
| |
A crafted mp4 file could cause an integer overflow in mp4_decode
function in src/inputPlugins/mp4_plugin.c. mp4ff_num_samples()
function returns some tainted value. sizeof(float) * numSamples is an
integer overflow operation if numSamples is too huge, so xmalloc will
allocate a small memory region. I constructe a mp4 file, and use
faad2 to open the file. mp4ff_num_samples() returns -1. So I think mpd
bears from the same problem.
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
* mk/client-merge: (49 commits)
client: shorten names of the struct client variables
client: simplified client_read()
client: client_input_received() returns 0
client: check for COMMAND_RETURN_CLOSE
client: renamed local variable "selret" to "ret"
client: moved CLOSE/KILL check after client_process_line()
client: don't check FD_ISSET(client->fd) on expired client
client: removed assert(client->fd)>=0
fix -Wcast-qual -Wwrite-strings warnings
playlist: return -1 after assert(0)
command: concatenate strings at compile time
audio: don't pass "fd" to {en,dis}ableAudioDevice()
volume: don't pass "fd" to changeVolumeLevel()
directory: printDirectoryInfo() does not call commandError()
directory: don't pass fd to traverseAllIn()
directory: don't pass fd to traverseAllIn() callbacks
playlist: PlaylistInfo() does not call commandError()
playlist: don't pass "fd" to storedPlaylist.c functions
playlist: don't pass "fd" to playlist.c functions
playlist: showPlaylist() and shufflePlaylist() cannot fail
...
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Seeing the token "client" repeatedly in the same blocks of code
adds to mental fatigue and makes it harder to follow code
because there's fewer unique tokens to distinguish.
"cl" is unique within mpd and conveys enough information
to be useful to anybody reading the code.
|
| |
| |
| |
| | |
Remove one comparison by changing branch order.
|