Plex for Windows refuses direct connection

Plex Players Desktop Players
, ,
1

Server Version#: 1.30.06.6442
Player Version#: 1.58.1.3380
I have had this problem that appears to be “spreading” to multiple clients on my network and I am having quite the time remedying:

First, Plex-For-Windows started refusing direct connections to the server in any form except for indirect. This was not previous behavior for this application. Similarly Plex-For-Vizio smart TV followed the same: Would work normally, then spontaneously stopped recently with similar/same results. I then defaulted to using the Playstation 4 which worked for awhile but then similarly stopped in the same manner.

It has been offered previously that this is a DNS rebinding issue, and I might agree accept for the fact that the Android Client accepts the direct connection and plays correctly (the Dashboard indicating bandwidth occurring only via the local network as well as streaming beyond the 2Mbps limit). I would have expected if it were a DNS rebinding issue all local clients would suffer the same: Refusing direct connections and only connecting via indirect.

Does anyone have any insight on what I should approach and check first?

2

Plex Media Server platform (Win/Mac/Linux/Docker/etc)?

  1. Windows Network Settings

On any Windows based client or server, check that the network interface is configured as private, not public.

Windows 10: Settings → Network & Internet. Properties if need to modify.

Then restart/reboot the client/server if you changed the setting.

  1. DNS Settings

Configure server and clients to use public DNS server such as 1.1.1.1 (Cloudflare), 8.8.8.8 (Google), 9.9.9.9 (Quad9), etc.

  1. PMS version

Did this happen with 1.29.2? If not, fall back to 1.29.2.6364, available as non-Plex Pass download at plex.tv.

3

PMS platform: Synology.

It was set to public on the windows based client. I have since altered it to private, restarted/rebooted the client and server. No love.

Server is already set to use 8.8.8.8 and client side DNS alteration did not have an impact.

I rolled back to 1.29.2 with the same effect (I even tried rolling back to 1.25.4) with the same result. I have rebase-lined to 1.30.0. In some instances an error is displayed after waiting:

“Playback Error
An unknown error occurred (4294967283)
Error code: 4294967283”

When I first noticed this occurring I posted about the issues under PMS for Synology thread, and after working through the troubleshooting process there it was determined that the server is working correctly, but that this is a client-side issue (potentially one between the chair and the keyboard).

Edit-
More peculiarity: There is an active stream outside of my network that is showing a remote connection without using the Relay–Dashboard indicates remote bandwidth utilization and >2Mbps transfer rates.

I then opened up a session of Plex-for-Windows and logged in as another Home user and attempted to play a file for 20~ seconds. Downloaded logs and inspected. I note no errors and I do not see anything peculiar except for “DEBUG - CERT: incomplete TLS handshake from…” which given the classification do not think it necessarily the problem per se, but it is the only thing I see.

When duplicating the procedure above and inspecting the console in real-time I get the following warning: " [Req#2358]Could not convert “state” (“error”) to the correct type " which I think relates to the previously mentioned error code.

4

Took a gamble to see if I could spot any differences between a successful client play (via android) and a faulty play (via Windows). I also happened to turn on Verbose logging in case anything happened to show up and have since turned it off. I am unsure if this is normal behavior, but a rather blatant difference appears to be in Part ID enumeration of the stream. For instance from the Window’s client (snipped to save space):

