I need help troubleshooting or tweaking settings or understanding if this is not going to work.
My issue is that 4K content is buffering during transcoding playback.
It is using HW Accel of the CPU (Quick Sync)
Web Player starts off in direct play and switches to 1080p HW Transcoding, it will play for a minute and then buffer and then play for 30 seconds to 90 seconds or so and buffer, and will keep doing this.
MacOS Client direct plays, but if I force transcoding 1080p it buffers like every 30 seconds to 60 seconds.
I donât think the issue is that its not using quick sync, because before when I was having issues with it not using HW Accel, it would show on my CPU usage, when its using HW accel now there is almost no CPU usage. It also has the (hw) in the dashboard.
â ~ uname -srm
Linux 6.12.12-amd64 x86_64
â ~ ls -la /dev/dri
total 0
drwxr-xr-x 3 root root 100 Feb 17 17:32 .
drwxr-xr-x 21 root root 5080 Feb 17 17:56 ..
drwxr-xr-x 2 root root 80 Feb 17 17:32 by-path
crw-rw---- 1 root video 226, 0 Feb 17 17:56 card0
crw-rw---- 1 root render 226, 128 Feb 17 17:32 renderD128
â ~ id
uid=1000(seion) gid=1000(seion) groups=1000(seion),24(cdrom),25(floppy),29(audio),30(dip),44(video),46(plugdev),100(users),101(netdev),993(render),994(kvm),1002(media)
I was having another issue that I posted on discord about.
"
I have 2 linux servers
One of them is running my original plex server @ x.x.x.3
One of them is running my new plex server @ x.x.x.4
When I go to x.x.x.4:32400 it lets me login and if the plex service was just started, I can see the server and its config. I can also see x.x.x.3 plex also. If later in the day I check back and go to x.x.x.4:32400 I can still login but it only shows the x.x.x.3 server and not the x.x.x.4 server. But if I restart the x.x.x.4 plex service it shows back up.
"
I will be turning down the 10.0.0.3 eventually for this new server
I am asking this because Iâm trying to determine if the problem is the server or the player.
At this time, I donât have any definitive data for either way.
The server logs donât appear to be a problem other than having caught the server during DHCP refresh
So my laptop that I ran iperf from in the first post might of been on Wifi. But if I do a iperf between the old server and new server (both hardwired) there is no retries.
Ok found some reddit posts with people with similar issues for the network change stuff. Only thing people figured out was that it was related to Docker using Network Host mode. So I switched the container to Bridged and no more Network Change in the logs so far.
I tried a movie out again and its still doing the buffering issue.
Does this mean it asked for the same segment 4 times?
Feb 18, 2025 08:21:05.655 [140566770592568] DEBUG - [Req#2bf/Transcode/tikpg745vs5a8rsjm7apcl3d] Returning segment 578 from session
Feb 18, 2025 08:21:05.655 [140566770592568] DEBUG - Content-Length of /dev/shm/Transcode/Sessions/plex-transcode-tikpg745vs5a8rsjm7apcl3d-ad8e332c-580f-46b7-9a02-b95e86e1ef31/init-stream0.m4s,/dev/shm/Transcode/Sessions/plex-transcode-tikpg745vs5a8rsjm7apcl3d-ad8e332c-580f-46b7-9a02-b95e86e1ef31/chunk-stream0-00579.m4s is 3989810 (of total: 3989810).
Feb 18, 2025 08:21:05.666 [140566706359096] DEBUG - Request: [10.0.0.78:59220 (Subnet)] GET /video/:/transcode/universal/session/tikpg745vs5a8rsjm7apcl3d/1/579.m4s (8 live) #2c5 TLS GZIP Signed-in
Feb 18, 2025 08:21:05.666 [140566706359096] DEBUG - [Req#2c5/Transcode/tikpg745vs5a8rsjm7apcl3d] Asked for segment 579 from session.
Feb 18, 2025 08:21:05.821 [140566807636792] DEBUG - Completed: [10.0.0.78:59231] 200 GET /video/:/transcode/universal/session/tikpg745vs5a8rsjm7apcl3d/0/578.m4s (8 live) #2bf TLS GZIP 1168ms 3989810 bytes (pipelined: 53)
Feb 18, 2025 08:21:05.901 [140566751386424] DEBUG - Request: [10.0.0.78:59231 (Subnet)] GET /video/:/transcode/universal/session/tikpg745vs5a8rsjm7apcl3d/0/579.m4s (8 live) #2c6 TLS GZIP Signed-in
Feb 18, 2025 08:21:05.901 [140566751386424] DEBUG - [Req#2c6/Transcode/tikpg745vs5a8rsjm7apcl3d] Asked for segment 579 from session.
Feb 18, 2025 08:21:06.340 [140566747015992] DEBUG - Request: [10.0.0.78:59270 (Subnet)] GET /statistics/bandwidth?timespan=6 (7 live) #2c1 TLS GZIP Signed-in Token (seion) (Firefox)
Feb 18, 2025 08:21:06.342 [140566807636792] DEBUG - Completed: [10.0.0.78:59270] 200 GET /statistics/bandwidth?timespan=6 (7 live) #2c1 TLS GZIP 1ms 1487 bytes (pipelined: 53)
Feb 18, 2025 08:21:06.870 [140566734326584] DEBUG - [Req#2c3/Transcode/tikpg745vs5a8rsjm7apcl3d/ad8e332c-580f-46b7-9a02-b95e86e1ef31] Transcoder segment range: 532 - 579 (579)
Feb 18, 2025 08:21:06.903 [140566751386424] DEBUG - [Req#2c6/Transcode/tikpg745vs5a8rsjm7apcl3d] Returning segment 579 from session
Feb 18, 2025 08:21:06.903 [140566751386424] DEBUG - Content-Length of /dev/shm/Transcode/Sessions/plex-transcode-tikpg745vs5a8rsjm7apcl3d-ad8e332c-580f-46b7-9a02-b95e86e1ef31/init-stream0.m4s,/dev/shm/Transcode/Sessions/plex-transcode-tikpg745vs5a8rsjm7apcl3d-ad8e332c-580f-46b7-9a02-b95e86e1ef31/chunk-stream0-00580.m4s is 4248096 (of total: 4248096).
Feb 18, 2025 08:21:06.969 [140566706359096] DEBUG - [Req#2c5/Transcode/tikpg745vs5a8rsjm7apcl3d] Returning segment 579 from session
Feb 18, 2025 08:21:06.969 [140566706359096] DEBUG - Content-Length of /dev/shm/Transcode/Sessions/plex-transcode-tikpg745vs5a8rsjm7apcl3d-ad8e332c-580f-46b7-9a02-b95e86e1ef31/init-stream1.m4s,/dev/shm/Transcode/Sessions/plex-transcode-tikpg745vs5a8rsjm7apcl3d-ad8e332c-580f-46b7-9a02-b95e86e1ef31/chunk-stream1-00580.m4s is 31534 (of total: 31534).
Feb 18, 2025 08:21:06.969 [140566805527352] DEBUG - Completed: [10.0.0.78:59220] 200 GET /video/:/transcode/universal/session/tikpg745vs5a8rsjm7apcl3d/1/579.m4s (7 live) #2c5 TLS GZIP 1303ms 31534 bytes (pipelined: 69)
I was thinking about trying native today. I will try it out tomorrow and report back.
I am also investigating if the following is supposed to be using the xe driver if there is one and if because itâs using i915 that maybe itâs not working as well as it should.
You need the i915 to get to the xe gpu just as you would to get to the (old) i965 gpu.
Given youâre in docker, you have to make certain the group membership ID inside the container is such that it aligns with the GID of /dev/dri on the real host
-OR-
the assigned UID is a member of the group which owns /dev/dri
With the native package, I take care of all the udev rules for GPU access
( I put âplexâ in the group ; video or render or whatever it might be â except root)
Regarding ârootâ group. If your /dev/dri is owned by root GROUP, thatâs a problem. udev rules should exist to remap it to a non-privileged group. (Root group is too dangerous to use for non-system applications)
With the native package, you can change the UID/GID as you wish but now youâre back to docker-style , with one exception.
When you write an override.conf (config customization), I read that at package installation and adjust group memberships as needed.
I do my best to reduce installation and configuration to minimal user loading.
