moonlight keeps disconnecting
kmworld opened this issue · comments
READ ME FIRST!
If you're here because something basic is not working (like gamepad input, video, or similar), it's probably something specific to your setup, so make sure you've gone through the Troubleshooting Guide first: https://github.com/moonlight-stream/moonlight-docs/wiki/Troubleshooting
If you still have trouble with basic functionality after following the guide, join our Discord server where there are many other volunteers who can help (or direct you back here if it looks like a Moonlight bug after all). https://moonlight-stream.org/discord
Describe the bug
A clear and concise description of what the bug is.
Steps to reproduce
Any special steps that are required for the bug to appear.
Screenshots
If applicable, add screenshots to help explain your problem. If the issue is related to video glitching or poor quality, please include screenshots.
Affected games
List the games you've tried that exhibit the issue. To see if the issue is game-specific, try streaming Steam Big Picture with Moonlight and see if the issue persists there.
Other Moonlight clients
- Does the issue occur when using Moonlight on PC or Android?
Moonlight settings (please complete the following information)
- Have any settings been adjusted from defaults? deafult
- If so, which settings have been changed? no
- Does the problem still occur after reverting settings back to default? yes
Gamepad-related issues (please complete if problem is gamepad-related)
- Do you have any gamepads connected to your host PC directly? no
- If gamepad input is not working, does it work if you use Moonlight's on-screen controls? no
- Does the problem still remain if you stream the desktop and use https://html5gamepad.com to test your gamepad?
- Instructions for streaming the desktop can be found here: https://github.com/moonlight-stream/moonlight-docs/wiki/Setup-Guide
Device details (please complete the following information)
- iOS/tvOS version: [e.g. iOS 14.2] 16
- Device model: [e.g. iPhone 11 Pro] 13 mini
Server PC details (please complete the following information)
- OS: [e.g. Windows 10 1809] Windows 11 21H2
- GeForce Experience version: [e.g. 3.16.0.140] 3.26.0.131
- Nvidia GPU driver: [e.g. 417.35] 517.48
- Antivirus and firewall software: [e.g. Windows Defender and Windows Firewall] Windows Defender and Windows Firewall
Additional context
Anything else you think may be relevant to the issue or special about your specific setup.
pc specs : 9900k / 32gb / rtx 3080
Hi.
If I playing games for about almost 10 minutes using Moonlight, suddenly app will be forced to close.
But, game is still running on my PC, and I can return to the game by resume again.
However, if I playing games for 10 to 15 minutes, the same thing will happen.
When I checked the NvStreamerCurrent.log file, I checked the log as below.
#4(W)[2022-09-28 02:56:28,681]=11:56:28={5189033000984229476} waitForClientCommand: No packets seen on control channel from 7514 ms, time-out: 500 ms, last command 200 received, dispatch queue size is 2314885530818453536.
#5(W)[2022-09-28 02:56:29,182]=11:56:29={5189033000984229476} waitForClientCommand: No packets seen on control channel from 8015 ms, time-out: 500 ms, last command 200 received, dispatch queue size is 2314885530818453536.
#6(W)[2022-09-28 02:56:29,682]=11:56:29={5189033000984229476} waitForClientCommand: No packets seen on control channel from 8515 ms, time-out: 500 ms, last command 200 received, dispatch queue size is 2314885530818453536.
#7(W)[2022-09-28 02:56:29,730]=11:56:29={7699961024659795146} Packet 154 on channel 0 retransmitted 27 times; current timeout is 500 and timeout limit is 160
#8(W)[2022-09-28 02:56:30,184]=11:56:30={5189033000984229476} waitForClientCommand: No packets seen on control channel from 9017 ms, time-out: 500 ms, last command 200 received, dispatch queue size is 2314885530818453536.
#9(W)[2022-09-28 02:56:30,684]=11:56:30={5189033000984229476} waitForClientCommand: No packets seen on control channel from 9517 ms, time-out: 500 ms, last command 200 received, dispatch queue size is 2314885530818453536.
#0(W)[2022-09-28 02:56:30,731]=11:56:30={7699961024659795146} Packet 154 on channel 0 retransmitted 29 times; current timeout is 500 and timeout limit is 160
#1(M)[2022-09-28 02:56:31,168]=11:56:31={2404429921060333688} Client has not responded in 10001 ms, triggering disconnection
#2(I)[2022-09-28 02:56:31,168]=11:56:31={2404429921060333688} Found 2314885530818453536 packets in socket queue that are not dispatched
#3(D)[2022-09-28 02:56:31,168]=11:56:31={2404429921060333688} Setting event 'Session'. NvscStreamingSession: NvscStreamingSession::HandlePreCaptureEvent (0x80040018 NVST_NETERR_CLIENT_TIMED_OUT_PACKETS_IN_DISPATCH_QUEUE)
#4(I)[2022-09-28 02:56:31,168]=11:56:31={2612636755034591657} Stop event received, tearing down.
#5(I)[2022-09-28 02:56:31,168]=11:56:31={2612636755034591657} Starting teardown
#6(I)[2022-09-28 02:56:31,168]=11:56:31={2612636755034591657} Quit requested, waiting on child threads to quit
#7(I)[2022-09-28 02:56:31,168]=11:56:31={2612636755034591657} Termination infos:
#8(I)[2022-09-28 02:56:31,168]=11:56:31={2612636755034591657} - Source 'NvscStreamingSession', reason 'NvscStreamingSession::HandlePreCaptureEvent', code 0x80040018 NVST_NETERR_CLIENT_TIMED_OUT_PACKETS_IN_DISPATCH_QUEUE
#9(I)[2022-09-28 02:56:31,168]=11:56:31={2612636755034591657} Termination reason to report: NVST_NETERR_CLIENT_TIMED_OUT_PACKETS_IN_DISPATCH_QUEUE
#0(D)[2022-09-28 02:56:31,168]=11:56:31={2612636755034591657} Destroying video streamer thread.
#1(I)[2022-09-28 02:56:31,168]=11:56:31={3708500471382890733} Invoking diagnosticsEventRaised TerminationReason
#2(I)[2022-09-28 02:56:31,168]=11:56:31={2404429921060333688} Client not alive. Will now quit after 42963 frames completed
#3(D)[2022-09-28 02:56:31,168]=11:56:31={1692877488063076642} About to destroy native thread: VideoStreamerThread (thread id: 215E4046241F2878)
#4(W)[2022-09-28 02:56:31,168]=11:56:31={2404429921060333688} Forcing failure to get frame, signalling stop
#5(M)[2022-09-28 02:56:31,168]=11:56:31={2404429921060333688} Perform video streaming is done. stream:0 Actual frames:42962. Frame Number 42962
#6(I)[2022-09-28 02:56:31,168]=11:56:31={2866109302478211984} Server has been asked to end the current streaming session.
#7(I)[2022-09-28 02:56:31,168]=11:56:31={2866109302478211984} Server is now in state: EndingSession
#8(D)[2022-09-28 02:56:31,168]=11:56:31={2866109302478211984} Append to 'Session'. NvscStreamingSession: NvscStreamingSession::HandlePreCaptureEvent (0x80040018 NVST_NETERR_CLIENT_TIMED_OUT_PACKETS_IN_DISPATCH_QUEUE)
#9(I)[2022-09-28 02:56:31,168]=11:56:31={3708500471382890733} DiagnosticEvent: Reported UnifiedErrorCode 8043800e for SessionTerminationReason 800e
#0(I)[2022-09-28 02:56:31,168]=11:56:31={2404429921060333688} VideoStreamEventRaised
#1(I)[2022-09-28 02:56:31,168]=11:56:31={2866109302478211984} Terminating RTSP session
Suddenly, the dispatch queue rises and then disconnects. Why is it like this?
I'm using wifi 6 router and I don't think it's a router problem because there was no problem while streaming and playing PC games through Oculus Quest 2.
and my android tablet was work fine.
I need your help.
- Newly discovered facts:
When I checked the time when the connection was terminated (the app was forced to shut down), it was close to 18 minutes.
It seems to be terminated intentionally by something.
Along with my iPhone 13, I had the same symptoms on iPad pro 11 (gen4).
Duplicate of #527
This is fixed by c21f638 and 2ae79c5.
It turns out that streaming worked on GFE 3.26 basically by luck. Due to a bug in buffer processing exposed by a change in GFE 3.26, we were discarding the first video data buffer which contained garbage data from the new video data header introduced in GFE 3.26. If not for that bug, streaming wouldn't have worked at all. However, the first buffer was also where we attached the reference to handle freeing the underlying video data itself, so discarding it meant that nothing ever freed the video data. As a result, we would leak memory for each video frame and eventually run out of memory and crash.
The fixes are included in v8.2.0 which is live for iOS now and still waiting for review for tvOS at the time of this post.
This is fixed by c21f638 and 2ae79c5.
It turns out that streaming worked on GFE 3.26 basically by luck. Due to a bug in buffer processing exposed by a change in GFE 3.26, we were discarding the first video data buffer which contained garbage data from the new video data header introduced in GFE 3.26. If not for that bug, streaming wouldn't have worked at all. However, the first buffer was also where we attached the reference to handle freeing the underlying video data itself, so discarding it meant that nothing ever freed the video data. As a result, we would leak memory for each video frame and eventually run out of memory and crash.
The fixes are included in v8.2.0 which is live for iOS now and still waiting for review for tvOS at the time of this post.
I haven't played for a long time but, played for more than 20 minutes. there is no symptoms occurred.
I think it's working fine. Thank you!