Synchronizing without gpodder


to me, gpodder’s service has proven to be quite unreliable, ever since I started using it. Especially when trying to sync more than 2 devices, there have always been discrepancies regarding subscriptions and their status. Now the service has been down completely for days, and who knows when (and if!) it is going to come up again.

I’ve read quite a few articles and discussions about what is necessary to synchronize a podcast app’s data between different devices, and I understand that it takes some API and some data base to store all the information about the subscribed podcasts and their status.

But I still think that there might be a different way to sync this data. To me, a server based solution like gpodder, offers the possibility to sync the data nearly instantly: if I stop listening to a podcast on one device, within seconds the listening position is synchronized and I can pick up any other device and continue listening there.

But what about user, who don’t need this instant synchronization?

I imagine the following scenario:

AP could store all its information in one local data base (sqlite) file, whenever some changes are made, whether it’s a new subscription, a positioning info within a podcast, or whatever. This file could then be synchronized using a simple service like Nextcloud. Any synching software, regardless on which device, will always take care of timestamps and will always see that the most recent version is uploaded to the NC server, so that any device will always download the most recent version.

For example, this is the way I use Osmand (my navigation app) in conjunction with Nextcloud: whenever I save a new favorite location or a pre-calculated route one one device, this new data will be synchronized to all my devices.

Of course, there is one drawback: you can not use this kind of synchronization and expect changes to be available on all devices within seconds or even minutes. But for people who can live with a longer delay, this could be a solution for them. For instance: my Osmand/Nextcloud combination is being synchronized once a day, and that is sufficient enough for me, because I don’t switch from one device to another very often. And even if I suddenly have to use my tablet instead of my phone, I can easily trigger manual synchronization to make the latest changes available to me.

What do the experts think about this idea?

Hi! The problem with that approach is that services like Nextcloud see the database as one single file. Therefore, even if you just mark a single episode as played, it has to upload the whole database again (20-100 MB). Additionally, it can not merge changes from two devices: if you mark an episode as played on one device, add an episode to the queue on the other device, and then synchronize, Nextcloud does not know what to do. In order to make a reliable sync service, a server is needed.

Gpodder is open-source, so it is theoretically possible to run your own server that is more reliable. That requires quite some technical knowledge and a server, though.

Unfortunately, I don’t have a better idea than that. Unless there is a volunteer who is really motivated to develop our own AntennaPod sync service, this is pretty hard to solve.

I am aware that this solution is far from being perfect, and I understand your points there. But, as I was saying, this kind of synching should be considered as a sort of “plan B”, meant for users, who don’t need more than one or two synchronizations per day and who don’t use more than two or three different devices for their podcasts and who don’t switch between their devices often.

Of course, this solution will not work for someone who starts listening to a podcast on one device, then adds a new podcast using a second device, while simultaneously marking an episode as read on yet another device. I am not sure, if a real synching service like gpodder would be suitable for this kind of power usage, or if this would make the service go haywire.

I am using three devices to listen to postcasts: my phone, when I am away from home, my tablet, when I am at home but not using my PC, and my PC. Gpodder has not managed to synch these three devices without me having to intervene regularly. At least once a week I need to manual synch me devices by copying the database from one device to the other two.

So, from my perspective, gpodder is not any more reliable than the method I described above.

As a matter of fact, there is just a very tiny change that needs to be done toAP to make my “solution” work, or at least make it possible to try it out: AP would need a setting to automatically export its database on a scheduled base. A regular backup has never been a bad idea, no matter which piece of software is involved, so I would call this a real necessity to be implemented anyway.

Gpodder handles individual “events” whenever something happens in the app (eg Play x, delete y). So that should work fine with them.

Something like that is being discussed here: I do not think yet another setting for that would be good, though. So I would only do a pre-determined interval.

I am still puzzled about the amount of data that is really necessary for a synchronization. Maybe I am a bit naive on this, but the way I look at it, each subscribed podcast would require these data:

  • URL (type string)
  • list of new episodes available since last sync (type date+time) (complete list = old + new )
  • position of last stop (type integer [seconds]) (if duration = stop position -> episode completed)

