Okay, so now it’s been half an hour without a TCPIP error in the system logs. That’s quite goodm isn’t it? At least it’s the longest time I’ve had this task running without a 4227 error 
Here are the logs @sa2000, I hope you can find something (or better: Don’t find anything peculiar 
)
If I remember correctly the analysis task started at 02:25 o’clock, with maxuserport set to 32768 and TIME_WAIT set to 30. Oh and the PMS version has changed to 1.19.5 since our last conversation 
Hey there Volts!
Thank you for joining the discussion. I’m not quite sure which of the plenty of changes helped now, but either PMS 1.19.5.XXXX or the TIME_WAIT set to 30 helped a lot. At least this is the first time I’m not getting Windows log events about tcp ip issues and the analysis task presumably being finished and actually analyzing the items.
So I’m not sure what helped, but something surely did. Could you leave me a link or further explanation about StrictTimeWaitSeqCheck? I don’t wanna change anything crucial on my machine that I cannot understand at least partially.
Thanks again for hopping in
Pshaw, don’t you always make random registry changes because random people mention that they saw them somewhere? 
Honestly I don’t see official documentation for StrictTimeWaitSeqCheck, which is annoying me. I probably shouldn’t have mentioned it. I see it on a number of vendor posts, adjacent to TcpTimedWaitDelay, suggesting that it is necessary for TcpTimedWaitDelay to be effective. I’m not sure if it’s just not documented or if it’s snake oil - there’s a LOT of “use this registry key” copy/paste “advice” on the Internet. I wish I hadn’t done the same.
I’m not advocating for this - just a link that referenced StrictTimedWaitSeqCheck:
What DID you change? That old Microsoft article seems a bit incoherent. It’s odd how it mentions MaxUserPort and how it used to start at 1025. But it also used to only go from 1025-5000 - Microsoft never shipped an OS where it went from 1025-65535. I think that article was half-updated from an old version.
This one - weirdness - it just seems old and broken to me:
MaxUserPort was the right registry value to change in Windows before Vista/2008. After that, the “netsh” method became the appropriate way to change the ephemeral port range. It’s weird to “just” set MaxUserPort on modern Windows.
This Microsoft document seems modern/relevant/accurate:
I’m curious if the Plex folks can confirm/deny that Curl’s too-many-connections behavior was fixed, because that would be nice too.
What do you see if you do this today? This should display the effective range on YOUR system, and should confirm if the MaxUserPort change actually did anything.
netsh int ipv4 show dynamicport tcp
netsh int ipv4 show dynamicport udp
netsh int ipv6 show dynamicport tcp
netsh int ipv6 show dynamicport udp
Hahaha you’re absolutely right! Same thing with random people on the internet starting their sentences with “Trust me…” - yeah sure mate
You seem to be very familiar with port exhaustion and ephemeral ports! Glad you joined.
So atm my port range is the standard one
(Startport : 49152
Port numbers : 16384)
That’s for the port range. Besides that I have the wait time set to 30 and the MaxUserPorts set to 32768 and so far everything seems to be fine after 80 minutes of analysis.
Now I can’t tell whether this is due to my changes or due to the recent PMS update today to v1.19.5…
Whatever it is, it finally seems to have resolved my issues (which was basically that VPT generation didn’t finish if I analysed an entire library and now seems to do it).
So you say TIME_WAIT set to 30 is not a big deal?
EDIT: Now I noticed that the VPT generation does at least start, but it doesn’t finish for all items, goddamnit!
“Familiar” in the sense that my eye starts to twitch when I think about it …
I absolutely wouldn’t worry about a 30 second TcpTimedWaitDelay / TIME_WAIT.
When a socket is in TIME_WAIT that means that end has closed the connection. The socket sticks around in TIME_WAIT “in case” there’s still some data floating around that you haven’t received or that the other end hasn’t sent yet.
But that’s an ooooold idea. (The movie War Games came out the same year TCP/IP was introduced.) Once your end has closed the connection, it ain’t sticking around and listening for data any more. It has Moved On. Talk to the hand, honey.
So today it mostly just causes a “quiet time” before the same combination of address:port gets reused. That might be helpful for some stateful, semi-broken firewalls. It’s probably not necessary at all for localhost.
If I’m wrong and it breaks you can keep both pieces. Or change it back.
I have a Plex Media Server development build now to make available to test out a curl fix for this
I will send out to a few users - but you will need to re-instate the windows defaults for the dynamic pool and timewait
Oh great! Will gladly test and revert the settings prior to testing.
But how do I install it? Does it have to override my current installation or can it exist alongside of my main PMS installation? And does it have to have the same items like my main installation, e.g. do I need to scan all 70.000 episodes?
Just shutdown Plex Media Server and upgrade to this test version
I will PM a link
@sa2000 Thank you very, very much for this build and all of your efforts.
It seems like this build doesn’t have the 4227 error at least in my logs and it’s blazing fast! I am quite surprised how fast the analysis/scanning/going through episodes is and also how fast metadata is being loaded when editing season/TV show posters. It feels like this is a huge step in the right direction.
However, the analysis task still didn’t finish yet and might take a while still (70k episodes).
The most important question now is for me: Would you like to have the logs when the task has finished?
Kind regards
EDIT: Correction. It seems like the analysis (viewed under “Notifications” in the server settings) was really quick at the beginning, but is now pretty slow. It’s taking like 3-~8 seconds for a single episode now. I’m not an expert but it seems to be waiting for something (ports or whatever?) to be free to go over to the next episode, but I’m not sure. After it reached shows with the letter “E” it became slower and slower. The most important thing here is, that it’s working. But with this speed it might take quite some hours or maybe days to finish its task Seems to be fine. Was maybe just “heavier” to analyse
EDIT 2: After installing the test server how can we upgrade to the stable again? Will we be able to update via the server dashboard like before? Or do we have to manually install the next PMS release?
I can also confirm, that there was no 4227 error in my system logs after installing the test server. Not before, nor after the analysis task and with all Windows settings set to default!
You cannot do that - not until 1.19.6 goes out as an official public or beta release
We are currently on 1.19.4. 1.19.5 will be beta soon.
So manual updates until then if I provide more builds.
Alright thank you, will do so. Do you need current logs?
But I’m wondering about your current PMS version statement. Yesterday I had a server update to v1.19.5 on my server which wasn’t posted in the announcements channel. Are you behind this sir?
That release was pulled back - a few users managed to update to it. There were some windows updater issues.
Happy to see logs
Oh okay I see, I was already wondering 
Thank you for clarification.
There you go. Let me know if you need anything else that needs testing.
Mhh. I don’t know what’s happening, but it doesn’t let me upload my logs. Are they too big? (66MB) Can I upload them somewhere else for you if that’s the case?
I thought the limit was 100Mb. I will try and find out
There is nowhere else - you can see if a Private Message has same restriction
Otherwise - dropbox/google drive etc and share a link
I have no idea why it’s aborting it. Always at 18%.
But I got you covered: https://drive.google.com/file/d/1Zxg6qPzRNOPE6mH-OhuHI3HfBzUOQxJu/view?usp=sharing
The limit appears to be 30Mb
It was too big because of LogNumFiles set to 50 - so the zips would be too big for the forum
Logs look good. So the curl issue has been fixed.
Only errors in the logs appear to be a few permissions / access errors
Jun 30, 2020 09:44:00.690 [11728] ERROR - Error opening file '"B:\Serien\Roots (2016)\Season 1\S01E01 - Part 1.mkv"' - Permission denied (13)
Jun 30, 2020 13:09:19.217 [25456] ERROR - Error opening file '"P:\Serien\Cheer (2020)\Season 1\S01E04 - Hit Zero.mkv"' - Permission denied (13)
This one is strange as we would have done this i expect a number of times before this error and it relates to the local app data area
Jun 30, 2020 13:56:47.765 [12732] DEBUG - BaseIndexFrameFileManager: building index (320x240) for parts for MetadataItem 152974 (Pilot)
Jun 30, 2020 13:56:47.766 [12732] ERROR - Error creating directory "Indexes": Zugriff verweigert
Jun 30, 2020 13:56:47.766 [12732] ERROR - Error creating directory "Indexes\tmp": Zugriff verweigert
I expect these to be relating to creation of
"C:\Users\donat\AppData\Local\Plex Media Server\Media\localhost\x\xxxxxxxxxxxxxxxxxxxxxxxxxx.bundle\Contents\Indexes\tmp\xxxxxx.jpg" and the .bif file
Ah okay, I see. Shall I set the lognumfiles back to its default state?
And yeah, you’re partially right. I believe these errors are due to a Sonarr import which wasn’t fully processed. I’ve had an I/O error on one of my hard drives and Sonarr imported only “half” of the episodes of “Roots (2016)”, that’s why there are access and .bif creation errors, at least that’s what I believe. Correct me if I’m wrong.
The other thing is - drum roll - I just had a 4227 and full transcoder errors for all streams. Logs again?
Yes - set it to 5
yes and application and system event logs exports to evt files
how big are the libraries ? send me download of the database
