Apple Player Update Beta Testing

Plex Players Player Betas
, , ,
1077

@Craig_Holliday:

I definitely think this would be a huge step forward, and allow us all to have the same fixtures to compare and test with. For now, a google drive folder would be more than sufficient, I imagine. Don’t let good be the enemy of progress on this one!

However, I strongly feel this is only half the story.

Of course, all of this is said with lots of respect for the hard work you are doing, and not in any way should it be taken as criticism, but hopefully to spark innovation, etc.

From my perspective, I think that it’s critical that there’s a foolproof way to capture and report consistent, ‘verifiable’ info. To that end, reproducing logs that (in one line/event) include EVERYTHING that you/we need to be able to understand the context in which that experience happened in.

It’s great that people here are taking the time to capture the relevant items, but unless you have some kind of automagical parser that can digest a log and turn it into something easily assessed and comparable, then I would imagine you are likely spending far far too much time trying to process and digest what happened within a user’s setup.

Also, given that some of the elements that may impact play state aren’t in the logs, so it relies on user reporting (thermal state, for example), which obviously can change (sometimes dramatically, right?) during playback. So even if a reporter mentions it, it may not necessarily be valid – it may not be the state when an event happened.

Personally, i’ve started noticing random quits during playback – playback stops, the Plex app quits entirely and switches to the screensaver – it feels a lot like an OOM or thermal state kill by the app switcher/task manager… but without logs or any way to tie it to console or similar – it’s pretty tough to get you relevant meaningful info, other than “it randomly crashed”.

So, tl;dr: Will you improve the log format also, so we have an easier tool to report exact settings / playstate for faster and more accurate comparison/diagnosis?

again, no criticism meant here, just hopeful we can have a few more tools!

thanks!

1078

@imajes @Craig_Holliday

The issue of ATV client random quits. I can concur this has been happening on this release but could not tie it down to any particular issue or circumstance.

It has happened with high bit rate 4K DoVi/HDR10 (HEVC Main 10). EAC3

