Hi,

I've noticed that responsiveness when resuming tracks have been
noticeably worse in some cases between the Jan 18 and Jan 19 builds, at
least on my Sansa e200.

To reproduce, resume some ways into a long Vorbis file, say about 40
minutes in a 50-60 min file, at least 20 MB large (and additional files
buffered after it). Immediately on resuming, search back about 30
seconds in the file (to catch up).

With the Jan 18 build, the time it takes for playback to start at the
new position after releasing the rewind button is 2-3 seconds, which is
fine (seeking in Vorbis files is a little slow). With the Jan 19 build,
this takes 10-15 seconds, sometimes a little more.

Another strange thing, which also seem to have started in the Jan 19
build, is that when you start (or resume) playing a playlist (could be
an auto playlist for a directory), the WPS first shows a playlist index
of 1, as expected. After a little while of buffering, this changes to 2,
while still playing track 1...

Are mutexes behaving significantly different from spinlocks, or what is
going on here? :) Even though the strip_extension changes can cause
buffer overflows in albumart.c, I'm pretty sure that isn't the problem here.

   Magnus
Received on 2008-01-23