212e7808d5
As well as using an index, which breaks when a file is added or removed, use the crc32 of the filename. When the crc32 check passes the index is used directly. When it fails, the slow path is taken checking each file name in the playlist until the right crc is found. If that fails the playlist is started from the beginning. See http://www.rockbox.org/tracker/6411 Bump plugin API and nvram version numbers Change-Id: I156f61a9f1ac428b4a682bc680379cb6b60b1b10 Reviewed-on: http://gerrit.rockbox.org/372 Tested-by: Jonathan Gordon <rockbox@jdgordon.info> Reviewed-by: Jonathan Gordon <rockbox@jdgordon.info>
42 lines
1.9 KiB
Text
42 lines
1.9 KiB
Text
This is a list of known "issues" in the current Rockbox.
|
|
|
|
These are flaws/bugs we know of that are not likely to be fixed within a
|
|
reasonable time so we list them here and close the bug tracker entries for
|
|
them.
|
|
|
|
FS#894 - When the complete playlist fits in the mpeg buffer, and the playlist
|
|
is played multiple times, the tracks are reloaded from disk multiple times
|
|
instead of loaded only once.
|
|
|
|
FS#2147 - It's a bug in the MAS. It starts bitshifting data on occasion. High
|
|
load on the MAS makes this behaviour more likely (high recording level, high
|
|
quality setting, high sample rate). It's impossible to avoid, but there are
|
|
plans to implement a recording 'framewalker' that checks recorded data and
|
|
restarts recording when the MAS starts delivering bitshifted data.
|
|
|
|
FS#4937 - A constant rhythmic ticking noise occurs in the right
|
|
channel. Believed to be related to our slow I2C implementation, and occurs
|
|
when the battery status and/or realtime clock are updated (the battery is
|
|
read at up-to 2.5hz and the clock at up-to 1hz). Nothing is going to change
|
|
with it until someone spends a lot of time analyzing the portalplayer's I2C
|
|
control registers, or finds a datasheet for the damned thing.
|
|
|
|
FS#5796 - Early encoders such as this one employed a floor of type '0', as
|
|
opposed to the more efficient/cheaper floor type '1' which has been used in
|
|
all encoders from libvorbis 1.0 onwards, I believe.
|
|
|
|
The problem appears to be that most DAP decoders can only handle a floor of
|
|
type '1'.
|
|
|
|
While floor '0' type files like mine are, it turns out, pretty rare, they
|
|
still conform to the standards, as can be seen in the documention linked
|
|
below:
|
|
|
|
http://www.xiph.org/vorbis/doc/Vorbis_I_spec.pdf
|
|
|
|
which specifically states that "Floor 0 is not to be considered
|
|
deprecated..."
|
|
|
|
Files like these require quite a bit of memory to decode, more than what
|
|
Rockbox has set aside for the purpose. Adding a real malloc for the codecs
|
|
might help...
|