Is there an existing issue for this?
- I have searched the existing issues
Is your issue described in the documentation?
- I have read the documentation
Is your issue present in the latest beta/pre-release?
This issue is present in the latest pre-release
Describe the Bug
With DRM screencasting on an HDR display, the connector’s HDR_OUTPUT_METADATA blob ID changes unexpectedly even though the metadata bytes remain unchanged. refresh() runs on every display refresh, and an ID change can trigger capture reinitialization. This causes Moonlight to show only one frame or no frames.
The log shows the connector discovered with blob ID 159, followed by is_hdr() failing to read that ID. Capture then reinitializes, and the current metadata is reported under blob ID 146:
Note: The log excerpt below includes custom diagnostic logging.
Found connector ID [135]
Found hdr_metadata_blob_id [159]
...
is_hdr hdr_metadata_blob_id: 159
Unable to get HDR metadata blob: No such file or directory
...
Reinitializing capture after HDR metadata change
Previous HDR metadata: couldn't read blob 159: No such file or directory
Current HDR metadata (blob 146, 32 bytes)It’s unclear why the blob ID changes.
Possible fix requires to compare the newly read metadata bytes with the last successfully read bytes: update the cached ID without reinitializing if the contents match; reinitialize if they differ.
Steps to reproduce
- Run DRM screencasting with an HDR display.
- Connect via Moonlight
- Observe the connector’s HDR metadata blob ID change during capture.
- Observe
refresh()trigger reinitialization and Moonlight display one frame or no frames. - This repeats infinitely.
Expected Behavior
No response
Additional Context
No response
Host Operating System
Linux
Operating System Version
Architecture
amd64/x86_64
Package
other (self built)
GPU Type
AMD
GPU Model
GPU Driver/Mesa Version
latest
Capture Method
KMS (Linux)
Apps
undefinedLog output
undefinedOnline logs
No response
Activity
0No activity yet.