With low bit rate B & W. (480p (H.264 Constrained Baseline) AAC

Have tried to reproduce without luck on same title

The Title quits without warning or any early defects and returns to the Home Screen, Resume works without issue then plays as intended.

So my conclusion: This was not happening (9616) would be a good place to start

1079

There’s possibly a non zero chance it’s to do with the extra logging… so i reckon this might go away once the app is more production-streamlined. (at least, i hope!)

1080

Yes, I think it is a good idea to have better-formatted logs that provide more information about the player’s state.
In most scenarios, a developer will need to reproduce the bug by stepping through the code with a debugger, profiling, or just validating a fix.

Personally, I don’t spend a lot of time reviewing logs. While there seem to be a lot of logs, it can be fairly simple to find what is required to debug a basic playback issue.
With playback not starting or failing during playback, those logs are clear.

The issue with random quits during playback is a good example of where logs would be beneficial.
Though the logs as they are right now allow me to see what type of media is being played, the verbose logs do give me playback states, and I’ll still try to correlate multiple tester setups so I can reproduce the issue.
If the issue is a memory leak, I will definitely have to reproduce it to properly profile the player.

That doesn’t mean that verbose logs don’t help with reproducing issues; it only means that what we have right now is helpful enough.
I’ve been doing this specific work for a while now. For many years, I have discussed and worked on using logs to replicate playback sessions more systematically.

My big issue right now is consistently reproducing issues, tracking those issues for each user/setup, and validating the fix for the specific issue.
I have also discussed this internally with the team and have heard about similar problems with systematic testing.

That said, I do believe these are good ideas that will be implemented. I also take them as constructive feedback, so don’t worry about it coming off the wrong way.

1081

On the point about random quit outs or closing of the app:

Do y’all have verbose logging and the Newer Audio Engine on?

The verbose logging was added so that is a good suggestion.

I may have found a memory leak with the Newer Audio Engine but it seemed to only be happening in the new app. I also thought we would have seen that before but I’m not sure.

1082

Fantastic feedback.

Could you send me some samples of the Anime you are playing back?
I don’t have a ton of media with as complex subtitles.
This is something I can definitely work on.

By new audio engine you mean the setting that is “Newer Audio Engine” correct?
That one does seem to have problems especially with receivers and Airplay as I have been working on it recently.
Just clarifying because I’ve been seeing similar issues.

1 Like
1083

Could you send me your app logs?
I bet it is something with how the views are loaded but your logs may help in debugging.

1084

What is your setup?

I’ve been working on issues with Airplay that people have been experiencing with HomePods and I am consistently seeing the issue with scrubbing/seeking/pausing etc having lag.

1 Like
1085

Yep this is what I’m thinking.
Or a server where y’all can download videos that are provided.
We obviously have to keep in mind the normal issues with sharing/hosting media, like you’re saying.

2 Likes
1086

Newer audio engine is ON, I will turn Verbose Logging on and send logs on next quit out.

cheers

1089

I understand where you’re coming from, but I see things a bit differently, and here’s why:

Right now, we don’t have clarity on whether all combinations of settings—codec, player, device, format, and so on—perform as expected. For example, starting with a simple sample media file (e.g. 1080p / h264 / AAC / 2-channel), we could all test it and compare results.

To make that process practical and useful, we’d need a structured approach. For instance:
1. Everyone plays the same file, using the same method of playback;
2. Collect logs in a standardized format (JSON, ideally).
3. Submit them to a shared repository or tool for analysis.

This would make it easier to generate reports showing whether playback succeeded or failed, along with potential reasons why. Even a basic AI could assist with anomaly detection for a first pass.

If that’s too ambitious, a simpler option could be a structured Google Form for users to submit their setup details and test results. The data could then be compiled into a format that’s easy to analyze.

With this approach, we’d get a clear picture of specific configurations causing issues and the types of errors occurring. That would make debugging and fixing far more straightforward.

From there, we’d repeat the process for other media types, incorporating regression testing along the way. This methodical testing could help prevent the cycle of fixing one issue while introducing another.

Without a structured system like this, I’m worried it’ll feel like two steps back for every step forward.

1090

Yes, my PMS is a static IP. All my patch panels and cables tested good with a fluke cable tester. I’m a Network Engineer and understand how networks work. I was just reporting what I was experiencing, which seems to be possibly due to the verbose logging that is enabled. Instead of the app crashing like others were reporting, mine just slowed to a crawl. My assumption is that the memory got full from logging and didn’t leave any headroom for the video buffer, which explains why it was only buffering a few seconds of video at a time, hence the slow throughput I was seeing on the Apple TV port. As soon as I closed the app and opened it backup, that cleared the memory in use by the app and it is now buffering correctly. No Rx or Tx errors on the port. Speedtest app on the ATV shows my full gigabit speed being used over the ethernet port. Does not appear to be a network issue.

It took a few days for this to happen with nightly watching sessions and I usually keep the app open while the ATV goes to sleep so it resumes with an already open Plex app. Until I can reproduce regularly I will refrain as to not clog up the forum. Once I can narrow it down, I will let you know what causes it.

1092

logging 3.15.00 PM.zip (1.2 MB)
i can’t seem to recreate the issue now, but i do have a recent file that acts like its going to play, then just goes to the screen to watch the next episode. file works fine on browser/non beta player as is. setting to auto convert, gets it started for a few seconds/minutes then it does the same thing.

1093

Apologies I believe we’re saying similar things I’m only being too verbose in my thoughts.

Yes we should do the structured approach with however we can track it. I’m tracking everything internally in my own way but I’d rather have something more open to the testers in this thread to submit directly.
Like you’re saying.

I only believe the logs we currently have are okay to diagnose issues so we can focus on the other parts of this process.

1094

I do believe your assumptions are good here. I think there is some memory issue I’ve missed.
Either way, just acknowledging that yes I see your report and let me know if you narrow any more things down.

I’ll continue to investigate on my side.

1 Like
1095

Could you turn on verbose logs and capture the issue with the file that just goes to the next episode?

1096

attached. i also thought the file was bad, so i replaced it, refeshed metadata, and did the plex dance.
logging.zip (1.2 MB)

1 Like
1097

Newest Apple TV 4K > Yamaha TSR-700 Receiver > Samsung s90c.

Both Match settings on.

1099

I’ve sent you two sample files via private message for further analysis.

To confirm your question: Yes, the problems I mentioned are related to the “Newer Audio Engine” setting. The old audio engine, on the other hand, works perfectly for me so far. However, I haven’t had the chance to test it with 4K videos or other audio formats yet.

I’ll definitely share more feedback on how both the old and new audio engines perform once I have more time to test these scenarios.

If I can provide any additional information or assist further, please don’t hesitate to let me know!

1 Like
1100

So I tested again last night and played a 4k movie. About 1hr 30min in (roughly) the Plex app just quit. Back to the ATV home screen. I realized that verbose logging was not enabled. Audio is EAC3 5.1. I sent you logs via direct message.

So I resumed playback and it finished the movie without any issues.

When playing 4k HDR content on my iPhone 13 Pro Max (iOS 18.2.1), the thermal state ramps up quickly to fair and then serious within 10 minutes. Causing my phone to lag. Playback remains smooth, just switching to other things and typing is choppy (thermal throttling). Pip worked for the most part, but when resuming back to the Plex interface there was a pause in the video.

Hope this helps.