First of all let me congratulate and thank the developers for this beautiful and very much needed app!
I’m trying various features, but the sync one, that should be interesting for me having two phones, I was not still able to setup.
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.
Regarding nextcloud I was not able to find an instance with the plugin required already installed (and I’m not for a self hosting if possible).
Clearly network filesharing is very abundant (google drive, nextcloud base, dropbox, etc), and a feasible solution might be found even if clearly a server with dedicated api would be easier. 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).
Another solution might involve using the telegram API and interact with a dedicated BOT (that in reality is just a fictitious name of a chat that I can easily create). In this case every message sent is an event meningful to be recorded (eg episode played), and reading the chat history (from the last known point) the device can syncronize with the latest events.
Other solutions might be found, the important point is that they should be reliable and easily accessible.
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).
This is not an option:
Then:
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).
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.
Regarding full DB replica I think that there are ways to upload just deltas, for example always creating a new file with a sequential number and writing there the delta. The reaaders also can maintain the deltas sequential numbers they arrived for the various devices. And files for the various devices can be put into subdirectories.
Good instead that Telegram BOT solution is being found viable!
A general note (apply eg to the feedbaack to the latter proposed solution with DecSync): proper alignment is nice, but the solution might be (at least for now that there are none) just “good enough”. This means for example that might miss some element in the replication (for example for me already having all the subscription list without details on episodes would be already a good start), and even that in some extreme circumstances might take some light error (eg choosing the wrong timestamp or similar).
PS: Surely there might be more important updates to take care, but when this will come on top at least there would be some ideas on how to do!
To do som expectation management: Please note that this is just my personal estimation, and that I am no developer.
In some situations that might work, not so for sync I think. Users just enable what they find in the settings and then complain it doesn’t fully work -as is shown by the frequent Google Play reviews I see complaining about ‘sync not working’.
Here, too, I doubt it’d be the priority for anyone in the currently active volunteers.