Dircache odd behaviour or not?

[baobab68]

A simple question about dircache: I am not sure if what I am seeing is new behaviour or if it was always like this - does dircache normally build the directory cache on every single boot?

I thought on earlier builds that I've used on my iRiver H320, it was somehow built once and then was quite quick to cache on subsequent boots. (I can't for the life of me think how that would be achieved from a technical point of view, but that's the way I remember it!)
What I am seeing on the player on startup is that my music resumes on startup, and according to the debug screens, the directory cache and track buffering seem to compete with each other. I seem to remember it wasn't like that before.

Please tell me I am wrong so I can stop thinking about how I am going to troubleshoot the problem.

I plan to defrag the device - hopefully having all the file allocation table together in one spot will help.

I must admit too, at the highly probable risk of getting flamed, I'm using an unsupported build. I thought it worth posting here in the hopes that responses might enlighten future people having issues with dircache. In case it's relevant, I'm using the build from here:

http://hendrik.feuerware.com/rockbox.htm

I am also slightly suspicious of multifont as I know it uses a lot of RAM (although I am only using one font, so it mightn't matter.

bao

[AlexP]

The way it normally works is that dircache is built on first boot, and then on subsequent boots it scans for updates - rockbox has no way of knowing if you changed anything when off - i.e. you could have added music with the OF etc.

If it is performing the foreground scan on every boot, it shouldn't be.  However, please try with an official build.  Patches can change many things you would not expect.  We have that rule for a reason.

[baobab68]

So the answer is "yes it is meant to work like that?"

Glad to know I'm not imagining that it used to work that way.

From a technical standpoint, is it cached in a file in order to survive reboots? I don't recall a file in \.rockbox that rings a bell re: dircache.

bao

[roolku]

Dircache is built from scratch on every re-boot (unless you have a flashed firmware on h1x0 and it is hibernating in a file). The difference between foreground and background scan is that in the former case it doesn't know the required buffer size so it can't be allocated in advance. In the latter it will use the buffer size from the last foreground scan (+ some extra I think). 'Hibernating' (store cache on disk) can only work if there is no way to alter the disk contents without rockbox knowing and with current targets this can only be guaranteed in the above mentioned case of the h1x0.

Unfortunately there is currently an issue with buffering/concurrent disk access that makes the background building of the dircache have a negative effect on the responsiveness of the DAP at startup. Let's hope it gets resolved quickly.

[AlexP]

Dircache is built from scratch on every re-boot (unless you have a flashed firmware on h1x0 and it is hibernating in a file). The difference between foreground and background scan is that in the former case it doesn't know the required buffer size so it can't be allocated in advance. In the latter it will use the buffer size from the last foreground scan (+ some extra I think).

Aha, cheers for the clarification.

[baobab68]

I'm now running an official build from a couple of days ago, and I can clarify further how the problem appears for me:

- rarely get "Scanning disk" on startup (ie a foreground scan doesn't happen)
- on each startup, I check the dircache stats in the debug menu - about 50% of the time, the cache built itself in under 5 seconds, the other 50% of the time, it takes about 30 seconds. Either way, I now reliably end up with a valid cache, which is good.

I can't find a pattern any more detailed than that at this stage. Every boot is an auto-resume playback. There seems to be no pattern regarding disk write activity, it happens whether I've written to disk or not.

One thing that might be relevant is that I have a desktop cradle for my H320, so on the times when I want to *charge* rather than *connect*, I hold down the REC button, which means "charge only". These days it also means "prepare to start recording". I hold REC, put it in the cradle, then release REC and press stop to exit the recording screen. Maybe this counts as a write, I don't know. Certainly no recorded WAV file ever gets created.

Just putting this info here in case anyone else has the same problem. It does seem similar to these issues from late last year:

http://forums.rockbox.org/index.php?topic=13090.msg98952#msg98952
http://forums.rockbox.org/index.php?topic=13071.0

bao

[squidkidd]

bao,

I definitely know of the issue you're talking about.  I used to have the issue of my 80gb ipod doing a foreground scan upon every other boot.  I think this issue was resolved with the fix that took care of not having to completely rebuild the dircache if the player was turned off before a background scan was complete.

Another issue I had was that it seemed upon every other boot my dircache would turn itself completely off.  From what I can tell this issue has been resolved...to a degree.  Now, instead of dircache just being off, it will start normal functionality only after the background scan has completed.  Half of the time I don't notice this because like you are experiencing, it only takes 5 secs  for dircache to build.  The other half of the time, it takes upwards of, like you, 30 seconds.  In that 30 seconds, I have no dircache functionality.  If I just leave my player alone and let if build, and then start to browse, it works, no problem.  Does this seem to be consistent with what you are experiencing?

Regards,
Brian

[baobab68]

Squidkidd - you got it in a nutshell! That's exactly it.

I don't even mind the 30 seconds as I am still putting in my 'phones anyway, but I would prefer the 5 seconds just from the point of view of saving battery. Get on with dircache and get on with buffering some music and then shut off the disk asap.

I wonder what the issue is? I did once notice that the disk *never* turned off, but at that time I deleted and recreated the database, which appeared to fix it.

[baobab68]

Devs - should we report this as a bug? It sounds a bit like 7253 but it is different enough, I think, to justify a separate bug report.