A Variety of Screensharing Issues

[AdalynBlack]

Describe the bug

• impossible to stream fullscreen applications. Normally in Discord, it has some issues, but if you alt tab to the fullscreen application and back, it shows up for a bit, then disappears, and if you click it during that time, you can stream it. On Vesktop, there simply is no way to stream a fullscreen application. The best I've gotten is by making it windowed mode, streaming it, then going to fullscreen, at which point it only sends a new frame every time I alt tab from the game.
• stream enters an infinite loading screen initially, with the only way to fix it being to go to the stream options and switching applications, at which point it works fine. Also, there's no way to customize the bitrate, which while not an inherent bug, is somewhat annoying if any parties have a poor internet connection.

To Reproduce

Steps to reproduce the behavior:

1. Start a call
2. Attempt to stream a fullscreen application
3. The fullscreen application doesn't appear as an option
4. Attempt to stream a windowed application
5. The stream loads forever and never shows a single frame
6. Change windows to any application/screen (including the current one)
7. Stream suddenly works?

Expected behavior

Streaming a screen or application works, regardless of windowed or fullscreen status, and works on the first attempt without needing to switch the stream target to make the stream actually start.

Screenshots

Desktop (please complete the following information):

• OS: Windows 11
• Version: 22H2

Command line output

[19036:0201/112448.098:ERROR:wgc_capturer_win.cc(255)] Source is not capturable.
[19036:0201/112449.130:ERROR:wgc_capturer_win.cc(255)] Source is not capturable.
[19036:0201/112506.812:ERROR:cert_issuer_source_aia.cc(34)] Error parsing cert retrieved from AIA (as DER):
ERROR: Couldn't read tbsCertificate as SEQUENCE
ERROR: Failed parsing Certificate

[Vendicated]

The second issue is that the stream enters an infinite loading screen initially, with the only way to fix it being to go to the stream options and switching applications, at which point it works fine

issue either with discord or your desktop environment. this even happens on stock discord sometimes

[Vendicated]

as for your other issue, any reason you can't just share the monitor the fullscreen app is on?

[AdalynBlack]

For the second issue, I've never had that happen on stock discord. I also can't exactly change my DE given that I'm on windows. I might be able to mess with some settings, but I wouldn't know where to start with that even. I'll check for a driver update, but I have my doubts that it will help, given that it worked fine yesterday when I first installed it, and I've never had the issue on Discord/Vencord with everything else otherwise being the same

For the first issue, that's the workaround I've been having to use. That or switching to borderless windowed, but some apps don't have that. It's just not exactly convenient, nor is it really the same given that, should I ever alt tab (I only have one monitor), viewers will be able to see everything going on. It also means that desktop audio will be streamed rather than just game audio, and that notifications will show up in stream

[Curve]

as for your other issue, any reason you can't just share the monitor the fullscreen app is on?

I can share full screen applications just fine

[AdalynBlack]

Interesting
For me it's always been a bit buggy on Discord/Vencord, with the option only showing for a second or so after alt tabbing
With Vesktop, it just flat-out doesn't show up
Are you using windows? And if so, what version, and what graphics drivers?

[Curve]

Interesting
For me it's always been a bit buggy on Discord/Vencord, with the option only showing for a second or so after alt tabbing
With Vesktop, it just flat-out doesn't show up
Are you using windows? And if so, what version, and what graphics drivers?

Using Arch Linux, Latest Nvidia drivers

[AdalynBlack]

I see
I'll update my graphics drivers and test once I get the chance to. I'm also using NVidia, but I'm also a version or two behind right now I believe

Also, I had a friend that had the same issue the other day, and they're running AMD. I can ask what driver version specifically if that helps for debugging

[AdalynBlack]

I checked my drivers, and I am using driver version 31.0.15.4617, which appears to just be another name for version 546.17. I am using this with an RTX 3070 from ASUS

[Vendicated]

drivers shouldn't have anything to do with this. i made the desktop comment referring to Linux desktop environments, it doesn't apply to windows

[Vendicated]

