SUMMARY *** When syncing my AntennaPod & kasts with nexcloud-gpodder, all episodes in kasts get marked as played. So it seems played state isn't synced correctly!? *** STEPS TO REPRODUCE 1. Sync AntennaPod with nextcloud-gpodder 2. Enter login data into kasts 3. initial sync 4. play states aren't synced correctly, but all episodes get marked as "played" EXPECTED RESULT I'd expect to have play states being synced correctly SOFTWARE/OS VERSIONS Linux/KDE Plasma: *buntu 20.04 KDE Plasma Version: 5.18 KDE Frameworks Version: 5.68 I'll link this bug to nextcloud-gpodder github as I don't know if it's a matter of kasts or nextcloud-gpodder
There could be a large number of things going on here. Please note that episode syncing is not trivial, so most apps make choices to avoid major catastrophes (like losing all episode progress). One of those choices is that only episode state *changes* are registered from the moment you set up syncing. None of the existing states will be synced at the time you set up the syncing feature. You mentioned that you set up syncing on antennapod and then tried to sync to kasts. Have you just set up the syncing on Antennapod? If so, I bet this is the actual problem. To investigate: please change the play position of an episode on AntennaPod, then perform a sync on AntennaPod. Then go to Kasts and do a sync from there. The state of that one episode should now be the same in Kasts. (You should obviously also be able to do it the other way around: Kasts --> AntennaPod). PS: If I recall correctly, you can force AntennaPod to upload all *existing* episode states to the server, but I'm not entirely sure. It's advised to make a backup before doing that. I've lost my episode states more than once by experimenting with these options.
So to get a 1:1 state with both, AntennaPod & Kasts, This is the way to go? After I've done the initial sync (either AntennaPod or Kasts being empty/clean before), I mark an already played episode in AntennaPod or Kasts as unplayed, sync again, mark it as played again and do another sync? Will I get the 1:1 state with this? See also: https://github.com/thrillfall/nextcloud-gpodder/issues/76 for the corresponding issue on nextcloud-gpodder. Is there something AntennaPod could do to improve the initial sync?
> That's quite sad, as when syncing Kasts I'm unable to differentiate what episodes I've already listened to in AntennaPod ;( This could be a point in my opinion. The auto-mark-as-played feature sounds very useful on stand-alone instances, but it could be annoying on instances with regular synchronization. I would find an option useful that allows me to disable this auto-mark-as-played in new feeds. If I already listened to (and synced) a lot of episodes in Antennapod or Kasts and then started with a fresh Kasts instance, after an initial sync only actually listened to episodes would be marked as played and not all episodes of a newly synced feed. Could this be a useful feature?
(In reply to JonOfUs from comment #3) > Could this be a useful feature? I'm not sure but I think at a certain point in time Kasts did have such a toggle. :) That was before it was able to sync with anything. It might indeed be useful to reintroduce it. Anyway, if we're discussing the scope of syncing full sets of episode "played" states across devices, then, in my opinion, it would be advisable to extend the sync API to include such field explicitly. Maybe also add a "queued" state or "queue position", although that might not be implemented by all apps?
(In reply to qwasi_1999@yahoo.de from comment #2) > So to get a 1:1 state with both, AntennaPod & Kasts, This is the way to go? > > After I've done the initial sync (either AntennaPod or Kasts being > empty/clean before), I mark an already played episode in AntennaPod or Kasts > as unplayed, sync again, mark it as played again and do another sync? Will I > get the 1:1 state with this? I can only speak for Kasts, but, yes, if you would toggle the played state twice in Kasts, it should then sync the state of all episodes across to AntennaPod. Any further updates should then sync "perfectly". And, again, there is hardly any way around defining the state of each episode explicitly once after setting up the sync in order to get *unambiguous* sync results. Remember that there can (and will be) be lots of potential conflicts that the apps need to be able to resolve when syncing. This procedure will take a one-time effort when you set up the sync on the first device (and after adding each new feed); it should then work perfectly for any new device from that point onwards. > Is there something AntennaPod could do to improve the initial sync? I don't know AntennaPod well enough. I think there was a "force sync" button that might do what you want to achieve; but it might also be doing something completely different. But, again, I think it's a bad idea to force push all episode states to the server on initial sync *by default*, because that e.g. would overwrite any states that might have already been on the server. Of course, having the option available (as non-default) would be ok if there's a big warning sign saying that it will overwrite everything on the server.
Created attachment 149329 [details] AntennaPod sync behaviour for state PLAYED screenshot of AntennaPod app next to gpoddersync table in phpmyadmin
> I'm not sure but I think at a certain point in time Kasts did have such a > toggle. :) That was before it was able to sync with anything. > It might indeed be useful to reintroduce it. > > Anyway, if we're discussing the scope of syncing full sets of episode > "played" states across devices, then, in my opinion, it would be advisable > to extend the sync API to include such field explicitly. Maybe also add a > "queued" state or "queue position", although that might not be implemented > by all apps? These features in the api sound useful, especially syncing the queue would be great. But I am not sure whether the Nextcloud-Gpodder api should alter even more from the original gpodder.net. We already allow syncing by GUID, which is not specified by gpodder.net. Altering even more could make it more difficult to allow synchronizing with gpodder.net and Nextcloud-Gpodder in the same app. I might discuss this with the repository owner of the api, it would definitely be a useful feature. I just tested it and it seems like AntennaPod synchronizes the state PLAYED by POSITION being equal to TOTAL (or probably even by being close to TOTAL, I think it even has an option for such a deadzone in seconds): https://bugs.kde.org/attachment.cgi?id=149329 (screenshot of AntennaPod app next to gpoddersync table in phpmyadmin)
(In reply to JonOfUs from comment #7) > These features in the api sound useful, especially syncing the queue would > be great. But I am not sure whether the Nextcloud-Gpodder api should alter > even more from the original gpodder.net. We already allow syncing by GUID, > which is not specified by gpodder.net. Altering even more could make it more > difficult to allow synchronizing with gpodder.net and Nextcloud-Gpodder in > the same app. > I might discuss this with the repository owner of the api, it would > definitely be a useful feature. Indeed, keeping compatibility with gpodder.net is also important. I'm also not looking forward to maintaining two implementations. :) Just saying that that would be the proper way to deal with it. ;) > I just tested it and it seems like AntennaPod synchronizes the state PLAYED > by POSITION being equal to TOTAL (or probably even by being close to TOTAL, > I think it even has an option for such a deadzone in seconds): > https://bugs.kde.org/attachment.cgi?id=149329 (screenshot of AntennaPod app > next to gpoddersync table in phpmyadmin) Indeed, that's also what my investigation of the source code and output of AntennaPod showed at the time. That's why the implementation in Kasts does the same thing (also with dead zone at the end) to ensure maximum compatibility with AntennaPod. So from a practical point of view, it's not that bad, but it still feels like abusing the API. :)
A possibly relevant merge request was started @ https://invent.kde.org/plasma-mobile/kasts/-/merge_requests/74
Git commit 67c96fdfbc42666fb92e615c174bd3f6622776d4 by Bart De Vries. Committed on 01/07/2022 at 20:03. Pushed by bdevries into branch 'master'. [Sync] Enable pushing all local episode states to server M +61 -1 src/qml/Settings/SynchronizationSettingsPage.qml M +58 -1 src/sync/sync.cpp M +3 -0 src/sync/sync.h M +1 -0 src/sync/syncjob.cpp M +1 -0 src/sync/syncutils.h https://invent.kde.org/plasma-mobile/kasts/commit/67c96fdfbc42666fb92e615c174bd3f6622776d4
Git commit 01cb685d54ebf0f902e74fef75c836da46bf4ba5 by Bart De Vries. Committed on 01/07/2022 at 20:03. Pushed by bdevries into branch 'master'. Add option to mark custom amount of episodes as unplayed when adding new feed M +32 -0 src/qml/Settings/GeneralSettingsPage.qml M +22 -0 src/settingsmanager.kcfg M +14 -1 src/updatefeedjob.cpp M +1 -0 src/updatefeedjob.h https://invent.kde.org/plasma-mobile/kasts/commit/01cb685d54ebf0f902e74fef75c836da46bf4ba5