Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Synchronize episode status with gpodder.net #542

Closed
danieloeh opened this issue Nov 3, 2014 · 28 comments

Comments

Projects
None yet
@danieloeh
Copy link
Member

commented Nov 3, 2014

Link: http://wiki.gpodder.org/wiki/Web_Services/API_2/Episode_Actions

Especially the current playback position of an episode should be synced.

@kkoksvik

This comment has been minimized.

Copy link

commented Nov 3, 2014

+1

@dfarley1

This comment has been minimized.

Copy link

commented Jan 2, 2015

I would love this, I've been looking for a simple (and free) way to sync podcast episode status between PC and Android for a while! Definitely +1

@mfietz

This comment has been minimized.

Copy link
Contributor

commented Mar 18, 2015

So when should a sync occur? As soon as the episode is paused (play) or the download is started? Or should the actions be synced in the same process as the subscriptions?
We could even have different intervals for uploading to and getting actions from the server. If we update to often, the battery gets drained quickly - if we update now often enough, we might miss an update.

Easiest to implement: Sync in same process as subscriptions, user can always force refreshing...

@dfarley1

This comment has been minimized.

Copy link

commented Mar 18, 2015

What is the process for subscription syncs? I definitely wouldn't want an episode marked as read/listened to as soon as it's downloaded, I usually download a few episodes ahead of what I'm actually listening to.

@mfietz

This comment has been minimized.

Copy link
Contributor

commented Mar 18, 2015

As far as I can tell, subscriptions syncing only concerns the feeds - No information about the actual items or episodes is submitted here.
First it gets the subscriptions that where added since the last sync (from other devices or via web interface) from the server and then tells the server which feeds where added locally.

Actions only include download, delete, play and new (forget state). Listened or unlistened can only be determined locally by the position of the play action.
What Farlo describes would only result in a download action. AntennaPod could perhaps delete the item when it was downloaded to another device, but I would probably just ignore this kind of action. Delete and play are much more interesting

@keithzg

This comment has been minimized.

Copy link

commented Mar 18, 2015

The easiest to implement option seems like the best one. Having this sync tied to the existing subscriptions sync makes the most sense in my opinion, since that's around the time you'd need to learn such information anyways (so that for instance AntennaPod can learn that the user already listened to a new episode on another device, so right after pulling down that feed it can already mark the episode as having been listened to and avoid superfluously downloading it). Conceptually, I think it's easy for users to think that the existing sync button is just generally how everything is synchronized. I assume then the background procedure would be first synchronizing feeds and then pulling down any new episode actions from gpodder.net so that the actions could be applied to the newly-refreshed episode listings?

I think you're also right on ignoring Download actions. The most important would seem to be Play, for the sake of position and marking episodes as having been listened to. I'm not sure Delete is even needed, though, since as long as Play is synchronized and thus episodes that are finished are indeed marked as listened to, the episode cache and queue setup will take care of that, right? Yet for instance a person might manually delete an episode on a device where they're running out of space, under the intention of listening to it on their other device.

@sim6

This comment has been minimized.

Copy link

commented Mar 18, 2015

I don't know why a reference node does not apear. Anyway, my point of view is in #682 (comment)

@mfietz

This comment has been minimized.

Copy link
Contributor

commented Mar 19, 2015

I'm beginning to hate gpodder - nothing seems to work as described...

The basis sync mechanism is implemented (send download, delete and play, retrieve play). For some stupid reason it seems there can only be one play action per episode (feed item). Sending another play action (with new position), this new action seems to be ignored completely.
Quite frustrated right now - gpodder is and was a good idea, but the people behind it don't seem to care anymore :/

@Horrendus

This comment has been minimized.

Copy link

commented Mar 19, 2015

The people behind it still care, but are busy with other stuff than working on gpodder. I think it should support more than 1 play action, but could be wrong, didn't work with the API for quite some time. You could write to the gpodder mailinglist and see if this should be possible.

@mfietz

This comment has been minimized.

