Proposed as a Blocker for 40-final by Fedora user lruzicka using the blocker tracking app because:

 Default application does not work properly.

Yeah, I can reproduce this bug too. Fedora-Workstation-Live-x86_64-40-1.13

Reproducible in aarch64 VM, Fedora 40 RC 1.14.

Didn't happen the first time I tried just now on my usual work system, will try again on a bare metal system in a bit.

I cannot reproduce on my fairly ancient BIOS laptop. Intel T9300, AMD RV630.

Just tried it on candidate 1.14 and it works fine.

Created attachment 2026981 [details]
crash confirmed at Fedora-Workstation-Live-x86_64-40-1.14

Created attachment 2026982 [details]
more logs from the moment it crashed

confirmed at an installed RC 1.14 VM with this setup:
ester@localhost-live:~$ hostnamectl
     Static hostname: (unset)                              
  Transient hostname: localhost-live
           Icon name: computer-vm
             Chassis: vm 🖴
          Machine ID: a0d2da53a8b648b9bd1b6c5a031c9ba3
             Boot ID: 3973bc2c62c1443fb8ab79db8b983819
      Virtualization: kvm
    Operating System: Fedora Linux 40 (Workstation Edition)
         CPE OS Name: cpe:/o:fedoraproject:fedora:40
      OS Support End: Tue 2025-05-13
OS Support Remaining: 1y 3w 6d                             
              Kernel: Linux 6.8.5-301.fc40.x86_64
        Architecture: x86-64
     Hardware Vendor: QEMU
      Hardware Model: Standard PC _Q35 + ICH9, 2009_
    Firmware Version: edk2-20240214-7.fc40
       Firmware Date: Wed 2024-02-14
        Firmware Age: 2month

Lukas didn't say it crashed...he said he got an error message. Are you seeing exactly the same symptoms he described in https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/7582 ?

Tried twice on my test box which has a clean F40 Workstation install, recorded two 30 second full-screen videos, didn't see this bug either time.

OK, tried in a VM (virt-manager with virtio graphics, no 3D passthrough) and reproduced first time. Seems like this is easier to trigger in a VM.

> OK, tried in a VM (virt-manager with virtio graphics, no 3D passthrough) and reproduced first time. Seems like this is easier to trigger in a VM.

Dropping a comment here too: please ensure you have Wireplumber 0.5.1 - which fixes a 30 second timeout issue - installed when testing (https://bodhi.fedoraproject.org/updates/FEDORA-2024-21ccf560ea).

well, that's kind of a problem, because we're deciding whether this bug is a Fedora 40 blocker, and that update is not in our Fedora 40 release candidate. If that update fixes the bug, then the bug is not fixed in Fedora 40 at present.

For me this is fixed with wireplumber 0.5.1 indeed, can others confirm?

FEDORA-2024-21ccf560ea (wireplumber-0.5.1-1.fc40) has been submitted as an update to Fedora 40.
https://bodhi.fedoraproject.org/updates/FEDORA-2024-21ccf560ea

Discussed during the 2024-04-15 blocker review meeting: [0]

The decision to classify this bug as a "RejectedBlocker (Final)" and an "AcceptedFreezeException (Final)" was made as our testing during the meeting suggests this is almost 100% reproducible on libvirt/qemu VMs (especially without 3D passthrough), but not reproducible at all on bare metal. That makes this a conditional violation of the "basic functionality" criterion for default apps and the default panel functionality criterion, but we judge that it's not severe enough to constitute a blocker, but it is bad enough to grant an FE.

[0] https://meetbot.fedoraproject.org/blocker-review_matrix_fedoraproject-org/2024-04-15/f40-blocker-review.2024-04-15-16.00.txt

I tested in a VMware VM and was able to reproduce only with wireplumber 0.5.0-2 "AND" 3D Acceleration disabled.  wireplumber 0.5.1-1 solved the issue.

So I tested at Baremetal live usb session:
   Basic graphic mode = bug present
   Normal mode = no bug
############################
And for the installed VM I applied the wireplumber 0.5.1-1 update and now bug seems to be fixed. Good :)

I am very sorry to say that, but unfortunately I reported the issue with wireplumber 0.5.1 already installed and it was not about a 30 seconds limit per se. What I meant was, that the error message appeared withing the first 30 seconds of time. 
I checked the journal logs and this time, I only got a single message:

dub 16 09:39:19 vseved gjs[91036]: JS LOG: Failed to start recorder: All pipelines failed to start

I am attaching the error message as a screenshot, that I get from gnome shell. The message is in Czech (czech locales), but the meaning is something like "Failed to start screencasting."

Created attachment 2027164 [details]
Error reported from gnome shell

Huh. I could reliably reproduce all the symptoms you listed - error message after 25 seconds of recording, recording not present or corrupted - on a VM, and wireplumber 0.5.1 reliably fixed it for me, on multiple attempts. Recording behaves normally with it in place, for me. No errors, recordings are complete and correct. Geraldo seems to have found the same.

Exactly I can't reproduce the bug anymore with wireplumber 0.5.1

From the upstream issue it sounds like we're actually seeing something different from Lukas, which is funny. Probably still not a blocker, though.

FEDORA-2024-21ccf560ea (wireplumber-0.5.1-1.fc40) has been pushed to the Fedora 40 stable repository.
If problem still persists, please make note of it in this bug report.