Hi All,
AFAIK failing for all transcodes, but I know it to fail for H264/MKV and H265/MKV and I don’t know of any that succeed. I can see the chunk transcode files building up on the server so I kniow it’s creating the transcode.
Transcoding works to my Andriod phone using the PLEX app.
No problem until upgrading to 1.71, in fact PLEX and Rasplex in general have been so reliable until now that I’m not sure where to start to fix this, any help would be most gratefully received!
Thanks,
Iam
What version of PMS are using? We’ll need debug logs as I cannot replicate the problem. My transcodes are working fine.
Hi Benjamin, thanks very much for your response, I’m using PMS Version 1.3.3.3148 server platform is Windows 7 x64 SP1. I’ve attached a log file from PMS too.
I have 2 RPi clients and they both exhibit the same problem. I reflashed one of them yesterday but it still has the issue.
Regards,
Ian
@duggers:
What about non-transcoded MKV/MP4 files ? Do these play correctly on your RPi clients ?
Normal H264 files should not need any transcoding, unless their bitrate is higher than a limit you set for the client.
H265 is different, as the extreme complexity of that encoding makes transcoding necessary even for modest bitrates.
A normal RPi1 can’t handle H265 formats well. You need an RPi2 or RPi3 for that, and even they are limited in bitrates.
Exactly what RPi model(s) is it that you’re using ?
I have a very similar PMS setup myself, running PMS v1.3.2.3112 on ‘Windows 7 pro x64 SP1’ and I do not have your problem on any of my RPi clients, which include RPi1B, RPi2 and RPi3. So I don’t think that any bug in RasPlex is causing your problem, but rather some peculiarity of the server/client configurations or of the network connecting them.
Best regards: dlanor
Hi dlanor,
Thanks for your attention to this, non-transcoded MP4 and MKV files play fine, one of my RPi clients is well connected to the server and does not need to transcode even 1080p MKV and MP4 files, though I’ve forced transcoding to confirm the issue exists there too. The other is less well connected and needs to transcode 1080p and fails but 720 and lower direct plays are fine.
My well connected RPi client is a Pi2 and the other is a Pi3.
I think you may be right but the only thing I can think of that has changed is that I updated to version 1.71 of Rasplex and installed Mullvad VPN client. I have since uninstalled that client and rebooted the server, and the problem persists. The other thing that would point away from a server/network config issue is that the android client on my phone transdcodes those same files fine. I do think it may be an issue that surfaced because of how I’ve configured something or other, but only affects the RPi for whatever reason. Just don’t know what that is yet.
Regards
Ian
@duggers I’ve not been able to replicate your exact issue and the PMS log you uploaded did not reveal much information in the OpenPHT way.
I have seen some issues with the new transcoder in Windows PMS versions 1.3.1.3102 and above. What I’m seeing is an occasional long queue period before playing transcoded streams and a timeout on some resumed files. Seems to be possibly impacting Windows servers PMS versions only as my Linux server has not demonstrated the issue. I was just able to get it to happen on my Linux server so it’s not Windows specific.
Does this describe what you’re seeing as well? And if you downgrade your PMS to a pre 1.3.1.3102 version does it resolve the issue?
Hi benjaminwolf, yes that’s exactly what I see, II suppose I could have been clearer when i said that I could see chunk files building up, but yes, I see the transcoding notice, then see please wait for what could be many minutes - I waited once for over 30 mins with transcode files building up on the server before I canceled the playback. Some more research revealed that it happens with certain MKV files but not others although they are all 1080p/6 channel, and the same files all transcode to the Plex client on my phone ok.
Regards
Ian
I am experiencing the same issue. However, turning off the ffmpeg avio feature helps for me.
Thanks Lesferatu, I tried that and it helps for me too, so I can play those files now.
I also noticed that running a problem file through MKVvalidator gave "5383 bytes of void data, then passing the file through Meteorite MKV repair to patch the voids also resulted in a playable file.
