Thousands of network error messages, but straightforward network connection

Plex Media Server
1

Server Version#: 1.21.1.3830

In the recent past, I’ve been investigating some remote-access hiccups. Via scanning my server logs, I see several thousand “Errors” being indicated … which don’t actually seem to be meaningful, and often contradict themselves. Examples:

Dec 30, 2020 13:35:17.544 [0x70000dd47000] DEBUG - NetworkService: Browsing on interface 10.0.1.110 on broadcast address 239.255.255.250 (index: 0)
Dec 30, 2020 13:35:17.544 [0x70000dd47000] ERROR - Network Service: Error in browser handle read: 89 (Operation canceled) socket=-1
Dec 30, 2020 13:35:17.653 [0x70000dd47000] INFO - Network Service: Abandoning browse socket, it was closed.
Dec 30, 2020 13:35:17.653 [0x70000dd47000] ERROR - Network Service: Error in browser handle read: 89 (Operation canceled) socket=-1
Dec 30, 2020 13:35:17.763 [0x70000dd47000] INFO - Network Service: Abandoning browse socket, it was closed.
Dec 30, 2020 13:35:17.763 [0x70000dd47000] ERROR - Network Service: Error in browser handle read: 89 (Operation canceled) socket=-1
Dec 30, 2020 13:35:17.873 [0x70000dd47000] INFO - Network Service: Abandoning browse socket, it was closed.
Dec 30, 2020 13:35:17.873 [0x70000dd47000] ERROR - Network Service: Error in browser handle read: 89 (Operation canceled) socket=-1
Dec 30, 2020 13:35:17.983 [0x70000dd47000] INFO - Network Service: Abandoning browse socket, it was closed.
Dec 30, 2020 13:35:17.983 [0x70000dd47000] ERROR - Network Service: Error in browser handle read: 89 (Operation canceled) socket=-1
Dec 30, 2020 13:35:18.083 [0x70000dd47000] INFO - Network Service: Abandoning browse socket, it was closed.
Dec 30, 2020 13:35:18.083 [0x70000dd47000] ERROR - Network Service: Error in browser handle read: 89 (Operation canceled) socket=-1
Dec 30, 2020 13:35:18.187 [0x70000dd47000] INFO - Network Service: Abandoning browse socket, it was closed.
Dec 30, 2020 13:35:18.187 [0x70000dd47000] ERROR - Network Service: Error in browser handle read: 89 (Operation canceled) socket=-1
Dec 30, 2020 13:35:18.218 [0x70000db3b000] DEBUG - NetworkInterface: Notified of network changed (force=0)
Dec 30, 2020 13:35:18.219 [0x70000db3b000] DEBUG - Network change notification but nothing changed.

“…but nothing changed” - yeah, that’s the gist of it. I have a Mac mini running the latest Plex server, connected via ethernet cable to my router, Plex Remote Access seems to be enabled reliably, etc. No changes to the network configuration in months.

Remote users sometimes (often?) report significant hiccups when accessing my content, which is what prompted this investigation. While my ISP (Comcast) might be suffering occasional hiccups, it doesn’t seem that this would explain the repeated challenges, or the specific entries being seen in the log. By last count, it was over 5000 such “ERROR -” indications, within a 6 hour period (!) … when the server wasn’t even actively streaming any content (!!).

I’m guessing there must be some kind of oddity with my network configuration - but again, the setup is pretty straightforward, and seems to be working for all other needs in the household. Is this solely a Plex issue, or is there some other issue at play? Any tips on what kind of network configuration details I should investigate further, to try and resolve this concern?

** ALSO: Short of repeatedly scanning through 64,000-line “Plex Media Server.[n].log” files for strings reading “ERROR -” and trying to make sense of them, is there a better way to debug these details?

2

Hmmm… more details: In addition to my remote clients getting routine network hiccups and timeouts, I now am getting Plex playback hiccups within my local network. In addition to routine pauses during playback, I often get errors indicating that I “don’t have sufficient network bandwidth” to play back the selected file. However, the file in question is a low-bitrate 480p video, and the Plex client is connected via a hard-wired Cat6 ethernet cable to the server - with a confirmed iperf3 network speed result between these two hosts of over 650 Mbps.

So… it appears there is something else amiss, which is causing Plex to have issues with serving up its content. Again, all other network behaviors (external network speed tests, external streaming tests, web browsing/file downloads, etc. etc. etc.) all appear to work as desired - it’s only Plex which seems to have issues.

Suggestions on the server settings which I should review, or even simply how to debug further, would be greatly appreciated.

3

Do you have any security software, antivirus software, VPN software, or something like Little Snitch installed?

4

Good thoughts - but no: I specifically verified I don’t have significant security measures in place, no Little Snitch on this particular machine, and it doesn’t run a VPN client.

I keep thinking there is some kind of loopback in effect - which eventually allows the connection to “work”, but only after a significant amount of rerouting. But, I have no proof that this might be the case.

I also investigated a possible double-NAT issue, but this doesn’t seem to be apparent, either: While I do have my cable modem able to supply DHCP addresses, I handoff all “real” responsibilities for this to my router. My configuration seems to work like a charm, with no conflicts (that I’m aware of), no significant network timeouts apparent for other interactions, etc.

Any ideas on how best to troubleshoot further? Again, most other network interactions appear to be fine - it’s only Plex serving up content, which seems to be problematic.

5

Ideally reproduce the problem, then gather & share logs at that time.

6

A similar situation just occurred: At 21:41 tonight, I started to watch ST:Discovery S2E4, and it began fine, but then hiccuped part way through. This was playing back within my local network, from a server which is connected to my hard-wired network backbone - although my client in this case was connected via WiFi to a different access point, which was connected to that same hard-wired backbone. Just FYI, iperf3 tests against this configuration, verifying connections to the same Plex server host, are consistently at least in the 300-400 Mbps range. if not higher.

Appropriate Plex Media Server.log file enclosed - although I can also provide all others which were obtained via “Settings -> Manage -> Troublshooting -> Download Logs” as well, if desired.

Any ideas what’s going on? I see that it’s trying to “Direct Play” (which would be correct; great network speed, and there should be no need to transcode), but then see several Failed to stream media, client probably disconnected after {some_number} bytes: 32 - Broken pipe messages, which don’t make sense.

Also, many more of those:

WARN - NetworkServiceBrowser: Error sending out discover packet from 10.0.1.110 to 10.0.1.255: Network is down
WARN - NetworkServiceBrowser: Error sending out discover packet from 10.0.1.110 to 239.255.255.250: Network is down

and

DEBUG - NetworkService: Got notification of changed network (first change: 0)
DEBUG - NetworkService: Dispatch network change after two second delay.
DEBUG - Network change notification but nothing changed.

and

 ERROR - Network Service: Error in browser handle read: 89 (Operation canceled) socket=-1
 INFO - Network Service: Abandoning browse socket, it was closed.

…messages, but no actual change to the network during this period, should have been apparent.

And again, there are no other significant network issues which I am aware of, although this does “feel” like some sort of network problem (vs. a Plex server issue), which I need to diagnose and resolve. I’d love to be wrong, and have this simply be a Plex configuration change which I need to make, though.

Any and all insights would be welcome.

(File removed)

7

I took a stab at addressing this, by changing my network setup preferences, but am not sure it was effective. I had a Thunderbolt Bridge virtual interface active (used to expedite local transfers between two hosts), but have since disabled this - but again, cannot confirm that it has had any positive effect.

Again, any insights into what could be causing the issue, and/or additional steps to be taken in providing more diagnostic information, would be greatly appreciated.