Even if the original developer said so, I still find it surprising. Developers make mistakes too, I just don’t see how the OpenGL API wrapper around Metal could be a bottleneck here.
While I agree with what you’ve written, if true, I feel like there could be other (short term) solutions. Basically if it’s possible to instrument the delay introduced by this “shim” or use some sort of buffering system with a to regulate the pipeline to a fixed/known delay, then that could be a be used to adjust the audio delay. Just spitballing, as there obviously aren’t enough specifics here to know what is in their control. Either way it is… a mess.
I find it dumbfounding that you struggle to see that this has led to potential issues with their current implementation. It makes sense that this would be related to the issue.
‘Wrapper’ approaches likes this often cause unforeseen issues in development land all the time.
Instead of shaking your head at the idea that this is even being discussed, let’s at least encourage Plex to further investigate this as the core of the issue. It can’t hurt.
Imagine yourself being responsible for the Plex ATV client. An engineer comes to you and suggests to rewrite the client from the OpenGL API to Metal in order to fix an annoying issue the users have been complaining about for years. You invest 6 months, you rewrite the rendering pipeline, the sync issue is still there.
Or, some other engineer comes and suggests to reimplement the audio engine. You invest the time, rewrite the audio engine (adding an audio offset feature along the way), and the sync issue is still there.
Rewriting is fun, shifting the responsibility onto some past decisions and third-party codebase maintainers is convenient, but when you hear the convincingly-sounding explanations like “the OpenGL shim causes this”, it’s important to ask “How, exactly?”
Hypotheticals are fun.
If someone has done their own tests and posts their findings, I’m not going to immediately imply they are wrong just because I don’t understand the how.
That’s the thing, we didn’t get to see the “how”, and I, for one, am genuinely curious to see it.
I’m not going to argue further. I just wanted to point out that there is no magic in computers, pretty much everything has an explanation. If somebody believes they have found a root cause, they should either have an explanation for the “how”, or continue the investigation until it’s clear what’s going on. Jumping to conclusions too soon will only delay the resolution of the problem.
Trusting what someone says is key.
@Achilles knows enough to be trusted. Go re-read what he has shared thus far.
The issue is known, and it can be fixed. Period.
Of course it can hurt. We don’t want Plex barking up the wrong tree. Lord knows they have barked up enough of them during the life of this thread.
I have just given Plex in the App store 1/5 score and written the app is broken.
Can the rest of you please also do this so the problem will be highlighted to potential new users?
The wrapper is the issue if you trust what @Achilles shared.
No, it will not hurt to have them at least look into this. Not complicated to understand.
I have sync issues on plex on my apple tv. I have zero sync issues with infuse on the same set up.
1 Like
What do you want them to do? You say the wrapper is the issue. It’s required with their current solution therefore no way around the delay.
Only likely solution is a complete rewrite using Metal. They couldn’t do this before they laid off 20% of their staff, so pretty sure it won’t be a priority now for them.
Using native player is not an option either, because that has its own deficiencies.
They constantly said ‘we don’t see the issue on our end’, then said they did when we pushed them on it.
If the wrapper is the issue, that’s the issue.
The staff cuts may pave the way for new eyes on old issues. Leaner dev teams can be a good thing. I speak from experience. We also don’t know all the reasoning for specific layoffs. There may have been some obstinate devs in regards to this issue and others. Who knows.
What I do know is that they can fix it. How they do it is up to them. Either they fix it or they don’t.
Yup, this. Plex doesn’t have the resources to address fixing Apple TV (or the interest/prioritization) to do so considering those resources. They are trying to move beyond just being a media playback app, and Apple TV is one of the smallest media player install bases out there. I’m disappointed that they weren’t more candid earlier about the choices they were facing and exploring, but it makes sense now. I don’t expect to see a fix here until Apple updates their video codec (the “old” codec) such that Plex can use instead of MPV. (Would love it if MPV supported Metal, but that doesn’t seem to be on the table.)
Nobody knows for sure that ‘Plex doesn’t have the resources’. That’s a bit hyperbolic.
Supposedly many of the 37 that were let go were apparently involved across the areas that we all wish they would have avoided.
Plex specifically said that along with additional internal changes, they would be “reprioritizing product road maps and reducing marketing spend”, which seems like a positive shift.
iOS/iPad OS/tvOS uses mpv. Why does only tvOS suffer from sync issues? I don’t see these sync issues on my iPad.
Probably because those devices aren’t outputting any audio/video to a third party device.
1 Like
Has anyone tried Emby? Curious if it’s worth changing media servers over this.
Use Jellyfin.
It’s missing polish, in my opinion.
