• Status Unconfirmed
  • Percent Complete
  • Task Type Bugs
  • Category Drivers
  • Assigned To No-one
  • Operating System iPod 5G
  • Severity Low
  • Priority Very Low
  • Reported Version Release 3.4
  • Due in Version Undecided
  • Due Date Undecided
  • Votes
  • Private
Attached to Project: Rockbox
Opened by rmaniac - 2009-10-22
Last edited by sideral - 2011-05-19

FS#10706 - Tag DB Never Builds

I am running 3.4 on a 5.5G iPod modified with a 240gb drive. Rockbox is stock 3.4 with LBA48 added in and the max sector size turned off. The database was working ok on 3.3. Only issue was it took forever to add new files. After upgrading to 3.4 I noticed every time I powered on rockbox would lock up in the menus for up to 10 minutes before functioning normally. So I completely removed the .rockbox dir (including the database files of course) and re-expanded a fresh copy. I then tried to init the db. It runs until it is around ~44k files and 99% and then just sits there. If left alone it will eventually just turn it self off. When I turn it back on it will ask me to init the db again. I have seen it try to commit once or twice but it never takes. I am not really sure how to debug this at this point. Also in the debug disk info area, it things my drive is 131071MB. Under Rockbox Info it says 223GB which is better, but these two things are the same as in 3.3. All my Oggs are converted via a script I wrote from my flacs. I do not believe my flacs have any art, I am not even sure you can store art in a flac tag and even them I don’t think the ogg encoder is transferring them. I ran a tag dump (ogginfo) against my oggs and do not see anything to do with album art. I had 4 files on the device with album art. They were all in a directory with a database.ignore file. So they should not have been noticed. Just in case I removed that directory and rebuilt. It went though 44k files, commited 1-9 and then went back to “scanning” but the disk activity had stopped. Upon reboot it asked me to init the db again.

This is not a patched build. I simply changed the config to include large drive support. This is an issue that needs to be looked at. Please check into it, I will be happy to test any ideas.

torne commented on 2009-10-22 11:21

This *is* a patched build; you have changed the code. The “config” as you call it is part of the code too. If you expect anyone to look at this (which is not guaranteed), the absolute minimum information needed is the exact changes to the code you have...

Here is all that
HAVE_LBA48 /*#define MAX_PHYS_SECTOR_SIZE 1024*/

Added a define and removed a define. Other than that I did a normal build for a 64mb iPod Video.


torne commented on 2009-10-22 14:56

You realise that removing the define for MAX_PHYS_SECTOR_SIZE doesn’t *remove* the limit, but changes it back to 512, removing all the code which supports drives that need large sector accesses?

Anyway, this is *still* requesting support for a patched build. I’ll leave it up to someone else whether to close it though...

I can try changing that to 4096 but my understanding is this, The MAX_PHYS_SECTOR_SIZE is only needed when a drive is not properly reporting its sector size. (Specifically the 80GB drives in the iPod Video) If I remove it on that drive it will not boot. If I remove it on the 240gb all is well. I do not believe it goes back to 512 because if the sector size is set in rockbox to anything less than 4096 with that variable then the 240gb will fail to boot. Comment from the config:

/* define this if the hard drive uses large physical sectors (ATA-7 feature)
and doesn’t handle them in the drive firmware */

The 240gb seems to handle them in the firmware fine.

torne commented on 2009-10-22 16:28

The hard drive you have in your ipod is happy emulating 512 byte sectors, so that’s fine (and preferred, in fact - it’s better for rockbox to let the drive emulate it than to try and do it itself in the vast majority of cases). It does revert to doing 512 byte sector accesses though, I assure you :) I would expect a drive that supports 512 byte sector accesses to work with any value of MAX_PHYS_SECTOR_SIZE; the fact that it doesn’t is slightly odd. Setting it to something just makes rockbox align all accesses up to the size given, using read-modify-write to emulate 512 byte sector writes: this should work fine on any drive...

Well if someone wants to tell me how to run this without compiling the code myself I am all ears. This used to work ok and I would love to trouble shoot this and get it fixed.

Does this issue still persist?


Available keyboard shortcuts


Task Details

Task Editing