im not sure how fixable this is. screenshare framework is provided by electron/chromium and the one calling it is discord, so both issues are out of our control. maybe there is some weird workaround for fullscreen windows but it seems like it's a chromium limitation

try opening discord.com/app in a chromium based browser (like edge or chrome) and see if you can share full screen apps in them. if not, there's likely not much we can do

[AdalynBlack]

I just updated my graphics drivers and the issue of needing to switch stream inputs seems to be fixed now, but last time it broke after a reboot, so we'll have to see if it works after a reboot or not. As for the fullscreen apps, the same issue is still present

[TacoCake]

I know this is wontfix, but just for the sake of tracking this;

I have the same screensharing issues.

System info

OS: openSUSE Tumbleweed
Desktop: KDE Plasma 5.27.10 (Wayland)
Vesktop Version: 1.5.0 (Flatpak)

AMD GPU with mesa 23.3.4 drivers.

Pipewire 1.0.1

[Vendicated]

im not sure how fixable this is. screenshare framework is provided by electron/chromium and the one calling it is discord, so both issues are out of our control. maybe there is some weird workaround for fullscreen windows but it seems like it's a chromium limitation

try opening discord.com/app in a chromium based browser (like edge or chrome) and see if you can share full screen apps in them. if not, there's likely not much we can do

^

[TacoCake]

Works correctly in Google Chrome for me

[TacoCake]

In my case, it might be related to Wayland/xdg-desktop-portals, because it seems that Google Chrome, at least for me, is running under XWayland whilst Vesktop is running in Wayland mode.

Might be an issue with the desktop portal implementation for getting the video stream?

Anyway, the issue is not consistent, it works for a moment, then at some point, it will refuse to share anything.

[Vendicated]

it shouldn't depend on whether you run in wayland or xwayland. it will use the pipewire capturer either way, which in turn uses your desktop environment's xdg portal

inconsistent behaviour with chrome is strange, that should not happen. but it might be related to vesktop using a slightly older chrome because the past few chrome versions have brought many improvements. try running with latest electron

there's not much we can do anyway as we just use the apis provided by electron & chrome

[stevenre3d]

Can confirm I and my partner see this issue regularly. Usually right after Vencord starts up screen sharing will work, but if it's been more than a few minutes, I often get this infinite loading loop. A working stream will also eventually stop working spontaneously. I didn't know about using "Change Windows" as a workaround, but can confirm this does work. I've also never seen this behavior with the stock client or the browser client, but obviously those don't share sound.

My suspicion is that something is getting moved around in pipewire, and maybe electron has a bug where it doesn't track the state change appropriately, and restarting (or changing windows I guess) forces it to re-query the state, or something.

I'm on manjaro, with QTile WM, and an AMD GPU, and my partner is on Mint, with Cinnamon, on an Nvidia GPU. I also saw this same behavior with Webcord, so yeah, I'm convinced it's electron's fault.

Perhaps...it's possible to detect when the situation is happening somehow and do two rapid Change Windows automatically? It would be hacky, but I would rather have a quick flicker than my friends tell me, "yeah, it stopped working again" every 20m. I would be surprised if this isn't a common issue people are hitting.

[Curve]

Can confirm I and my partner see this issue regularly. Usually right after Vencord starts up screen sharing will work, but if it's been more than a few minutes, I often get this infinite loading loop. A working stream will also eventually stop working spontaneously. I didn't know about using "Change Windows" as a workaround, but can confirm this does work. I've also never seen this behavior with the stock client or the browser client, but obviously those don't share sound.

My suspicion is that something is getting moved around in pipewire, and maybe electron has a bug where it doesn't track the state change appropriately, and restarting (or changing windows I guess) forces it to re-query the state, or something.

I'm on manjaro, with QTile WM, and an AMD GPU, and my partner is on Mint, with Cinnamon, on an Nvidia GPU. I also saw this same behavior with Webcord, so yeah, I'm convinced it's electron's fault.

