time bookmarks

[6arms1leg]

feature to save time bookmarks, so its easier to resume listening to an audiobook (for example).

[tilboerner]

just putting some thoughts up for discussion. time bookmarks should probably not be associated with individual tracks, but playlists. the question is: how?

• bookmark gets saved with the playlist: less than ideal.
  • doesn't work easily for public playlists, unless a copy is made for the individual user.
  • does loading a (personal) playlist always jump to the bookmark? what if the queue wasn't empty?
• bookmarks get saved per user with a reference to playlist (and track?)
  • loading a bookmark replaces the current queue with bookmark content
  • flexible handling of public (shared) playlists
  • easier to deal with changes to playlist content and track (addition, removal)

[6arms1leg]

do you use an android phone? have a look at MortPlayer Audio Books, where this feature works perfectly:

https://play.google.com/store/apps/details?id=de.stohelit.audiobookplayer&feature=more_from_developer

[tilboerner]

No, my phone's basically a brick that has buttons to dial with and a paper membrane for a microphone. :) I'm also not a heavy consumer of audiobooks.

I had a look at the feature list of the audio book player you mentioned, and it looks quite useful. But let's disregard concrete features for the moment.

What's interesting to know, from anyone: how would you expect these time bookmarks to work for you as a user, in general, and with an eye on audiobooks in particular? What are explicit and implicit (automatic) functions? Keep in mind, though, that the software that does not, and will not, have a concept of "audiobooks".

[devsnd]

I think each playlist should have a unique identifier. and by unique i mean sha512 or something.

a timed bookmark just points to such a identifier and contains:

• a text (could be a remark etc.)
• a track number
• a playtime

playlists referenced by a timed bookmark are kept as they are. if they're changed, the timed bookmark keeps a copy of the original playlist. From a programming point of view this means, that playlist are immutable, and "garbage collected" once not referenced anymore by the playlist-database or the bookmark database.

The nice thing about this implementation would be, that timed bookmarks never stop to work unless the underlying media is lost and that they aren't bookmarks anymore. they could be send as a link to a friend, to point out the favorite position in the favorite track of an album.

[tilboerner]

I like the benefits of this approach, but not all of its other implications. If a bookmarked playlist gets changed, there will then be two of them, and they'll be hard to tell apart. It's also not necessarily clear why, after a change, the old version sticks around sometimes, only to be suddenly gone after some bookmark got deleted. This is especially confusing for public playlists, I think.

I guess we could add version numbers and only ever display the newest version, if several are available; but wouldn't it be weird then if a playlist looks different if you access it via an old bookmark?

For audiobooks, a self-updating bookmark would be nice. If the bookmark automatically follows my progress, it significantly lowers the management overhead of create-new, delete-old. Is this a special case of a bookmark, or actually a different concept?

• a track number

If we store a file UID (or unique path or something), almost all changes to the playlist won't affect the bookmark. If that very track should not be part of the playlist, e.g. because it got deleted, the bookmark's invalid and defaults to the start of the first track.

they could be send as a link to a friend

That's a very good idea. In general, if the API could respond to something like

http://server:port/music/playlists/${reasonably-short-hex-string}/${track}#${timecode}

that would actually be all we need for (static) time bookmarking. Add a button somewhere to generate the link, et voilà. In my heart of hearts, I've fancied an API like that for a while now. I haven't tried to find a concept yet of how to integrate something like that with a static player that keeps its own state in between page reloads. Maybe these two approaches just don't mix well.