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?
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.
Can you define "play it from the api"
Are you making the call yourself? What is the endpoint you're using?
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:
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.
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!
@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.
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.
Wait, I'm confused.
So:
Is this what you're seeing? Because this is appropriate.
Am I missing any details here?
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?
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.
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
But if you do not stop either video and then play video again, it will resume
If you stop after video B and then play video B again, it starts from the beginning
And if you stop after video B and then play video A again, it starts from the beginning
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.
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? 
Nah, I'll get to it.
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.
Well, just know your hard work is appreciated!
Hey @maddox - Not sure if you've had a chance to look into this yet or not, but I'm assuming it would show up in TestFlight prior to the final release. Would it be possible to get a TestFlight invite code? Thanks!
Thanks @Fofer. I see what I was doing wrong. I think you need to use the link on an iPhone first to accept the invite, and then Channels beta becomes available on TVOS.
