Directory cache rebuilds for no obvious reason

[pondlife]

If I repeatedly start and immediately shut down my H340, I get similar symptoms.  That is, every OTHER time I start up, I get a "Scanning disk..." splash.

USB is not involved at all.

If I let the player run for awhile before shutting down, this doesn't happen.  So perhaps it's a result of shutting down while the audio is still being buffered?

Whenever I check the dircache status, it's active, and size is well below it's limit (about 1MB, 13829 entries).

pondlife

[Multiplex]

I have similar bahaviour on my H320 - hadn't characterised it in such detail, but it often does a quick re-scan on startup - doesn't take long on 5500 tracks and lots of other things to deal with to look into it.

I did wonder if it was down the using USB for charging triggering the "USB used, must check the disk logic"

Will pay more attention...

[LambdaCalculus]

I'm also seeing this as well on my 5.5G iPod video. If I stop an audio track while it's playing, then shut down the iPod, it gives me the "Scanning disk..." splash on startup.

My stats are:

Files: 15323
Music: 4254
Dirs: 569
Max files in Dir: 621

I do get "Scanning disk..." when I start up after having transferred files to my iPod, but it's strange seeing it when I start it up when I haven't used USB.

[Lear]

Actually, the directory cache rebuilds on every boot (unless you run Rockbox from flash on a H1x0, I think, in which case it is loaded from a file).

However, it should normally be done in the background, without  a "Scanning disk..." splash. I've no idea why it would do it on every other boot though. Once it has done a proper scan, it should ideally only happen again if you add a "large enough" number of files, so that certain buffer allocations aren't enough any more. Or that's at least how I've understood it.

Sounds like you should make a test build with a few splashes in init_dircache (main.c) and dircache_build (dircache.c) to figure out what is going on.

[AlexP]

I believe it will do a full rescan on boot if you interupt a background scan on the previous boot.  Therefore you get:

Boot 1)  Starts a background scan, you shut it down before it has finished.

Boot 2)  Previous boot had interupted background scan, so do foreground scan

Boot 3)  Previous boot did full foreground scan, therefore start background scan, you shut it down before it has finished.

Boot 4)  Previous boot had interupted background scan, so do foreground scan

and so on.

I don't know whether the behaviour of doing a full foreground scan on next boot if previous boot background scan did not complete is a bug or not, but that is what seems to happen.

[psycho_maniac]

yes my ipod also does this but directory cache is always completed and no sound is being played meaning i stop a playlist and when i start it up i have it to start in the menu. i get a scanning disk... or a loading... pop up at the begining of every OTHER boot.

[Lear]

Indeed, that would trigger this behavior. Interrupting a background scan shouldn't force a full rebuild on next boot, IMO, but that happens due to the code in tree_flush (tree.c). It should probably make sure that the dircache isn't initializing before updating global_status.dircache_size (it will be set to 0 in that case)...

Just stopping a track and then shutting down (after dircache scanning is complete) shouldn't trigger it though.

psycho_maniac, it sounds like you don't do a proper shutdown, but rather a forced reset or shutdown. Could that be the case? A proper shutdown comes from a long press on play, from what I can see in the manual.

[pixelma]

Maybe the problem here is that Ipods stop playback and shut down with a long press of play, meaning that if you keep holding play from the WPS it will shut down while dircache hasn't finished writing the changes (or whatever it does) yet? There was a short discussion about it in IRC yesterday and this leads me to the question if the same happens if you first stop playback, let it return to the browser or menu (leave it for a few seconds) and then turn the Ipod off?

[(:@)]

It's not a ipod specific problem: pondlife and Multiplex have it on their H320 (first 2 posts) and I also have this "scanning disk" message on my h100 from time to time (without usb usage meanwhile).

I don't think it has something to do with an interrupted scan.
I can let my player run for a while and shut it down without deleting or modifying any files or connected it the pc and the next time I turn it on this message appears.
I cannot say why or if it will popup on the next boot. The message popup doesn't bother me, but it indicates a bug.

[AlexP]

I never get it on my H140 if I let disk activity stop after booting before shuting down.

[Multiplex]

Loking at the recent comits it seems that there may have been an issue that has been looked at - must do an update (except that I let my player at work ...)

"Don't get the dircache size while dircache is still initializing. If done during shutdown, it will force a foreground scan on next boot. "

[Lear]

Just updated and it seems to have completely stopped all of the seemingly unnecessary scans, and it has also fixed my broken dircache discussed here:
http://forums.rockbox.org/index.php?topic=13071.0

That's strange. The problem there, at least the one reported by psycho_maniac, should be unrelated to the recent fix... It should only make a difference if you shut down before the background scan has finished. I'd imagine this isn't the normal usage pattern - unless the scanning takes a very long time for some reason.

Oh well, good to know it improved things, even if I don't quite understand why.

[Llorean]

On 80gb iPods, I believe disk access may still be "slow" while the player's active (resume playback, for example) which might result in long rescans.

As well, many people "testing" this bug would turn on their player, check, turn off, turn on, check, to see the "every other" thing happen. And of course, since the foreground scan wasn't interrupted, it would finish.

[squidkidd]

Well, not only have I yet to get a "scanning disk" since the update, but I have yet to have dircache be reported as "dircache initialized: No" when it should be yes, as it previously would do.  Perhaps when rockbox was previously shutdown before a background scan could be completed, it would not work period upon next boot?

Regards,
Brian

EDIT:

Ok, seems Lear was right.  I take back what I said about it fixing the other problem as well.  After some practical use, I discovered that still on about every other boot, dircache becomes disabled (see http://forums.rockbox.org/index.php?topic=13071.0).  If I turn the player on and off repeatedly, Rockbox will not scan disk, which is good.  This is a result of the fix where if you turn the player off before it has time to build the dircache, it will not do a foreground scan on next boot.  There is still some bug I guess causing dircache to disable, which may or may not have something to do the number of files on the player.