1.7.x creates (some) MKV files that won't stream to (some) Plex clients without transcoding

Unlike the UK problem, in Australia it appears the MKV files that DVR recordings produce are valid and will play on normal media players. However streaming from a QNAP it appears that PMS incorrectly attempts to transcode everything, resulting in an unplayable ‘not powerful enough’ message.

This certainly happens on the PS4 client. The android client seems to just hang trying to play the stream.

Have had to downgrade back to 1.5.1. Hopefully this will be fixed quickly.

it may well be related, plex are working hard on a fix for UK, just give them a little time, and see if it helps you, if not respond here and i will draw it to there attention.

@lennier76 That sounds more like an issue with your server, and what the client supports? However, could you give me a little more information on what channel you were recording, and what program (where in Australia would be good too, I’m in Melbourne). I’ll look into it. :slight_smile:

Hi @DaveBinM, it’s certainly an issue of what the clients support and the fact that I can’t transcode (QNAP ARM server), but that was never an issue for the Melbourne HD channels in the past (it was for the SD ones). So Plex have done more than change the container, they’ve done something that makes the client believe something (I suspect audio) has to be transcoded for it to be played, whereas in the past that was not the case.

This shouldn’t happen since as Plex state they use native playback capabilities in general on most platforms, and the PS4 media player can happily play all the recorded DVR files without any transcoding (even the SD ones that have never worked in the Plex client).

Since I seldom watch SD channels this was an acceptable (if annoying) situation when I made the decision to set up Plex the way it is and purchase Plex Pass for the DVR functions, but as it stands Plex have rendered my DVR almost useless for what appears to be non-technical reasons. It should be able to work as it did, and in fact it should be able to work better than it did!

I’m hoping this is simply a bug in the clients that doesn’t correctly deal with the server changes they’ve made and it will be fixed soon, but I’m worried that their approach is getting very transcoding-centric and they won’t bother to ensure that things just stream as they are whenever possible, as they should.

So confirmed for @DaveBinM that you are in Melbourne but no information on what channel/program you are trying to record so he can look into it.

@lennier76 Could you provide some more information, please? It’s very difficult to look into without knowing specifics. I personally don’t think that having files that don’t Direct Play to all clients is necessarily a problem, but I can’t say what’s going on exactly without some more information. :slight_smile:

Can you please provide:
What channel you were recording
What program it was
Time of airing
Preferably a sample file

@johnm_ColaSC lots of information about the channels, I explicitly note that this has always happened for SD channels but not previously for HD channels, which it now does. Given they nearly all use the same encoding the exact channel and program is irrelevant. The point is all these channels used to stream without transcoding and still should, but Plex have made the clients think transcoding is required which breaks any PMS that isn’t capable of transcoding.

@DaveBinM see above, appreciate the offer but I wasn’t expecting anyone here to look in to this, I merely posted it as a warning for people looking at upgrading. I only did one short sample recording on one of the HD channels (10 I think) and once confirmed that it definitely would not play without wanting to transcode I had to revert to an earlier server version.

@lennier76 The channel and program are entirely relevant, as the codecs can vary between programs. Without having specifics and a sample to look at, it’s impossible to ascertain if there’s actually anything wrong with the recording, or if it’s just that your client can’t direct play them. I have a PS4, and can test myself, but I need something to test with.

Yep true I appreciate that for a specific example, but regardless of the cause the point is I’ve had no problems playing recordings from any of the HD channels without transcoding prior to the change to MKV containers, and since the channels didn’t change anything in how they regularly encode stuff then Plex have clearly changed how the server and client interact in relation to playing the exact same types of streams, in a way that should not be necessary. I could create a sample file if you wanted it for interest sake but as I say I wasn’t looking to get anyone to look at this for me other than Plex. Unless it’s possible to tell PMS to never transcode then tricky for you to reproduce without the relevant server platform, too.

Note too that I’ve never said there was anything wrong with the recording, in fact I said the exact opposite in the original post, The recordings play fine in regular media players (such as the PS4 one). The problem is purely that something about the way Plex clients and servers communicate has been broken by this change, causing the client to request unnecessary transcoding of a stream it should be able to play directly.