Perhaps...it's possible to detect when the situation is happening somehow and do two rapid Change Windows automatically? It would be hacky, but I would rather have a quick flicker than my friends tell me, "yeah, it stopped working again" every 20m. I would be surprised if this isn't a common issue people are hitting.

I doubt it's an issue related with pipewire, once the stream is stopped everything goes back to the default state (i.e. venmic node and all associated links are deleted)

[stevenre3d]

I agree, I said I think it's a bug in electron.

[GsK380]

The only thing that I wanna to say - is that for me, it worked sometime and stopped on the newest version (v1.4.2), at first, everything worked, then the same issue, but then Flatpak's version of Vesktop (v1.4.1) started working, I have no idea what happened, all actions were done on Fedora 40 with AMD Based system on vanilla GNOME with minimal extensions, Vesktop v1.4.2 were installed using rpm package from this GitHub while Vencord v1.4.1 - from Flathub

[yumio7]

Perhaps...it's possible to detect when the situation is happening somehow and do two rapid Change Windows automatically? It would be hacky, but I would rather have a quick flicker than my friends tell me, "yeah, it stopped working again" every 20m. I would be surprised if this isn't a common issue people are hitting.

this. seemingly just starts an infinite loading loop after a time, sometimes its once every few minutes, and other times it runs for like an hour before i see it, but i have absolutely no idea what the cause is. Arch Linux, Wayland, AMD drivers

[nullcubee]

Chiming in to say that the issue where screensharing works for a few minutes and then turns into an infinite loading loop has been plaguing me too on Wayland. Restarting sharing/changing windows works until it decides to break again, rinse and repeat.

I've tested with both the wlr and hyprland xdg desktop portals and it's the same deal with both, and I get the following line in the console when the screensharing breaks:

'loop->recurse > 0' failed at ../src/pipewire/thread-loop.c:425 pw_thread_loop_wait()

Relevant line in the pipewire code

I did some testing and in just the Chromium browser with stock discord I had the same issue, but without the error in the console as far as I can tell. Using just a regular screen sharing test appears to work just fine however. Same story with Firefox. I'm really not sure where the underlying issue could be coming from or if its just a config/setup issue on my end, but a workaround as mentioned to restart the sharing/change windows in the background would be greatly appreciated, if possible.

System Info
OS: NixOS (unstable)
Desktop: River (Wayland/wlroots)
Vesktop Version: 1.5.3 (nixpkgs)
XDG Desktop Portal: wlr (also tested with hyprland)
GPU: AMD

[Dazukodesu]

This same exact thing is happening to me
System Info
OS: EndevourOS
Desktop: Hyprland (Wayland)
XDG Desktop Portal: Hyprland
GPU: Nvidia RTX 4070
Vesktop Version: 1.5.3

