Stuck in `Flushing` state for too long

keevitaja commented 2 years ago

Hello,

i have dual monitor setup and kooha is recording both screens into one video. Is this a bug or i can fix it with configuration?

OS: Manjaro 21.1.2 Pahvo
Kernel: x86_64 Linux 5.10.61-1-MANJARO
Uptime: 11h 59m
Packages: 1344
Shell: zsh 5.8
Resolution: 3840x1080 (this is wrong, should be 2 times 1920x1080)
DE: GNOME 40.0
WM: Mutter
WM Theme: Matcha-light-sea
GTK Theme: Matcha-light-sea [GTK2/3]
Icon Theme: Papirus-Light-Maia
Font: Ubuntu 10
Disk: 301G / 484G (66%)
CPU: Intel Core i7-10750H @ 12x 5GHz [60.0°C]
GPU: NVIDIA GeForce GTX 1660 Ti
RAM: 4295MiB / 31928MiB

SeaDve commented 2 years ago

In the latest git version, it is now possible to select a monitor to record. But in the current one, unfortunately, not

major-mayer commented 2 years ago

Can confirm that. I get the usual XDG Portal like with Firefox and Chromium. The problem is, that the generated "video" is more like a screenshot for me (even though the flushing takes forever).

I could upload the video, but it would not show much. And i can't find anything on the stdout when i open Kahoo from the commandline. Any ideas how i could help to debug this?

SeaDve commented 2 years ago

you need these envvar: GST_DEBUG=3 PIPEWIRE_DEBUG=3 RUST_LOG=kooha=debug

major-mayer commented 2 years ago

All right thanks. Here is what my logs look like:

~/.../_build/src >>> GST_DEBUG=3 PIPEWIRE_DEBUG=3 RUST_LOG=kooha=debug ./kooha
 INFO  kooha::application > Kooha (io.github.seadve.Kooha)
 INFO  kooha::application > Version: 1.2.1 ()
 INFO  kooha::application > Datadir: /usr/local/share/kooha
 DEBUG kooha::backend::recorder > is_show_pointer: true
 DEBUG kooha::backend::recorder > is_selection_mode: false
 INFO  kooha::backend::screencast_portal > ScreenCastProxy created
 INFO  kooha::backend::screencast_portal > Session created
 INFO  kooha::backend::screencast_portal > Select sources window showed
 INFO  kooha::backend::screencast_portal > Screencast session started
 INFO  kooha::backend::screencast_portal > Ready for pipewire stream
 DEBUG kooha::backend::recorder          > pulse_server_version: pulseaudio version 15.0
 DEBUG kooha::backend::recorder          > PipelineBuilder { is_record_speaker: false, is_record_mic: false, framerate: 30, file_path: "/home/laurenz/Videos/Kooha 09-11-2021 11:32:09.webm", fd: 20, streams: [Stream { pipewire_node_id: 42, position: Some((0, 0)), size: Some((3072, 1728)) }], speaker_source: Some("alsa_output.pci-0000_00_1f.3.analog-stereo.monitor"), mic_source: Some("alsa_input.usb-Sonix_Technology_Co.__Ltd._USB_2.0_Camera_SN0001-02.iec958-stereo"), coordinates: None, actual_screen: None }
 DEBUG kooha::backend::pipeline_builder  > is_use_vaapi: false
 DEBUG kooha::backend::pipeline_builder  > pipeline_string: queue name=queue0 ! videorate ! video/x-raw, framerate=30/1 ! videoconvert chroma-mode=GST_VIDEO_CHROMA_MODE_NONE dither=GST_VIDEO_DITHER_NONE matrix-mode=GST_VIDEO_MATRIX_MODE_OUTPUT_ONLY n-threads=6 ! queue ! vp8enc max_quantizer=17 cpu-used=16 cq_level=13 deadline=1 static-threshold=100 keyframe-mode=disabled buffer-size=20000 threads=6 ! queue ! webmmux name=mux ! filesink name=filesink location="/home/laurenz/Videos/Kooha 09-11-2021 11:32:09.webm" pipewiresrc fd=20 path=42 do-timestamp=true keepalive-time=1000 resend-last=true ! video/x-raw, max-framerate=30/1 ! queue0. 
