Thank You for your continued support and contributions!
I've spent the better part of a week figuring out that the database must be updated manually every time the device is re-autofilled! How did I discover this? From the manual? No. Surprisingly, after searching through the forum on several occasions for '(ERR)', which I was seeing at the front of almost every track in my then-current playlist, I ran across a forum post from 2008 mentioning this fact.
Why isn't enabled Auto Updating for the database the default?
And why isn't the issue of accessing the various context menus described better in the Getting Started chapter of the manual?
Next time just read the manual.
All of this in the first 5 or 6 sentences of the database section.
Most people don't use the database, so its not enabled by default.
Because it has its own section and doesn't really have anything to do with the rest of the stuff in "quick start". If you want to rewrite the manual, you're welcome to do it, but I'm not sure mixing a bunch of random things into the first section really makes sense. IMO if someone wants to know how to use the database, the database section is the obvious place to look.
Why should "context menu" be in "Getting Started?" Not everything can go there, or it would become the whole manual. Specifically, your description is awfully long for describing it. Don't the keymap tables tell you that 'long select' brings you to the context menu, and then searching for context menu tells you further information about it?
Auto-updating the database by default can be a performance penalty even for people who *do* use it: I boot my player up far more often than I change the music on its drive. My entire music collection is on there, so it only changes when I get new stuff...
Have you read the manual? There is already a "Context Menu" section in "Getting Started." I have added 3 or 4 sentences to it.
Also, regarding performance, I get that, but I reboot my player every time I get into my car; it doesn't seem to do anything if there haven't been any changes. Maybe that's all done in the background, and, because I'm talking about my little portables, I do not perceive any performance hits from whatever takes place?
I was asking about this on IRC. Is there some reason we can't fold the database autoupdate into the walk through the FAT done by dircache after a USB unmount? Thats actually fairly quick and can detect deleted and added files. I was thinking this could be done by having the dircache store a hash of each file name in a table when its updated. That way checking if a file has been deleted is just stepping through a table in memory, and the hash only requires about 4 bytes per file in the database which should be affordable on most any target and much smaller then the full dircache. The database scanner then only looks at files that are new to the dircache table.
Doesn't it do something with a similar effect *anyway* if dircache is enabled? I thought it did...
In fact, this mode of creating a playlist isn't even described in the manual section on creating playlists, and it was the only one I could find that let me shuffle the tunes without setting "Shuffle" to On in the playback settings.
Okay, how about something like this small revision to the Context Menu section of Quick Start (this would've given me a clue to how to find the Database Menu in the first place)
Yes but that requires you to enable the entire dircache and store potentially hundreds of KB or even MBs of additional data thats not really needed. I'm suggesting always storing a list of filename hashes produced by dircache, and then discarding the filenames if dircache is disabled. That way the database update doesn't fail on devices were using dircache is impractical or unwanted.
Page created in 0.721 seconds with 64 queries.