Copy link
Contributor

commented Mar 20, 2015

@Horrendus just did that.

Also filed a bug for top tags (gpoddoer search categories) which is IMHO also broken

@mfietz

This comment has been minimized.

Copy link
Contributor

commented Mar 26, 2015

Good news everyone! (Sorry, could not resist)

Just heard back from on of the devs. The problem should be fixed and I will begin testing tomorrow.

@mfietz

This comment has been minimized.

Copy link
Contributor

commented Mar 27, 2015

There are two kinds of people: Those that play podcasts two the end and those who do not.

The point of discussion is:
When a podcast is not played all the way to the end, what is a reasonable threshold to assume the episode can be marked as "read"?
"Mark as read" policies can be relative (less than 5% of the episode left) or absolute (only 30 seconds left). We can combine relative and absolute thresholds freely.

I'm open for suggestions.

@TomHennen

This comment has been minimized.

Copy link
Contributor

commented Mar 31, 2015

I like this idea in theory and I think it would work well combined with a more prominent skip episode button (which is a feature for another day).

I feel like absolute would be the safest. You can imagine a very long podcast where you'd miss significant content with a percentage based approach. Also, most podcasts probably have outros that are < 30 seconds.

I do have one or two that have outros that are longer than 30 seconds, but those podcasts are not especially long by themselves, so relative wouldn't help much either.

So, I think the principle of least surprise says absolute makes the most sense. I personally think we should default to 'on', since that's the most natural behavior (very few people probably stop or skip an episode with that much time left expecting to come back). If we want it to be optional we could allow people to turn it off if desired.

@mfietz

This comment has been minimized.

Copy link
Contributor

commented Mar 31, 2015

I see no harm in giving the users control. Programming is not that much more complicated and we avoid any "but I think the value should be x" or "I have this odd podcast and I want this to work on it" discussions.
Reasonable options should be: off, 15s, 30s [default], 45s, 1min [alternatively: 1min and 2min; just want to have the default value in the middle...]

Endgame: I think you should actually be able to set this value per feed (global value if not set). Update interval for feeds, too. In most cases, the user knows best.
Beginners get reasonable default values and experienced users can adjust these settings to their habits.

btw, whatshallwecallit? "Smart mark as...?"
As I am not a native speaker, what is a good generic term for listened and watched? I find it quite annoying to mark an audio episode as read... Completed? Finished?

@TomHennen

This comment has been minimized.

Copy link
Contributor

commented Apr 2, 2015

My thinking was that one of the reasons I liked AntennaPod was how simple
it was compared to something like BeyondPod. It had the interface that was
most similar to Google Listen. I think a lot of podcatchers have a ton of
features but aren't necessarily usable. I worry about that for AntennaPod,
but realize this one option isn't going to make or break it either way.
Long term I think I'd like to add a 'simple' user interface (either as a
mode or a different skin for this app) that uses sensible defaults and does
what the average user would expect. With podcasts becoming more popular it
won't be just techies that are using the apps. But, I'm getting ahead of
myself.

At first I was thinking this should be a per feed thing too, but I'm not
sure I'm convinced. Personally, if I were to use this, I'd set it to 30
seconds and want it to apply to all my feeds. That would just match my
listening style the best and require the least amount of interaction to get
it done. Then I wouldn't have the experience of "why does this work for
feed X and not feed Y" only to realize it was because i set it for feed X
and not feed Y. Thoughts?

As for what to call it - 'Listened'?

The use of 'Read' in the app is definitely confusing.

On Tue, Mar 31, 2015 at 3:56 AM Martin Fietz notifications@github.com
wrote:

I see no harm in giving the users control. Programming is not that much
more complicated and we avoid any "but I think the value should be x" or "I
have this odd podcast and I want this to work on it" discussions.
Reasonable options should be: off, 15s, 30s [default], 45s, 1min
[alternatively: 1min and 2min; just want to have the default value in the
middle...]

