Black screen / mediaStatus stuck at NoMedia even with gstreamer backend and valid config

[ACFHarbinger]

Environment

• Plugin version: 2.12.0
• Plasma: 6.6.6
• Qt: 6.10.2
• OS: Ubuntu 26.04 LTS
• QT_MEDIA_BACKEND: gstreamer (confirmed active in the running plasmashell process's environment)

Symptom
Video wallpaper shows a persistent black screen. Confirmed via the plugin's own DebugEnabled overlay that this is a genuine NoMedia state, not a decode/codec failure (InvalidMedia) or a still-loading state (LoadingMedia).

What I ruled out before filing

1. isLoading race on plugin switch — known issue, already avoided in my repro by writing config well after the plugin was already active (not a fresh switch), and independently by fully restarting plasmashell and re-testing.
2. Stale LastVideo vs VideoUrls mismatch — real, separate bug I found (when ResumeLastVideo is on and LastVideo doesn't match any entry in the current VideoUrls, main.currentSource resolves to Utils.createVideo(""), which FadePlayer.next()'s direct assignment (playerSource = root.currentSource) then captures into the active player). I fixed this on my own tool's side (kept LastVideo in sync with VideoUrls) and confirmed via the debug overlay that main.currentSource.filename correctly resolves to the intended video. next() demonstrably runs — the debug overlay's player: 1/2 value toggles between writes, confirming the primary/secondary player swap happens.
3. Config validity — read back via readConfig after each write; VideoUrls is well-formed JSON, enabled: true, filename is a correctly percent-encoded file:// URI to an existing, valid, directly-playable file (confirmed the file plays fine both in an external player and via KDE's "Preview" button in this plugin's own settings dialog, which appears to use Haruna — same file plays correctly there).
4. Stale/corrupted session state — did a full systemctl --user restart plasma-plasmashell.service, confirmed the new process has QT_MEDIA_BACKEND=gstreamer in its environment, and re-tested a single clean config write against the fresh process. Same result: playing: true (the outer main.qml computed property), but player1 playing: false, player2 playing: false, mediaStatus: 0 (NoMedia), nothing renders.

So even with a fresh process, the documented gstreamer backend fix already active, and a config that is provably correct and consistent (right filename, enabled: true, LastVideo in sync), the underlying VideoPlayer never actually receives a working media source. This looks like it's inside FadePlayer.qml's player/otherPlayer selection or the QML→QtMultimedia source handoff itself, rather than anything about how the config is written.

Happy to provide the exact qdbus scripting sequence used to reproduce this from a completely clean plasmashell restart, or test any suggested QML-side debugging (extra console.log in FadePlayer.qml, etc.), if that's useful.

[ACFHarbinger]

Follow-up: I found #290 and ran the same diagnostic the author suggested there — a standalone MediaPlayer/VideoOutput QML scene (QT_MEDIA_BACKEND=ffmpeg, no wallpaper plugin involved), same video file.

Result: createTexturesFromMemory fired 168 times over an 8-second run, interleaved with continuous real NAL-unit decode log lines at what matches the video's actual framerate. CUDA hardware decode failed to initialize (Failed setup for format cuda: hwaccel initialisation returned error) but fell back to software decode cleanly with no errors or stalls.

So on this machine (NVIDIA RTX 3090 Ti, driver 580.173.02, Wayland session — non-hybrid, discrete GPU only, unlike #290's hybrid AMD+NVIDIA laptop), Qt Multimedia/FFmpeg decode and texture creation work correctly standalone. The failure only happens inside the actual wallpaper plugin/KWin compositor path — that's a second, independent data point (different GPU config than #290, same symptom class) pointing at the Wayland compositor's texture-import step rather than either individual plugin or Qt Multimedia's decode pipeline. Also confirmed on my end that a second, unrelated plugin (smartervideowallpaper) fails identically here, same as #290's Wallpaper Engine cross-check.

Happy to run any further targeted diagnostics if useful — this is cleanly and repeatably reproducible on this machine.

[ACFHarbinger]

Follow-up, and a correction to the working theory: tested under an X11 session too (installed kwin-x11 + plasma-session-x11, logged into "Plasma (X11)").

Same result under X11: mediaStatus: 0 (NoMedia), player1/player2 playing: false, nothing renders. Confirmed compositing is active via qdbus6 org.kde.KWin /KWin supportInformation: Compositing Type: OpenGL, OpenGL platform interface: GLX — the older, long-mature NVIDIA GLX compositing path, not EGL/DMA-BUF.

Since the standalone MediaPlayer/VideoOutput test works fine, and the wallpaper plugin fails identically on both Wayland (EGL/DMA-BUF path) and X11 (GLX path) — two structurally different NVIDIA rendering paths — this doesn't look like a Wayland-specific compositor bug after all. The common factor across all four failing combinations (this plugin on Wayland, this plugin on X11, smartervideowallpaper on Wayland, and presumably X11 too) is specifically "hosted as a Plasma wallpaper delegate," not the windowing system. Might be worth looking at whether the wallpaper containment renders into a different/restricted render target (e.g. an offscreen QSGRenderNode within KWin's own scene) than a standalone top-level QQuickWindow gets, which could explain why VideoOutput's texture never makes it through in either windowing backend.

Apologies for the earlier steer toward #290/Wayland-NVIDIA specifically — that doesn't hold up as cleanly given this X11 result, though the underlying "video texture never reaches the compositor" symptom is still the same. Happy to test anything else that would help narrow this further.

[luisbocanegra]

Please attach the full log of plasmashell startup and a screenshot of the debug overlay.

1. Run journalctl --user -u plasma-plasmashell -f |& tee plasmashell.log
2. While the above command is running run this other command systemctl --user restart plasma-plasmashell
3. after plasmashell restarts stop the first command and share the plasmashell.log file

Also if kindly cut down the LLM stuff, if you can't understand or verify what it is "saying" to be able to remove the nonsense, it's just extra noise

[luisbocanegra]

Also from the wall of text I can't tell if you tested the wallpaper with ffmpeg, if you haven't please try that too.

If it also doesn't play with ffmpeg, try disabling hardware video decoding with QT_FFMPEG_DECODING_HW_DEVICE_TYPES=,

[luisbocanegra]

Last but not least, this may be a nvidia driver bug or ubuntu bug, testing with a Arch on a 5070ti the video is able to play in the wallpaper even without hardware acceleration

[ACFHarbinger]

True, I think the LLMs makes the output have a prettier format, but it does add extra noise and hallucinates some stuff. TLDR: I tried it with both FFMpeg and GStreamer, and also disabling hardware video decoding, as well as on three different KDE Ubuntu Kernel versions, and none of them worked. Furthermore, it happened on both a X11 and Wayland session, which torpedoed my initial theory that it might be a Wayland related issue. I think it might be a Nvidia driver bug, but I am unsure. The issue is recent, as the plugin was working correctly just last week. I will run the commands you indicated once I get the opportunity later today, and then report back with the results.
Thank you for your attention!