Rockbox

A) How would Rockbox know which folders do or don't have useful content without scanning your whole drive and identifying if files are music or not?
B) Why not just flag those folders as hidden. In the modes that aren't "Show All" files and folders with the hidden attribute are not shown.

B> I didn't think of that; I'll use that for now.

A> I think the dircache is the ideal place for that, since it does scan the directory tree at boot and updates it whenever a change occurs.

DirCache is a bad idea in my opinion. The goal of DirCache is to offer the exact same view when it's on as when it's off. At the moment DirCache doesn't have to distinguish between files, it just has to create a map of the filetree. So the options are "Have DirCache treat your files differently when it's on, than the normal browser does when it's off" or "Make DirCache have a 'view files option' that you don't have when it's off, and take slightly longer to generate" or "Make browsing take more CPU because folders have to be scanned when entered."

Indeed, this makes dircache less transparent than it used to be.
But it doesn't make it less useful.
If you look at it from a "minimal intrusiveness" point of view (aka maximum reuse, aka maximum laziness), using dircache makes sense.

The patch I'm including:
- is against today's CVS
- has been tested in the simulator only (toolchain not ready yet)
- works with all levels of filtering: all, supported, music, playlists;
- hides directories according to the filter when dircache is enabled;
- should speed up browsing slightly (because file type recognition is moved to boot time)
- should slow down boot time slightly for the same reason

I forgot to add:
- it doesn't support the dircache's dynamic update hooks yet.

Here is a second iteration of the patch.
It uses the dynamic update hooks, has been tested on the real thing, and does not visibly impact startup performance (8s to build the dircache with or without, with playback at startup disabled, for ~5000 entries).
The deep filtering is updated when files are created, moved, or copied; removes have no effect (they do not cause their parents to be filtered), but I don't feel it's a really a problem. It could be solved by storing slightly more info (3 ints instead of an enum) in entries.
I'm happy with that patch, and I'd like to propose it for inclusion.

Implementation details:
the patch adds an enum field to every directory entry, which in case of files contains their filter level (as seen in the "show files" selector or the quick menu), and in case of directories contains a filter level which is greater to each of the children's levels. The filtering done in the file list has been changed to just use this field instead of asking the type. The field has the same lifecycle as the rest of the dircache, which means it is dynamically updated whenever files are renamed, moved, and created. The init sequence has been changed so that the type code is initialised before the dircache.