Support and General Use > Audio Playback, Database and Playlists

Dealing With Long Database Delays

<< < (2/5) > >>

Bilgus:
see when I disable dircache my clipzip runs like dog crap

I think better would be to implement incremental loading so you get into the menu and only rebuffer a screen or two at a time

but just storing the results (when possible) so when you return to the screen you don't have to wait again would be enough for me

Bilgus:

--- Quote ---dircache+db_cache enabled: 1m 30s (!)
--- End quote ---
i'd say this needs investigated they are probably fighting each other

chris_s:

--- Quote from: Bilgus on January 17, 2023, 01:45:02 AM ---
--- Quote ---dircache+db_cache enabled: 1m 30s (!)
--- End quote ---
i'd say this needs investigated they are probably fighting each other

--- End quote ---
yeah, maybe. This is what causes the additional delay: https://github.com/Rockbox/rockbox/blob/aae34b2e7faead258e99e42bd199b329475eb17c/apps/tagcache.c#L4414

There's already a dircache_wait() before that though.

iPodVT:
I did have Load to RAM turned on.  But I did not have Directory Cache turned on, so I turned it on, rebooted and timed the processes again:  Database->Track still took about a minute, as did returning to that Track list from the WPS.

Bilgus:

--- Quote from: chris_s on January 17, 2023, 02:48:39 AM ---yeah, maybe. This is what causes the additional delay: ...

There's already a dircache_wait() before that though.

--- End quote ---

yeah I was looking at that last night it looks to only be checking for deleted entries maybe we could move that out get the list up and check for validity once the user selects it if the scan isn't finished in a separate thread

@chris_s whats it do if you just disable the dircache part with #if 0
and let it use file_exists()?

Navigation

[0] Message Index

[#] Next page

[*] Previous page