[11283:0902/120952.547443:ERROR:interface_endpoint_client.cc(722)] Message 6 rejected by interface blink.mojom.WidgetHost [11283:0902/120952.547466:ERROR:interface_endpoint_client.cc(722)] Message 7 rejected by interface blink.mojom.WidgetHost [11321:0902/120952.631968:ERROR:angle_platform_impl.cc(44)] ImageEGL.cpp:112 (operator()): eglCreateImage failed with 0x00003009 ERR: ImageEGL.cpp:112 (operator()): eglCreateImage failed with 0x00003009 [11321:0902/120952.632114:ERROR:scoped_egl_image.cc(23)] Failed to create EGLImage: EGL_SUCCESS [11321:0902/120952.632135:ERROR:native_pixmap_egl_binding.cc(113)] Unable to initialize binding from pixmap [11321:0902/120952.632265:ERROR:ozone_image_backing.cc(329)] OzoneImageBacking::ProduceSkiaGanesh failed to create GL representation [11321:0902/120952.632405:ERROR:shared_image_manager.cc(230)] SharedImageManager::ProduceSkia: Trying to produce a Skia representation from an incompatible backing: OzoneImageBacking [11321:0902/120952.632471:ERROR:gpu_service_impl.cc(1125)] Exiting GPU process because some drivers can't recover from errors. GPU process will restart shortly. [11283:0902/120952.636621:ERROR:gpu_process_host.cc(1002)] GPU process exited unexpectedly: exit_code=8704 [11391:0902/120952.815264:ERROR:angle_platform_impl.cc(44)] ImageEGL.cpp:112 (operator()): eglCreateImage failed with 0x00003009 ERR: ImageEGL.cpp:112 (operator()): eglCreateImage failed with 0x00003009 [11391:0902/120952.815579:ERROR:scoped_egl_image.cc(23)] Failed to create EGLImage: EGL_SUCCESS [11391:0902/120952.815868:ERROR:native_pixmap_egl_binding.cc(113)] Unable to initialize binding from pixmap [11391:0902/120952.816073:ERROR:ozone_image_backing.cc(329)] OzoneImageBacking::ProduceSkiaGanesh failed to create GL representation [11391:0902/120952.816220:ERROR:shared_image_manager.cc(230)] SharedImageManager::ProduceSkia: Trying to produce a Skia representation from an incompatible backing: OzoneImageBacking [11391:0902/120952.816476:ERROR:gpu_service_impl.cc(1125)] Exiting GPU process because some drivers can't recover from errors. GPU process will restart shortly. [11283:0902/120952.826446:ERROR:gpu_process_host.cc(1002)] GPU process exited unexpectedly: exit_code=8704 [11420:0902/120952.987019:ERROR:angle_platform_impl.cc(44)] ImageEGL.cpp:112 (operator()): eglCreateImage failed with 0x00003009 ERR: ImageEGL.cpp:112 (operator()): eglCreateImage failed with 0x00003009 [11420:0902/120952.987130:ERROR:scoped_egl_image.cc(23)] Failed to create EGLImage: EGL_SUCCESS [11420:0902/120952.987147:ERROR:native_pixmap_egl_binding.cc(113)] Unable to initialize binding from pixmap [11420:0902/120952.987189:ERROR:ozone_image_backing.cc(329)] OzoneImageBacking::ProduceSkiaGanesh failed to create GL representation [11420:0902/120952.987204:ERROR:shared_image_manager.cc(230)] SharedImageManager::ProduceSkia: Trying to produce a Skia representation from an incompatible backing: OzoneImageBacking [11420:0902/120952.987270:ERROR:gpu_service_impl.cc(1125)] Exiting GPU process because some drivers can't recover from errors. GPU process will restart shortly. [11283:0902/120952.990474:ERROR:gpu_process_host.cc(1002)] GPU process exited unexpectedly: exit_code=8704 [11328:0902/120953.054659:ERROR:command_buffer_proxy_impl.cc(132)] ContextResult::kTransientFailure: Failed to send GpuControl.CreateCommandBuffer. 'loop->recurse > 0' failed at ../pipewire/src/pipewire/thread-loop.c:425 pw_thread_loop_wait() [2024-09-02 12:10:13.014] [venmic] [info] [patchbay] (handle) found default metadata: 38 [2024-09-02 12:10:13.014] [venmic] [info] [patchbay] (meta_update) speaker name: "alsa_output.usb-Burr-Brown_from_TI_USB_Audio_CODEC-00.analog-stereo-output" [2024-09-02 12:10:13.014] [venmic] [info] [patchbay] (get) running venmic 6.1.0 [11283:0902/121039.747149:ERROR:screen_capture_portal_interface.cc(48)] Failed to request session: Timeout was reached [11283:0902/121039.747186:ERROR:base_capturer_pipewire.cc(81)] ScreenCastPortal failed: 3

[Cleboost]

same prblm

[Bahnschrift]

I've been having issues with screensharing for the last month or two (I'm guessing since the release of v1.5.4?), but rolling back to previous commits, it seems like I need to go all the way back to df05d12 (from April) to get properly working screenshare on Linux. I've been using Vesktop since around September, and I've always had issues with streams being initially low resolution then switching to the correct resolution, but the issues have got particularly bad recently.

With the commit after that (8eaa520, which from what I can see, overhauled how screenshare works on Linux), the stream doesn't load at all if watching on an Android phone, but somewhat works if watching on the desktop app on another device (albeit at a weirdly low resolution for a while, then flashes to black, and comes back at a higher resolution).

