Yet Another Sync topic

[keunes]

@Stefano

Clearly gpodder.net is broken, and personally I think make no sense to let people lose time trying it. I would strongly suggest to remove it and put back just in case it will work again.

Thanks for your input. That’s been proposed, discussed and rejected in the past. But I think it’s good to discuss again in the next community call (@ByteHamster).

@Stefano

One might be for example that each device would clone its database (with a filename different from the other devices) and then read all the other it finds (of the other devices) and align its internal state with the latest information and then write back the result (note that first cloning can be skipped for efficiency).

This is not an option:

@ByteHamster

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.

@ByteHamster

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.

Then:

@Stefano

Another solution might involve using the telegram API and interact with a dedicated BOT

That might work indeed and I think we would be open to code for this. But that’d require a new volunteer that’s motivated to implement it because I doubt anyone from the core team would take the time to do that (we have other things we prefer to improve & fix).

@ChronoTriggered

Crazy idea of the day, implement some sort of DecSync spec and let us use Syncthing and/or any other filesyncing server.

I’m not a technical expert but I think that mainly works for certain things like RSS feeds and contacts because there are ‘native’ file formats like XML and RSS. Such thing does not exist for entries in the AntennaPod database.
Secondly, there’s less chance of conflicts because the of the frequency of data changes, and because of the type of changes. For example: ‘timestamp of playback’ is a much bigger scale (sometimes with thousands of seconds) than a simple ‘yes/no’ whether an article has been read or not. Conflict resolution with DecSync is far less advanced than what’s possible with a proper API:

However, there will still be a conflict when A and B update the same keys. This conflict is solved by having timestamps and choosing the most recent update.
Source

Imagine you listen to an episode on device A for 15 minutes, then on device B, which is currently offline, accidentally tap play for that same episode and pause again within 5 seconds. You then have a conflict. In DecSync, when both devices are online again, device B would prevail because that’s the most recent change. And thus your timestamp is incorrect. With a dedicated API you can say: whichever device has the biggest total play time for that episode (which is recorded separately from the pause timestamp) takes precedence.

And then we haven’t talked yet about all the listening stats which require a bunch of data, too.
So I’m not saying it’s impossible but it does seem damn difficult Here, too, I doubt it’d be the priority for anyone in the currently active volunteers.