Opinions of User-friendliness in rockbox

[cpchan]

I think it is very good as it is, actually (for me, it's one of the killer features in Rockbox). True, I don't use the database, nor create dynamic playlists, so I don't really encounter the big limitations... 8-)

Same here, it work rather well for me. But like you I never use the database or create dynamic playlists. I wasn't even aware of the problems.

Charles

[AlexP]

I think if music stops naturally (end of playlist) it should go back to the Main Menu (right now it doesn't), but if it's stopped by user input, it should go back to some other screen (since a user can VERY easily press Menu too).

I don't really like the main menu, I have start screen set to file tree.  If I start up in the file tree, play some music, it ends, I don't really want to end up back in the menu, only to have to select file tree again every single time.

stop: I understand the whole thing to make it easier for blind users, but the main menu was put in to be the home/start/main screen.. the one where you would be dumped in when nothing else is happening so you can choose easily where you want to go.  imo it should work like this. stop->menu, select->browser/playlist/file
arg.. I dunno... I dont like stop going to the browser....

I know where I want to be - the file tree.

[Llorean]

How 'bout "If music ends, go back to the selected 'start screen' unless that screen is also a playback screen of some sort, then go to wherever the WPS was invoked from" or something like that?

I haven't used the bookmark feature myself, so I don't know the advanced bits of it at all, and am not really qualified to speak relating to it. All I need from bookmarks is basically "I click on a file, and it populates the playlist, and resumes from a certain point in a certain file." Basically, what resume on startup does. I'd basically be happy with the ability to dump the current playback state (I assume, something similar to nvram.bin) to a file, whenever I wanted (or automatically when playback is stopped).

[JdGordon]

The plugin buffer is used to buffer the filenames, which are (often) loaded from disk when getting a filename from a playlist. If the dircache is enabled, you might get away with not using the plugin buffer...

oh? that should only be the case when doing "dirplay" though

[AlexP]

How 'bout "If music ends, go back to the selected 'start screen' unless that screen is also a playback screen of some sort, then go to wherever the WPS was invoked from" or something like that?

Sounds good to me!

[Lear]

The main problem with bookmarks is that they are Folder-based.  They need to be Playlist-based.  I have an "AllRandom" playlist which I can jump to at any time when I don't really know what I'd like to listen to but I end up reshuffling it each time, when I should be able to carry on where I left off, using a bookmark.  I'd like to be able to listen to my big playlist until I feel inspired enough to go and choose an album, then later return to where I left off.  (Hope that makes some sense.)

Huh? Bookmarks are based on folder or playlist, depending what you "played" (a file in a directory or a playlist). I also have a shuffled "All" playlist, and I resume that one all the time. I've had well over a hundred bookmarks for that playlist alone...

[Lear]

The plugin buffer is used to buffer the filenames, which are (often) loaded from disk when getting a filename from a playlist. If the dircache is enabled, you might get away with not using the plugin buffer...

oh? that should only be the case when doing "dirplay" though

The opposite, actually (unless I misunderstood you). When doing dirplay, the playlist is fully stored in memory, so in that case the filenames would not be loaded from disk.

In order to support really big playlists on targets with limited memory, only the file index of each entry in the playlist file is stored in memory (along with some flags).

[cpchan]

I also have a shuffled "All" playlist, and I resume that one all the time. I've had well over a hundred bookmarks for that playlist alone...

My default playlist is a large shuffled "All" playlist from my music library and, like you, bookmarking works like a charm

Charles

[pondlife]

Huh? Bookmarks are based on folder or playlist, depending what you "played" (a file in a directory or a playlist). I also have a shuffled "All" playlist, and I resume that one all the time. I've had well over a hundred bookmarks for that playlist alone...

Hmm, I've never found it works reliably for a database generated playlist.  Maybe it was broken last time I tried.

I don't see why there's a need for folder-based bookmarks; aren't folder selections just another method of generating a playlist really?  I see the main job of both browsers to be playlist generation (albeit normally dynamic playlists).

pondlife

[pondlife]

How 'bout "If music ends, go back to the selected 'start screen' unless that screen is also a playback screen of some sort, then go to wherever the WPS was invoked from" or something like that?

Why not just go back to the last non-WPS screen the user browsed to.  I think that's what's meant to happen at the moment, but it may be slightly buggy.

pondlife

[Lear]

Hmm, I've never found it works reliably for a database generated playlist.  Maybe it was broken last time I tried.

No, that is a limitation with the current bookmark system.

I don't see why there's a need for folder-based bookmarks; aren't folder selections just another method of generating a playlist really?  I see the main job of both browsers to be playlist generation (albeit normally dynamic playlists).

Selecting a file in a folder does generate a playlist, yes, but a special in-memory one.

But I think I see what you're after here. A generic bookmark system that can handle any selection by the user, be it a file in a "normal" folder, a file from a database query or a plain old playlist (modified or not).

In that scenario, a folder selection would just be another dynamically generated playlist, to be handled in the same way as the rest.

Should be possible, though I don't see how it could be done without copying the current .playlist_control file somehow (perhaps as a part of the .bmark file, which could make them noticeably larger).

[Llorean]

Would larger bookmark files present a problem with disk space, or also with lowmem targets?

[Lear]

The files could be fairly large, and many of them could be created, so it could waste some disk space (several megabytes). Shouldn't be a problem for lowmem targets as such though.

[Llorean]

Personally, I'd sacrifice some disk space for a more consistent bookmarking feature, but I'm not sure how others feel.

[JdGordon]

the resume files arnt that large.. unless you do some serious fiddling with the playlists...
90% of them would just be the 2 or 3 line file saying "this directory/db list was loaded" and imo that is a much better bookmark setup than current