[Flatpak] Screen and Window Capture no longer works with new update due to org.kde.Platform 6.6 about obs-studio HOT 34 OPEN

I have the same issue on Debian 12, OBS 30.1.0 (Flatpak).

Also: Please provide a Matrix (and/or IRC) room. Asking people to use Discord is... Weird...

Here is a log for when I try to select a window:

info: [pipewire] Stream 0x55dd734acb70 state: "paused" (error: none)
info: [pipewire] Stream 0x55dd734acb70 state: "unconnected" (error: none)
'loop->recurse > 0' failed at ../src/pipewire/thread-loop.c:426 pw_thread_loop_wait()
info: PipeWire initialized
info: [pipewire] Screencast session created
info: [pipewire] Asking for window
info: [pipewire] window selected, setting up screencast
info: [pipewire] Server version: 0.3.65
info: [pipewire] Library version: 0.3.83
info: [pipewire] Header version: 0.3.83
error: bmalloc: Allocating 0 bytes is broken behavior, please fix your code! This will crash in future versions of OBS.
error: bmalloc: Allocating 0 bytes is broken behavior, please fix your code! This will crash in future versions of OBS.
error: bmalloc: Allocating 0 bytes is broken behavior, please fix your code! This will crash in future versions of OBS.
error: bmalloc: Allocating 0 bytes is broken behavior, please fix your code! This will crash in future versions of OBS.
error: bmalloc: Allocating 0 bytes is broken behavior, please fix your code! This will crash in future versions of OBS.
error: bmalloc: Allocating 0 bytes is broken behavior, please fix your code! This will crash in future versions of OBS.
info: [pipewire] Created stream 0x55dd734acb70
info: [pipewire] Stream 0x55dd734acb70 state: "connecting" (error: none)
info: [pipewire] Playing stream 0x55dd734acb70
info: [pipewire] Stream 0x55dd734acb70 state: "paused" (error: none)
info: [pipewire] Negotiated format:
info: [pipewire]     Format: 8 (Spa:Enum:VideoFormat:BGRx)
info: [pipewire]     Modifier: 0xffffffffffffff
info: [pipewire]     Size: 1680x1050
info: [pipewire]     Framerate: 0/1
info: [pipewire] Stream 0x55dd734acb70 state: "streaming" (error: none)

And here is from when I try to create a screen source:

info: PipeWire initialized
info: User added source 'Skärmkälla (PipeWire)' (pipewire-desktop-capture-source) to scene 'Scen'
info: [pipewire] Screencast session created
info: [pipewire] Asking for desktop
info: [pipewire] desktop selected, setting up screencast
info: [pipewire] Server version: 0.3.65
info: [pipewire] Library version: 0.3.83
info: [pipewire] Header version: 0.3.83
error: bmalloc: Allocating 0 bytes is broken behavior, please fix your code! This will crash in future versions of OBS.
error: bmalloc: Allocating 0 bytes is broken behavior, please fix your code! This will crash in future versions of OBS.
error: bmalloc: Allocating 0 bytes is broken behavior, please fix your code! This will crash in future versions of OBS.
error: bmalloc: Allocating 0 bytes is broken behavior, please fix your code! This will crash in future versions of OBS.
error: bmalloc: Allocating 0 bytes is broken behavior, please fix your code! This will crash in future versions of OBS.
error: bmalloc: Allocating 0 bytes is broken behavior, please fix your code! This will crash in future versions of OBS.
info: [pipewire] Created stream 0x55dd734d2470
info: [pipewire] Stream 0x55dd734d2470 state: "connecting" (error: none)
info: [pipewire] Playing stream 0x55dd734d2470
info: [pipewire] Stream 0x55dd734d2470 state: "paused" (error: none)
info: [pipewire] Negotiated format:
info: [pipewire]     Format: 8 (Spa:Enum:VideoFormat:BGRx)
info: [pipewire]     Modifier: 0xffffffffffffff
info: [pipewire]     Size: 1920x1200
info: [pipewire]     Framerate: 0/1
info: [pipewire] Stream 0x55dd734d2470 state: "streaming" (error: none)

from obs-studio.

I'd like to close my comments by thanking everyone involved in this. At least in todays world Debian Stable has flatpaks Snaps, AppImages, and Distrobox containers as third party ways to run OBS and of course the work around here to use Backports / Testing Sid if needs be. So thank you all for you're hard work for this issue.

from obs-studio.

This sounds more likely to be a support request rather than a bug report, and we are not currently accepting support requests on GitHub Issues. Please use our forums or Discord for further assistance.

Thank you!

from obs-studio.

@tytan652 where do we report bugs with the flatpak then? I don't see how this is a support issue but a bug in the latest version distributed through flatpak.

