Details

After changes to yesterdays SVN (probably related to r25099) , I've started to receive messages like,

*PANIC*
FTL: Scheduling bank 2 block 6214 for remap!

on my 8GB Nano 2G when I play certain songs, after around 3 seconds into the track. I can't see a link with the songs that are played, but it is the same songs and reproducable. I've had it report bank 1 blocks for remap as well. I'm currently on the r25112 daily build.

Oh well, looks like the performance improvements backfired. (r25099)
I would have rather expected that kind of trouble to show up on writes, not reads, though.
And once again, I can't even reproduce it :-/
Can you have a look in the System => Debug => View HW info screen and tell me the values from the "NAND" section?

I've installed a fresh r25127 (no database, using the default settings, just selected the file directly to play it) and tried both the nandworkaround builds - with no success. The same file returns the same PANIC statement (same bank and block) each time.

Hm, seems to be always the same chip that's causing trouble, maybe we should just adjust some timings for that one... I'll check.
I can't really explain why both of these builds fail though, as the -safe one is basically doing what rockbox used to do before the performance improvements, at least for reading.

It would be awesome to get this sorted. I'm not a programmer or anything, but if there's anything I can do to help (try beta versions etc) I'll be more than glad! I did download the new nandworkaround fix.ipod, Should I perhaps try that for you and post the results?

OK, I finally have an idea what could be going on here... Sadly this will probably mean there won't be fast NAND access for you as your chips just don't support it.
Nevertheless both of those files should work for reading, just not for writing...

Also. when playing a song (64kbps AAC) and then going back to the database window...it shows "searching...160 found PLAY/PAUSe to abort" for about 30 seconds, each time I goto database (even after re-booting from initial database initialization). I'll try loading database to RAM and see if that helps....

Ah ha!! Loading into RAM works perfectly...instant!!

I'll continue testing for the next 30 min before my next client arrives!

I've reverted to r25098, and the same files work correctly. I'm going to clear it all off, start with a fresh SVN head install, and copy it back - but it'll take a bit of time then to find a file that causes the problem.

rdolmat - just a thought, but have those AAC files ever played without cutting out, for you? Your cutting out issue may be unrelated entirely to this NAND issue. I would imagine that, for you, 64kbps MP3s would work just fine. HE-AAC files, in particular, are notoriously CPU-intensive and will cut out on almost all rockbox-support targets - see here http://www.rockbox.org/wiki/CodecPerformanceComparison (and note in particular the first line in the Nano2G table where the 64kbps HE-AAC/M4A codec runs barely above 100% realtime - that file format *WILL* cut out during playback)

Listening to your standard MP3 file. 128kbs. stereo...I was set on shuffle and was clicking through to next song fairly quickly (within 2 seconds of the current song starting, I would click next, next, next trying to get to a good song).