[Enhancement]: shared state between users #681

Closed
opened 2026-04-24 23:16:45 +02:00 by adam · 8 comments
Owner

Originally created by @rhyst on GitHub (Oct 5, 2022).

Describe the feature/enhancement

There are some podcasts that I listen to alone and some that I listen to only with another person. Something I would really like but as far as I know no podcast app supports is the ability to share podcast state between two people so that the "continue listening" and "finished" states are shared between the accounts.

I can think of two ways this could work for me:

  • Flag a podcast as being shared - all state is shared between accounts whenever either account listens to that podcast
  • Some way to state who you are listening with when starting a podcast, then all state is shared for any podcast that is played

Is this the sort of thing you would accept a PR for?

Originally created by @rhyst on GitHub (Oct 5, 2022). ### Describe the feature/enhancement There are some podcasts that I listen to alone and some that I listen to only with another person. Something I would really like but as far as I know no podcast app supports is the ability to share podcast state between two people so that the "continue listening" and "finished" states are shared between the accounts. I can think of two ways this could work for me: - Flag a podcast as being shared - all state is shared between accounts whenever either account listens to that podcast - Some way to state who you are listening with when starting a podcast, then all state is shared for any podcast that is played Is this the sort of thing you would accept a PR for?
adam added the enhancement label 2026-04-24 23:16:45 +02:00
adam closed this issue 2026-04-24 23:16:46 +02:00
Author
Owner

@advplyr commented on GitHub (Oct 6, 2022):

I don't understand the use-case for this, why would you want to share listening state?

This would a bigger project as it would require either changing the data model of media progress objects or keeping copies of the same media progress object in each user.

@advplyr commented on GitHub (Oct 6, 2022): I don't understand the use-case for this, why would you want to share listening state? This would a bigger project as it would require either changing the data model of media progress objects or keeping copies of the same media progress object in each user.
Author
Owner

@rhyst commented on GitHub (Oct 6, 2022):

As a specific example I often drive places with another person. Sometimes I drive and sometimes they drive. Whoever is not driving controls what we listen to. There are a couple of podcasts that we only listen to together so it would be useful to have the same listening state when either of us is logged into the app so that we can pick up where we left off no matter who is driving.

It's niche and I know that there are non code solutions (just use the same device, use the same account etc.) but if it's a feature you'd accept then I would be interested in trying to make it.

From a technical point of view, is the idea of selecting who is listening and then copying the media progress object difficult?

@rhyst commented on GitHub (Oct 6, 2022): As a specific example I often drive places with another person. Sometimes I drive and sometimes they drive. Whoever is not driving controls what we listen to. There are a couple of podcasts that we only listen to together so it would be useful to have the same listening state when either of us is logged into the app so that we can pick up where we left off no matter who is driving. It's niche and I know that there are non code solutions (just use the same device, use the same account etc.) but if it's a feature you'd accept then I would be interested in trying to make it. From a technical point of view, is the idea of selecting who is listening and then copying the media progress object difficult?
Author
Owner

@advplyr commented on GitHub (Oct 7, 2022):

I think it would be a big project for an uncommon use-case. It wouldn't be as simple as copying the media progress. We also have syncing of progress as well as android auto (and iOS car play eventually) that don't have an interface we can ask the user to select which progress to use. Then we have completely offline listening which keeps progress locally and syncs it when the server is connected. The mobile app repo is https://github.com/advplyr/audiobookshelf-app

If you have a solution that could fit in the existing data model then I'm open to it but just thinking about this for the last few minutes has me overwhelmed!

@advplyr commented on GitHub (Oct 7, 2022): I think it would be a big project for an uncommon use-case. It wouldn't be as simple as copying the media progress. We also have syncing of progress as well as android auto (and iOS car play eventually) that don't have an interface we can ask the user to select which progress to use. Then we have completely offline listening which keeps progress locally and syncs it when the server is connected. The mobile app repo is https://github.com/advplyr/audiobookshelf-app If you have a solution that could fit in the existing data model then I'm open to it but just thinking about this for the last few minutes has me overwhelmed!
Author
Owner

@ponchohoncho commented on GitHub (Aug 1, 2023):

For what it's worth, I came here to request this same thing. I have the same use case: I listen to a book with a partner and it's always a toss up who's phone is closest, on, or otherwise available. We also listen to our own books, and sometimes the same book but at different rates, so sharing a single account won't work here.

As far as UI and permissions & such go, this is how I could imagine it would go. There's two parts: permission to sync/share state, and the state sharing itself.

