Server Version#:1.18.4.2171
Windows Player Version#:1.6.2.994-e05b79d6
Web Player Version#: 4.22.1
Hey there,
I am having some issues when playing content in my local network. When playing content locally, Plex is always restricting the bitrate to the bitrate set in the remote access settings. I’ve found another post regarding the same issue: Playing back content locally, but the stream is limited to remote stream bitrate.
The suggested solution is to disable IPv6 support. The solution works but unfortunately I need to have IPv6 support enabled in order for remote access to work. Are there any other ways to eliminate this issue ? Help is greatly appreciated.
Regarding DEBUG vs VERBOSE, Verbose logging is almost never needed. It actually loses data because the log buffers are fixed-length (64MB). I can see so much more - and far easier - in normal debug mode. (Debug on, Verbose off , is the default for this reason)
I am seeing what looks like the known ApolloLake bug. First and foremost, I’d like to address this.
Remove /usr/lib/plexmediaserver/lib/dri/iHD_drv_video.so, restart, and retest.
Let’s see if we can clean up the transcoder startup and all those failures.
Feb 07, 2020 20:00:32.034 [0x7f3457fff700] ERROR - [FFMPEG] - Failed to initialise VAAPI connection: -1 (unknown libva error).
Feb 07, 2020 20:00:32.035 [0x7f3457fff700] DEBUG - [FFMPEG] - Format 0x32315659 -> yuv420p.
Feb 07, 2020 20:00:32.035 [0x7f3457fff700] DEBUG - [FFMPEG] - Format 0x30323449 -> yuv420p.
Feb 07, 2020 20:00:32.035 [0x7f3457fff700] DEBUG - [FFMPEG] - Format 0x3231564e -> nv12.
Feb 07, 2020 20:00:32.035 [0x7f3457fff700] DEBUG - [FFMPEG] - Format 0x32595559 -> yuyv422.
Feb 07, 2020 20:00:32.035 [0x7f3457fff700] DEBUG - [FFMPEG] - Format 0x59565955 -> uyvy422.
Feb 07, 2020 20:00:32.035 [0x7f3457fff700] DEBUG - [FFMPEG] - Format 0x48323234 -> yuv422p.
Feb 07, 2020 20:00:32.035 [0x7f3457fff700] DEBUG - [FFMPEG] - Format 0x58424752 -> rgb0.
Feb 07, 2020 20:00:32.035 [0x7f3457fff700] DEBUG - [FFMPEG] - Format 0x58524742 -> bgr0.
Feb 07, 2020 20:00:32.035 [0x7f3457fff700] DEBUG - [FFMPEG] - Format 0x30313050 -> p010le.
Feb 07, 2020 20:00:32.035 [0x7f3457fff700] DEBUG - [FFMPEG] - Created surface 0x4000000.
Feb 07, 2020 20:00:32.035 [0x7f3457fff700] DEBUG - [FFMPEG] - Direct mapping possible.
Feb 07, 2020 20:00:32.036 [0x7f3457fff700] DEBUG - TPU: hardware transcoding: final decoder: vaapi, final encoder: vaapi
Feb 07, 2020 20:00:32.036 [0x7f3457fff700] DEBUG - Job running: EAE_ROOT='/tmp/pms-67f5296a-191c-4f56-88f1-e23b5cae5a5d/EasyAudioEncoder' FFMPEG_EXTERNAL_LIBS='/var/lib/plexmediaserver/Library/Application\ Support/Plex\ Media\ Server/Codecs/8bf330d-2818-linux-x86_64/' XDG_CACHE_HOME='/var/lib/plexmediaserver/Library/Application Support/Plex Media Server/Cache' XDG_DATA_HOME='/usr/lib/plexmediaserver/Resources' X_PLEX_TOKEN='xxxxxxxxxxxxxxxxxxxx' '/usr/lib/plexmediaserver/Plex Transcoder' '-codec:#0x100' 'h264' '-hwaccel:#0x100' 'vaapi' '-hwaccel_fallback_threshold:#0x100' '10' '-hwaccel_output_format:#0x100' 'vaapi' '-codec:#0x101' 'ac3' '-analyzeduration' '20000000' '-probesize' '20000000' '-i' '/media/raid/plex/serien/Hubert und Staller - Hubert ohne Staller/Season 09/Hubert und Staller - Hubert ohne Staller - S09E02 - Hals- und Beinbruch.ts' '-filter_complex' '[0:#0x100]hwupload[0];[0]scale_vaapi=w=1280:h=720:format=nv12[1];[1]hwupload[2]' '-filter_complex' '[0:#0x101] aresample=async=1:ocl='\''stereo'\'':osr=48000[3]' '-map' '[2]' '-codec:0' 'h264_vaapi' '-b:0' '2757k' '-maxrate:0' '3676k' '-bufsize:0' '7352k' '-r:0' '50' '-map' '[3]' '-metadata:s:1' 'language=ger' '-codec:1' 'libopus' '-b:1' '119k' '-f' 'segment' '-segment_format' 'matroska' '-segment_format_options' 'live=1' '-segment_time' '1' '-segment_header_filename' 'header' '-segment_start_number' '0' '-segment_list' 'http://127.0.0.1:32400/video/:/transcode/session/47dql1qbp2d5269bmc96ydbs/fc046cb5-2086-4f96-8ffb-3569fabbd84d/seglist' '-segment_list_type' 'csv' '-segment_list_unfinished' '1' '-segment_list_size' '5' '-segment_list_separate_stream_times' '1' '-avoid_negative_ts' 'disabled' '-map_metadata' '-1' '-map_chapters' '-1' 'chunk-%05d' '-start_at_zero' '-copyts' '-y' '-init_hw_device' 'vaapi=vaapi:,driver=i965,kernel_driver=i915' '-hwaccel_device' 'vaapi' '-filter_hw_device' 'vaapi' '-nostats' '-loglevel' 'quiet' '-loglevel_plex' 'error' '-progressurl' 'http://127.0.0.1:32400/video/:/transcode/session/47dql1qbp2d5269bmc96ydbs/fc046cb5-2086-4f96-8ffb-3569fabbd84d/progress'
Feb 07, 2020 20:00:32.036 [0x7f3457fff700] DEBUG - Jobs: Starting child process with pid 4286
Feb 07, 2020 20:00:32.042 [0x7f33eeffd700] DEBUG - Request: [127.0.0.1:57778 (Loopback)] PUT /vide
Thanks for the info.
Yes I have an Intel Celeron J4105 and are affected by the AapolloLake Bug. I’m using the “delete the iHd driver” workaround since the bug appereaded back in November. Without the workaround no transcoding is possible at all, and all I get is a frozen image.
Sorry seems to be a misunderstanding. With the iHD driver removed everything works fine. If I don’t remove the iHd driver after an update I only get an frozen image.
Each time you update, a new copy of the iHD_drv_video.so is brought with the package and reinstalled. Local hardware drivers are always included in the package. Codecs are downloaded on demand.
If, after removing the iHD_drv_video after the upgrade and having restarted Plex, you’re still seeing the frozen video then please provide the XML and we’ll look further at it.
I’m sorry but I have to clarify. Removing the iHD driver is not the solution to my described problem. I had a frozen image back in November when the ApolloLake bug apperead, but I’m using the “delete the iHd driver” workaround since then. With the workaround playback and transcoding works fine with exception of my “limited to remote bandwidth problem”. These Logs have taken with the iHd driver already removed.
Sorry for butting in, but have you tried to set
Settings - Server - Network - ‘Show Advanced’ - “LAN Networks”?
Insert the network address of your LAN (in your case it’s probably 192.168.178.0/24)
Is the router perhaps a FritzBox?
Then you also need to add the domain plex.direct to the exception list of the ‘DNS rebinding protection’.
Yes I have tried with and without inserting my network adress in the correct way. Funny thing is plex is recognizing me as Local in the daschboard but is still applying the remote bandwith limitation.
Dns rebinding is already setup in the FritzBox.
Everything works when disabling IPv6 Support in the PMS. Seems to be somehow related to IPv6. Maybe some incorrect Router Settings ?
Yes I know :). It’s set to Maximum on all clients.
It’s directly related to the remote access stream bandwidth.
Setting it to 2Mbit for example results in the following:
The logs you posted above were all showing access by devices with IPv6 adresses. And for some reason these are classified by Plex as “remote”.
AFAIK, IPv6 support in Plex is still experimental. This is the first time that I have seen a client connecting over IPv6.
I have a strong suspicion that this issue has to do with IPv6.
If you can, make sure that your local devices don’t get IPv6 adresses from your DHCP server, but only IPv4.
That is right. I’ve IPv6 enabled in my local network for remote access to work. Unfortunately I have a Dual Stack Lite internet connection and no other choice.
So the winning question is why these IPv6 adresses are classified as remote. Maybe thats something the devs should know about for the future IPv6 development. I did some more testing and disabled IPv6 in Windows. With IPv6 disabled the problem still occurs. Perhaps simply all connections are handled as remote connections when the IPv6 support feature is enabled ?
Thanks for the help so far