The latest version of Vesktop (v1.5.4) just has an infinitely loading stream or black screen for most viewers.

I'm running Arch, and these issues occur on both Hyprland (wayland) and Plasma (wayland AND x11).

This seems like it's probably the same issue as #1012.

[AdalynBlack]

It's been a while since I posted on this issue, so here's my update

Screensharing works perfectly for me on Linux. Here's the output from inxi -Fxz as a reference for my system setup

I have a friend on a very similar setup to me, same distro, same DE, same audio setup, etc, except they're using an AMD gpu, and both screensharing and camera feeds are partially broken for them. Specifically, the screenshare or camera output often will flash green, then completely freeze and stop updating for many users. For me, I see the green glitching, as well as some tearing, but their screenshare is still fully functional afterwards

[Kiriaevi]

My system:
OS: Arch Linux
Kernel version: Linux 6.12.8-zen1-1-zen
Desktop: Gnome (wayland) 47.2
Vesktop Version: 1.5.3 flatpak
CPU: AMD Ryzen 7 6800HS
GPU: AMD Radeon 680M
All the streams I have done are in "720p 30 fps" with "prefer clarity" option enabled.

Regarding the infinite loop loading, I have the same issue on Arch Linux.
I tried doing some testing and found out that if the other user tries to connect to my live stream using an Android device or the web client (for example: firefox), it works. However, if the other user uses only the official Discord app, only the preview is visible. This behavior has been tested with another Discord client on Windows.
I tested it with GNOME, Hyprland and Sway, it doesn't work. I tried using both XWayland and Wayland, still doesn't work.
This is the output when I run flatpak vesktop inside GNOME with XWayland:

[kiriaevi@archMachine ~]$ flatpak run dev.vencord.Vesktop
Passing the following arguments to Electron: --enable-speech-dispatcher
[3:0107/121837.505156:ERROR:bus.cc(407)] Failed to connect to the bus: Failed to connect to socket /run/dbus/system_bus_socket: File o directory non esistente
APPIMAGE env is not defined, current application is not an AppImage
checkForUpdatesAndNotify called, downloadPromise is null
[3:0107/121838.030768:ERROR:bus.cc(407)] Failed to connect to the bus: Failed to connect to socket /run/dbus/system_bus_socket: File o directory non esistente
[3:0107/121838.030861:ERROR:bus.cc(407)] Failed to connect to the bus: Failed to connect to socket /run/dbus/system_bus_socket: File o directory non esistente
[arRPC > ipc] listening at /run/user/1000/discord-ipc-0
[arRPC > websocket] listening on 6463
[arRPC > process] started
[45:0107/121842.138073:ERROR:gl_surface_presentation_helper.cc(260)] GetVSyncParametersIfAvailable() failed for 1 times!
[45:0107/121842.154688:ERROR:gl_surface_presentation_helper.cc(260)] GetVSyncParametersIfAvailable() failed for 2 times!
[3:0107/121853.134875:ERROR:egl_dmabuf.cc(408)] Error during eglInitialize: EGL_NOT_INITIALIZED
[45:0107/121853.194276:ERROR:gl_surface_presentation_helper.cc(260)] GetVSyncParametersIfAvailable() failed for 3 times!
'loop->recurse > 0' failed at ../src/pipewire/thread-loop.c:425 pw_thread_loop_wait()
[2025-01-07 12:18:53.637] [venmic] [info] [patchbay] (handle) found default metadata: 40
[2025-01-07 12:18:53.637] [venmic] [info] [patchbay] (meta_update) speaker name: "bluez_output.AC_12_2F_F0_05_EA.1"
[2025-01-07 12:18:53.638] [venmic] [info] [patchbay] (get) running venmic 6.1.0
[3:0107/121900.796285:ERROR:egl_dmabuf.cc(408)] Error during eglInitialize: EGL_NOT_INITIALIZED
'loop->recurse > 0' failed at ../src/pipewire/thread-loop.c:425 pw_thread_loop_wait()
[3:0107/121901.003585:ERROR:egl_dmabuf.cc(408)] Error during eglInitialize: EGL_NOT_INITIALIZED
'loop->recurse > 0' failed at ../src/pipewire/thread-loop.c:425 pw_thread_loop_wait()

