Bug: API does not respect client Resume Playback setting

#1

On my client (Apple TV 4K) under Playback settings I turned Resume Playback off.

That works as expected when accessing the Channels app directly. No matter where I am in a video, pressing play restarts it at the beginning.

But when I play it via the API, it still resumes where it left off. Is this a bug?

API - Play from beginning?
#2

Ok what’s happening is that it always resumes. This was decided as this seemed to be the most reasonable default without having to provide any options.

But it def feels not great.

We’ll do a revamp on this stuff soon and add resuming as an option.

I think it should use defaults, but allowing you to specify resume to be false so that it doesn’t resume. This way there’s expectations set AND the ability to override it.

#3

Thanks @maddox!

#4

Can you define "play it from the api"

Are you making the call yourself? What is the endpoint you're using?

#5

OK, the latest TestFlight beta improves this a bit.

It no longer forces resume or auto play styles. It now derives these from the settings. So if you tell it to play a show or a recording, it will first check the TV Show's Auto Play setting, and use that (or the system setting if the TV Show's auto play setting is set to Default). Basically the exact same thing that happens when playing from within the app.

Additionally, it does not force resume and instead uses the system setting to decide how it resumes.

This does two things:

  1. removes the forced resume and auto play
  2. works just like when playing from the app
  3. allows you to override how things play back by using existing settings.

What this change does not do, is allow for a resume override at the API endpoint level. This is a bit trickier and may come later, but we wanted to roll this change out first.

#6

I am using this endpoint via Home Assistant:
/api/play/recording/:recording_id

Thanks for making the changes! I am looking forward to checking it out!

#7

@maddox I just installed the new Apple TV 6.0.1 version today. I'm not sure if I have discovered a bug or if this is intended behavior:

If a video is stopped (either via api/stop or manually stopped within the app) - The next time it plays via the API it does correctly start at the beginning.

However, if Video A is playing and then the API is used to start Video B without explicitly stopping Video A first - If you return to play Video A later it will resume rather than start from the beginning.

#8

Yeah, probably a bug. It's just another of the millions of scenarios of all of this, and was missed.

I'll look into it.

#9

Wait, I'm confused.

So:

  1. Video A is playing
  2. API is called to start Video B
  3. Video player replaces Video A with Video B
  4. Stop player
  5. Browse to find Video A
  6. Click to watch Video A
  7. Video A resumes from where it was last watched

Is this what you're seeing? Because this is appropriate.

Am I missing any details here?

#10

I knew as I was writing that, that it would be confusing! Sorry about that.

Yes, you described what is happening. So to confirm, that would be expected behavior even when Resume Playback is set to Off?

image
image740×201 23.7 KB

#11

Any time you play something by browsing to it, it should be respecting the resume setting.

Can you tell me HOW and WHERE in the app you are starting it up?

Also, can you try just playing that show normally from your library, and then playing it again to see if it does the same problematic behavior? I say this as, the first bunch of steps you described should really have no bearing on anything.

#12

Apologies in advance. I am trying to make this as easy to follow as possible!

I am doing some more experimenting. This seems to be isolated to the API. When I browse/play through the App, it works consistency.

But I think it expects a Stop to happen prior to a Play. Regardless of which video is being stopped or played. If a Stop happens, the next video to play starts at the beginning. If a Stop does not happen, the next video to play resumes.

Examples.
Assuming A and B are both queued to the beginning at Step 1:

With a Stop between each Play, everything works as expected

  1. /api/play/recording/11882 - Plays video A from beginning
  2. /api/stop - Stops video A
  3. /api/play/recording/11819 - Plays video B from beginning
  4. /api/stop - Stops video B
  5. /api/play/recording/11819 - Plays video B from beginning

But if you do not stop either video and then play video again, it will resume

  1. /api/play/recording/11882 - Plays video A from beginning
  2. /api/play/recording/11819 - Plays video B from beginning
  3. /api/play/recording/11882 - Resumes video A

If you stop after video B and then play video B again, it starts from the beginning

  1. /api/play/recording/11882 - Plays video A from beginning
  2. /api/play/recording/11819 - Plays video B from beginning
  3. /api/stop - Stops video B
  4. /api/play/recording/11819 - Plays video B from beginning

And if you stop after video B and then play video A again, it starts from the beginning

  1. /api/play/recording/11882 - Plays video A from beginning
  2. /api/play/recording/11819 - Plays video B from beginning
  3. /api/stop - Stops video B
  4. /api/play/recording/11882 - Plays video A from beginning
#13

OK, this is what I was trying to discern with my step list originally.

So it's only happening if you launch a video via the API while something else is already playing. This makes sense as it's a very specific code path, vs all the others. And here, it's probably still forcing resume.

#14

Yes, that sounds correct. So is this an issue that can be corrected or should I just shut up and be happy with what I have? :slight_smile:

#15

Nah, I'll get to it.

1 Like
#16

I figured it out, but it's actually buried realllllllllll deep and gonna be hard to resolve. This explains why it got missed when this change happened a while back.

#17

Well, just know your hard work is appreciated!