So what’s the story with this error? I’ve seen a couple random threads asking about this since the release of PMS 1.2.7. They tail off without acknowledgement that anything is identified as broken. I updated to this version a couple weeks back and ever since, much of my library is unplayable, resulting in this error. I tried the Plex Pass version (1.3.0) but it didn’t resolve anything. Most of my content is h264 with AAC, AC3 or DTS 5.1 audio streams. Which direct play anyway (on a Roku 3, latest firmware that fixes the 4GB local media bug). I’m guessing that the error text is not actually indicative of the problem since playback always starts off okay with both audio and video. The playback usually stops about a minute or two into the video when the error message pops up.
Right now, Plex is totally hit or miss when it comes to picking things to play. The hit rate (by my guess) is that I can successfully play back about 1 in 10 items. Which isn’t very successful and making me look pretty bad to the wife. It seems like a few folks were able to resolve the issue by rolling back PMS versions, but I run off a Synology NAS and DSM doesn’t allow me to install an older, downgraded package. So I’m kinda stuck.
Logs are attached for an occurrence from just today. We watched a movie successfully, then went to catch up on some back TV episodes, which all resulted in the same error after a minute or so of playback.
Seems like as if you have some sort of network connectivity issue. The automatic download of codecs (that was introduced with 1.0 I believe) reports errors of it not being able to download correctly. I’d double-check that all is OK with your network. If you are running proxies, ipv6 or such I’d disable all that and go for the basic. Check MTU too so jumbo frames aren’t enabled (it should never be).
ERROR - Error issuing curl_easy_perform(handle): 28 Dec 04, 2016 11:13:10.846 [0xf2fffb40] DEBUG - HTTP simulating 408 after curl timeout Dec 04, 2016 11:13:10.847 [0xf2fffb40] ERROR - Codecs: Download failed: Failed to download 'https://downloads.plex.tv/codecs/4b2f00a-1141/linux-synology-i686/liblibmp3lame_encoder.so': 408 Dec 04, 2016 11:13:10.847 [0xf2fffb40] WARN - Codecs: Failed to download libmp3lame encoder; bailing out
So, I spotted that when I was trawling through the log file too. What doesn’t make sense is why that encoder is even needed. In every case that this error pops up, the video started playing fine with both audio and video. So it doesn’t make any sense that another “required” codec is necessary. On top of that, both the audio (AC3 DD 5.1) and video (h.264) don’t need transcoding on a Roku 3. If the encoder really was necessary to playback, why wouldn’t it refuse to play from the very start, rather than give me 1-2 minutes of working content before erroring out?
While it may be network related, it’s a little tough to swallow since my NAS is currently connected to Amazon Cloud Drive syncing my data. Updates to it download fine. Packages install without a hitch. Whatever the issue is, it seems like there’s either a latency problem connecting to downloads.plex.tv or the timeout needs to be a bit more generous. Especially in the face of a video that starts up fine.
I did not look at your logs, but it’s possible that the Roku was direct playing the file originally, so it didn’t need the codec. Something happened and it couldn’t continue to direct play so it wanted to switch to either direct stream or transcode which does need the codec. If this is the case, it had nothing to do with downloading or timeouts, but the Roku actually telling PMS that it couldn’t playback that file.
Interesting. So what would cause a player to stop direct play and require transcoding mid-stream? I’ve never run across a file that had multiple codecs in the same track so I’m guessing it’s not that the file starts with AC3 and switches to something the Roku can’t understand.
I guess the more useful question is how do I force Plex to download all the possible encoders and have them stored locally to avoid this? I have a few terabytes unused and would be happy to spare a few gigabytes to store encoders. Since I started using Plex on my NAS, it’s never failed to pull in metadata, posters, banners, backgrounds, etc. It downloads all manner of updates to installed software fine. It syncs to Amazon Cloud drive. If I buy that there’s a networking issue, it seems like the only one that’s been a showstopper (bad pun, I know) is when it comes to trying to download an encoder from Plex.tv.
Okay, I found a Band-Aid solution to this. Manually copying the encoder/decoder files resolves the download failure. For anyone who may be reading this later, here’s what I did…
Dig through the PMS logs and look for the error lines that indicate a codec failure. Doing a find for “download failed” will bring you directly to the line you need.
Grab the URL for the failed download, so in the example I posted, the link would be: https://downloads.plex.tv/codecs/4b2f00a-1141/linux-synology-i686/liblibmp3lame_encoder.so
Load that URL in a browser and save the target file.
On your Plex server, locate the “Codecs” directory. In my case, on a Synology NAS, the path is volumes/Plex/Library/Application Support/Plex Media Server/Codecs/
In the URL to the encoder, there’s a hexadecimal ID, “4b2f00a-1141”. This matches a directory on my NAS, with the full path being: volumes/Plex/Library/Application Support/Plex Media Server/Codecs/4b2f00a-1141-linux-synology-i686/
Drop the saved .so file into that directory.
While there may be a network issue preventing the download of these files directly from my NAS, I’m still not convinced there isn’t any buggy behavior going on here. Things are playing smoothly now, even things that were erroring out yesterday. The thing is, if PMS has to switch from direct play to transcoding mid-stream, I’d expect there to be a short hiccup while the transcoder re-buffers. No such thing happens and as far as I can tell, it direct plays from start to finish. So in light of this problem only starting when I updated to 1.2.7, I still believe that there’s a problem prompting unnecessary attempts to download codecs.
To mitigate this even more and reduce the chance of this happening again, I downloaded a whole bunch of other .so files and copied them all into the Codecs directory. I found close to 30 of them. For the record: these are the ones I found:
libaac_decoder.so
libaac_encoder.so
libac3_decoder.so
libac3_encoder.so
libdca_decoder.so
libh263_decoder.so
libh264_decoder.so
libhevc_decoder.so
libindeo4_decoder.so
liblibmp3lame_encoder.so
liblibx264_encoder.so
libmp3_decoder.so
libmpeg1video_decoder.so
libmpeg2video_decoder.so
libmpeg4_decoder.so
libmsmpeg4v2_decoder.so
libmsmpeg4v3_decoder.so
librv20_decoder.so
librv30_decoder.so
libsvq1_decoder.so
libsvq3_decoder.so
libvc1_decoder.so
libvp6f_decoder.so
libwmav2_decoder.so
libwmv1_decoder.so
libwmv2_decoder.so
libwmv3_decoder.so
Is there a similar workaround for the MAC version of the server?
And yes this must be addresses more permanently than just making workarounds
/gustav
Solved it.
It turned out that I had two network interfaces enabled. Both Ethernet cable connected and Wireless. After disabling wireless and reboot it seems to work.
So I am all happy again but perhaps something to look into for others experiancing similar issues
Yes! Searching the log file for a failure to download a .so file and manually copying it to the proper codecs directory worked for me.
i only have eth0 & lo as my network devices, so i can’t exactly say for sure why it fails to download the codec.
