feat: increase first frame timeout

[nenkoru]

This small change relaxes the timeout for the first frame to come from the remote hosts which take long time to initialize a videostream.

This is primarily targets use case when using Windows Hyper-V GPU Partitioning.
For some unknown reason when streaming using Sunshine it takes quite some time for the first frame to actually be sent into the stream.

Closes: #93

References:
https://www.reddit.com/r/LizardByte/comments/13n1mn6/sunshine_moonlight_on_hypervvm_with_gpupv_results/
itsmikethetech/Virtual-Display-Driver#9 (comment)
https://www.reddit.com/r/cloudygamer/comments/ubjej0/if_you_are_experiencing_the_black_screen_issue/
https://www.reddit.com/r/cloudygamer/comments/zunij1/sunshine_is_giving_me_a_blank_screen_on_a_hyperv/
https://www.reddit.com/r/LizardByte/comments/1ec8n65/enhancedgpupv_with_sunshinemoonlight_and_virtual/

[nenkoru]

ofc it doesnt remediates the root cause of the issue, which is yet unkown why long initialization, but it allows at least to use the moonlight with hyper-v gpu partitioning

[cgutman]

I think we should try to address this on the Sunshine side rather than papering over it in Moonlight. The 10 second timeout is already quite long (about 3-5x longer than the first frame is expected to take). Having to wait tens of seconds for the video to start is a bad user experience.

Please file a bug on Sunshine with logs and we can troubleshoot there.

[nenkoru]

I think we should try to address this on the Sunshine side rather than papering over it in Moonlight. The 10 second timeout is already quite long (about 3-5x longer than the first frame is expected to take). Having to wait tens of seconds for the video to start is a bad user experience.

Please file a bug on Sunshine with logs and we can troubleshoot there.

I would argue about 'bad experience' and 'no experience at all'.
I mean isn't this setting is just the upper-limit of the time Moonlight waits for the first frame?
If the frame from Sunshine in the regular installation comes fast as usual it won't hurt anyone. But those users with Hyper-V GPU-P would be able to at least receive a video stream after waiting up to 60secs.

Getting logs of this is complicated, I remember there were no distinct logs of what exactly is happening. I will try to gather info but no promise on this.

Thanks for the feedback anyway tho!

[cgutman]

I mean isn't this setting is just the upper-limit of the time Moonlight waits for the first frame?

It is, but the reason we don't just wait forever is that we want to indicate to users when they have some network issue or host-side problem that needs to be addressed. If people just see a black screen for 60 seconds with working audio and input, they're probably going to exit and assume Moonlight is broken rather than identifying that something on their host or network is the issue.

Getting logs of this is complicated, I remember there were no distinct logs of what exactly is happening. I will try to gather info but no promise on this.

You don't have to try to diagnose it all on your own. We can help. I would start with capturing a Sunshine log with the Log Level set to Verbose, so we can see the timing of the initialization that happens when starting the stream.

After getting the logs, also get a memory dump of Sunshine during this phase of the connection. Using an alternate remote desktop client, open Task Manager, go to the Details tab, then try to start a connection and wait for for Moonlight to reach the point where it's waiting for the first frame (black screen), finally right click on Sunshine.exe and choose Create Memory Dump. I would wait for at least 5 seconds at the black screen before collecting the memory dump, but make sure you don't wait so long that Moonlight has already terminated the connection. You can use your 60s workaround to make this time window easier to hit.

Additionally, does this only happen with hardware encoding or does it also happen if you force software encoding in Sunshine?

[cathyjf]

This pull request should be accepted for the reasons given at #93 (comment).