And this is with wayland:

[kiriaevi@archMachine ~]$ flatpak run dev.vencord.Vesktop
Wayland socket is available, running natively on Wayland.
To disable, remove the --socket=wayland permission.
Passing the following arguments to Electron: --enable-speech-dispatcher --ozone-platform-hint=auto --enable-wayland-ime
[3:0107/122504.698661:ERROR:bus.cc(407)] Failed to connect to the bus: Failed to connect to socket /run/dbus/system_bus_socket: File o directory non esistente
APPIMAGE env is not defined, current application is not an AppImage
checkForUpdatesAndNotify called, downloadPromise is null
[3:0107/122505.280158:ERROR:bus.cc(407)] Failed to connect to the bus: Failed to connect to socket /run/dbus/system_bus_socket: File o directory non esistente
[3:0107/122505.280252:ERROR:bus.cc(407)] Failed to connect to the bus: Failed to connect to socket /run/dbus/system_bus_socket: File o directory non esistente
[arRPC > ipc] listening at /run/user/1000/discord-ipc-0
[arRPC > websocket] listening on 6463
[arRPC > process] started
[3:0107/122515.815944:ERROR:shared_x_display.cc(39)] Unable to open display
'loop->recurse > 0' failed at ../src/pipewire/thread-loop.c:425 pw_thread_loop_wait()
[2025-01-07 12:25:18.198] [venmic] [info] [patchbay] (handle) found default metadata: 40
[2025-01-07 12:25:18.198] [venmic] [info] [patchbay] (meta_update) speaker name: "bluez_output.AC_12_2F_F0_05_EA.1"
[2025-01-07 12:25:18.199] [venmic] [info] [patchbay] (get) running venmic 6.1.0
[3:0107/122522.254392:ERROR:shared_x_display.cc(39)] Unable to open display
'loop->recurse > 0' failed at ../src/pipewire/thread-loop.c:425 pw_thread_loop_wait()
[3:0107/122522.524513:ERROR:shared_x_display.cc(39)] Unable to open display
[55:0107/122523.982663:ERROR:gbm_pixmap_wayland.cc(82)] Cannot create bo with format= YUV_420_BIPLANAR and usage=SCANOUT_CPU_READ_WRITE
[55:0107/122523.982823:ERROR:gpu_channel.cc(503)] Buffer Handle is null.
[55:0107/122524.018358:ERROR:gbm_pixmap_wayland.cc(82)] Cannot create bo with format= YUV_420_BIPLANAR and usage=SCANOUT_CPU_READ_WRITE
[55:0107/122524.018491:ERROR:gpu_channel.cc(503)] Buffer Handle is null.
[55:0107/122524.054841:ERROR:gbm_pixmap_wayland.cc(82)] Cannot create bo with format= YUV_420_BIPLANAR and usage=SCANOUT_CPU_READ_WRITE
[55:0107/122524.054980:ERROR:gpu_channel.cc(503)] Buffer Handle is null.
[55:0107/122524.087340:ERROR:gbm_pixmap_wayland.cc(82)] Cannot create bo with format= YUV_420_BIPLANAR and usage=SCANOUT_CPU_READ_WRITE
[55:0107/122524.087528:ERROR:gpu_channel.cc(503)] Buffer Handle is null.
[55:0107/122524.121758:ERROR:gbm_pixmap_wayland.cc(82)] Cannot create bo with format= YUV_420_BIPLANAR and usage=SCANOUT_CPU_READ_WRITE
[55:0107/122524.121872:ERROR:gpu_channel.cc(503)] Buffer Handle is null.
[55:0107/122524.157317:ERROR:gbm_pixmap_wayland.cc(82)] Cannot create bo with format= YUV_420_BIPLANAR and usage=SCANOUT_CPU_READ_WRITE
[55:0107/122524.157502:ERROR:gpu_channel.cc(503)] Buffer Handle is null.
[55:0107/122524.194185:ERROR:gbm_pixmap_wayland.cc(82)] Cannot create bo with format= YUV_420_BIPLANAR and usage=SCANOUT_CPU_READ_WRITE
[55:0107/122524.194355:ERROR:gpu_channel.cc(503)] Buffer Handle is null.
[55:0107/122524.226224:ERROR:gbm_pixmap_wayland.cc(82)] Cannot create bo with format= YUV_420_BIPLANAR and usage=SCANOUT_CPU_READ_WRITE
[55:0107/122524.226399:ERROR:gpu_channel.cc(503)] Buffer Handle is null.
[55:0107/122524.261374:ERROR:gbm_pixmap_wayland.cc(82)] Cannot create bo with format= YUV_420_BIPLANAR and usage=SCANOUT_CPU_READ_WRITE
[55:0107/122524.261518:ERROR:gpu_channel.cc(503)] Buffer Handle is null.
[55:0107/122524.297081:ERROR:gbm_pixmap_wayland.cc(82)] Cannot create bo with format= YUV_420_BIPLANAR and usage=SCANOUT_CPU_READ_WRITE
[55:0107/122524.297228:ERROR:gpu_channel.cc(503)] Buffer Handle is null.
[55:0107/122524.333541:ERROR:gbm_pixmap_wayland.cc(82)] Cannot create bo with format= YUV_420_BIPLANAR and usage=SCANOUT_CPU_READ_WRITE
[55:0107/122524.333728:ERROR:gpu_channel.cc(503)] Buffer Handle is null.
[55:0107/122524.366847:ERROR:gbm_pixmap_wayland.cc(82)] Cannot create bo with format= YUV_420_BIPLANAR and usage=SCANOUT_CPU_READ_WRITE
[55:0107/122524.366963:ERROR:gpu_channel.cc(503)] Buffer Handle is null.
[55:0107/122524.402614:ERROR:gbm_pixmap_wayland.cc(82)] Cannot create bo with format= YUV_420_BIPLANAR and usage=SCANOUT_CPU_READ_WRITE
[55:0107/122524.402752:ERROR:gpu_channel.cc(503)] Buffer Handle is null.
[55:0107/122524.438060:ERROR:gbm_pixmap_wayland.cc(82)] Cannot create bo with format= YUV_420_BIPLANAR and usage=SCANOUT_CPU_READ_WRITE
[55:0107/122524.438209:ERROR:gpu_channel.cc(503)] Buffer Handle is null.
[55:0107/122524.476277:ERROR:gbm_pixmap_wayland.cc(82)] Cannot create bo with format= YUV_420_BIPLANAR and usage=SCANOUT_CPU_READ_WRITE
[55:0107/122524.476475:ERROR:gpu_channel.cc(503)] Buffer Handle is null.
[55:0107/122524.476737:ERROR:gbm_pixmap_wayland.cc(82)] Cannot create bo with format= YUV_420_BIPLANAR and usage=SCANOUT_CPU_READ_WRITE
[55:0107/122524.476818:ERROR:gpu_channel.cc(503)] Buffer Handle is null.
[55:0107/122524.512773:ERROR:gbm_pixmap_wayland.cc(82)] Cannot create bo with format= YUV_420_BIPLANAR and usage=SCANOUT_CPU_READ_WRITE
[55:0107/122524.512899:ERROR:gpu_channel.cc(503)] Buffer Handle is null.
[55:0107/122524.513066:ERROR:gbm_pixmap_wayland.cc(82)] Cannot create bo with format= YUV_420_BIPLANAR and usage=SCANOUT_CPU_READ_WRITE
'loop->recurse > 0' failed at ../src/pipewire/thread-loop.c:425 pw_thread_loop_wait()

