Rockbox General > Rockbox General Discussion
Why Isn't Database Auto Update The Default?...
torne:
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...
jrredho:
--- Quote from: Llorean on September 03, 2010, 05:00:07 PM ---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?
--- End quote ---
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?
By the way, no one has yet answered my question... :)
cheers,
john
saratoga:
--- Quote from: torne on September 03, 2010, 05:23:52 PM ---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...
--- End quote ---
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.
Llorean:
--- Quote from: jrredho on September 03, 2010, 06:44:16 PM ---Have you read the manual? There is already a "Context Menu" section in "Getting Started." I have added 3 or 4 sentences to it.
--- End quote ---
Maybe you should bold the sentences you suggest adding. In my opinion, the vast majority of that could be left out of "Getting started" and it could be summarized with "By holding (button) on an item in a list, or in the WPS, you can usually access the context menu which allows you to choose from a selection of context-specific options relating to the highlighted item or the current screen such as copying a selected file or adjusting playback options from the WPS. The full list of these options and what they do is described later in the manual within the appropriate subsection."
--- Quote ---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?
--- End quote ---
The fact remains though that you aren't the only user, and you either have to ask "everyone who doesn't want it, wait the extra time on first boot for it to initialize, then turn it off" or "everyone who does want it, turn it on." Opting in is often considered "better" for things that like this in a lot of cases.
torne:
--- Quote from: saratoga on September 03, 2010, 06:55:12 PM ---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.
--- End quote ---
Doesn't it do something with a similar effect *anyway* if dircache is enabled? I thought it did... ;)
You'd still need to do it on boot as well, though, since the disk might've been modified externally.
also, jjredho: yes it's done in the background but this steals disk bandwidth and CPU time from the processes of building the dircache and buffering a playlist to be played...
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version