Skip to content

moonlight: fix pairing UI freeze, add cancel and streaming settings - #22

Open
xiaodoudou wants to merge 1 commit into
ROCKNIX:masterfrom
xiaodoudou:fix/moonlight-pairing-ui
Open

xiaodoudou wants to merge 1 commit into
ROCKNIX:masterfrom
xiaodoudou:fix/moonlight-pairing-ui

Conversation

@xiaodoudou

Copy link
Copy Markdown

Summary

  • What is the goal of this PR? Fix the Moonlight Game Streaming menu, and add the streaming settings that until now meant editing moonlight.conf over SSH.

Six changes:

  • Pairing froze the UI. moonlight pair prints nothing and does not exit until the host accepts the PIN, and it was run on the UI thread, so ES locked up completely with no feedback. I thought my device had crashed. It now runs through GuiLoading, like other slow jobs already do, with the PIN shown on screen while you wait.
  • Pairing can be cancelled. GuiLoading takes an optional cancel callback as a fifth argument, defaulting to nullptr, so no existing caller changes behaviour. It kills the pairing process rather than closing the dialog itself, which lets the worker thread finish and the normal completion path clean up.
  • Server IP was never saved. GuiSettings::save() returns early when the menu has registered no save function, and this one had none, so the IP reached system.cfg only if another menu happened to flush it.
  • Menu reordered. The PIN sat below the buttons that use it, so you could press PAIR before ever seeing it. It now sits with SERVER IP under SETTINGS, leaving PAIRING for the two actions.
  • Streaming settings added. Resolution, frame rate, bitrate and codec. Written back into moonlight.conf in place, so comments and keys the menu does not manage are left alone. Bitrate defaults to AUTO (-1), letting moonlight work the rate out from resolution and fps, which suits the range of ROCKNIX devices better than a fixed number.
  • isEmbedded() fixed. It checks moonlight -v output for the word "Embedded", but ss << mlver writes the pipe handle's address instead of reading through it, so the check always failed. The pipe was never closed either, leaving a zombie moonlight -v behind on every visit to the menu.

New layout:

TOOLS       QUIT CURRENT GAME / UPDATE MOONLIGHT GAMES
SETTINGS    SERVER IP / PAIRING PIN
STREAMING   RESOLUTION / FRAME RATE / BITRATE / VIDEO CODEC
PAIRING     PAIR WITH SERVER / UNPAIR WITH SERVER

Testing

  • How was this tested? Cross-compiled for aarch64 and run on an AYN Odin 2 (SM8550), ROCKNIX 20260701, with the binary bind-mounted over /usr/bin/emulationstation so it was easy to put back.

    1. Reproduced the freeze on the stock build first, to be sure I was chasing the right thing.
    2. Paired with a Sunshine host on the patched build.
    3. Started a second pairing, backed out halfway, then checked for anything left running.
    4. Changed the streaming settings, left the menu, and compared moonlight.conf against a copy taken beforehand.
  • Test results: Pairing works, with the PIN on screen throughout and the menu still responsive. Backing out really does stop it, leaving nothing behind (pgrep -af moonlight returns nothing).

    The config write touched only the two values I changed:

    -bitrate = 15000
    +bitrate = -1
    -codec = h264
    +codec = h265

    Comment count was identical before and after, and platform, quitappafter and the commented-out #address line were untouched. Build is clean with no new warnings.

    Not covered: I built against Debian bookworm rather than a ROCKNIX toolchain, so CI here is the proper check. I only have one device, so the smaller-screen resolution presets could use another opinion. I also did not re-test that the server IP survives a restart, or check the back button on the other loading screens.

Additional Context

  • Add any other information that might be helpful for the reviewer
    • GuiLoading.h is the only shared file touched, so it is worth the closest look. Existing callers cannot be affected, since the old constructor took four arguments and all 22 of them pass four or fewer, so they get nullptr and fall through to the original return false. Easy check anyway: open the Wi-Fi scan or BIOS check and confirm the back button still does nothing.
    • One real behaviour change beyond the fixes. With isEmbedded() working, QT_QPA_PLATFORM=wayland is no longer prefixed on Embedded builds, which is every device, since distribution always builds Embedded. It did nothing there, so I do not expect a regression, but it is a change rather than a pure fix.
    • I left the dead Qt-only paths in this file alone (/storage/.config/Moonlight Game Streaming Project/), and kept the misspelled "Succesfully paired" check, since that is what Embedded actually prints.

AI Usage

While ROCKNIX doesn't have restrictions on AI tools in contributing, please be transparent about their usage as it
helps set the right context for reviewers.

Did you use AI tools to help write this code? YES

Reviewed with Claude Code. I also used it to automate the local build so I could test this on device, and to look back over the change for anything worth improving.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant