Issue/Describe the bug
Stuttering every 100ms - Video Queue is full
Stable Launcher v4.22.9 Client 3.9.8
Steps to Reproduce:
1. Using this AppImage https://update.shadow.tech/launcher/prod/linux/ubuntu_18.04/Shadow.AppImage
2. Using Testing -> Software Decoding
3. Launching any game in sufficient Bitrate/Resolution/Framerate. (at least 1080p/60hz)
4. Checking Shadow.log:
The shadow.log shows me that the Video queue is full:
[52564 ] [2021-02-26 17:34:55.701] [i] [VIDEO ] (0) asking for IDR, clearing the queue
[52564 ] [2021-02-26 17:34:55.801] [i] [VIDEO ] (0) Idr received after 99 ms
[52564 ] [2021-02-26 17:34:56.494] [w] [VIDEO ] (0) Video queue full
[52564 ] [2021-02-26 17:34:56.494] [i] [VIDEO ] (0) asking for IDR, clearing the queue
[52564 ] [2021-02-26 17:34:56.588] [i] [VIDEO ] (0) Idr received after 94 ms
[52564 ] [2021-02-26 17:34:57.225] [w] [VIDEO ] (0) Video queue full
[52564 ] [2021-02-26 17:34:57.225] [i] [VIDEO ] (0) asking for IDR, clearing the queue
You implemented a while ago the function to use Software decoding in the Ubuntu app.
That solved a lot of problems, for people like me. I am running a laptop with a MX150 and it doesnt have an integrated NVIDIA decoder. So now the Cloud App uses the iGPU to decode.
I use shadow the same way under windows, just using the iGPU, no problems.
Now, since 1 week or so, the decoding is broken, so that it has reload-stuttering about every 100ms.
This goes on and on every time the video decoder is loaded with anything like a game for example.
Its most likely caused a change on the streamer (encoder) side that made a regression on client end.
I sent you logs multiple times now, that show the buffer overflow.
"Share the following code with developers: LFRTFG"
Thanks for submitting your bug report.
Could you also send the system information from your Ubuntu computer?
(From Ubuntu section of https://help.shadow.tech/hc/en-gb/articles/360000541374-How-to-Send-Diagnostic-Logs-to-Shadow-Support)
Thank you in advance.
///////*767//////////////// OS: Pop!_OS 20.04 LTS x86_64
//////7676767676*////////////// Host: TM1701
/////76767//7676767////////////// Kernel: 5.8.0-7642-generic
/////767676///*76767/////////////// Uptime: 6 mins
///////767676///76767.///7676*/////// Packages: 2195 (dpkg), 22 (flatpak),
/////////767676//76767///767676//////// Shell: bash 5.0.17
//////////76767676767////76767///////// Resolution: 2560x1440, 2560x1440, 192
///////////76767676//////7676////////// DE: GNOME
////////////,7676,///////767/////////// WM: Mutter
/////////////*7676///////76//////////// WM Theme: Pop
///////////////7676//////////////////// Theme: Pop-dark [GTK2/3]
///////////////7676///767//////////// Icons: Pop [GTK2/3]
//////////////////////'//////////// Terminal: gnome-terminal
//////.7676767676767676767,////// CPU: Intel i7-8550U (8) @ 4.000GHz
/////767676767676767676767///// GPU: NVIDIA GeForce MX150
/////////////////////////// GPU: Intel UHD Graphics 620
///////////////////// Memory: 2596MiB / 15829MiB
Short explaination, PopOS (or all Ubuntu derivatives) support Nvidia Prime Offloading.
Which in theory is great, cause I could use the GPU for running shadow (Arekinath Patch https://gitlab.com/aar642/libva-vdpau-driver) but the MX150, and some others, dont have a dedicated VDPAU Decoder for some reason.
So the only option is to run Shadow in the iGPU, which the Software Decoder allows.
Everything worked since you implemented the Testing->Software Decoding until a while ago when the Video Buffer Queue Problem started.
Thanks for sending the requested info.
After reviewing your logs, we noticed you were using H.265 (also known as Low Bandwidth mode setting) which is slower to decode than H.264.
Could you try switching to H.264 (disable Low Bandwidth setting) and let us know if that resolves the stuttering issue?
I’ve sent you the logs where I am on 264, and the bug is there, then switch to 264, the bug is the same there (even more frequent, even though the logs show 100ms still).
“We're on it! Share the following code with developers: WSRGBL”
Excerpt from Shadow.log (full shadow.log via sent ID)
I tried answering, but only got that my answer is under revision. I added the code from the shadow.log.
Here again the shared log:
We're on it! Share the following code with developers: WSRGBL
To make it clear, the error is under 264 and 265. Under 265 it feels that the stuttering is quicker but the shadow log still shows a repeating full video queue of 100ms
[23061 ] [2021-03-06 16:07:00.597] [w] [VIDEO ] (0) Video queue full
[23061 ] [2021-03-06 16:07:00.597] [i] [VIDEO ] (0) asking for IDR, clearing the queue
[23061 ] [2021-03-06 16:07:00.687] [i] [VIDEO ] (0) Idr received after 90 ms
[23061 ] [2021-03-06 16:07:01.349] [w] [VIDEO ] (0) Video queue full
[23061 ] [2021-03-06 16:07:01.349] [i] [VIDEO ] (0) asking for IDR, clearing the queue
[22989 ] [2021-03-06 16:07:01.544] [i] [APP ] Changing codec to H265
[23188 ] [2021-03-06 16:07:06.322] [w] [VIDEO ] (0) Video queue full
[23188 ] [2021-03-06 16:07:06.322] [i] [VIDEO ] (0) asking for IDR, clearing the queue
[23188 ] [2021-03-06 16:07:06.415] [i] [VIDEO ] (0) Idr received after 92 ms
[23188 ] [2021-03-06 16:07:06.767] [w] [VIDEO ] (0) Video queue full
[23188 ] [2021-03-06 16:07:06.767] [i] [VIDEO ] (0) asking for IDR, clearing the queue
[23188 ] [2021-03-06 16:07:06.861] [i] [VIDEO ] (0) Idr received after 93 ms
Before further questions arrise of “changing options in the shadow app”:
There is no combination of settings, in the current Appimage provided as Normal or Beta App, that doesnt produce this Bug. (Trust me: Hours of trying, there is NO functioning option setting combination)
ANY combination of checkboxes taken, or not taken, WILL produce this bug.
There is NO way to prevent this bug with the software I have available from shadow on ANY Computer running Linux/Ubuntu/PopOS that is running a dGPU while using Software decoding, in 264 or 265.
I hope this disclaimer drastically speeds up more clarification questions.
It might be important to note, that this error is only happening when playing high-refresh-rate applications via Shadow.
The desktop, or editing a text file is not sufficient to overflow my Video Queue.
There is a direct correlation between frames shared / per time interval - and the emergence of this bug.
I assume that somehow the shadow app doesnt clear out the video queue in a proper way. And once the vram is full, it needs to ask for clear space, and then gets it, video queue full again, etc.
Thats the major theory in Discord currently on this bug. Also others are having this error too. Its systemic in the Shadow Encoder/Decoder software.
Its not system related in the sense that the PCs cant decode, because any video stream decoding (264 OR 265) works fine, for example the same tech under PARSEC works flawlessly.
I cant edit existing Post to add more information, thats why I am writing a reply.
Its important to add that this is not a fundamental error on the client side. The tech is there and everything is supported.
The error is on the Shadow Appimage for Linux, or the shadow streamer.
Booting Shadow on the same Computer, creates the video overflow and stuttering.
Activating Parsec, to stream to the parsec app from shadow to the parsec app on client (linux pc), doesnt stutter.
Both streams can be side by side, shadow stutters, parsec doesnt. Also Steam (gaming plattform) STREAM, doesnt stutter.
I can have left monitor Shadow, right Monitor Parsec/Steam/whatever, and only Shadow App stutters.
Parsec or Steam use 264 decoding. But parsec also has a 265 decoding. ALL OF THOSE WORK.
They are just not native to the shadow architecture, so a higher delay/latency is existing.
The Steam STREAM is currently the best solution, but it has worse resolution/details than the Shadow Streamer. So I am still massively invested in a fix.
Please guys, it was perfect only 1 week ago. The “golden age” from 01.01 - 01.03.
Dont leave your clients hanging, I use shadow daily and have second shadow already in pre-order...
Thanks for your detailed reply. I’ll circle back with the dev team on this so they can further investigate.
Can I ask what the status of this Issue is?
Where the technicians able to replicate or do you guys need more data logs?
Hi guys, have you got a proper response to this issue by now ?
I actually wanted to go back to Linux for some reason and discover that it is litterally impossible to make my Shadow work properly.
I shall say that makes me quite unhappy considering there was also this “one free month” stuff that was unclear and I ultimately couldn’t get it.
5 months and this isn’t solved yet, apparently.
Nor L-100 error or Encoder / Decoder stuttering.
Any deadline for this ?
Please try the latest Linux beta app released today to see if that resolves your issues.
You can download it at https://shdw.me/linuxbeta
All the best!