I followed the suggestion of another user in the issue #1012 and tried downgrading to version 1.5.1 using the command:
flatpak --user update --commit=b03a262a4a03e08167e04bc0a65ae09ff6f520882c1f4c40da02ff0895911899 dev.vencord.Vesktop and now it works in GNOME with the following output.

[kiriaevi@archMachine ~]$ flatpak run dev.vencord.Vesktop
Passing the following arguments to Electron: --ozone-platform-hint=auto
[3 zypak-helper] Wait found events, but sd-event found none
[3:0107/124007.200237:ERROR:bus.cc(407)] Failed to connect to the bus: Failed to connect to socket /run/dbus/system_bus_socket: File o directory non esistente
[3:0107/124008.106683:ERROR:bus.cc(407)] Failed to connect to the bus: Failed to connect to socket /run/dbus/system_bus_socket: File o directory non esistente
[3:0107/124008.106808:ERROR:bus.cc(407)] Failed to connect to the bus: Failed to connect to socket /run/dbus/system_bus_socket: File o directory non esistente
[arRPC > ipc] listening at /run/user/1000/discord-ipc-0
[arRPC > websocket] listening on 6463
[arRPC > process] started
[3:0107/124022.507549:ERROR:shared_x_display.cc(39)] Unable to open display
[2025-01-07 12:40:25.884] [venmic] [info] [patchbay] (get) running venmic 3.3.2
[2025-01-07 12:40:25.896] [venmic] [info] [patchbay] (add_global) found metadata: 40
[3:0107/124032.326881:ERROR:shared_x_display.cc(39)] Unable to open display
'loop->recurse > 0' failed at ../src/pipewire/thread-loop.c:426 pw_thread_loop_wait()
[3:0107/124033.807970:ERROR:shared_x_display.cc(39)] Unable to open display
'loop->recurse > 0' failed at ../src/pipewire/thread-loop.c:426 pw_thread_loop_wait()
[3:0107/124033.851061:ERROR:shared_x_display.cc(39)] Unable to open display