[I][00430.300001][      pipewire.c:  562 pw_init()] version 0.3.34
[I][00430.302193][          conf.c:  326 conf_load()] config 0x5619330d9a10: loading config '/usr/share/pipewire/client.conf'
[I][00430.302241][       context.c:  348 pw_context_new()] context 0x5619330db950: parsed context.properties section
[I][00430.302507][       context.c:  438 pw_context_new()] context 0x5619330db950: parsed 2 context.spa-libs items
[I][00430.302792][          conf.c:  419 load_module()] config 0x5619330db950: loaded module libpipewire-module-protocol-native
[I][00430.303096][          conf.c:  419 load_module()] config 0x5619330db950: loaded module libpipewire-module-client-node
[I][00430.303302][          conf.c:  419 load_module()] config 0x5619330db950: loaded module libpipewire-module-client-device
[I][00430.303501][          conf.c:  419 load_module()] config 0x5619330db950: loaded module libpipewire-module-adapter
[I][00430.303681][          conf.c:  419 load_module()] config 0x5619330db950: loaded module libpipewire-module-metadata
[I][00430.303897][          conf.c:  419 load_module()] config 0x5619330db950: loaded module libpipewire-module-session-manager
[I][00430.303912][       context.c:  442 pw_context_new()] context 0x5619330db950: parsed 6 context.modules items
[I][00430.303920][       context.c:  447 pw_context_new()] context 0x5619330db950: parsed 0 context.objects items
[I][00430.303927][       context.c:  450 pw_context_new()] context 0x5619330db950: parsed 0 context.exec items
[I][00430.303959][       context.c:  241 context_set_freewheel()] context 0x5619330db950: exit freewheel
[I][00430.303972][       context.c:  245 context_set_freewheel()] context 0x5619330db950: freewheel error:Operation not supported
[I][00430.303984][ impl-metadata.c:  196 impl_set_property()] metadata 0x5619330db010: add id:0 key:log.level type: value:0
[I][00430.303993][ impl-metadata.c:  196 impl_set_property()] metadata 0x5619330db010: add id:0 key:clock.min-quantum type: value:32
[I][00430.304003][ impl-metadata.c:  196 impl_set_property()] metadata 0x5619330db010: add id:0 key:clock.max-quantum type: value:8192
[I][00430.304011][ impl-metadata.c:  196 impl_set_property()] metadata 0x5619330db010: add id:0 key:clock.force-quantum type: value:0
[I][00430.304018][ impl-metadata.c:  196 impl_set_property()] metadata 0x5619330db010: add id:0 key:clock.force-rate type: value:0
0:00:04.370632722  5892 0x561931ae3860 FIXME                default gstutils.c:4025:gst_pad_create_stream_id_internal:<pipewiresrc0:src> Creating random stream-id, consider implementing a deterministic way of creating a stream-id
[I][00430.309409][     impl-node.c:  356 node_update_state()] (kooha-0) creating -> running
 INFO  kooha::backend::recorder          > Pipeline state set from Null -> Ready
 INFO  kooha::backend::recorder          > Pipeline state set from Ready -> Paused
0:00:07.416499878  5892 0x7f270c2831e0 FIXME               basesink gstbasesink.c:3384:gst_base_sink_default_event:<filesink> stream-start event without group-id. Consider implementing group-id handling in the upstream elements
 INFO  kooha::backend::recorder          > Pipeline state set from Paused -> Playing
 INFO  kooha::backend::recorder          > Sending eos event to pipeline
[I][00544.694067][     impl-node.c:  356 node_update_state()] (kooha-0) running -> idle
[I][00544.704046][     impl-node.c:  356 node_update_state()] (kooha-0) idle -> suspended
[I][00544.704086][     impl-node.c: 1721 pw_impl_node_destroy()] (kooha-0) destroy
 INFO  kooha::backend::screencast_portal > Session closed
 INFO  kooha::backend::recorder          > Eos signal received from record bus
~/.../_build/src >>>

And i also attach the recorded video to this post. Interestingly the "screen record" grows to about 35 seconds, even though i only recorded for maybe 5 seconds. Really don't know what is going on...

https://user-images.githubusercontent.com/17907799/132943568-41e47c79-0336-4a39-8185-3a153788a458.mp4 I renamed the video to ".mp4" so i can upload it here on Github, but originally it was a Webm recording. Nevertheless I got this behavior with all video formats and even when I activate hardware accelerating.

SeaDve commented 2 years ago

ill rename this since that feature is already implemented in main but comes with an issue, thanks!

SeaDve commented 2 years ago

oops

major-mayer commented 2 years ago

No problem and thanks for your great work. Good to hear that you found the problem.

SeaDve commented 1 year ago

In the main branch, you can now cancel the recording at flushing state. Unfortunately, this would also delete the recording.

SeaDve commented 1 year ago

Btw, @major-mayer I just noticed that your version is 1.2.1. Is this issue still reproducible in the latest commits at the main branch?

guymii commented 1 year ago

This is happening to me as well. I'm using the flatpak on fedora 37 with gnome 43.2. The video is stuck on flushing after I stop the recording. At first I thought that I recorded for too long, but it happens on shorter recordings also.

SeaDve commented 1 year ago

This is happening to me as well. I'm using the flatpak on fedora 37 with gnome 43.2. The video is stuck on flushing after I stop the recording. At first I thought that I recorded for too long, but it happens on shorter recordings also.

Please check if it is still reproducible in v2.2.3

guymii commented 1 year ago

Tried it again today on v2.2.3 and it still happens. The video was an hour long. A 10 minute recording took sometime but did get flushed in the end.

major-mayer commented 1 year ago