There would need to be some kind of very light friend system, where you could consent to sharing your media progress with another specific user, For ease of use, we make it bidirectional in nature, like FB friends, rather than unidirectional like Twitter follows. It could be as granular as "I want to share the media progress of this book with this user" and then that user gets a notification to accept that connection. Then the consent/permission is there for future media progress syncing.

The syncing UX could be implemented only on the app side, don't worry about car interfaces, they're just for playback. You don't expose dual book/chapter seek bars to the car interface, so don't worry about this one either.

In the 3 dots menu on the playback screen, there'd be a new item called "Catch up with your friend's progress" or something similar. Tap that and you get a confirmation that you'd be moving your progress to Chapter Y at time HH;MM;SS, which was last played by your friend Z days ago on MM/DD/YY, and to confirm or cancel. Bonus to give a warning that your current playback position is later, or more recent than your friends and are you sure you want to go backwards? The date of last sync would let the people doing the sync say "yeah, that was the other day when we got groceries" or "wait, that's too long ago, remember, we were offline last week, let me open my app and sync my media progress up".

I think that accounting for offline listening is a red herring, and not worth a ton of thought. Let the user know that it's a best effort kind of thing and that obviously, the app can't know things that it doesn't know (such as where an offline user is in their book).

@ponchohoncho commented on GitHub (Aug 1, 2023): For what it's worth, I came here to request this same thing. I have the same use case: I listen to a book with a partner and it's always a toss up who's phone is closest, on, or otherwise available. We also listen to our own books, and sometimes the same book but at different rates, so sharing a single account won't work here. As far as UI and permissions & such go, this is how I could imagine it would go. There's two parts: permission to sync/share state, and the state sharing itself. There would need to be some kind of very light friend system, where you could consent to sharing your media progress with another specific user, For ease of use, we make it bidirectional in nature, like FB friends, rather than unidirectional like Twitter follows. It could be as granular as "I want to share the media progress of this book with this user" and then that user gets a notification to accept that connection. Then the consent/permission is there for future media progress syncing. The syncing UX could be implemented only on the app side, don't worry about car interfaces, they're just for playback. You don't expose dual book/chapter seek bars to the car interface, so don't worry about this one either. In the 3 dots menu on the playback screen, there'd be a new item called "Catch up with your friend's progress" or something similar. Tap that and you get a confirmation that you'd be moving your progress to Chapter Y at time HH;MM;SS, which was last played by your friend Z days ago on MM/DD/YY, and to confirm or cancel. Bonus to give a warning that your current playback position is later, or more recent than your friends and are you sure you want to go backwards? The date of last sync would let the people doing the sync say "yeah, that was the other day when we got groceries" or "wait, that's too long ago, remember, we were offline last week, let me open my app and sync my media progress up". I think that accounting for offline listening is a red herring, and not worth a ton of thought. Let the user know that it's a best effort kind of thing and that obviously, the app can't know things that it doesn't know (such as where an offline user is in their book).
Author
Owner

@bjhiltbrand commented on GitHub (Sep 15, 2023):

I just came here to request the same enhancement for the same reasons. I think @ponchohoncho has a pretty straightforward idea for how to make this work.

@bjhiltbrand commented on GitHub (Sep 15, 2023): I just came here to request the same enhancement for the same reasons. I think @ponchohoncho has a pretty straightforward idea for how to make this work.
Author
Owner

@zerodogg commented on GitHub (Mar 19, 2024):

For me, I'd be happy with just being able to view another persons location in a podcast/audiobook. As state syncing fits poorly into the data model as @advplyr said, being able to view another persons progress and just manually jumping to it would, at least for me, be a perfectly viable solution for what is probably a somewhat niche feature.

@zerodogg commented on GitHub (Mar 19, 2024): For me, I'd be happy with just being able to view another persons location in a podcast/audiobook. As state syncing fits poorly into the data model as @advplyr said, being able to view another persons progress and just manually jumping to it would, at least for me, be a perfectly viable solution for what is probably a somewhat niche feature.
Author
Owner

@w4itey commented on GitHub (Jul 16, 2024):

This Feature would also be good for me and my wife, and zerodogg's answer would also work just find, just a way to get my book in sync with their book.

@w4itey commented on GitHub (Jul 16, 2024): This Feature would also be good for me and my wife, and zerodogg's answer would also work just find, just a way to get my book in sync with their book.
Author
Owner

@Jab2870 commented on GitHub (Jan 30, 2025):

Just wanted to weigh in and say that this would be extreamely useful for me. THere are a couple of podcasts I listen to with my wife and sometime on my device, sometimes on hers.

@Jab2870 commented on GitHub (Jan 30, 2025): Just wanted to weigh in and say that this would be extreamely useful for me. THere are a couple of podcasts I listen to with my wife and sometime on my device, sometimes on hers.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/audiobookshelf#681