Respectfully, I don’t think anything has been “broken” here, while they have been remuxed into MKV containers, that is all. It’s documented that the PS4 client doesn’t support MKV containers (https://support.plex.tv/hc/en-us/articles/204377253-What-media-formats-are-supported-), so if it would have otherwise direct played, it should now just direct stream (put the same streams into a different container).

I don’t think there’s any issue with how the clients and server are communicating, I think it’s more likely that your particular combination of server and client are leading to less than ideal streaming. Of course, it’s impossible to know without a sample file :slight_smile:

Well if they’ve chosen to move all DVR recordings to a container their own clients don’t support then that’s pretty broken if you ask me! :smile: But that would not appear to be the case, as I have downloaded and played many mkv files via Plex with no issue on the PS4 client. Also would the client report an inability to transcode if it couldn’t even open the container? Does transcoding ever change the container format or only the audio or video codecs encoding the streams?

It still seems as if people are missing the point that nothing has changed other than the container format (supposedly). So you should expect that streams that could play without the client requesting transcoding before should still be able to play without requesting transcoding now. Since they can’t (unless somehow my testing was an anomaly) then something more has changed than just the container format, no?

I’m happy to create a sample file but I assume you’re not a Plex employee so I don’t expect private individuals to spend time trying to sort out issues with this for me (unless that’s what you’re keen to do :smile: ).

@lennier76 is this based on one recording only? Was it a HD file? If so can you reinstall the new version and record another show or two for testing purposes? Maybe try a recording of an SD show and a HD show. (1 of each).

In the mean time can you at least provide the XML of the movie/show you did record as the MKV previously? You can get this info by click the ellipse (3 dots) on the video, selecting Get Info then on the “pop up” display click the Show XML link bottom left.

Just copy that info and paste it here or into a text file, then drag that text file into a message here after saving it which will make it an attachment.

DaveBinM is trying hard to help you and willing to step up to help diagnose any issues but he needs info from you to do this. Keep in mind he’s part of the Plex Team with direct access to the developers so you can’t get a better guy to work with especially considering he’s in Melbourne and probably has the best chance of any team member to diagnose an issue in Australia.

Carlo

If you insist on moving your recordings back to being in a .ts container (which in general I would not recommend, as Plex has changed the container for a variety of good reasons) for compatibility with your PS4, you could always use a postProcessing script to remux it back to a .ts container. :slight_smile:

Not wedded to the TS container in any way, more than happy for them to be MKV but if it breaks playback that previously worked using their own clients then that’s a problem, as has been discussed ad infinitum now. I strongly suspect this is just unintended consequences and will be fixed at some point. As it stands I see no reason that the client should request transcoding (which can’t be done for servers like mine) when it didn’t previously, simply due to a container change. Admittedly I’ve only tested the one recording as I had to revert to ensure scheduled recordings succeeded, so now that I know I can successfully downgrade back to a working setup I’ll try to upgrade again and test a bit more extensively. But since I picked a random HD channel to record and none of my clients could play it (PS4, Android or Windows RT) it seemed like it was a pretty major issue. @cayars SD recordings have always had this problem, which I took the decision to live with since I seldom record SD, but HD was all fine until the container change. Never quite understood why the Plex client on PS4 couldn’t play the SD recordings either though. I know it’s the audio codec it thinks has to be transcoded but again the PS4 native media player handles is fine so it’s not a lack of actual codec support, it’s something the Plex client decides to do for reasons unknown.

Will try 1.7.2 now that that has been released and see if there is any difference. Clear from the multiple other 1.7.X threads that more has happened than a simple container change, which as discussed should never change the transcoding requirements of the client. This really has been the worst handled release I’ve seen in the time I’ve used Plex, not impressed (not that it appears anyone from Plex is listening to any of this).

The only thing that should be changed is the container here. As stated previously though, the PS4 client does not support MKV containers, so it would need to be Direct Streamed.

The PS4 client plays MKV files from other sources just fine, as I’ve said before. And if it didn’t then forcing a change to a container that their own client doesn’t support is even worse! (Edit: or are you saying that MKV files I’ve played are Direct Streaming and I just hadn’t realised the repackaging was happening on the fly? Is that low enough CPU that even ARM-based NAS servers can do it?)

The problem remains though that something causes the client to want to transcode streams that do not need to be transcoded, and aren’t when packaged in TS. I suspect Plex are not even considering people who do not have transcoding-capable servers, thinking everyone is watching things on mobile devices or something and are transcoding all the time. Will be interesting to see what happens with 1.7.2 and I’ll try to do more testing.

Also, according to the Plex info on the PS4 client the only container it supports is MP4, so if that’s true I would have been Direct Streaming from the TS containers as well, not Direct Playing. So the same overhead process of repackaging in both cases and no reason why anything should be different about the contained streams that suddenly prevents playing without transcoding. Unless perhaps repackaging from MKV is more resource intensive than it was from TS and the error message about the server not being ‘powerful enough’ is actually to do with the repackaging and nothing to do with transcoding after all? But if that was the case, why could I play MKV files from other sources without this issue?

Just coming across this, I’ve had similar issues with Plex Server DVR Beta 6, then 1.7.1.3856, playing back DVR recordings to my Android TV client. Plex Server is running on Synology Diskstation DS215J, client is running on Nvidia Shield (not running as server), DVR is a HD Homerun HDHR4-2DT. On previous DVR betas and Plex Pass releases recordings played back fine, rewind and fast forward worked and audio worked fine. With DVR Beta 6, rewind and fast forward of recordings stopped working (even recordings made before installing beta 6) - both would just start the playback over again at 0. Installing Plex Server 1.7.1.3856 solved the rewind/ff problem, but now there’s no sound!

This seems to occur with any channel and any program, but an example is Rage recorded off ABC1 (HD) in Melbourne.