Hi I just tried it using the latest kooha-git from AUR and for me everything is working perfectly now :heart_eyes: :heart: Here are the logs if you want to have a look into them anyway: https://pastebin.ubuntu.com/p/86G4WvCTw4/ The only thing that's maybe missing is the ability to record a single window, but that's a different issue.

SeaDve commented 1 year ago

The only thing that's maybe missing is the ability to record a single window, but that's a different issue.

It exists behind an env var. It is disabled by default due to bugs.

major-mayer commented 1 year ago

All right, thanks for your great work :+1:

m1nicrusher commented 1 year ago

Same thing is happening here. Fedora 37. v2.2.3 from Flathub. Video is about an hour long. Has been flushing for more than 1.5 hours. File size is slowly increasing.

Update: It has been flushing for nearly 24 hours. The file is only 650MB, but still slowly increasing.

Update update: 40+ hours now. File is now 1.6GB

Alexious-sh commented 9 months ago

Takes ages to flush a 5 seconds recording. The app just became unusable.

Serkan80 commented 9 months ago

Same issue, flushing takes too long even for very small recordings.

I've given permission for the home folder in Flatseal.

Does it need any other permissions that I'm not aware of ??

Btw, I'm using v2.2.4 from Flatpak.

gmocquet commented 9 months ago

Same here with same version

Serkan80 commented 9 months ago

As someone else has mentioned earlier: when you downgrade to v2.2.1 then it works.

gmocquet commented 8 months ago

Version 2.2.3 work for me

thecodygriffin commented 8 months ago

I have the same issue that I can reproduce with a specific workflow.

Pre-Requisites

Fedora 38 installation with GNOME 44.5 running on Wayland
Download Kooha 2.2.4 from Flathub
Do not modify the permissions via Flatseal or similar app
Do not modify the Preferences within the Kooha app

Steps to Reproduce

Open Kooha
Ensure the Capture Monitor or Window button is selected
Ensure the Enable Desktop Audio button is selected so that desktop audio is captured
Ensure the Enable Microphone button is selected so that mic audio is captured
Ensure the Show Pointer button is selected so that the mouse pointer is captured
Select the Record button to start the recording
After some amount of time, select the yellow Desktop Sharing that appears in the GNOME panel
Select the Stop button of the Kooha app to stop the recording

Notes

If you skip Step 7, the issue does NOT occur
See the attached screen capture using the built in GNOME tool for a no audio illustration of the issue

Screencast from 2023-10-11 13-38-06.webm

AkechiShiro commented 8 months ago

Hi @SeaDve, any way, I can help move this forward ?

Just prior to this issue, I had this issue XDG_CURRENT_DESKTOP was not set as an environment variable, so following troubleshooting instructions.

I thus did check for this line in my sway autostart config : dbus-update-activation-environment --systemd WAYLAND_DISPLAY XDG_CURRENT_DESKTOP="sway"

I then did restart systemd user services :

systemctl --user restart wireplumber
systemctl --user restart xdg-desktop-portal
systemctl --user restart xdg-document-portal

Checked if XDG_CURRENT_DESKTOP is set properly and it was :

< "/proc/$(pidof xdg-desktop-portal)/environ" tr '\0' '\n' | grep '^XDG_CURRENT_DESKTOP='

That fixed the first error that linked me to the troubleshooting page.

I did not restart Sway (the desktop environment) nor did I log-out/login again, I just tried to test directly.

On 2.2.4, I have the following behavior on Sway :

Do an area capture, select the area and record 5 seconds,
Flushing a file, file gets created but does not have any size (just 0 data/empty file), it just never gets any data,
I need to cancel the flush as it looks like it is not doing anything at the moment even after waiting for a few minutes, please let me know if I can give any debug input, to move this issue forward.

I will report if this fixes the flushing empty file issue : https://github.com/emersion/xdg-desktop-portal-wlr/wiki/%22It-doesn't-work%22-Troubleshooting-Checklist#other-known-problems

Since I did not restart my sway session yet.

RafaelAmr93 commented 7 months ago

I updated to 2.2.4 and the same started to happen, it was stuck in 'Flushing...'.

The solution was roll it back to 2.2.3.

This can be done with flatpak and it is explained how here: https://askubuntu.com/questions/1349179/how-to-install-a-previous-version-of-gimp-with-flatpak-on-ubuntu-20-04#:~:text=Installing%20older%20flatpaks%20versions,installed%20for%20this%20to%20work.

maslennikov commented 7 months ago

Ubuntu 22.04 with flatpak: experienced the same issue with 2.2.4. Only downgrading to 2.2.3 helped.

sudo flatpak update --commit=1f4a2e437cef54c8c5ff21cf1645d798e8c8e70d0b497950fcbcb053bfbed1d3 io.github.seadve.Kooha

gredler commented 4 months ago

I recorded a 1 minute video, the app flushed 210 MB to disk over the course of 7 hours before I gave up and cancelled it. This is the version 2.2.4 flatpak on Pop!_OS 22.04.