Plex for Mac playback error 1008 since 1.55

Server Version (Mac)#: 1.29.2.6334-817e19b35
Player Version (Mac)#: 1.56.1.3327-90bc844c

Plex for Mac is once again no longer playing media for me since 1.55.

Can connect to server and browse, but attempting to play anything results in Playback Error “A codec required for playback could not be downloaded. Make sure you are connected to the Internet and try again. Error code: 1008”

1.54 works fine. I had a similar issue for a long time (see this thread from 2020) but at some point several months ago it started working again (not sure in which exact release). So I’m sticking with 1.54 for now.

Thanks

The codec download is failing. This is logged in a different log file at ~/Library/Application Support/Plex/Plex Media Server/Logs/Plex Media Server.log. It is attempting to download to a directory within ~/Library/Application Support/Plex/Plex Media Server/Codecs so ensure that directory is writable.

Thanks for the reply. Yes, that dir is writable with the same permissions as the others and has some downloaded contents. Again, 1.54 works fine.

The relevant line in 1.56 log seems to be:

Oct 28, 2022 07:43:13.652 [0x700012c38000] WARN - [HttpClient/HCl#1] HTTP error requesting GET https://plex.tv/api/codecs/aac_decoder?build=darwin-x86_64-standard&deviceId=ec7f25b0-341e-4104-8283-7013abaee916&oldestPreviousVersion=legacy&version=fc0c73c-4397 (60, SSL peer certificate or SSH remote key was not OK) (SSL certificate problem: self signed certificate in certificate chain)

This does not appear in the log for 1.54.

If I check this link in my browser or curl, I can load it fine. However, my client Mac is behind a corporate web gateway which assigns its own certs. I’m assuming something re how that is handled has changed in 1.55+ and is causing the issue.

Update: Resolved with workaround

I downloaded the codecs manually, constructing the URI from what was in the logs + the dylib file names I already had from 1.54, put the new ones in the empty 1.56 Codecs subfolder, and now 1.56 works!

I was able to reproduce the issue with 1.54 when I deleted the already-downloaded codecs, so it seems the issue wasn’t introduced with 1.55+, rather at some point after 1.54 was released, my corporate gateway changed, reintroducing this issue. And 1.54 only worked because I already had the codecs. Anyhow, now I know to manually download them. Thanks for pointing me in the right direction of where to look.

Web inspection box doing something. Middleboxes are the enemy!

I agree with your assumption that Plex is now validating connections more diligently. That makes sense given what you’ve shown.

Do you know if the corp gateway is transparently hijacking connections?

Plex will use an HTTPS proxy if one is manually configured in the macOS network settings. That might be more straightforward than (cleverly) copying codec libs.

Yeah, corp gateway absolutely plays man in the middle. But it’s interesting that Plex doesn’t fail on other connections or going to the Plex site, just downloading codecs so far. Setting my own proxy won’t work — I’ve tried that for something else. This will have to do, since I don’t exactly have a valid business reason to ask corp tech for an exclusion for Plex. :relaxed:

This is exactly why you get:

Expect this to be an issue with every single update until your corporate firewall ceases this evil behavior.

Some pieces respect certificates trusted by the OS and some do not. The codec download is one that will not. I would expect that downloads for offline viewing from media servers in the desktop app will fail for the same reason.

Ok, I’ll bite: So then why wouldn’t the desktop app be designed to respect all certs trusted by the OS? And why has PMP never had this issue?

Quite frankly, you are suggesting a substantial change to accommodate evil behavior. Namely a device playing man-in-the-middle that masquerades as every website on the planet and your computer has been instructed to implicitly trust. You do realize that this device sees every username/password you enter and every session token all while downgrading the security of the communications to what it can handle (instead of what the site and browser can handle). I could go on about this but I trust my point has been made.

  1. I’m not suggesting anything, simply asking why it respects OS-trusted certs in some cases and not in others. And why PMP doesn’t have the same behavior. I’ve only encountered one other app with similar cert issues so far that I couldn’t work around. If you’re saying it’s good that Plex doesn’t respect the OS’s trust and it should actually do that in MORE cases than it already does, that’s a fair opinion.

  2. “Evil” is a pretty strong word evoking a morality argument I’m not sure is valid, but while I personally hate the corp tech security infrastructure for many reasons, it’s unfortunately commonplace in the enterprise.

Anyhow, I suppose things are how they are because Plex isn’t built with an enterprise-secured client base in mind, which is fair.

Thanks for your responses.

1 Like

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.