SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2

[matsch]

codecs will write into the log, mostly if not always in error cases (FLAC codec seems to always write the number of decoded frames though)

get no info from logf if Clip MP3 playing stops randomly

EDIT:

from 'View buffering thread' I get PCM 0/176400 if MP3 playing stops. Perhaps this is helpful.

[saratoga]

codecs will write into the log, mostly if not always in error cases (FLAC codec seems to always write the number of decoded frames though)

get no info from logf if Clip MP3 playing stops randomly

EDIT:

from 'View buffering thread' I get PCM 0/176400 if MP3 playing stops. Perhaps this is helpful.

You'll probably have to insert your own debug statements to print things into the log.  Its unlikely someone has already added the correct ones in expectation of deadlock issues on future targets.

[daytona955]

I just posted FS#10308 to flyspay to add some preconfigured frequency configurations to clock-target.h.  As a note, there are 2 configurations which use 32MHz for dbop which will let e200v2 users use their radio for now until we find a better solution. There is a tradeoff there but if you simply must have your radio....

The weird thing is, the performance hit is minimal. I sort of hinted at this:
http://www.rockbox.org/tracker/task/10267#comment30797
For test_codec I get:

DBOP	62M	31M
MP3 VBR5	593%	591%
OGG	551%	549%

The test_disk figures are also broadly similar.
But even stranger is that the test_fps figures are completely identical:

LCD Update
1/1	44.7
1/4	173.5
LCD YUV
1/1	29.5
1/4	113.5

I would have expected the DBOP clock to affect LCD update most...
These figures are from an otherwise unchanged r21234 build. On an e260v2.

[FlynDice]

Okay, it only took me 2days but i finally got the plotting thing to work.  One is SVN before FS#10048(mmu), one is with mmu and 62/31 fastbus only, and finally the winner is 248/62 synchronous bus.

[matsch]

Playing MP3 with r21228 does not work on Clip v1. MP3 files are directly skipped with the message 'codec failure'.

R21207 was OK.

[funman]

please make sure you rebuilt the codecs (make && make zip) and not only rockbox (make bin) and give a try to FS#10309

[helios]

rockbox-r21245 on my Sansa e200v2 with 2 MB flash, no SD card, appears to run fine - after I also upgraded the bootloader. I was not sure whether I had to scramble the bootloader, but since scramble.c was already compiled after making the bootloader and mkamsboot didn't complain I assume it has been scrambled by making the bootloader already.

Well it works. I am able to play a mpeg video now. Video and music are perfectly in sync. jpeg images are rendered way faster at least in my subjective perception. mpeg3, ogg vorbis, flac playback appears to be just fine - it doesn't appear to boost that often anymore. some c64 sid files play, some do not, but that didn't change to previous versions. Well thanks - its getting better all the time. I did not apply FS#10309, so far it appears to work without it or it has been applied meanwhile.

[FlynDice]

well I'm back to having problems with the 8GB sd card.  If I format it it works great for awhile. Then it starts acting up on me until I reformat it again and it works great for awhile and then......   I'm hoping funman's FS#10309 is going to help this but we will see.  Funman is there an easy or intelligent way to check the card after it gets borked up to see what's getting changed on it?  I think I can still access the card on my desktop machine.  I'm pretty sure something on the card is getting altered as rockbox  boots up without any problems once the card gets reformatted.

[matsch]

please make sure you rebuilt the codecs (make && make zip) and not only rockbox (make bin) and give a try to FS#10309

After rebuilding codec and applying patch FS#10309 same result. What is your clip v1 doing?

[funman]

@flyndice : there is nothing to check, if rockbox SD driver is buggy it will randomly write bad data to the card, and could corrupt your files, your filesystem, or both. Perhaps you can run md5sum of known files to see if they changed.

@matsch : my clip works fine (r21245 + fs#10309), did you check your filesystem/reformat before using fs#10309 ?

[werich]

Hello, my testing results are:

my fuze 8GB with 8GBsd finally works with r21245 (with and without fs#10309, actual bootloader, reformatted) before that it froze on startup since FS#10048 was included in SVN. But there seems to be problems with the 4GB barrier?!

Building up the database stops after reading half of the internal songs, always at the same number. SD card sums up to that number with no errors, if inserted. After build DB fails, the filesystem is corrupted.

The player doesn't recognize internal filesystem anymore, if i try to access one song from the second half of the internal memory (its nearly full and newly copied in one rush after reformatting the player). Playing music from first half or sd-card is running fine and speed with FS#10048 is awesome!

[matsch]

@matsch : my clip works fine (r21245 + fs#10309), did you check your filesystem/reformat before using fs#10309 ?

Now I did reformat clip,  install bootloader again, but r21245 + fs#10309 leads to
skipping MP3s and showing 'codec failure' before skipping

[funman]

Thanks to all you

I'll resume my understanding of the current situation:

• The storage driver (internal and µSD) is unreliable since the commit of FS#10048
• FS#10309 doesn't fix this problem

If you think you have a fix for this, here is how to test it :

• Format from the OF
• stress your test, by updating rockbox several times with newer revisions, and using lossless codecs, test_disk .. anything intensive on storage I/O

[matsch]

@matsch : my clip works fine (r21245 + fs#10309), did you check your filesystem/reformat before using fs#10309 ?

Now I did reformat clip,  install bootloader again, but r21245 + fs#10309 leads to
skipping MP3s and showing 'codec failure' before skipping

Sorry, I made a compile error. Now it works with r21245.

[funman]

But there seems to be problems with the 4GB barrier?!

Building up the database stops after reading half of the internal songs, always at the same number. SD card sums up to that number with no errors, if inserted. After build DB fails, the filesystem is corrupted.

The player doesn't recognize internal filesystem anymore, if i try to access one song from the second half of the internal memory (its nearly full and newly copied in one rush after reformatting the player). Playing music from first half or sd-card is running fine and speed with FS#10048 is awesome!

I just committed a potential fix as r21248 : we didn't check if the data transfer used for bank selection succeeded or not. Now it will retry indefinitely until it succeeds, just like normal data transfers.

Can you give it a try ?