from obs-studio.

Something that raised my eyebrow on the log provided is this:

12:21:04.414: [pipewire]     Framerate: 0/1

According to my napkin maths, 0 frames per second it not a satisfactory value!

from obs-studio.

@columbarius hey, do you know what this modifier means in context of PipeWire:

12:21:12.649: [pipewire]     Modifier: 0xffffffffffffff

Is it the implicit modifier?

from obs-studio.

Also: Please provide a Matrix (and/or IRC) room. Asking people to use Discord is... Weird...

An IRC room already exists:

• #obsproject on Libera.chat
• #obsproject on QuakeNet

Other than that, let's keep this Issue on-topic.

from obs-studio.

Just some added information:
The surface is not black, it's transparent.

from obs-studio.

@columbarius hey, do you know what this modifier means in context of PipeWire:

12:21:12.649: [pipewire]     Modifier: 0xffffffffffffff

Is it the implicit modifier?

If this is the whole 64bit no, invalid starts with some 0s. If its only the lower bits cut to 32bit, this could be invalid.

from obs-studio.

If this is the whole 64bit no, invalid starts with some 0s. If its only the lower bits cut to 32bit, this could be invalid.

It is indeed MOD_INVALID , or 0x00ffffffffffffff. We can probably modify the precision to show leading zero but there is no modifier defined for -1 so readers should assume this is MOD_INVALID in most cases.

from obs-studio.

Can we please stay on topic for this problem. OBS flatpak has retained the above problem for multiple releases on Debian 12. I am using Distrobox and a Ubuntu 20.04 container as my work around. Where specifically can we request the need for a fix / workaround to the org.kde.Platform 6.6 dependency ?.

from obs-studio.

Can we please stay on topic for this problem.

None of the last comments are off topic.

OBS flatpak has retained the above problem for multiple releases on Debian 12.

So it's highly possible a bug from Debian packages.

from obs-studio.

The topic is flatpak related. The very title suggests an issue with a flatpak package. Thank goodness for Distrobox. Though I will try with Fedora 39 on Flatpak and see if the same issue appears.

from obs-studio.

Duplicate of #10371

All actual reporting users are using Debian 12.

from obs-studio.

#10371

Many thanks I will continue to track #10371

from obs-studio.

Thanks to @serhii-nakon in #10371 for figuring out an update of pipewire on Debian resolves the issue.

I'm going to list the steps I did here for anyone in the future and closing the issue.

sudo cat > /etc/apt/sources.list.d/bookworm-backports.list <<'EOF'
deb http://deb.debian.org/debian bookworm-backports main
EOF

sudo apt update
sudo apt -t bookworm-backports install --upgrade pipewire

Then I rebooted, unmasked OBS as I was sticking to the last release, upgraded OBS and it worked.

from obs-studio.

@tytan652 OBS just changed requirements for Pipewire version in 30 release. It would be cool if it will described in requirements that it now require newer version than before...

from obs-studio.

@tytan652 It not Debian issue, OBS just started require newer version of pipewire than before and nobody know about it.

from obs-studio.

We use what the Freedesktop Runtime/SDK provides for PipeWire.
If Debian no longer works with newer Flatpak runtime, the issue is unlikely on OBS Studio.

Until now only Debian 12 users have reported the issue, no Ubuntu users, no EL/RHEL users…

from obs-studio.

@tytan652 Problem happened only after update OBS (without any changes on Debian side), also I not sure does it only Debian specific issue, I think it depend on what Pipewire version OBS require now and what version installed in each distributive. And also remember that not all distributive use Wayland by default, if i correctly remember Arch, Fedora, Debian and last one does not update everything for 2 years (I mean that Debian use Pipewire from 2023 - and additional updating from backports helps) but Arch and Fedora regularly update everything. Ubuntu if I correctly remember use Xorg by default.

That's why better to show somewhere what version is require for every release OBS.

from obs-studio.

If you want OBS to even have a prayer at providing you with this kind of information you should request pipewire provide a stronger compatibility guarantee and testing. They report being compatible and as you have found they broke compatibility. There isn't much we can do if our dependencies say "it should work" but actually it does not.

We certainly dont have the resources to test all of our dependencies on debian so we can only rely on bug reports to know when things are broken. We also cant know if/when things might be fixed on every linux distribution under the sun, so trying to maintain such a list is not feasible. If you want to take up maintaining the list of all compatibility bugs with debian and software from the future, im sure debian users would appreciate it. Then we could link your maintained list for users wondering what version is required for every OBS release.

from obs-studio.

@kkartaltepe @tytan652 I got what you are trying to say. I just though that OBS developers changed requirement for Pipewire and thought that you can add information about it to readme or something like that - looks like can not.

