bookmarks? if you use them read this!

[JdGordon]

I want to work on bookmarks again but I'm a bit stuck...

(bare with me if you know this already...)
Rockbox has 3 different types of internal playlists, each with their own quirks...
dirplay - play the contents of one folder (shuffled or not)
m3u - playlist from a file
inram - everything else, any playlist that you modify, change the track order, add, remove tracks, etc... (this include databse playlists)

now, from my quick test, the current bookmark stuff wont even let me create a bookmark from an inram playlist... So I want to fix this...

my problem is choosing where to save the bmark file to.
If its a dirplay or m3u8 playlist then we can save it as <foldername>.bmark or <playlistname>.bmark in the same folder as the dir or m3u (current behaviour)
database playlists? inram playlists? (from the playlist POV there is no difference between these, but there should be... thats something for later though). I'm thinking we could store it in /bookmarks/ and show the keyboard so the user can choose a name? as long as the resume point is stored straight away then any delay naming the file wont cause an issue with the wrong point being saved. Then that begs the question, why not save all bookmarks in the one folder and then we can replace the "recent bookmarks" screen with a file browser pointing to the right folder?

how does that sound?

Also, while we are here... if you have any suggestions for bookmarks.. now is the time to mention them...

[soap]

... Then that begs the question, why not save all bookmarks in the one folder and then we can replace the "recent bookmarks" screen with a file browser pointing to the right folder?

Pretty please?   

[pondlife]

I already posted on the ML, but this might be a better place...

I don't know the innards, but I thought Rockbox only had two types of playlist:
- dynamic (inram and dirplay, stored in .playlist_control as a set of instructions on how to recreate the playlist)
- saved (stored in .m3u file)

Could bookmarks be incorporated entirely into the playlist storage?  Without the corresponding playlist, a bookmark isn't much use.

I'm personally against having a centralised store of bookmarks.  Better, I feel, to avoid "special" directories (outside of .rockbox).   If integrated it would make it simple to move playlists and their corresponding bookmarks from device to PC to device.

pondlife

[bluebrother]

As I proposed earlier bookmarks could be included in the playlist itself -- with extm3u there's a way adding own data to the playlist file. From my information this won't create any incompatible file format (though I haven't checked up to now) and it would also allow a more simplified handling.

There is of course the chance that opening such a bookmark-ized playlist in a different player will loose the bookmark information upon re-saving it. OTOH, having a bookmark format that includes the playlist doesn't sound like a nicer solution to me.

[JdGordon]

- dynamic (inram and dirplay, stored in .playlist_control as a set of instructions on how to recreate the playlist)

aparently they are handled slightly differently (at least from the current bookmark POV...

Could bookmarks be incorporated entirely into the playlist storage?  Without the corresponding playlist, a bookmark isn't much use.

adding resume info to a m3u means that loading will be much slower usually... the .playlistcontorl file can rebuild a playlist very quickly

[bascule]

I'm not keen on bookmarks being incorporated into the actual playlist file, but I do think they should be saved to the same folder as the playlist catalogue, so that they can be managed together.

[pondlife]

Could bookmarks be incorporated entirely into the playlist storage?  Without the corresponding playlist, a bookmark isn't much use.

adding resume info to a m3u means that loading will be much slower usually... the .playlistcontorl file can rebuild a playlist very quickly

No, I meant to continue using playlist_control, just to use the same mechanism for bookmark resume and "normal" resume.

Also, the bookmark doesn't have to be stored in the same file as a playlist - it's more a clarification that a bookmark is always a reference into a playlist, not necessarily a directory (i.e. bring the database and saved playlists into parity).  Alongside the playlist would be fine by me too.

One problem is maintaining the current per-directory auto-saved bookmarks.  This would be an extension of the basic system, on the assumption that a bmark file with no corresponding playlist means "create a playlist for the containing directory".

pondlife

[JdGordon]

code is now working to load and save .bmark files from the playlist control.... so we really need to get some consensus on how to name them....
he who yells loudest gets his way....

[pabouk]

...database playlists? inram playlists? (from the playlist POV there is no difference between these, but there should be... thats something for later though). I'm thinking we could store it in /bookmarks/ and show the keyboard so the user can choose a name? as long as the resume point is stored straight away then any delay naming the file wont cause an issue with the wrong point being saved.

What about configuring the database playlist bookmark names in the tagnavi.config file? The file name could consist of a constant part and a variable part containing the database query parameters. To identify multiple bookmarks of the same query there could be a serial number or time in the filename.

Then that begs the question, why not save all bookmarks in the one folder and then we can replace the "recent bookmarks" screen with a file browser pointing to the right folder

I am not against using a single directory but sub-directories should be used as flat structure for storing bookmarks could be pretty messy.

[JdGordon]

What about configuring the database playlist bookmark names in the tagnavi.config file? The file name could consist of a constant part and a variable part containing the database query parameters. To identify multiple bookmarks of the same query there could be a serial number or time in the filename.

not really possible.. there is currently no way to know if its a batabase list, or just a random bunch of files... also I dont like that idea much... if its from the db the search path shold be used when possible (which is not currently)

[JdGordon]

not getting much input on the dev list so ill try here also (and yes im going to get told off for posting a patch here instead of the tracker.... tough! its not ready yet...)

please try out the attached patch. your old bmark files WONT work... and actually the only thing that does at the moment is creating bookmarks in the wps context menu, and loading .bmark files in the file browser...

One important thing...
if the name of the current playlist cant be determined (i.e its not dirplay or m3u) it creates a numbered /bookmark_*.bmark file which you can go and rename later (unless someone comes up with a better way to name them?)

[AlexP]

I'm sorry for being late to the party (I've been away) and I'll admit right now I haven't tried the patch - but does the recent bookmarks entry still exist in the main menu with this?  It is a feature I use all the time and I would be very sorry to see it go.

Apologies if this is a non-concern!

[JdGordon]

yes, it will stay, in some undecided form....

[JdGordon]

moving this to the tracker as its almost fully working... http://www.rockbox.org/tracker/task/9407

If you use bookmarks please let me know whay I've broken from the old behavior.
things are that not yet converted:
- autoload (not sure how this is supposed to work...)
- recent bookmarks

[JdGordon]

bmark.6.diff on the tracker is where im sort of stuck at now (should still be in sync with svn...)
automload is working..

I'm completely stuffed as to what to do about the recent bookmark list. Because the .bmark actually has to be loaded before it can be displayed, if we want to show the track title and the resume position in the recent list we need to waste a fair bit of ram storing track title, .bmark filename, resume point (~500 bytes each!)
Now we can do this, but thats quiet a bit of waste for people who dont use bookmarks (yes it can be allocated at boot but thats a bit annoying also)

One option is to only save the .bmark filename and only have a list of them, then selecting one would load it and display the resume points in it... good enough?

I need suggestions.... (also testers for the actual WIP patch..)