-
-
Notifications
You must be signed in to change notification settings - Fork 33
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Stream loses audio after network hiccup #493
Comments
Since there are new updates, would you like to try that first? Somehow I can't reproduce on my webOS 5 TV with 15% packet loss. |
Can confirm it happens too on my TV: LG 55UN70006LA, WebOS 5.5 Not sure if it's connected to this issue, Sunshine with debug logs also prints out:
around the same time the stream loses audio. I recorded a video of it happening: |
Hi @CraftWorksMC, do you experience it when you stream desktop too? |
Yes, it lasted a bit longer this time but it still cut out. |
@CraftWorksMC What about stereo? Does it stop and you have to restart streaming? |
With it set to stereo, using the NDL-WebOS5 backend it works flawlessly, rarely the audio stutters a bit, probably because of the connection, but the sound continues to work. Uses the PCM-S16LE codec. |
Moonlight Version
1.6.25
Device Type
webOS TV
Device Model
LC C2
Device OS
webOS 8.3.0
Host OS
Windows
Host Software
Sunshine
Host Setup
Bug Description
When using the experimental 5.1 surround sound, I semi-regularly hit a problem where sound cuts out on the stream entirely. This often coincides with a network hiccup (over wireless) where it mentions Unstable Network in the top right. However, sometimes it goes away when that message isn't shown, and I've also seen that message be shown where audio does not cut out. Suspending the stream and rejoining does not seem to fix it, so I usually quit the game+stream and just relaunch it.
I believe I have seen this since one of the first versions that added 5.1 surround. I do not remember ever seeing this without surround enabled, though I'm not positive this is true.
Is there any other information I can add to this bug report to make it easier to fix such as logging? I do not have a rooted device.
Reproduction Steps
Expected Behavior
Audio continues to work.
The text was updated successfully, but these errors were encountered: