Starting from yesterday Plex stopped to play anything
Server version: 1.23.1.4528
Domain name not resolved, but I checked via ssh - it’s resolvable from the server!
What I can do?
In the console I found
user@homesrv:~/docker$ sudo docker exec -it plex bash
/# ls
Media config etc init lib32 libx32 opt proc sbin tmp var
bin data healthcheck.sh installBinary.sh lib64 media plex-common.sh root srv transcode version.txt
boot dev home lib libexec mnt plex_service.sh run sys usr
/# nslookup downloads.plex.tv
bash: nslookup: command not found
/# curl downloads.plex.tv
<html>
<head>
<title>Plex Redirect</title>
<META http-equiv="refresh" content="0;URL=https://plex.tv/downloads">
</head>
<body bgcolor="#323232" link="yellow" vlink="yellow">
<p> </p>
<center><font size="5" color="white">The page you're looking for was not found.<br>
You will be redirected automatically in 5 seconds.<p>
<a href="https://www.plex.tv/downloads">https://plex.tv/downloads</a></font>
</center>
</body>
</html>
/# wget https://downloads.plex.tv/codecs/fa235d6-3858/linux-x86_64-standard/libh264_decoder.so
bash: wget: command not found
/# curl https://downloads.plex.tv/codecs/fa235d6-3858/linux-x86_64-standard/libh264_decoder.so
Warning: Binary output can mess up your terminal. Use "--output -" to tell
Warning: curl to output it to your terminal anyway, or consider "--output
Warning: <FILE>" to save to a file.
/# curl https://downloads.plex.tv/codecs/fa235d6-3858/linux-x86_64-standard/libh264_decoder.so --output
curl: option --output: requires parameter
curl: try 'curl --help' or 'curl --manual' for more information
/# curl https://downloads.plex.tv/codecs/fa235d6-3858/linux-x86_64-standard/libh264_decoder.so --output libh264_decoder.so
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 1601k 100 1601k 0 0 2993k 0 --:--:-- --:--:-- --:--:-- 2993k
/# ls
Media data home lib32 libx32 plex-common.sh run tmp version.txt
bin dev init lib64 media plex_service.sh sbin transcode
boot etc installBinary.sh libexec mnt proc srv usr
config healthcheck.sh lib libh264_decoder.so opt root sys var
/#
I checked it from the inside of container…I really confused
Look at the first RED error:
[Transcode] Error issusing curl_easy_perform(handle): 6
This is a DNS lookup failure (CURL error 6)
Checked with the build team.
Can you please create a tar.gz of the Logs directory (with this captured in DEBUG logging) for me?
They are anxious to see and address it.
Do you mean
Plex Media Server Logs_2021-05-20_22-23-12.zip (638.0 KB)
download them from troubleshooting at the plex’s settings?
I’m working with the Build team now.
Would you please grab and report:
-
ping 8.8.8.8from within the container - The container’s
/etc/resolv.conf
Sure, here we go:
:/# ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=109 time=33.8 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=109 time=33.7 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=109 time=33.7 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=109 time=33.7 ms
64 bytes from 8.8.8.8: icmp_seq=5 ttl=109 time=33.7 ms
64 bytes from 8.8.8.8: icmp_seq=6 ttl=109 time=33.7 ms
64 bytes from 8.8.8.8: icmp_seq=7 ttl=109 time=33.8 ms
64 bytes from 8.8.8.8: icmp_seq=8 ttl=109 time=33.7 ms
64 bytes from 8.8.8.8: icmp_seq=9 ttl=109 time=33.7 ms
64 bytes from 8.8.8.8: icmp_seq=10 ttl=109 time=33.6 ms
64 bytes from 8.8.8.8: icmp_seq=11 ttl=109 time=33.6 ms
64 bytes from 8.8.8.8: icmp_seq=12 ttl=109 time=33.9 ms
64 bytes from 8.8.8.8: icmp_seq=13 ttl=109 time=33.6 ms
64 bytes from 8.8.8.8: icmp_seq=14 ttl=109 time=33.6 ms
64 bytes from 8.8.8.8: icmp_seq=15 ttl=109 time=33.7 ms
64 bytes from 8.8.8.8: icmp_seq=16 ttl=109 time=33.7 ms
^C
--- 8.8.8.8 ping statistics ---
16 packets transmitted, 16 received, 0% packet loss, time 15013ms
rtt min/avg/max/mdev = 33.613/33.691/33.859/0.063 ms
:/# cat /etc/resolv.conf
# This file is managed by man:systemd-resolved(8). Do not edit.
#
# This is a dynamic resolv.conf file for connecting local clients directly to
# all known uplink DNS servers. This file lists all configured search domains.
#
# Third party programs must not access this file directly, but only through the
# symlink at /etc/resolv.conf. To manage man:resolv.conf(5) in a different way,
# replace this symlink by a static file or a different symlink.
#
# See man:systemd-resolved.service(8) for details about the supported modes of
# operation for /etc/resolv.conf.
nameserver 192.168.1.1
Thank you !
I’ve forwarded to the team.
Hey! Any update on this?
We’re trying to get some time with any users who will let us have access into the machine / VM / container so we can get our hands in the debugger while it’s running and trace it.
This is such a bizarre problem that we can’t recreate it yet.
I have tried VMs, (NAT, Bridge, IPv4 , IPv6, mixing all different ways)
I’ve tried containers too.
I have dual stack LAN and dual stack ISP – which is why I think I won’t be able to reproduce it.
what’s your LAN stack and WAN stack configuration ?
Just usual wi-fi router, all devices in the same lan, router forwarding connection to the server, I wonder why it’s worked for almost 2 years
I can give you temporary access to ssh if you promise to look only, without changing configs without my permission and, of cause, you are forbidden to install any malware 
thank you …
Overnight, much progress was made.
We are building a test version of server now.
if it passes on the native platforms, it will be released – which means you’ll get an updated container.
It’s work! Thank you!
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.