Dec 04, 2022 10:49:24.876 [0x7fa7eeb70b38] DEBUG - Completed: [192.168.1.240:61733] 200 GET /status/sessions (6 live) TLS GZIP 1ms 2250 bytes (pipelined: 1)
Dec 04, 2022 10:49:24.903 [0x7fa7e9b5bb38] DEBUG - [Req#f43d] PlayQueue: Client tfc2we7knojd1m6xya6xm7aa requested ownership of play queue 3785, but already had it.
Dec 04, 2022 10:49:24.905 [0x7fa7e9b5bb38] DEBUG - We’re going to try to auto-select an audio stream for account 24511356.
Dec 04, 2022 10:49:24.905 [0x7fa7e9b5bb38] DEBUG - Selecting best audio stream for part ID 8061 (autoselect: 1 language: en)
…
Dec 04, 2022 10:49:24.907 [0x7fa7e9b5bb38] DEBUG - Selecting best audio stream for part ID 8062 (autoselect: 1 language: en)
…
Dec 04, 2022 10:49:24.909 [0x7fa7e9b5bb38] DEBUG - Selecting best audio stream for part ID 8063 (autoselect: 1 language: en)
…
Dec 04, 2022 10:49:24.911 [0x7fa7e9b5bb38] DEBUG - Selecting best audio stream for part ID 8064 (autoselect: 1 language: en)
…
Dec 04, 2022 10:49:24.929 [0x7fa7e9b5bb38] DEBUG - Selecting best audio stream for part ID 8073 (autoselect: 1 language: en)
Dec 04, 2022 10:49:24.929 [0x7fa7e9b5bb38] DEBUG - We’re going to try to auto-select a subtitle.
Dec 04, 2022 10:49:24.929 [0x7fa7e9b5bb38] DEBUG - Subtitles: Found a candidate subtitle language [en] for a foreign film
Dec 04, 2022 10:49:24.929 [0x7fa7e9b5bb38] DEBUG - Audio Stream: 21619, Subtitle Stream: 21621

But when compared to a successful run of a client on the local network (the android client–snipped as well):

Dec 04, 2022 10:53:03.136 [0x7fa7ebde6b38] DEBUG - [Req#f6d8] We’re going to try to auto-select an audio stream for account 1.
Dec 04, 2022 10:53:03.136 [0x7fa7ebde6b38] DEBUG - [Req#f6d8] Selecting best audio stream for part ID 271 (autoselect: 0 language: en)
Dec 04, 2022 10:53:03.136 [0x7fa7ebde6b38] DEBUG - [Req#f6d8] Audio Stream: 20681, Subtitle Stream: -1
…
Dec 04, 2022 10:53:03.334 [0x7fa7e9b5bb38] DEBUG - [Req#f6f1] Selecting best audio stream for part ID 271 (autoselect: 0 language: en)
…
Dec 04, 2022 10:53:03.384 [0x7fa7ebde6b38] DEBUG - [Req#f5d1] Selecting best audio stream for part ID 271 (autoselect: 0 language: en)
…
Dec 04, 2022 10:53:05.540 [0x7fa7ebde6b38] DEBUG - Selecting best audio stream for part ID 271 (autoselect: 0 language: en)
Dec 04, 2022 10:53:05.540 [0x7fa7ebde6b38] DEBUG - Audio Stream: 20681, Subtitle Stream: -1

It reads to my layman’s eyes that the windows client is trying to start 12 streams simultaneously while the android client is just starting and updating one stream. Perhaps that’s not what’s happening and this is intended behavior?

Reviewing the client logs at the same time I see the following error:

Dec 04, 2022 10:49:23.495 [18820] ERROR - [Web] WebSocket connection to ‘wss://–REDACTED–.4db739e416524e7581a5b3e78c937e54.plex.direct:32400/:/websockets/notifications?X-Plex-Token=xxxxxxxxxxxxxxxxxxxx’ failed: WebSocket is closed before the connection is established.

There also seems to be errors with using [Loopback], but the servers are still found…

Dec 04, 2022 10:49:39.504 [18820] INFO - [Web] [Connections] Testing legacy connection for [Loopback] at http://127.0.0.1:32400
Dec 04, 2022 10:49:41.539 [18820] ERROR - [Web] [Connections] [Loopback] is unavailable at http://127.0.0.1:32400/media/providers (Status 0)
Dec 04, 2022 10:49:41.539 [18820] ERROR - [Web] [Connections] [Loopback] is unavailable at http://127.0.0.1:32400/media/providers (Status 0)
Dec 04, 2022 10:49:41.542 [18820] ERROR - [Web] [Connections] All connections to [Loopback] failed
Dec 04, 2022 10:49:41.543 [18820] INFO - [Web] [Servers] Found all servers = Balthasar, plex.tv
Dec 04, 2022 10:49:46.260 [18820] ERROR - [Web] An entity does not exist with the type “servers” and id “undefined”

These seem much more promising to isolating the source of the error/troubleshooting. Any ideas?

5

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