Why Isn't Database Auto Update The Default?...

[jrredho]

Hey All,

I have four old refurbed Sansa e200's (2, 4, 6 and 8gig).  Up until now, due to their inability to grok m4a, I've always hated loading new music onto them because it took hours to do it due to time required to translate m4a to mp3; I use autofill within Winamp to do that loading.
Then I encountered Rockbox v3.6.

Now, I want to say that Rockbox is a kick-ass alternative.  For one thing, I don't have to translate the m4a files anymore; this cuts my autofill time from several hours to approx 45 minutes for my 8G player; for another, the flexibility of the application is astounding.  But, as Uncle Ben would say, "With great power comes great responsibility."  Boy, did he ever get that right! 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.

Okay, you might say, once you learned that, what was the problem: Just go to the appropriate place and do that update.  In fact, from reading the manual, I found that there was a thing called a "Database Menu", but there is no mention, as far as I can tell, anywhere in the entire manual regarding how to access this menu (I learned this from a forum post).  Not only that, I learned from looking through my player, that the option "Auto Update" was not set to "Yes", and from the manual that an auxiliary setting (Settings → General Settings → System → Disk → Directory Cache) needed to be enabled to make auto updating possible.

Wow...

I really want to apologize for such a long-winded context set: I love all the things that all of you contributors have put together; Rockbox is an amazing product with amazingly talented personnel who are responsible for developing and maintaining it.  And I *know* that it's free!  But this weeklong experience has left me with the following simple questions: 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?  These few little tweaks would make life so much easier for those of us out there considering switching to Rockbox, and thus make fewer folks, perhaps like me, i.e. knuckleheads, decide not to take the plunge due to the high initial learning curve.

Thanks for your patience in letting me vent...

all the best,
john

[saratoga]

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.

Next time just read the manual.  All of this in the first 5 or 6 sentences of the database section.

Why isn't enabled Auto Updating for the database the default?

Most people don't use the database, so its not enabled by default.  I think the auto update also has issues on some players.  I can't really remember what the reason is though.

  And why isn't the issue of accessing the various context menus described better in the Getting Started chapter of the manual? 

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.

[[Saint]]

The manual is also lying about needing Directory Cache enabled for Auto Update to function.
But, you weren't to know that, nor did I until I questioned it on IRC.
However, now you know


[St.]

[jrredho]

Dear Saratoga,

Thanks for taking the time to respond to my long post.

Next time just read the manual.

Part of the point of my post was to provide constructive criticism to make your product more accessible.  I'm saying that having to read an entire 200+ page manual prior to using a product is too steep a price to pay for the non-robust prospective user. 

Regardless, and as I stated in my OP, I *read* a significant portion of the manual, and what I'm saying is the manual: (1) Isn't crystal clear in describing what a "context menu" is and how to access some of them, and (2) Is incomplete or even incorrect on some of things that relate to the software.

All of this in the first 5 or 6 sentences of the database section.

As far as I've been able to divine, none of what I experienced was described in the first 5 or 6 sentences of the database section.

Specifically, I encountered problems creating a playlist from either the Create Playlist menu pick from the playlist menu (I was not in the Database), or from the Database/Album-Artist/<all-tracks> context menu that I happened to stumble upon.  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.  This was after autofilling my (previously non-empty) device the first time after installing Rockbox.  After I updated the database, and re-created playlists using those two approaches, I had no errors shown in the playlist.

Are you saying there was something wrong with either of these approaches?  Can you please point out the exact wording in the first 5 of 6 sentences of the database section of the manual that could've helped me avoid my troubles?

Most people don't use the database, so its not enabled by default.

Again I ask, was there anything wrong with either of the approaches I described above?  If so, then there seems to be at least one unanticipated use of the database, namely, creating a playlist from the playlist menu.

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.

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):

-------------------------begin included revision-------------------------

Context Menu

Some menu picks and views, for example the WPS, the Database main menu
pick, and the file browser each have a context menu. These are
generally accessed using Long Select either while the WPS is showing,
or with a menu pick, such as a directory or file within the file
browser, highlighted.

The contents and objects of actions of a context menu can vary
depending on the situation from which you call it.  The file
browser context menu presents you with some operations you can perform
with the file or directory you called the menu from.  For the WPS this
object is the currently playing file.  Finally, there are some actions
that do not apply to an object, but instead refer to the screen from
which the context menu gets called; one example of this is the
playback menu, which can be called using the context menu from within
the WPS.

------------------------end included revision-------------------------

cheers,
john

[Llorean]

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?

As well, enabling the database by default can have significant performance penalties for people who don't wish to use it, so that's why it's not on by 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]

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?

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]

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...

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]

Have you read the manual?  There is already a "Context Menu" section in "Getting Started."  I have added 3 or 4 sentences to it.

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."

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?

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]

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...

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...

[saratoga]

Doesn't it do something with a similar effect *anyway* if dircache is enabled? I thought it did...

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. 

[[Saint]]

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.

Sorry, but, apparently you didn't look at the WPS context menu terribly well at all.
You'll find that any playlist can be shuffled without setting "Shuffle" to "On" by simply choosing the "Reshuffle" option from the WPS context menu.

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)

Now, this I find hard to believe...
Have you not noticed that the Database context menu is simply another way to access "Settings - General Settings - Database"?

Or, I just thought there is a chance you may mean calling the context menu after entering the Database menu option, but this only gives you access to "Playlist - Insert/Insert Shuffled".



[St.]

[torne]

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. 

Ah, that makes sense, yes. I tend to forget about the non-disk-based targets so i assume everyone uses dircache