UI Bug: Black screen with RTX VSR enabled and incorrect Media Info

[Wolfsaf]

Hello,

I've encountered two significant issues with the latest build:

1. RTX Super Resolution Conflict: When "Video Super Resolution" is enabled in settings, playing HEVC 10-bit files results in a black screen (audio only) in the main window. However, the small preview in the playlist/menu works perfectly with 24 FPS. Disabling VSR fixes the issue.

2. Broken Media Info: The "Properties" window shows incorrect metadata (Resolution 0x0, Music 0 kbps) for working MKV files, especially when accessed via network (SMB).

Attached are screenshots showing the 0x0 resolution bug.

Update on Media Info Bug:
I tested the player with a local file (on an internal SSD) to rule out network issues. The metadata parser is completely broken:

Data Swap: The player shows the audio bitrate (192 kbps) in the video bitrate field.

Missing Audio Info: It shows "0 kbps" for music/audio, even though the file has a working AC-3 track.

Inconsistency: The real video bitrate is ~4800 kbps, but the player is unable to read it correctly.

It seems the metadata engine is just pulling the first bitrate value it finds and assigning it to the wrong category.

[dosubot]

Hi @Wolfsaf! I'm Dosu and I’m helping the Screenbox team.

Both of these are known issues:

1. RTX VSR Black Screen — This is a confirmed upstream LibVLC bug in its Direct3D11 integration where the driver version isn't correctly detected, preventing the RTX scaler from being created [1]. The maintainer has noted that since it's a VLC-level issue, there's limited ability to fix it on Screenbox's side. It affects HEVC content on RTX GPUs (4070, 5070 confirmed) with recent NVIDIA drivers.

Workarounds:

• Disable RTX Video Super Resolution in NVIDIA Control Panel
• Disable Variable Refresh Rate (VRR)
• Try hardware decoding settings like --avcodec-hw=none or --avcodec-hw=d3d11va via Advanced Mode

2. Media Info showing 0x0 / 0 kbps — Screenbox uses Windows APIs for initial metadata extraction [2], which fail silently for codecs or containers Windows doesn't fully support. Network/SMB paths make this worse due to potential connection instability causing the metadata read to fail entirely [3]. The maintainer has acknowledged that using VLC-based extraction as a fallback would solve this, but it hasn't been implemented yet [4].

As a workaround for the metadata issue, installing a Windows Shell extension (like the K-Lite Codec Pack's property handler) can help Windows APIs read metadata from more formats [5].

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.

[Wolfsaf]

@dosu, thanks for the quick reply.

Regarding the Media Info issue: relying on Windows APIs is exactly why it's failing. Even on local files, the bitrates are swapped (showing audio bitrate in the video field). Installing 3rd party shell extensions (K-Lite) just to make a modern Store player show the correct resolution feels like a 2010s solution.

Please prioritize implementing VLC-based metadata extraction. It's frustrating to see "0x0" or "192 kbps" on a high-end PC (i9/RTX 3080) just because the player can't read a standard MKV header.

As for the VSR bug — if it's an upstream LibVLC issue, perhaps Screenbox should provide a clearer warning or a dedicated toggle that actually works without breaking the main render.

[dosubot]

Your frustration is completely understandable on both fronts.

Media Info — You're right that relying on Windows APIs for metadata in a player that already has LibVLC (which can parse container headers natively) is a gap in the current architecture. The VLC Media object already exposes track info including resolution, codec, and bitrate after parsing [1], so the data is available — it's just not being used as a fallback for the properties panel. There's no existing feature request or in-progress PR tracking this specifically, so this issue is a good place to have it on record.

RTX VSR — Currently the "Super Resolution" upscale mode option in Screenbox maps to LibVLC's --d3d11-upscale-mode parameter [2], and there's no detection or warning when the D3D11 scaler creation fails. A UX improvement — like detecting the failure and surfacing a notification, or auto-falling back to linear scaling — would be a reasonable mitigation even if the underlying LibVLC bug can't be fixed here. Issue #729 tracks the same black-screen symptom [3], so these could potentially be linked.

Both are valid enhancement requests for the maintainer to consider prioritizing.

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.