Hmm....that wasn't supposed to happen It was supposed to crash when you had traffic and do great when you were nowhere near any other planes.
My guess is that you'll run into this problem again when you come across an airplane for which we don't have an exact model loaded. We'll see. Don't be discouraged when it happens, though, if that's it, then we can fit it. SNA doesn't actually have a lot of drone traffic around it. Try some other spots with HIGH multiplayer visibility this time (20nm) and let me know what happens if you let it sit.
I went to LAX, set my Multiplayer Visibility to 20 miles and waited. Sometimes I would switch between COM 1 and COM 2 just because I was doing the same thing when the client crashed. I left my plane on the tarmac for almost an hour with no crash. I'm going to try an actual flight later this evening and see what happens then.
Alright, so far it sounds like the firewall change did it?
I'm going to GUESS that it was a UDP mapping timeout on the router then, especially based on the consistency of the timing from your numerous reports. So, your internet connection is fine...what's not fine is that after a certain amount of time, despite a continual flow of UDP traffic on that port, your router might be just 'forgetting' who to send the inbound UDP packets to (it shouldn't do this if your application is transmitting UDP packets on a regular basis, which, I think we are).
Opening a hole in the firewall shouldn't be necessary, but apparently it's made your router act the way it should've been acting to begin with, so I guess you're doing ok.
You can go back to whatever settings you'd like in terms of visibility and start enjoying the sim. Nice find, btw, regarding the port list in the other thread I posted. I wouldn't have thought it would apply to your situation or I definitely would've mentioned it!
If you'd like to know for SURE about the crash, try closing up that UDP hole that you made (9987), repeat the test and it should crash in 10-15 mins. I would probably do it once for piece of mind, because then you can open the hole back up, permanently, and know that it was the cause, as opposed to just hoping, but that's really up to you.
Took a wonderful 2-hour flight last night from KNSA to KSBP with no trouble at all. Whew!! I will try removing the port forwarding tonight and let you know the results. Thanks for sticking with me on this issue.
Looks like the lack of the UDP port forwarding was the cause. I removed it from the router settings, went to KNSA and sat in GA parking for about 25 minutes and - SHAZAM! - the client froze. I'm using an ASUS RT-966R router if it makes any difference to you.
*sigh* Keith, I'm afraid I'm back to square 1 with this. I added the UDP port forwarding back in and was still getting a client crash. Not sure if I happen to be flying at an odd time with odd aircraft in the system or what. Last night I flew for 2 hours with nary a drop and tonight I had to reboot the client 4 times in a 30-minute stretch. I'll keep looking into it to see if I can't lock down a consistent cause.
Hop on the ramp at KMMU (Morristown, NJ). I'll pop up in a 172 on 122.75 and we'll see what happens if then I connect in a plane that you don't have (which generates an HTTP request from the client to log it on our web server). If that crashes it, we'll have our result, and doing it on the east coast guarantees no other aircraft will be in play.
It was supposed to crash when you had traffic and do great when you were nowhere near any other planes.