FS#11965 - Database build problems and filesystem corruption on recent builds

Attached to Project: Rockbox
Opened by Michael Huth (Progweed) - Thursday, 24 February 2011, 09:52 GMT
Last edited by sideral (sideral) - Thursday, 24 March 2011, 12:57 GMT
Task Type Bugs
Category Drivers
Status Closed
Assigned To No-one
Operating System Sansa AMSv2
Severity Medium
Priority Normal
Reported Version Daily build (which?)
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No


Player: Sansa Fuze v2

Observed in r29305, the problem persists in r29387.
After I installed these builds the database wouldn't update past a certain point. I cancelled the database update and checked the file system for errors. Chkdsk reported a few dozen corrupted files inside the .rockbox directory. I fixed these errors and performed a clean install, but the same thing happened again. All files are MP3 with id3v2.3 tags, no embedded album art. An older build (r29128) works fine.

Related forum thread (#13 onwards):
This task depends upon

Closed by  sideral (sideral)
Thursday, 24 March 2011, 12:57 GMT
Reason for closing:  Fixed
Additional comments about closing:  Fixed in r29625/37/38. Thanks for helping debugging this, Progweed!
Comment by Dave Hooper (stripwax) - Thursday, 03 March 2011, 15:45 GMT
Try again using r29476 or newer.
Comment by Michael Huth (Progweed) - Thursday, 03 March 2011, 18:25 GMT
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.
Comment by MichaelGiacomelli (saratoga) - Friday, 04 March 2011, 02:28 GMT
I think r29476 is only for PP, so it probably won't affect the Fuze.
Comment by mcalcerano (mcalcerano) - Friday, 04 March 2011, 08:46 GMT
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
Comment by Stephan Jaensch (Scuppa) - Friday, 04 March 2011, 15:28 GMT
I have a similar problem with Rockbox 3.8 on my Sansa Fuze v2, see forum thread:,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.
Comment by Michael Huth (Progweed) - Sunday, 06 March 2011, 16:47 GMT
I tried r29511 again, turned on metadata logging and found that this is the offending file:

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.
Comment by Andree Buschmann (Buschel) - Tuesday, 08 March 2011, 21:39 GMT
The files seems fine, tested with r29537 sim.
Comment by Michael Huth (Progweed) - Thursday, 10 March 2011, 13:00 GMT
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.
Comment by MichaelGiacomelli (saratoga) - Thursday, 10 March 2011, 17:04 GMT
No, you have to compile them from SVN.
Comment by Michael Huth (Progweed) - Thursday, 10 March 2011, 17:34 GMT
Sure, but I'd like to know what was changed in each revision. Isn't there something like that shows the commits over a longer period, for the last two or three months?
Comment by MichaelGiacomelli (saratoga) - Thursday, 10 March 2011, 17:44 GMT Comment by sideral (sideral) - Thursday, 10 March 2011, 17:47 GMT

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.
Comment by Michael Huth (Progweed) - Thursday, 10 March 2011, 19:02 GMT

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.
Comment by MichaelGiacomelli (saratoga) - Thursday, 10 March 2011, 19:07 GMT
>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.
Comment by Michael Huth (Progweed) - Friday, 11 March 2011, 16:40 GMT
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!
Comment by Michael Sevakis (MikeS) - Monday, 14 March 2011, 18:21 GMT
Anyone experiencing problems should go to "System|Debug (Keep Out!)|View HW Info" and check "[Submodel :]".

Mine says "AMS v2 variant 0".
Comment by Stephan Jaensch (Scuppa) - Monday, 14 March 2011, 19:39 GMT
Mine says "AMSv2 variant 1"
Comment by Michael Huth (Progweed) - Monday, 14 March 2011, 20:14 GMT
"AMSv2 variant 1"
Comment by Eric Boyer (eboyer93) - Thursday, 17 March 2011, 04:32 GMT
Is it because I have variant 0 that it has been fixed for me for awhile now?
Comment by sideral (sideral) - Sunday, 20 March 2011, 21:23 GMT
Could you please try a recent unpatched SVN build? In r29625, funman seems to have fixed the issue that was introduced with r29169.
Comment by Michael Huth (Progweed) - Tuesday, 22 March 2011, 08:52 GMT
r29630: The debug screen displays "Progress 0%" upon generating or updating the database (and stays there)

Moreover, the MicroSD isn't detected.
Comment by sideral (sideral) - Tuesday, 22 March 2011, 23:24 GMT
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?
Comment by Michael Huth (Progweed) - Thursday, 24 March 2011, 12:30 GMT
sideral: I didn't try, but I can happily report that r29638 works flawlessly. Database generation was perhaps a bit slower than usual.