Endgame: I think you should actually be able to set this value per feed
(global value if not set). Update interval for feeds, too. In most cases,
the user knows best.
Beginners get reasonable default values and experienced users can adjust
these settings to their habits.

btw, whatshallwecallit? "Smart mark as...?"
As I am not a native speaker, what is a good generic term for listened and
watched? I find it quite annoying to mark an audio episode as read...
Completed? Finished?


Reply to this email directly or view it on GitHub
#542 (comment)
.

@TomHennen

This comment has been minimized.

Copy link
Contributor

commented Apr 2, 2015

Ah, just saw PR #706 (sorry I didn't get to answer this sooner). I like the user of 'Played' there. That's actually better than 'Listened'.

@mfietz

This comment has been minimized.

Copy link
Contributor

commented Apr 2, 2015

@TomHennen I think we are on the same page on this. Mac user here. I like clean GUIs. I like the principle of least surprise.
I used some linux distros for a while - most GUIs are far to complicated and have far to much options to chose from.

On the other hand, I don't want to be patronized as a user. Setting the threshold for mark as played is such a case. And if I find a podcast where the outro is 50 seconds long, I probably get angry if I cannot set an individual threshold for this one...

I don't like the idea of a switch from a simple GUI to some kind of expert mode. For me, this shows a basic flaw in the layout and design.

Individual feed settings would probably go in the same fragment as the feed authentication settings. This currently is the feed info - an issue for another day...

@TomHennen

This comment has been minimized.

Copy link
Contributor

commented Apr 2, 2015

It sounds like the thing to do, long term, might be to have some set of
global options that can be overridden on a per feed basis.

I wonder if we could make some good gains in usability by just changing
some of the defaults for settings in the app. Existing users wouldn't see
the behavior change, but new users might have a better experience.

On Thu, Apr 2, 2015, 3:13 AM Martin Fietz notifications@github.com wrote:

@TomHennen https://github.com/TomHennen I think we are on the same page
on this. Mac user here. I like clean GUIs. I like the principle of least
surprise.
I used some linux distros for a while - most GUIs are far to complicated
and have far to much options to chose from.

On the other hand, I don't want to be patronized as a user. Setting the
threshold for mark as played is such a case. And if I find a podcast where
the outro is 50 seconds long, I probably get angry if I cannot set an
individual threshold for this one...

I don't like the idea of a switch from a simple GUI to some kind of expert
mode. For me, this shows a basic flaw in the layout and design.

Individual feed settings would probably go in the same fragment as the
feed authentication settings. This currently is the feed info - an issue
for another day...


Reply to this email directly or view it on GitHub
#542 (comment)
.

@mfietz

This comment has been minimized.

Copy link
Contributor

commented Apr 2, 2015

Do you have something particular in mind?

@mfietz

This comment has been minimized.

Copy link
Contributor

commented Apr 2, 2015

Speaking of usability, going off topic now:
I believe https://github.com/amlcurran/ShowcaseView could make a huuuge difference in usability. For example, we could show the user on first startup how to add a feed.

API level says 11, but there is a legacy branch and also a pull request to support API level 7

@TomHennen

This comment has been minimized.

Copy link
Contributor

commented Apr 3, 2015

The following should probably be default:

  • Continuous Playback
  • Update Interval (if we add a feature so that it only auto-updates when charging)
  • Automatic download, when on wifi and when charging.
  • Expand Notificaiton
  • Persistent playback controls
  • Smart mark as played (with some low default value, 15 seconds?)
@TomHennen

This comment has been minimized.

Copy link
Contributor

commented Apr 3, 2015

ShowcaseView does look nice. Doesn't seem like the PR you referenced is getting any love though.

What would be your preferred method for integrating it, legacy branch or the PR?

@mfietz

This comment has been minimized.

Copy link
Contributor

commented Apr 3, 2015

I prefer the PR:
According to the developers, the legacy branch is less stable. Also, the changes to lower the API level are quite small.

@TomHennen

This comment has been minimized.

Copy link
Contributor