Did I forget any thing?

The list of available episodes does not need to include the episodes’ titles, because that information can be downloaded on each device separately and stored locally.

Now let’s speculate a bit and assume a typical URL consists of 1000 characters (which would be a looooong URL indeed!) and let’s say there are 10 new episodes available each day. That would make about 10 kilo bytes of data to be synchronized for this podcast. So, even if you subscribed to 100 podcasts that each required this amount of data, that would sum up to around 1 mega byte. And that 1 MB would only be necessary to transport if you synchronized the hole data base each time some data changed. I don’t know many people who really listen to podcasts on more then one device simultaneously. Most people will start listening to a podcast on one device, either listening to it completely or pausing it and continue listening later on the same device or another. Either way, there should be enough time to exchange and synchronize the needed amount of data.

So, from my point of view, what would be required is a service like good old CVS within Nextcloud or another web based server, that keeps track of changes and merges each incoming change into the last valid version of the data list.

As I said: I may be naive on this issue, but I simply can’t see why it should take such huge amount of data to synchronize AntennaPod’s data between two or more devices.

When exchanging the database without an actual synchronization server, you would need to transfer the whole database, not just the changes. This means that it includes all episodes of all subscriptions, together with all their data such as descriptions, URLs, etc. - Again and again, for every single playback event.

I think you misunderstood me there. I wasn’t talking about synchronizing without a server, I was talking about synchronizing without “gpodder” as a service. Mark the difference! :slight_smile:

I was speculating what it would need to create an own sync service, independent of gpodder and capable of being integrated into a self hosted service like Nextcloud.

But still there’s the question that puzzles me, why it takes that much of data to store to memorize subscriptions and their status.

You can open your database export and analyze it if you want :slight_smile:

1 Like

How about a self-hostable service that implements gPodder’s API? I would love for this service to take care of all my downloads and then have AntennaPod simply sync with it in the background. The service could also potentially have a web interface that allowed for subscriptions, playing episodes, etc.

I know this is a pretty big request, but it would put AntennaPod up on the level of commercial podcast apps like PodcketCasts.

For now, I’d just like a self-hosted way to sync episodes and their progress.

Gpodder is self-hostable and you can enter custom servers into AntennaPod. It is a bit hard to set up, though. There is currently someone who develops Nextcloud support (with a simple sync server without UI) and someone else who develops a full Nextcloud podcast application. I would love to have both of them combined instead of them being separate projects. Let’s see how that goes.


Is this FR dead?

I have just started using AP and would like to sync a backup DB to and S3 cloud which I do with a weekly autosync with FolderSync. What i would like is an auto generated backup file with grooming. Call it subborn independence. The google backup is a bit of a black box. It does seem that gPodder is about to enter the mortuary and I would not want to give it data in its present state.

Otherwise, really enjoying the app.

AntennaPod ships with Nextcloud support since March 2022. There are also projects working on plain php servers if you don’t want a full Nextcloud install. Furthermore, you can host gpodder yourself if you want. So there is plenty of options now :slight_smile:

Plain file sync is not enough for synchronization, so what you are trying to do will not work. You need a more tailored server than just simple file sync.

Do you (or anyone else) know to setup selfhosted on Docker on Synology NAS? is quite hard to setup. But there are some additional options:

1 Like

I’ve tried to install and I failed. It looks completely broken.

Are there any (self-hosted) alternatives? I would really love a synchronisation between my phone and desktop, so I can resume podcasts on my phone that I’ve started to listen on my desktop.

Read one message above yours

Well, unless they’re looking for a back-up system rather than a way to sync (what, from the post, seems to be the case).

Yes, I did. So for not being clear. I had @update.freak’s comment in mind: I’m also looking for an alternative that can be installed easily with Docker. Not because it’s essential for me personally, but because it should be easy to use to get the popularity it needs to get adopted by podcast clients.

As for the alternatives you mentioned: I’m not using Nextcloud so that’s not an option. The other ones are not really mature alternatives.