Please make Sonos service podcast bookmark aware

[splump]

When i use DSub to play podcasts it automatically creates a bookmark when i pause/stop it. I'm not sure where this bookmark is saved, if it's locally on my phone or if it saves it serverside in the database. It would be really neat if i could listen to a podcast in subsonic/dsub on my phone when i'm out and about during the day, and when i get back home i'd easily be able to keep listening where i left off but through the Sonos Subsonic service. Is it possible to sync bookmarks between different players and services at all?

[sindre_mehus]

Good news, I'm adding bookmark support to the next version (6.1). It works across Sonos, Chromecast, web players and supported apps (e.g., DSub).

[daneren2005]

Woohoo! I've been hoping for that for a while.

[sindre_mehus]

Yeah, it's about time

By the way, this is how it works:

1. Bookmarks are automatically created for videos, podcasts and audio books.
2. Bookmarks are automatically skipped to when starting to play a video, podcast or audio book.
3. During playback, the bookmark is updated with the current position every 10 seconds (web player) or 60 seconds (SONOS).
4. The bookmark is also updated if the user pauses or skips.
5. If there is less than 20 seconds left of the song/video, the bookmark is deleted.
6. The bookmark comment is set to "Last played in browser" etc.
7. I've added a page for showing all bookmarks for the current user, with options for deleting and playback.

Does this seem sensible to you? If so, it would be great if the user experience in DSub (and any other bookmark-enabled apps) was similar.

Cheers,
Sindre

[acroyear]

Could you publish any API changes (if there are any) on the API google group?

I use the play queue feature in SubFire because the bookmarks API in 6.0 and before isn't quite flexible enough for my needs. In particular, while I can bookmark the file, bookmarking its place in the current play queue isn't possible. It is fine to know that there were 60 seconds left in Pink Floyd's Money, but was I playing Dark Side of the Moon or a shuffled mix-up when I stopped? That's why I end up using the play queue instead (along with locally caching the current queue).

As for playback, with html5 audio on older webkit/blink browsers, it isn't possible to queue up to the exact spot. On Chrome and Firefox (and I *think* Edge, but not sure about IE), I can seek the html5 audio tag to the spot, give or take a second or two. However, on FireOS (Tablet and TV) I can't unless the file is VBR. So my support for using bookmarks will be a little limited. Hopefully Fire will get up to using Chromium 51 as its baseline web view and I'll be able to be consistent.

[Exrace]

Looking forward to the new release!

[Michael Bech Hansen]

Sounds good to me.

I recently implemented a similar scheme for bookmarks in play:Sub for iOS.
Of course the details differ:
The "automatic bookmark mode" in play:Sub will auto-bookmark any content longer than a user-controlled duration, and I'm adding additional criteria for video, podcast and audiobooks.
When resuming a bookmarked item, the user is given a choice between "start from beginning", "start at bookmark", and for audiobook chapters "Resume book".
I do not update bookmark position during playback, but only on pause, skip and otherwise starting playback of other things.
play:Sub also deletes bookmarks when playback is stopped near the end of the item.

All in all, minor differences... and I'm going to make adjustments when you publish how things will work in the released 6.1 version.

Cheers,
Michael.

[sindre_mehus]

Could you publish any API changes (if there are any) on the API google group?

There are no API changes for this.

Cheers
Sindre

[daneren2005]

How DSub handles bookmarks:

1) Bookmarks are automatically created for Podcasts, Audio Books, and when the file is longer than 10 minutes.
2) Bookmarks are automatically created when paused or changing current playing. I'm weary about setting an auto bookmark up because this is a mobile device and I don't want to kill the battery/a lot of times users have crap network connection on commutes.
3) There is a button users can press while listening to songs to create a bookmark for the current position. This can be useful if you want to pick up where you left off in an album.
4) Bookmarks are automatically cleared when 84% (to a maximum of 10 minutes) of the way through the file, but only when they remove the file from the list or go to the next file.
5) Created a tab where you can view all bookmarks
6) When resuming from a specific bookmark, it automatically loads the album it is in and resumes playing from the bookmarked position. It doesn't do this if the file is a podcast since those are often listened to one at a time.
7) When pressing play on an album with a bookmark, the user is asked if they want to resume from the bookmark or start over. If they start over the bookmark is automatically removed.
The bookmark comment is set to "Auto created by DSub". I can change that to "Last played by DSub" or whatever to keep it consistent.

The main difference between my work flow and yours is when you automatically clear bookmarks. I found in practice automatically deleted when only 20 seconds are left resulted in them almost never being deleted automatically. A lot of my podcasts have a commercial at the end where I would stop listening. I also a lot of time would get to my destination with a few minutes left and just not care enough to only listen to the last little bit next time. That sort of thing is a personal preference obviously but I haven't seen any complaints about this setup so far. I'm curious what other's opinions on this are.

I also really like how in DSub when you go to play an album it asks you if you want to resume or start over. For something like Audio Books you probably don't want to start over, but I also use bookmarks for keeping track of my spot in albums a lot. A lot of times the first time I go through an album I am looking for the best songs to add to playlists so I want to know whether I finished the process or not. This is once again a very personal preference.