commented Apr 3, 2015

Sounds good.

@pdurbin

This comment has been minimized.

Copy link

commented Jan 31, 2016

It looks like this feature was implemented in pull request #706 which is why this issue was closed 15 days ago. Mostly I'm leaving this comment because it wasn't clear to me if this had been implemented or not. @TwoD seemed confused by this as well, based on a comment from 8 days ago: #706 (comment) . In that comment (as well as in this issue) frustration is expressed about general flakiness with the gpodder.net service. I used gpodder.net for a few months but ended up giving up on it since the sync seemed so buggy (see #359 (comment) for a bug report by me). That was last spring so I thought perhaps I'd give the gpodder.net integration another try because I'm interested in any way to get my playback history off of my device so I can play with the data (I also looked at the "export/import database" issue at #377). However, I can't even visit https://gpodder.net right now because the site is showing "Internal Server Error".

To sum up the brain dump above, I like reviewing my playback history on my device but I'd also like to "liberate" this data somehow, by getting it off my phone and onto, say, my server. Could the playback history data be exported as JSON on a regular basis (POST'ed to my server? I'd be happy to write a little API to receive the data)? Is it possible for me to write a little Android app that accesses the playback history for them AntennaPod database (or it is hidden and sandboxed somehow)? Once I have the data in a form that I can play with it, I think I'd like to write a little software so that I could rate individual episodes and perhaps occasionally write little reviews of why I liked them. I'd publish this on my website somewhere. This way I (or others) could look back and reflect on which episodes were really good and worth listening to again or sharing with others, depending on their interests.

Now that I've written all this, I'm wondering if what might work for me is integration with the Huffduffer API at https://huffduffer.com/api . I could abuse their tagging system a bit by creating tags with names like "5stars", "4stars", "3stars", etc. (See a list of tags at https://huffduffer.com/tags .) However, I feel like it would be better for me to use Huffduffer at the very end of my "curation" process. That is, I want my workflow to be more like this:

  • Listen to an episode on AntennaPod. Great episode! Rate or review it somehow.
  • Rate or review episode from AntennaPod by...
    • Giving it a rating or review via gpodder.net? Is this possible?
  • Rate or review episode from my own server based on the latest playback history from AntennaPod.
    • AntennaPod playback history is synced to my server somehow?
  • Rate or review episode from a custom Android app on the side I develop
    • Can an Android app I create read the playback history from the AntennaPod database? Or is it sandboxed somehow?
  • Once episodes have been curated (rated, reviewed) decide if/when/how to post them to my own website and/or Huffduffer (may have nothing to do with AntennaPod).

I hope this makes at least a little sense! Thanks for AntennaPod! It's great!

@TwoD

This comment has been minimized.

Copy link

commented Jan 31, 2016

@pdurbin I filed a bug report about the website just now, seems the internal error includes the API.
The API was working when I wrote my post above, but it's possible much of the issues we're seeing are due to it being unreliable.

https://bugs.gpodder.org/show_bug.cgi?id=2061

@mfietz

This comment has been minimized.

Copy link
Contributor

commented Jan 31, 2016

Giving it a rating or review via gpodder.net? Is this possible?

The gpodder API [https://gpoddernet.readthedocs.org/en/latest/api/] doesn't support that.

AntennaPod playback history is synced to my server somehow?

Seems far to complicated to me.
First, we would have to implement some system to tag episodes or create lists with them. Then, we would need either a way to export these episodes to a file or even specify a server API that you could implement.
Don't think we should implement stuff nobody (less than 5 users) will actually use.

Can an Android app I create read the playback history from the AntennaPod database? Or is it sandboxed somehow?

Unless your device is rooted, no. That would be a HUGE security concern if apps could just read other apps' databases.

@Teyro

This comment has been minimized.

Copy link

commented Mar 16, 2017

Hi everyone,

Well i am useing a mix of "BeyondPod" and AntennaPod because i missing the episode sync feature.... Is there a chance to get someone who implement this for money?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.