Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

kmsgrab: HDR metadata blob ID changes cause repeated capture reinitialization and black/one-frame output

Open
  • Is something wrong?
#5,894 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
22/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
cpp, linux
Domain
desktop-dev

Research direction

The payload names refresh() and is_hdr() as the code paths involved; start by finding where the KMS capture code reads the connector's HDR_OUTPUT_METADATA blob ID and where it decides to reinitialize. Reproducing needs an HDR-capable DRM display, so first confirm the blob ID drift in logs. Done means the cached ID is updated without reinitializing when the blob bytes are unchanged, and capture still reinitializes when the bytes differ.

Written by the indexing model from the issue text.

Description

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

  1. Run DRM screencasting with an HDR display.
  2. Connect via Moonlight
  3. Observe the connector’s HDR metadata blob ID change during capture.
  4. Observe refresh() trigger reinitialization and Moonlight display one frame or no frames.
  5. 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
Log output
Online logs

No response

Dominant language
C++
Stars
42k
Forks
2.2k
Avg merge
1d 11h
Merged PRs (30d)
124

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from LizardByte/Sunshine

All issues in LizardByte/Sunshine

Similar issues

More C++ issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.