Short SELECT doesn't return to database browser

[DervishD]

Hi all

This is my second (and last, hopefully) problem with the Database.

I browse my music with the Database, and when I'm playing a song and I do a short "SELECT" press, the database browser is presented to me. I browse again and choose new songs, etc.

After doing the above I turn off my iAudio X5V. When I turn it on again, the last song (well, playlist) is resumed, and that's great, that's how I have it configured. The problem is that if I do a short "SELECT" now, the FILE browser is presented and not the Database browser (( That is, a turn off and on again and Rockbox forgets that I was browsing music using the Database and not the File browser. As soon as I browse and play again using the Database, short "SELECT" gets me to the Database browser and not the File browser... until I turn off and on the player again.

I have the "Follow playlist" option turned on (I need it right now), may this be the problem?

Thanks a lot in advance )

Raúl Núñez de Arenas Coronado

[GodEater]

I have the "Follow playlist" option turned on (I need it right now), may this be the problem?

I imagine this is the problem as you surmise, since it instructs the file browser to keep changing directory to the file currently being played.

[DervishD]

Hi GodEater

I have the "Follow playlist" option turned on (I need it right now), may this be the problem?

I imagine this is the problem as you surmise, since it instructs the file browser to keep changing directory to the file currently being played.

I've tested and no, that's not the problem. Disabling the option just makes short SELECT return to the root directory. After a turn off and turn on is not possible to go back to the Database browser and not the File browser, it seems.

I have the feeling that I'm missing something very obvious...

Thanks anyway for your answer, I'll keep investigating!

Raúl Núñez de Arenas Coronado

[Lear]

When you press select, the WPS exits with the message "return to the previous browser". This value (i.e., file or database browser) doesn't persist between boots and defaults to file browser, which explains the behavior you see. So there's not much you can do - except fix the code, of course. (Or perhaps file a bug report/feature request and wait for someone else to fix it.)

[JdGordon]

Lear is correct.. but I don't think its a bug worth fixing.

[Llorean]

Considering you can't know that the database even exists in the same form after the reboot (new filters rewritten, etc), nor what search was used to create the playlist (unless more data is saved), the only thing you *can* know with a certainty is "If this file is playing, then it exists on disk where we expected it to, so we can also send the file browser there"

[DervishD]

Thanks for all the answers.

Lorean made it clear: if we cannot know if the database is "up'n'running" after a reboot, going to it is a bit risky...

I'm starting to thing that this is not exactly a bug. I will have to live with it!

Thanks

Raúl Núñez de Arenas Coronado

[fizze]

Hey, I just updated to RB3, and I'm amazed at the progress. Very impressive!

I'm just stumped with a few database issues, so please excuse my "rant"!

Wow, too bad noone hasn't thought this through yet.
On my iriver H320 I enabled the db for two reasons:
1.) shorter boot-up-time
2.) less HD activity

Now when i disable dir-cache the HD always has to spin on when i press SELECT shortly. Too bad, because I really want to go th the DB browser, and presumably to the state where I left it when the device was powered off.

The file-browser mimicks this behaviour perfectly. I use the iriver in the car mostly, so it's nice to have the browser pick up where i left it.

Like this, the database (which is an incredible feat, imnsho!) is rather impractical.

Is there a customized build out there that perhaps handles this better?

[JdGordon]

they are not DB issues... your assumtpions are incorrect.
1) enabling the db if anything will increase boot time (maybe...)
2) there is more disk activity to keep the db up to date if any files change.

your biggest mistake was disabeing dircache which the file browserr and the DB use. re-enabe that and your disk activity will drop back to where its expected (almost none in regular browsing). enable "load to ram" in the database settings and you will have no disk activity when browsing the db.. (you will have a smaller audio buffer though so slightly more disk activity when you are listening to music though)

[fizze]

I did enable the load to ram feature.

Well, as my iriver is parked in my car it'S contents are hardly ever changing.
I really want to reduce boot-up time. So disabling dir cache seemed unnecessary when the DB was active.
Maybe I got the whole DB thing wrong..... :confused:

I'm aware of the reduced ram thingy, but that's fine with me.

[PaulPosition]

The database is great, but it is no magic.

As such, it resides on the disc. So does the system that runs it, the filters it uses for searches, and the media files it points to.  -  Hence enabling dir cache for faster disc access makes sense. 

[JdGordon]

enabling dircache shouldnt make boot times slower... iirc it updates in the background after the initial build.
If your files never change disable auto update in the DB which might speed things up (no guarentees)

[Llorean]

Also, as a note, there's no such thing as "RB3". Do you mean the 3.0 build, the 3.1 build or the 3.2 build? Or are you just referring to some revision that came out after 3.0 as "RB3" and really mean one of the recent current builds?

[fizze]

dir cache has a severe impact on boot time!
At least it did on the rockbox 2.x builds.

When I say RB3 I am referring to the 3.x builds, btw.

Well maybe that stuff improved in the 3.x builds, but in 2.x dircache was a bummer, because it delayed the "time until play" by about 20 seconds, on my 20GB H320.

[JdGordon]

arg... there was no such thing as 2.x builds... and every 3. build is 3 months apart... 3.0, 3.1 and 3.2 are completly different.. you cant say 3.x... (llorean will surely go into more detail.)