logs before you reduce to 5 !
Here are the DBs. I misunderstood what you said and already set the lognumfiles to 5 
If that’s not enough I’ll set them back to 30 and start an analysis again, let me know. I have my baby and the older one atm, sorry for being partially brain afk 
Plex Media Server Logs_2020-06-30_18-58-31.zip (10.8 MB)
https://drive.google.com/file/d/1EI2prUWvKIDZXNRP9FPZ2aEoe3uQS8Z0/view?usp=sharing
UPDATED 3rd July
So it appears that whilst the curl upgrade helped in delaying when we run out of ports - it did not eliminate the problem in all circumstances
The first analyze you did for the “Serien” library was at 09:36:17 and it completed at 13:58:11. The library has 61,000+ episodes. There were no errors then. - Ports were exhausted about 5 minutes after start of the analysis.
I do not know when you started the second Analyze for the library but the logs show it completed at 18:01:54 and we appear to run out of ports at about 17:53:36 (i can see some clues that suggest it was just after 17:53:28.616 - you need to tell me exact time of the first 4227 event to milliseconds)
It is possible that the 2nd analyze ran much faster than the first - using up the ports at a faster rate.
The 2nd analyze had lots of errors and this speeds up the port use but the errors i am seeing are after 17:53:36 - so could be a consequence of running out of ports. But there may have been errors before that accessing file content. (Each file takes 50ms to analyze but when there is an error accessing/processing the file, we go through it in 5ms - 10 times faster rate of port use)
I am still looking at the logs I have - so won’t ask yet for more logs.
What I will need is a complete set of logs from reboot of the PC and up to the time of the first 4227 error - to establish the rate of requests and also wireshark capture for loopback to confirm the curl fix. To get this will probably need going back to 50 logs and capturing logs every few hours until first failure.
Update
Subsequently provided event log export showed tcp ports exhausted in both analyze runs of the library. Although windows TIME_WAIT default was believed to be 120 seconds, port re-use was not happening till about 210 seconds or so after.
Current position:
The curl upgrade helps but does not resolve the problem for analysis of large TV libraries - failures were still happening after processing 4300 episodes / 3000 seasons / 1000 shows
1 Like
sa2000:
Thank you for your reply. I responded to you in another similar thread with my serve log, but I will upload them hear too. This is the first real problem with Plex servers that I haven’t been able to overcome with basic troubleshooting. Like I mentioned in the other post, I have run through the Double-NAT and port forwarding fixes to no avail. Until this point, Plex Server has been easy to use and fairly trouble free for more than a year now.Plex Media Server Logs_2020-06-30_16-57-22.zip (7.0 MB)
Whilst sifting through the logs; I did notice I am getting that error mentioned by other users in similar threads:
[10016] Error issuing curl_easy_perform(handle):28
[10016] SSDP: Error parsing device schema for https://xxx.xxx.xxx.x:49152/wps_device.xml
(just adding this last bit of info)
Respectfully,
The logs show about 1000 files that were processed at 5ms each - instead of the usual 50ms a file. So ports were used at a faster rate. I do not know what time the 4227 events were logged so i do not know if this was consequential of that or it actually contributed to the problem. The Plex Media Scanner Analysis logs do not go back to the period before the 4227 error
Do you have an idea on how to reproduce the problem? Is it just the 2nd library analysis that leads to the tcp ports issue?
I need logs covering whole period from reboot of the PC up to the time of the first 4227 event logged. Also to confirm the curl fix, i would need wireshark capture of loopback packets (pcap file) up to time of tcp port exhaustion. If you know the steps to reproduce the issue, then you could start the wireshark capture a few minutes before the ports are used up and failure.
Also would need the output from
netsh int ipv4 show dynamicport tcp
netsh int ipv6 show dynamicport tcp
@sa2000, would it make sense for Plex to approach this differently?
It seems like a losing game - scans happen faster, libraries get bigger. Even if the number of ephemeral ports is twice as big and they get returned twice as fast, it’s just a matter of time.
Is it necessary to establish a new connection for every message? Or could they be reused?
I dunno if this would address the issue, or what it would mean for Plex. I know curl supports re-using connections. I know the Server process sticks around, and it seems like the Scanner does, at least per run.
I also know lots of Transcoders get launched, and I’m not sure what else is going on, so maybe it wouldn’t address the issue.
Hey good morning y’all.
I will gladly try to capture it with wireshark. Do you maybe have a link? This is the first time I hear about it.
And to your questions: Yes, I think only the “Serien” library is causing the 4227 errors. I’m not sure how to 100% reproduce the error, but so far analyzing the Serien (TV Show) library was safe to produce TCP/IP errors and I will gladly do as you suggested and try to capture everything from a reboot until the 4227 error gets printed.
However, unfortunately my PMS machine is my working machine at the same time (I work from home and have programs running during my shift that capture my computer activities), so I won’t be able to come up with fresh logs until later this night. But I will gladly provide anything you need to smash this bug.
If you have anything to test without the necessity of a Windows reboot I’ll gladly assist you during my work shift though
I need an export of the whole system and application event logs to evtx files so i can see exact times of time windows launched and first 4227 after that - at the moment it is guesswork for me as to when we ran out of ports. Could you do that and zip the files and send me by PM. As times would adjust when i open these files (timezone diffs) - let me know what time is the first event you see when you export the file so i can adjust all the times i see to match your logs.
The other info I like to know is how many TV Library analyze runs did it take to get the first 4227. The morning run appeared to be error free
With regards to reboot - it is just the safe way of knowing we are starting from a known state with regards to what ports are in timewait and what are free when a library analysis is started
For wireshark - this is the link Wireshark · Download but loopback capture is extra setup and is mentioned here Loopback
Hey, good evening!
I will do everything you requested later this night, but for now the output of netsh int ipv4 show dynamicport tcp is
Startport : 49152
Anzahl von Ports : 16384
However, I don’t know where this belongs right now, as we’re on a custom build of yours, but I can’t use my library views right now for any of my librarie and I don’t know whether this has to do with the custom build or is a general issue of the most recently updated Plex Web (Unified design).
Of course I went for all 3 libraries 
and applied the duplicate filter, as I was missing a movie. The libraries aren’t loading anymore now and I can’t get out of there, as the options to alter or delete the filters are not present. If I wait for the spinning wheel I’d just get an error every time
Could you maybe help with that or is this another man’s pain? I don’t know to what this is related right now
And now my server keeps crashing randomly while many people are watching 
EDIT: Okay. I could get back to the library view with manually editing the plex.tv URL and replaced “duplicate” in the address bar with “actor”. Whew.
Will try and get a new build with the fix for the duplicates filter
Can you also check that tcp ipv6 range is also back to default
netsh int ipv6 show dynamicport tcp
I am still waiting for you to send me export of the event logs for the 4227 that already occurred
I will try and get a build with the fix for the duplicates filter
crashing as in the process disappears from windows task manager ?
If that is the case, look for dmp files within the Crash Reports folders and zip and send me privately together with logs after a crash
harmless
We send out an SSDP search to the local network and devices and computers on the local network respond giving details (url’s) to use and sometimes these url’s do not work
There is no impact
Adding my response here as well for continuity
This has no relevance to this forum thread and was simply a Double NAT caused by being assigned a CG-NAT (Carrier Grade NAT) IP Address by the ISP
The plan is to bring the bulk of the scanning work into the Plex Media Server process and have it in-line. This has already been done for photos and music. For movies there is a forum preview release that is being worked on New Plex Media Server movie scanner and agent preview and after movies, TV libraries would be the next one to look into
With regards to the curl reuse of connections, I believe the change was made but does not appear to help here
1 Like
Thank you again for your assistance 
I’ve been previewing that preview and it’s excellent overall. It’s wildly faster. I didn’t realize that it also changed the architecture in that way - very nice. Thanks for the response. Learning about the design of the Plex system is interesting.
1 Like
Hey all and @sa2000. Are there any updates on this? Anything I can test for you?
Oh I forgot. Yes, it has been and is at the default value 
And also I never changed it
I do not have any other changes to test. The curl upgrade has reduced the number of dynamic port pool ports used by 66% but that is not a sufficient reduction for analyzing a large TV Library on a fast PC.
I expect the curl upgrade to be released in version 1.19.6 of Plex Media Server. The issue is still open with the development team.
So for now, it will be the curl upgrade which will get round these errors for some users. For anyone that would still get the 4227 events logged in the Windows System Event Log, i would recommend temporary tactical steps such as doubling the size of the dynamic tcp pool to 32678 ports and reducing the timewait to 30 seconds - the steps to be reverted to default settings when there is another fix released.
2 Likes
