This is the bug/patch tracker for Rockbox. Click here for more information.
Quick links: Bugs · Patches · Rockbox frontpage
FS#12474 - [PATCH] Database: Support for multiple search roots.
Attached to Project:
Rockbox
Opened by Thomas Martitz (kugel.) - Wednesday, 21 December 2011, 20:52 GMT+2
Opened by Thomas Martitz (kugel.) - Wednesday, 21 December 2011, 20:52 GMT+2
|
DetailsThe setting works similar to the autoresume dirs: Directories are seperated
by colon, e.g. "/Music:/Podcasts". Default is "/sdcard" on android, "/" on all other targets. A maximum of 8 dirs can be selected, the setting cannot be longer than 80 chars. Note: There's one problem. If you specifiy "/Music:/" (or any folder and one if its parents afterwards), then /Music is scanned twice. It's tricky to fix, and I'm not sure if it's worth it. This does not happen for "/:/Music" as it can be detected more easily in this order (and this is already implemented). |
This task depends upon
Last thing thats needed on the ui side is to fix skin lists to do indenting (not trivial so too hard for my current extremely overtired state)
Which of my tagcache.c changes are you refering to? You seem to have added some which need cleaning up (the if (ignore) closedir()..., and #if 0 stuff).
A few other remarks:
a) IMO the search roots shouldn't be a separate file. It's a setting after all.
b) Shouldn't your new fancy UI be more generic and not a tagcache specific file (going by the file name)?
c) fast_readline looks wrong buggy. The callback is not called for every line, but for the first one of each read (the size of which depends on the buffer passed to it).
I haven't actually tested yet, just looked at the diff. Will try out later
b) deal with that later if anything else wants to use it
c) ?
ah, maybe i didnt merge our ptches cleanly, I'll go through it again if you say those changes arent yours.
b) should be easy enough to do now. The tagcache specific part can move to tagcache.c. Isn't that only one function anyway, the rest being completely generic? My fear is that nothing is going to want to use it because it's quite hidden behind a file name that suggests being quite tagcache-specific (devs just don't notice).
c): The fast_readline() function looks bogus to me, as if the callback isn't actually called for each line of the file. It's one call to the callback per read(). One read() can get multiple lines at once, though.
b) meh, nothing will use it because nothing else needs to really. if someone wants to split it later they can
c) I honestly have no idea what you're saying, if fast_readling() is broken its not new in this patch.
b) I'm sure autoresume wants it
c) yes, not new in this patch. It just looks wrong to me unrelated of this patch.