@captriker said:
Tell me if this is related or if I should open a different thread:
On Friday we were without Internet Access. The Plex App on the XBO wouldn’t work because I wasn’t signed in. I tried to use the built in Media App to play an MKV from my server and it failed with three or four different files. I was surprised as I’m positive I’ve played at least one of them before.
This does sound like what I experienced with the Microsoft
On Sunday, with access restored, I signed into the new app and fired up an MKV. The movie played for one hour and thirty minutes and then paused once or twice and eventually stopped playing. I couldn’t get another file to play.
Did that first file finish before it stopped or it stopped and then nothing else would play? If it started playing and then stopped midway then it would be a separate issue as the audio selection situation makes the file not start at all. If it finished and then others would not play because of the DTS then it definitely could be a symptom of this issue.
I noticed that files have DCA/DTS, which isn’t listed as supported in the XBOX One MKV page. I assumed it would skip DTS and jump to AC3 instead. What jmckee describes, the audio stream selection might be an issue for problem one (not a Plex issue but an MSFT issue) but could it result in issue 2?
In theory, when it is correctly working then yes the server should try and select a direct playable stream or convert the audio to a playable format. (Some of this depends on language settings and such) Like I explained above, the stream selection could cause other videos not to play, but it would/should not stop a stream that is already playing.
The first file played and gave out 3/4 of the way through, then nothing would play.
I did just notice that the server was struggling and a reboot cleared it up so the second issue might have been a server issue. Though if it wasn’t selecting a stream that was direct playable, it might have been transcoding needlessly?
@captriker said:
Though if it wasn’t selecting a stream that was direct playable, it might have been transcoding needlessly?
That could be a possibility. However, the current way it works only the 1st audio stream in the file can direct play, every other stream needs to at the least run through the transcoder for a remux. And at point a number of other things can be triggering the transcode which could only be changed by switching the position of the streams. (Until direct play of secondary audio streams is added in)
@mbarylski said:
Is there any conclusion for the San Andreas file I posted?
There’s was a couple different problems going on in this situation. One issue is some MKV’s have definitely started exhibiting bigger problems. The other issue (and the one that inadvertently) was affecting this issue was audio stream selection. I believe what was happening was that even though the app knew it couldn’t play the Atmos audio track, the media player framework was still selecting the unplayable track causing the ‘media unsupported’ issue. This should also be the case with the built in DLNA player on the Xbox One (Although, I am not 100% sure if you can even select a different audio stream before it starts trying to playback the file in that case)
So, in the case of the San Andreas file it should work after the audio stream selection behavior is fixed. (and also a lot of situations where the issue is the wrong audio stream being played)
I’ve also got TS files from the Plex DVR that take forever to skip forward and back. I dropped a sample TS file in the OneDrive location from my private message. Can you take a look at that as well?
Will do.
I still get banding, and stuttering/flickering on San Andreas. Was this issue supposed to be fixed with the update yesterday?
@mbarylski said:
I still get banding, and stuttering/flickering on San Andreas. Was this issue supposed to be fixed with the update yesterday?
No, issues with the decoder is something that Plex can’t fix directly themselves. The only solution Plex has for those issues is to force a transcode for the file. Samples have been sent to Microsoft to look into the issue, but no information has came back regarding tracking that issue down. From what I have seen that information normally only comes back when a fix is being implemented. (IE for the memory leak crash, we knew there was a fix coming in the fall update, but not when the fall update was coming)
The patch should have fixed issues with mkv’s simply not playing because of the audio selection being reverted back to an unplayable track, another problem with mkv’s simply not wanting to play, and subtitles disappearing part way through a stream, and audio stream selection not actually changing the stream. Those were the 4 major fixes in the patch.
@mbarylski said:
I still get banding, and stuttering/flickering on San Andreas. Was this issue supposed to be fixed with the update yesterday?
No, issues with the decoder is something that Plex can’t fix directly themselves. The only solution Plex has for those issues is to force a transcode for the file. Samples have been sent to Microsoft to look into the issue, but no information has came back regarding tracking that issue down. From what I have seen that information normally only comes back when a fix is being implemented. (IE for the memory leak crash, we knew there was a fix coming in the fall update, but not when the fall update was coming)
The patch should have fixed issues with mkv’s simply not playing because of the audio selection being reverted back to an unplayable track, another problem with mkv’s simply not wanting to play, and subtitles disappearing part way through a stream, and audio stream selection not actually changing the stream. Those were the 4 major fixes in the patch.
Got it, thanks. Is there enough information in the sample files to identify the “file type” that causes issues? Something that the Plex App can identify before playing and force transcoding if it’s a file type that causes problems?
@mbarylski said:
Got it, thanks. Is there enough information in the sample files to identify the “file type” that causes issues? Something that the Plex App can identify before playing and force transcoding if it’s a file type that causes problems?
Haven’t seen anything conclusive yet. The main thing I have noticed is that the refFrames is still low (at 2) and the other discs I have seen cause the issue have a refFrames of < 3 (usually 1), and upon transcoding the file I always end up at a minimum of 3 refFrames. In my experience I have only found this with direct bluray rips (I believe it’s because its the h264 decoder and only with streams pulled as 1:1 copies). Trying to replicated this to verify it is the cause is difficult, because every tool I have used automatically bumps the ref frames above this amount. I don’t believe it is anything in the header itself, as a remux doesn’t work to fix the problem. But as we recently saw with the eAC3 in a MKV container, sometimes it is something unrelated to the video itself causing the problem. In the sample file I tried with the auto selected track which I think was the commentary track and with transcoding the audio from the TrueHD track. In both cases I saw the artifactating which is why I believe it might be the refFrames.
This issue has been reported to Microsoft. But I can’t say for 100% that the low refFrames is the cause as I can’t actually generate a sample (convert a video to that amount of refFrames) to show definitively this is the cause. Without that type of re-creatable proof, the developers are normally hesitant forcing a transcode because for a good number of users running on lower end server hardware it means they can no longer watch these types of videos.
A majority of this information is based on my debugging of the issue, Moussa has his own set of debugging he has also done, and then Microsoft (might/should) have their own set of debugging they have done. This problem has also been noticed on the windows 10 media player, so it is not something specific to the Xbox, but rather seems specific to the decoder shared by both systems.
@mbarylski said:
Got it, thanks. Is there enough information in the sample files to identify the “file type” that causes issues? Something that the Plex App can identify before playing and force transcoding if it’s a file type that causes problems?
Haven’t seen anything conclusive yet. The main thing I have noticed is that the refFrames is still low (at 2) and the other discs I have seen cause the issue have a refFrames of < 3 (usually 1), and upon transcoding the file I always end up at a minimum of 3 refFrames. In my experience I have only found this with direct bluray rips (I believe it’s because its the h264 decoder and only with streams pulled as 1:1 copies). Trying to replicated this to verify it is the cause is difficult, because every tool I have used automatically bumps the ref frames above this amount. I don’t believe it is anything in the header itself, as a remux doesn’t work to fix the problem. But as we recently saw with the eAC3 in a MKV container, sometimes it is something unrelated to the video itself causing the problem. In the sample file I tried with the auto selected track which I think was the commentary track and with transcoding the audio from the TrueHD track. In both cases I saw the artifactating which is why I believe it might be the refFrames.
This issue has been reported to Microsoft. But I can’t say for 100% that the low refFrames is the cause as I can’t actually generate a sample (convert a video to that amount of refFrames) to show definitively this is the cause. Without that type of re-creatable proof, the developers are normally hesitant forcing a transcode because for a good number of users running on lower end server hardware it means they can no longer watch these types of videos.
A majority of this information is based on my debugging of the issue, Moussa has his own set of debugging he has also done, and then Microsoft (might/should) have their own set of debugging they have done. This problem has also been noticed on the windows 10 media player, so it is not something specific to the Xbox, but rather seems specific to the decoder shared by both systems.
Awesome, thanks for the info. Sounds like a trickier issue than eAC3. Glad they’re looking at it. I’ll keep forcing transcode for now.