Looks like we can only notice that after update runtime for OBS it can be incompatible with host and that all...

How about adding to Flatpak release notice something like "Updated runtime please check Pipewire compatibility and update it if need" - it looks like simple joke for Wayland users from Pipewire :)

Hmm, here more serious solution, do you can add some validation in OBS that check does Pipewire from host provide screen and works at least as expected (in runtime) and if no, show message about it, that can redirect customers to distributive maintainers to update Pipewire package.

If it not possible I think the best way just describe this situation in some Debian, Arch... wiki and that's all

from obs-studio.

To be entirely clear: there was no intention on our side to require newer PipeWire versions on the host system, and so far this is pointing to a regression on PipeWire itself.

Our PipeWire code wasn't changed in any backwards-incompatible way recently, but it may be that the specific combination of PipeWire 0.3.65 (Debian 12) on the host system, and PipeWire 0.3.83 (FreeDesktop SDK) on the app, may cause this.

I'll reopen this issue as we keep investigating what's going on.

from obs-studio.

AFAIK, PipeWire only guarantees old libraries to work with newer servers, and not the other way around, since a newer lib might require flags unknown to the server. We could check the versions and log if the lib/header version is newer.

from obs-studio.

@columbarius @GeorgesStavracas Thank you!!! I have a question, does it possible to get Pipewire server and client version in runtime and check does server version lower than clients, if yes then show message like "Your current Pipewire version {server_version} but we recommend to use {client_version} or newer to avoid problems with compatibility"?

Yes it a bit tricky but it allow to quickly figure out why something does not work correctly and update necessary parts if need. Better to avoid this situation but in case while it not yet possible it can be small workaround for users.

from obs-studio.

Flatpak has normally no access to the host PipeWire server (and we do not plan to add new features that relies on a sandbox hole).
Portals allows us to get a core object from it only after selecting the ScreenCast sources.

So we can't do such a check beforehand, maybe when we get the core but it's quiet late UI/UX wise.

I think we might have just crossed a limit of how much a fixed release distro can keep up with recent Flatpak runtime.

from obs-studio.

I think it's possible to change how the negotiation goes based on the version of the PipeWire server, we already have some checks for that. The main problem here, in my opinion, is figuring out what exactly OBS needs to do differently on older versions of PipeWire. I don't really know. Nothing about it seems documented anywhere 🙁

from obs-studio.

@gegoxaren can you please start the screencast starting obs with 'PIPEWIRE_DEBUG =4' and then run pw-dump and post both?

from obs-studio.

@GeorgesStavracas maybe if we restrict OBS to SHM buffers for older servers only. This should make negotiation easier.

from obs-studio.

If I may considering the discussion largely stemmed from Debian 12 users on stable.
Am writing this in the hope it prevents the developers a major troubleshooting headache
The version of pipewire in Debian 12 stable is 0.3.65 where OBS 30.1.1 Flatpak is BROKEN.
Using Distrobox and a container image of Ubuntu 20.04 Pipewire version 0.3.48 OBS 30.1.1 is WORKING.
Using Debian Backports which updates Pipewire to version 1.0.3-1~bpo12+1 OBS 30.1.1 is WORKING. (This is this forums suggested solution).
Fedora uses Pipewire version 0.3.84-2 and there doesn't appear to be any issue reported with OBS and flatpaks
Might the problem just be running OBS and future versions of it specifically on 0.3.65 of Pipewire.

from obs-studio.

@columbarius
Sorry for the late reply. Been sick.

Without capture active:
screencapture1.log

With capture active:
screencapture2.log

diff:
screencapture.txt

from obs-studio.

I think that these things should not happen, at all... I understand you want the latest and greatest, but Flatpak was promised to us to provide the middle layer to abstract away all the headaches.

The fact that the build of the middle layer (Qt Platform) is does not guarantee the Portal stuff works on Debian Stable is odd. It smells like it's a test-case or API versioning that has been missed somewhere (thus missing the need for fullbacks).

Sure, Backports are fine-and-dandy, but it should not be required. Flatpak and Desktop Portals was suppose to abstract away that headache.

If anyone goes down the back-ports route, please make sure that the priority of the repo is set so it's not used by default. See the following for more information: https://wiki.debian.org/AptConfiguration . And remember to read: https://wiki.debian.org/DontBreakDebian

Edit:
The workaround above does work. And I would argue that it's such a minor thing that it should not imact system stability or comparability.

from obs-studio.

This isn't only for Debian. It's also happening on Fedora 40 kinoite. I actually don't even have an option to select screen/windows:

from obs-studio.

@zastrixarundell, your issue is unrelated. You just have non-functional portal and we are not currently accepting support requests on GitHub Issues. Please use our forums or Discord for further assistance.

from obs-studio.