Rockbox

Try again using r29476 or newer.

I checked out r29511 and the bug is still there. Almost all files in .rockbox are damaged.

Can I do something to help and narrow down the cause of this bug? I suppose posting the metadata log isn’t that helpful as all my files seem to be tagged correctly and older builds work without problems. I reverted back to r29128.

I think r29476 is only for PP, so it probably won't affect the Fuze.

I'm experiencing the same problem:

After I installed these builds the database wouldn't update past a certain point.

Sansa Fuze v2.
Rockbox 3.8

I have a similar problem with Rockbox 3.8 on my Sansa Fuze v2, see forum thread: http://forums.rockbox.org/index.php/topic,27335.0.html

I get whitescreens saying '*PANIC* Updating reserved FAT entry' or '*PANIC* Updating size on empty dir entry'.

Chkdsk find multiple errors in the .rockbox directory, after complete re-install the problem persists.

No such problem with Rockbox 3.7.

I tried r29511 again, turned on metadata logging and found that this is the offending file:

http://www.mediafire.com/?76ei0xwou83duel

Other things I noticed:
* foobar’s integrity checker does not show any warnings
* I can’t enable dircache any longer, it’s always turned off after a reset.

The files seems fine, tested with r29537 sim.

r29554 doesn't work as well.

I'd like to try out several older builds to find the revision that introduced this bug. It there an overview of commits older than 4 weeks? I think that would help me a lot.

No, you have to compile them from SVN.

Sure, but I'd like to know what was changed in each revision. Isn't there something like http://www.rockbox.org/since-4weeks.html that shows the commits over a longer period, for the last two or three months?

Oh sorry, yes, theres http://www.rockbox.org/since-3.7.html

Progweed,

Thanks for trying to isolate the bug!

I assume you have already tried the more obvious ideas, such as repairing the filesystem with chkdsk / fsck.vfat, and deleting and regenerating the database (/.rockbox/database_*.*). (Please take a backup of the database files to be able to reproduce the bug in case removing the files takes care of the issue.)

The best overview of what has been committed since r29128 would be to look at the output of “svn log” or “git log”. If you use Git, you can do a tool-assisted bisect of the range of suspicious revisions with “git bisect”. This (or a manual bisect) should get you to the offending commit with trying about 10 revisions.

The “Updating reserved FAT entry” panic doesn't look like the problem originates from the database. It may just be that the database code crashes first because of something else going wrong. The database update usually is the first major computation that occurs after booting up.

Out of a whim, may I ask you to revert r29169? This change has caused media errors for me on another AMSv2 platform; see  FS#12001 , which also has a patch to revert it.

Thanks!

Yes, I already tried these more obvious ideas. The filesystem is okay, but becomes quite heavily corrupted during the database build process. It's impossible to even boot Rockbox after that.

I'll try the patch to see if it cures the problem.

>The filesystem is okay, but becomes quite heavily corrupted during the database build process. It's impossible to even boot Rockbox after that.

If this bug is happens everytime, a binary search might be the fastest way to find the broken revision. Theres maybe ~1000 revisions to check, so thats ~10 builds to compile and test.

Well, that went exceptionally smooth!

sideral, you were right:
I compiled r29567 and applied the patch. No database hiccups and no filesystem corruption so far.

Thank you very much!

Anyone experiencing problems should go to "System|Debug (Keep Out!)|View HW Info" and check "[Submodel :]".

Mine says "AMS v2 variant 0".

Mine says "AMSv2 variant 1"

"AMSv2 variant 1"

Is it because I have variant 0 that it has been fixed for me for awhile now?

Could you please try a recent unpatched SVN build? In r29625, funman seems to have fixed the issue that was introduced with r29169.

r29630: The debug screen displays "Progress 0%" upon generating or updating the database (and stays there)

Moreover, the MicroSD isn't detected.

Hi Progweed, that's unfortunate. :-(

Can the SD card be detected if removed and reinserted while Rockbox is running? This is a known issue tracked as  FS#11870 .

Can the DB generaion complete in case the SD card is detected after reinsertion?

sideral: I didn't try, but I can happily report that r29638 works flawlessly. Database generation was perhaps a bit slower than usual.