tytan652
commented
3 months ago Open ozonedGH opened 3 months ago
tytan652
commented
3 months ago 
fayaaz
commented
3 months ago @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.
GeorgesStavracas
commented
3 months ago Something that raised my eyebrow on the log provided is this:
12:21:04.414: [pipewire] Framerate: 0/1According to my napkin maths, 0 frames per second it not a satisfactory value!
GeorgesStavracas
commented
3 months ago @columbarius hey, do you know what this modifier means in context of PipeWire:
12:21:12.649: [pipewire] Modifier: 0xffffffffffffffIs it the implicit modifier?
gegoxaren
commented
3 months ago 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)
RytoEX
commented
3 months ago Also: Please provide a Matrix (and/or IRC) room. Asking people to use Discord is... Weird...
An IRC room already exists:
Other than that, let's keep this Issue on-topic.
gegoxaren
commented
3 months ago Just some added information: The surface is not black, it's transparent.
columbarius
commented
3 months ago @columbarius hey, do you know what this modifier means in context of PipeWire:
12:21:12.649: [pipewire] Modifier: 0xffffffffffffffIs 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.
kkartaltepe
commented
3 months ago 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.
wevansprojects
commented
3 months ago 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 ?.
tytan652
commented
3 months ago 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.
wevansprojects
commented
3 months ago 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.
tytan652
commented
3 months ago Duplicate of #10371
All actual reporting users are using Debian 12.
wevansprojects
commented
3 months ago 10371
Many thanks I will continue to track #10371
ozonedGH
commented
3 months ago Thanks to @serhii-nakon in https://github.com/obsproject/obs-studio/issues/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.
serhii-nakon
commented
3 months ago @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...
serhii-nakon
commented
3 months ago @tytan652 It not Debian issue, OBS just started require newer version of pipewire than before and nobody know about it.
tytan652
commented
3 months ago 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…
serhii-nakon
commented
3 months ago @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.
kkartaltepe
commented
3 months ago 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.
serhii-nakon
commented
3 months ago @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
wevansprojects
commented
3 months ago 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.
GeorgesStavracas
commented
3 months ago 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.
columbarius
commented
3 months ago 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.
serhii-nakon
commented
3 months ago @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.
tytan652
commented
3 months ago 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.
GeorgesStavracas
commented
3 months ago 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 :slightly_frowning_face:
columbarius
commented
3 months ago @gegoxaren can you please start the screencast starting obs with 'PIPEWIRE_DEBUG =4' and then run pw-dump and post both?
columbarius
commented
3 months ago @GeorgesStavracas maybe if we restrict OBS to SHM buffers for older servers only. This should make negotiation easier.
wevansprojects
commented
3 months ago 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.
gegoxaren
commented
2 months ago @columbarius Sorry for the late reply. Been sick.
Without capture active: screencapture1.log
With capture active: screencapture2.log
diff: screencapture.txt
gegoxaren
commented
2 months ago 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.
zastrixarundell
commented
2 months ago 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:
tytan652
commented
2 months ago 
yozachar
commented
5 days ago Updating pipewire fixed it.
For me pipewire screen sharing (both display and application) show blank screen:
flatpak infoOBS Studio - Live stream and record videos
ID: com.obsproject.Studio
Ref: app/com.obsproject.Studio/x86_64/stable
Arch: x86_64
Branch: stable
Version: 30.1.2
License: GPL-2.0-or-later
Origin: flathub
Collection: org.flathub.Stable
Installation: user
Installed: 545.8 MB
Runtime: org.kde.Platform/x86_64/6.6
Sdk: org.kde.Sdk/x86_64/6.6
Commit: 71d974e21fd96594d6ce66314962435a46674e1c441abcc9a6d64cbe5a5f7eda
Parent: 9acb8be364db52dcb4ea8ff0b20d63579ecd18d22bd7419deb20a2245356ffd7
Subject: Export com.obsproject.Studio
Date: 2024-04-05 23:58:57 +0000system info# System Details Report
---
## Report details
- **Date generated:** 2024-06-30 15:14:43
## Hardware Information:
- **Hardware Model:** TIMI Mi NoteBook 14
- **Memory:** 8.0 GiB
- **Processor:** Intel® Core™ i5-10210U × 8
- **Graphics:** Intel® UHD Graphics (CML GT2)
- **Disk Capacity:** 512 GiB
## Software Information:
- **OS Name:** openSUSE Tumbleweed
- **OS Build:** (null)
- **OS Type:** 64-bit
- **GNOME Version:** 46
- **Windowing System:** Wayland
- **Kernel Version:** Linux 6.9.6-1-defaultlogs
Operating System Info
Other
Other OS
Debian 12
OBS Studio Version
30.1.0
OBS Studio Version (Other)
No response
OBS Studio Log URL
https://obsproject.com/logs/irK1hfFTXzhAjn90
OBS Studio Crash Log URL
No response
Expected Behavior
When I click to add a screen or window source I see it show up in OBS.
Current Behavior
Doesn't show the source.
Steps to Reproduce
Anything else we should know?
This seems related to: https://github.com/obsproject/obs-studio/issues/10385
That indicates a SSL issue, which I'm not hitting. But digging in to the last commit of OBS Flatpak back to December this works as expected. So this seems to be an issue with OBS or the org.kde.Platform 6.6 as I attempted to roll back 6.6 itself and I was hitting this bug through all of the rollbacks.
$ flatpak remote-info --log flathub com.obsproject.Studio ID: com.obsproject.Studio Ref: app/com.obsproject.Studio/x86_64/stable Arch: x86_64 Branch: stable Collection: org.flathub.Stable Download: 207.5 MB Installed: 545.5 MB Runtime: org.kde.Platform/x86_64/6.6 Sdk: org.kde.Sdk/x86_64/6.6
Subject: Export com.obsproject.Studio Date: 2024-03-12 23:58:40 +0000 History: