Server Version#: 1.15.2.793
Player Version#: Web 3.91.0
I’m running PMS in a FreeNAS iocage jail using the most up-to-date build for FreeBSD gained through the PMS_Updater script. As of a couple days ago, the script updated the version to 1.15.x and any transcoding required now prevents the file from being played. This includes both direct stream and transcoding, meaning that as most of my library is in mkv format, I am unable to play most of these through plex web.
Through testing I can see that plex at least believes the transcoder to be working, as the progress bar proceeds at roughly the same rate as before, and the process exits once 100% is reached. I was originally running in a warden jail, however switching to an iocage jail has not fixed the issue, nor has reverting to a new install with either the FreeNAS plugin or with a fresh jail manually installed through either pkg or portsnap
Thanks in advance for any help on this issue,
Thomas
Keeping the script aside (there’s a few issues with updating that way, that should be solved by manually updating the rc.d script) and focusing on the fresh install via pkg.
Can you please give more details on what actually happening?
I.E. What errors do you see in the web player, it would also help if you post Logs from the server, feel free to DM those and hide any sensitive information first.
The web player is stuck on the buffering wheel, and even when transcoding finishes it still hasn’t loaded at all, despite other files (with the mp4 extension for the web player) playing almost instantly. The dashboard shows transcoding progress correctly but ticks up the play timer for a bit before switching to buffering when it realises that it is not playing correctly.
The image shows a successful stream using the native windows client (which can handle mkvs), and an unsuccessful one on the same machine using the web app.
I’ve also dm’d you the complete logs obtained from the troubleshooting tab
The problem is not the mkv container but that’s its transcoding HEVC(10bit) to H264, this can be expensive on the CPU.
Depending on the hardware running on FreeNAS you might not be able to do this smoothly, so perhaps the best is a player that supports HEVC 10bit DirectPlay or try to just use H264.
If the CPU supports Intel Qucik Sync you might be able to enable Hardware Transcoding which would also help.
This is not the case as the issue still exists when playing an H264 encoded mkv file through the web GUI as shown in the image below. I also do not believe the transcoder is at fault here as in prior versions of plex, the server has had no issues transcoding these particular files.
I’m confused now, the OP was about pms not sending transcodes, but that’s a DirectPlay session. And it is reaching the client as shown here, do you see any errors in chromes’s WebTools console log or network Tab?
No, that’s not a direct play session, but a direct stream one, meaning that the transcoder still needs to repackage the mkv as an mp4 to allow it to be played by plex web (playing an mp4 works fine). As for errors, the chrome console has the following errors and warnings
[Connections] Stacinator NAS is unavailable at https://External-IP-Address.plex.direct:29800/media/providers (Status 0)
[Connections] Prevented fallback to insecure connection for Stacinator NAS
[Connections] All connections to Stacinator NAS failed
GET https://Internal-IP-Address.plex.direct:32400/video/:/transcode/universal/dash/1gyn9bdxw6pq00o5zqla4gel/1/0.m4s 404 (Not Found)
POST https://analytics.plex.tv/collect/event net::ERR_BLOCKED_BY_CLIENT
[Player] Buffering detected, last position change was 521ms ago
It also seems to be opening a large amount of long polls (approximately 2000) before detecting buffering
1 Like
Ah you’re correct, I saw H264 and AAC and didn’t expect a DS so my brain tricked me 
It should direct play though, and now that I look more carefully I also noticed the “10Gbps” which means we probably don’t have the correct bitrate of that file.
Deep Analyses should fix this.
Can you make sure if you have schedule task enabled and this one is checked Perform extensive media analysis during maintenance ?
Transcode would still be an issue for HEVC 10 bit though (unless hardware transcoding is used), but as you said it wouldn’t explain the issue if its during a directStream.
Can you please send me new logs? when this happens with DirectStream only? thanks
I’m running into the same issue while also running PMS in a freenas 11.2 iocage FreeBSD 11.2 jail.
1.15.2.793 was installed via pkg from the “latest” repo.
CPU usage has plenty of breathing room.
Bandwidth permitting, I can DirectPlay fine but the clients wait indefinitely for DirectStream and transcoded streams.
mikec_pt I am sending you my log files with the last play being a failed DirectSteam.
As is the case for ThomasRules2000, using the webui, I get a lot of 401s and rejections. Also, gobs of long polling:
A lot of those are on 127.0.0.1, might not be it but are you sure the jail is created with VNET enabled, its at least suspicious that we can’t talk to 127.0.0.1, this can happen in a jail without vnet though cause then it wouldn’t have a loopback.
Ah!
I switched my jails away from VNET around the time I upgraded Plex. I was not aware it would be an issue with Plex.
Unfortunately, I have been having issues with VNET after the latest Freenas update. So it may take some time before I post back with results with VNET enabled for the jail.
Thanks.
I have been having similar issues in regard to running VNETs on iocage jails, so have been running all my iocage jails with VNET disabled. Previously I was running into what may be the same issue using iocage jails, so I was running with a warden jail with VNET enabled, however this broke when plex updated to 1.15. I will try creating a new iocage jail with VNET enabled to see if this fixes the issue and report back.
Are this know issues with iocage specifically?
I actually was just using jail.conf with vnet and netgraph which was very stable, I switched to iocage my self recently (note that I do use FreeBSD not FreeNAS) and I noticed they use epair but it all seems to work fine…
Anyway might be worth reporting that to them
Honestly, it’s probably just an issue with my configuration, as I’m not entirely sure what the proper process is for setting up a VNET, and using jails without them has worked up to this point so I just avoided using them
iocage handles it all for you, you just need to set vnet=on, if you want dhcp then you also need that and bpf, but still there’s no extra config, unless maybe if you’re using pf or other firewall on the host
OK, on creating a VNET correctly, I have resolved the issue. For others with the same problem, the commands I used to switch the jail to using a vnet were as follows:
iocage set vnet=on plex
iocage set ip4_addr="vnet0|192.168.1.2/24" plex
iocage set defaultrouter=192.168.1.254 plex
I also needed to add the following tunables under System>Tunables:
Variable: cloned_interfaces Value: bridge0
Variable ifconfig_bridge0 Value addm igb0 up (note that you may need to replace igb0 with your specific network interface
After making these changes, plex now works perfectly, meaning that the issue was probably to do with not having access to the full network stack
Note that you can also enable dhcp, I think for that you need to
set dhcp=on bpf=yes IIRC iocage does the devfs rules set for you ready for dhcp to work.
I use a different one cause I also want Hardware Transcoding in the jail.
I have resolved the issue as well by getting VNET working.
In my case, one of the many things I recently changed was I moved Freenas from bare metal to ESXi. As it turns out, all I needed to do was enable promiscuous mode for the VM’s vSwitch. Which is pretty obvious in hindsight as to why VNET was not working!
On a side note for anyone else reading this, at some point going from 11.1 to the latest Freenas 11.2. I no longer require the bridge tunables mentioned by ThomasRules2000 for VNET to work in Freenas.
@BraveBuc that might only be true for iocage though, I doubt its the case for the Legacy “warden” jails.