It still gives some kind of error, but the user on the other end can view my stream without any issues
Note that this version does not have encoding hardware acceleration.

[barraIhsan]

I have a friend on a very similar setup to me, same distro, same DE, same audio setup, etc, except they're using an AMD gpu, and both screensharing and camera feeds are partially broken for them. Specifically, the screenshare or camera output often will flash green, then completely freeze and stop updating for many users. For me, I see the green glitching, as well as some tearing, but their screenshare is still fully functional afterwards

I also reported the issue on #1031, but got marked as a duplicate (most likely duplicate of #851, #997, #837) & system issue. Anyway I asked on the reddit about this issue and someone said that it's happening because vesktop updated to recent version of chromium

[BlackFuffey]

I have a similar issue.

• If I share the whole screen, the stream will never load for other people.
• If I share a windowed application, the stream works. However it freezes the moment I fullscreen the application, and turns back normal if I window it again.
• If I share a fullscreened application, the stream does not load. If I window the application while still streaming, stream will load instantly.
• If I share region of screen, the stream never loads, and for some reason the preview on host pc is showing the whole screen instead of the selected region

A few things to note:

• Host stream preview always works (other than selected region)
• Audio always works, even when stream itself is loading
• Camera always works

System info:

• Distro: Arch
• GPU: 7800xt
• DE/WM: Hyprland
• Desktop portal: xdg-desktop-portal-hyprland
• Vesktop version: 1.5.4

Vesktop was installed through the vesktop-binAUR package. I also tested with the vesktop package, same thing.

[CelDaemon]

I'm currently having an issue with Vesktop sometimes completely freezing after clicking the button to start a screenshare, then selecting my main monitor in the KDE dialog.

It does open the menu to select the audio channel and other settings, but the application completely freezes after that, including the system tray menu. It's still possible to talk in the VC and hear things however.

I'm having this issue on Fedora 41 KDE, using Wayland and the official .rpm package

[extremq]

I also have an AMD GPU (6750xt) and screenshare is very buggy on Arch with KDE, vesktop on flatpak. 720p 30fps whole screen works but only if i dont select clarity.

[Vendicated]

We are aware of the issue. New comments contribute nothing, so I'm locking this issue