Thanks for your response Mike. Yes, now I see the other places where
dircache.last_size is set to 0, and understand that those are important.
(I probably should have looked at that myself.)

Adding some splashf() I see that dircache.last_size is set to 0 on
shutdown before scanning is finished at the end of build_volumes(),
at dircache.last_size = dircache.size. So how about adding the
dirchache.size != 0 condition there to not update last_size if size is
0? Like this:
https://github.com/dreamlayers/rockbox/commit/d438eb3b9ee9a824e2cac85aaa306c3891694e3a

On 2017-03-08 12:37 PM, Michael Sevakis wrote:
> It could cause issues with dircache not being able to expand itself to
> fit more files. The size is zeroed if it gets overstuffed (more than 3/4
> of the reserved is used) or wasn't able to finish to establish a new set
> point so it can scan later without blocking.
>
> Mike
>
>
> On Monday, February 27, 2017 8:06 PM, Boris Gjenero via rockbox-dev
> <rockbox-dev_at_cool.haxx.se> wrote:
>
>
> Hello everyone,
>
> Since upgrading to a 120 GB hard drive, dircache builds take longer.
> It's a bit annoying to have to wait for them with "Scanning disk..."
> displayed.
>
> It seems this happens because in tree_flush() in apps/tree.c, the saved
> dircache size is updated by "global_status.dircache_size =
> info.last_size;", and info.last_size is not set until the scanning is
> finished. It seems I can get around this by not updating the size if
> info.last_size is zero. This is the change I made:
> https://github.com/dreamlayers/rockbox/commit/a02d64799f16598eb5db9c26a799cb123b7b8f53
>
> Maybe I should have just put that up for review on Gerrit, but I don't
> know enough about dircache to know if there is some potential problem,
> so I'm first asking here.
>
> (This commit is on a personal branch with other modifications, which is
> currently installed on my 5G iPod. It's not based on the latest master
> because I had some responsiveness problems with a newer version.)
>
> Best regards,
> Boris
>
>
Received on 2017-03-09