1. bulk scan begins transaction, locking the db
2. cache regeneration is triggered, but waits for db to unlock
3. bulk scan calls cache_artwork_ping, which can't return because cache thread is waiting
-> scan thread is waiting for cache thread, which is waiting for scan thread
update db to v19 removing the file extensions from the stored playlists
An existing file extension in the virtual path leads to wrong entries in
MPDroid (and mpd does also not return the file extension).
encoded/converted. Characters above x7F were replaced by '?' character
although the rfc defines a ISO−8859−1 encoding for descriptive
field-content.
According to rfc2616 the field-content is defined as follows:
<the OCTETs making up the field-value and consisting of either *TEXT or
combinations of token, separators, and quoted-string>
The TEXT rule is only used for descriptive field contents and values
that are not intended to be interpreted by the message parser. Words of
*TEXT MAY contain characters from character sets other than ISO- 8859-1
only when encoded according to the rules of RFC 2047.
In the previous implementation the icy metadata was converted based on
fromcode "ascii".
Following incoming icy header field-values should be encoded as
"ISO−8859−1" before adding them to the metadata structure.
- misc.c unicode_fixup_string enhanced by an additional parameter to
define the fromcode
- misc.h unicode_fixup_string prototype updated
- filescanner.c function fixup_tags updated to stay compatible to the
previous implementation using fromcode "ascii"
- db.c function unicode_fixup_mfi updated to stay compatible to the
previous implementation using fromcode "ascii"
- http.c function metadata_header_get enhanced to encode the header
field-content as "ISO−8859−1" to comply with rfc2616
the current playlist
mpd does not expose a persistent song id, instead the id returned in
playlistinfo is a unique id for the song in the queue. The same song has
different ids if it occurs more than once in the queue.
ejurgensen
chme
stephan-01010011