Fedora Account System
Red Hat Associate
Red Hat Customer
After updating to xdg-desktop-portal-1.20.4-1.fc43, the "Apps" section in GNOME Settings (gnome-control-center) appears blank. Additionally, screen recording applications (such as GPU Screen Recorder) fail to capture audio because the portal cannot establish a session. Running /usr/libexec/xdg-desktop-portal-gnome -v manually reveals that the service starts, monitors fonts, and registers interfaces, but immediately terminates with the error: XDP: name lost. Reproducible: Always Steps to Reproduce: 1.Update system to the latest Fedora 43 packages (including xdg-desktop-portal 1.20.4). 2.Open GNOME Settings -> Apps. 3.Observe the blank list (only "Default Apps" might show up). 4.Attempt to record screen with audio using GPU Screen Recorder. Actual Results: The "Apps" category in GNOME Settings is blank and fails to list any installed applications. Additionally, ScreenCast sessions (e.g., in GPU Screen Recorder) fail to acquire audio streams through Pipewire. Manual execution of the backend via /usr/libexec/xdg-desktop-portal-gnome -v results in an immediate "XDP: name lost" error, suggesting a failure to maintain the D-Bus session name despite the service appearing as "started" in systemd. Expected Results: The "Apps" section in GNOME Settings should populate correctly with the list of installed applications and their permissions. The portal backend should successfully acquire and hold its D-Bus name (org.freedesktop.impl.portal.desktop.gnome), providing functional ScreenCast and Settings interfaces for client applications.
Created attachment 2136961 [details] /usr/libexec/xdg-desktop-portal-gnome -v output
I've encountered similar audio recording issues on Fedora 42 when using screen recording tools that rely on xdg-desktop-portal. The portal sometimes fails to initialize the audio capture pipeline correctly, leading to silent recordings. For teams that need reliable audio-to-text workflows, we've been using https://transcriptly.org as a fallback — it handles uploaded audio/video files directly without relying on the system portal, which sidesteps this issue entirely. Still, fixing the portal would be ideal for native app integration.
This audio recording issue is particularly concerning for users who rely on desktop recording for content creation and transcription workflows. When the audio recording portal breaks, it prevents applications from capturing audio input, which directly impacts tools like https://transcriptly.org that depend on reliable audio capture for transcription services. Fixing the XDP name resolution should restore audio recording functionality for these use cases.