I am worried about having the start of the dynamic port range to be as low as 1025. There was a reason for the dynamic ports to start at 49152 and that was to make the range as far as possible from ports used by applications - you have Plex Media Server as one example where the port has to be 32400 and if that port got given out as part of the dynamic pool it would lead to issues that would be difficult to investigate and confirm if it did happen
TIME_WAIT change may alone fix the issue and that is why I said one change at a time. If it did not then we go to next stage and decide if the port range needs to be increased and to what level but again that would be based on evidence collected from the failures with the lower TIME_WAIT value and investigated before any decision is made on what the next change would be
So I reverted the dynamic port range to default and let TIME_WAIT adjusted as it is. However, do you have any idea why the VPT generation still isn’t starting after triggering analysis on a library level?
I also had, according to the article you provided, set MaxUserPort to 32768 in the registry. I deleted that DWORD as well, so only time_wait is reduced to 60 atm
Alright. The analysis scan is already running for a few minutes and I’ll need to wait until it reaches the shows that I didn’t analyze manually yet.
But the 4227 tcpip error and therefore the transcoder errors are back (4227 in System logs), so only reducing TIME_WAIT doesn’t seem to resolve it. Should I increase the dynamic port range or not?
I also notice increased lags and unresponsiveness in the Plex Web UI while the analysis is running now, which wasn’t the case with the wider dynamic port range before and while analyzing
When I type netsh int ipv4 show dynamicport tcp it prints this
Startport : 49152
Port Numbers : 16384
Is this correct?
And yes, I rebooted after the changes. Could you maybe, if you won’t mind, copy the exact command for reverting the ports to their initial state? Is the correct command
NetSh INT IPV4 SET DynamicPort TCP Start=49152 num=16384 ?
I’ll set MaxUserPort to 32768 again and quickly reboot my machine. Thank you again for helping!
I have just experienced the same thing although only on specific movies, which is why I didn’t encounter it right away. FWIW the titles I’m having trouble with are all X265 encodes.
Yes that is the default and if it stays that way after a reboot then we know you are running at system default
The same should also show for the others as well. The 4 available commands are
netsh int ipv4 show dynamicport tcp
netsh int ipv6 show dynamicport tcp
netsh int ipv4 show dynamicport udp
netsh int ipv6 show dynamicport udp
and also regedit should either show 16384 decimal value for this HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\MaxUserPort or for the key to be absent
Next to try is a value of 32678 here and a reboot and seeing what you get from netsh int ipv4 show dynamicport tcp
May be better to do it via the Netsh command if not done already - that way we also ipv6
NetSh INT IPV4 SET DynamicPort TCP Start=32768 num=32768 NetSh INT IPV6 SET DynamicPort TCP Start=32768 num=32768
So the MaxUserPort was already set to 32678 before and all of these
showed
so that was just fine.
Now I’ve ran these 2 commands
and the 2 show commands for Ipv4/6 show
Startport : 32768
Port numbers : 32768
Is this how it’s supposed to be?
Also, this one
was present, as I’ve set it earlier and it showed 32678 as decimal
What’s the next step, if I’ve done everything correctly? Start the analysis again? If you don’t mind, was there anything peculiar you could find in the XML files/Server logs I’ve sent a few hours ago as well?
So according to your last post to set the dynamic ports to 32768 for IPv4/6 it seems like this helps a lot! I could stream without transcoder errors and a running analysis task on a library level = yay!
Now the last thing that is bogglin’ my mind is the VPT generation as stated earlier, which doesn’t start for episodes which would need VPT generation. If you may find the time, I’d appreciate if you could have a look at the logs and the XML file. If not no biggie.
Thank you for everything you’ve done so far. At least the analysis isn’t crashing the entire streaming anymore
Whilst there may be an issue with thumbnailing - these logs do not show a clean run. There were over 8000 tcp errors logged between 01:44:27 and 02:10:30
Would need to wait and know for sure the tcp ports issue is out of the way before investigating and may need to collect more data
Hey sa, thank you again for sharing your insights.
I guess it would be sufficient to wait time X after the analysis job was finished and start with a rebooted PMS? Is that correct?
If so I could just provide you with another debugging log after starting the analysis. I will do so now and if these logs are with empty tcp ports - all good and I’ll provide you with the logs - if not, please tell me how I can make sure that the tcpip error was completely filtered besides rebooting PMS.
The safest option is to reboot Windows after seeing a 4227 error in the event log
And need to know if they are still happening even with timewait set to 60 and number of ports doubled from 16384 to 32768
By the way you can using “Filter Current Log…” in Event Viewer for the System Log and where it says <All Event IDs> type in 4227,6005 and press ok
That will show 4227 and reboots - so you can easily see when the first 4227 arose after a reboot. Once you get a 4227 i am not interested in what happens afterwards until you do a reboot
Do we have an ETA on when this problem might be smoothed out? I have run through every recommended fix and work around and I eventually wind up at square one; every remote access being transcoded down to SD.
We’ve been on vacation for 2 weeks and there’s been a hell of work at work when I came home. I hope you don’t mind my late reply.
I just rebooted my Windows machine and set the ports to their initial state
(Startport : 49152
Port Numbers : 16384)
and triggered a new library scan while maxuserport is set to 32768 and TcpTimedWaitDelay to 30, as I’ve read in the meantime that this might be the recommended value. Will come back with fresh logs any minute.
This whole thread gives me flashbacks to a time that this Really Mattered for me at work.
In a past life I spent a bunch of time hunting down issues with ephemeral port range exhaustion. I expanded the ephemeral port range significantly and had problems with other apps that assumed that ports in the range would always be available to them.
Those other apps were by-definition stupid, but some of them came from Microsoft and involved important things like RPC and Active Directory and Antivirus. But this was the bad-old Server 2003 and Server 2008 days.
Reducing TcpTimedWaitDelay should be pretty safe, and Microsoft even pseudo-recommends making that change. Going from 120 to 30 should get you about 4x the headroom. It’s really unlikely you’ll break anything making that change.
I also see people talking about a StrictTimeWaitSeqCheck reg key. I wonder if you’ll need that too. I have the impression that it may be required to make TcpTimedWaitDelay fully effective. I don’t see it documented so well.
If you set TcpTimedWaitDelay and StrictTimeWaitSeqCheck and that doesn’t fix it, I wouldn’t personally hesitate to change the ephemeral port range on a personal, Plex-only, non-domain-member, modern, Windows box.
It SHOULD be perfectly safe. Unless there’s stupid software making stupid assumptions.
I would use the netsh method, and I would try start=32768 num=32768. (Default is start=49152 num=16384.)
