Moonlight removed from Software list?

Troubleshooting
1

Creating a bug report/issue

I have searched the existing open and closed issues

Required Information

  • DietPi version | 9.14

  • Architecture | x86_64 uefi

  • SBC model | Dell Wyse 5070 j4105 8GB

  • Software title | Moonlight

  • Was the software title installed freshly or updated/migrated? Not in list anymore

  • Can this issue be replicated on a fresh installation of DietPi? Yes!

Hi!
Moonlight isn’t on the Software-List anymore!? Or at least Incant find it unser “Gaming and Emulation” anymore.
How to Install it now?
Do I need an older Version of DietPi?

Kind regards

2

best to my knowledge it’s available on RPI only. You can check following to verify if it is disabled on your system

dietpi-software list | grep "Moonlight"
3

Yes It’s disabled. Is there a way to enable it?

4

As far as I can see, this is only possible on x86 as an AppImage application. There seems to be no installation like on ARM SBC.

5

Moonlight-qt works on my Orange Pi zero 2w also

Must use the installation method as described on GitHub

6

we have reviewed the available packages. Seems they added support for other platforms. If testing goes well, we will enable Moonlight-qt for other architectures on next release.

1 Like
7

How do “AppImages” work? :sweat_smile:
Just execute them, nothing else needed?

I wonder why they do not provide x86_64 builds just like the ARM ones. Should behave pretty much the same: Qt>X, DRM>EGL>OpenGL should be all identical to how aarch64 builds are done already :thinking:. However, if the AppImage just works without any engine or so, we can implement this as well.

8

Seems to be. At lest thats what found on my internet search

9

It works almost like that. libegl1 is needed on the host system. And it can only be started from within an X session, either from desktop, or:

xinit ./Moonlight*.AppImage

or as non-root:

startx ./Moonlight*.AppImage

This is inconsistent with the ARM builds, which should be explicitly executed from console to run via DRM/KMS. The information is somehow missing, the output gives an indicator that the embedded Qt build has X11 support enabled only. Found it in the AppImage build script: moonlight-qt/scripts/build-appimage.sh at 1dbdcb5279b3c2bce756e6eff3b97d3f12a38092 · moonlight-stream/moonlight-qt · GitHub

There are two branches from 3 and 2 years ago, with an approach to change it, but obviously it was never finished:

I mean not such a big issue, it is degrading performance, but for x86_64 systems with a somewhat proper GPU, not a big issue. And I guess that systems where you run a game streaming client will have a desktop anyway, making it also more comfortable to just execute Moonlight within.

This means however some more work to implement:

  • Download AppImage
  • Create desktop icon
  • Create launcher for console, which detects whether it is started within an X session, else wraps it into one, like our Chromium kiosk mode script does.

Fun facts: AppImages are compressed archives with a common Linux root filesystem structure/overlay inside with the needed data and libraries etc. Instead of being extracted to the host OS (which would be perfectly possible), or executed in an insolated/sandboxed environment via container engine, the contained filesystem is mounted to /tmp, and then just executed pretty normally with a fixed AppRun executable, which is a symlink to the actual moonlight executable within the directory tree:

image
image413×164 5.12 KB

root@VM-Bookworm:~# ls -Al /tmp/.mount_Moonli0feN0l/
total 1.0K
-rw-r--r-- 1 root root 820 Sep 17  2024 .DirIcon
lrwxrwxrwx 1 root root  17 Sep 17  2024 AppRun -> usr/bin/moonlight
-rw-r--r-- 1 root root 293 Sep 17  2024 com.moonlight_stream.Moonlight.desktop
-rw-r--r-- 1 root root 820 Sep 17  2024 moonlight.svg
drwxr-xr-x 7 root root   0 Sep 17  2024 usr

There is a regular Linux desktop launcher (.desktop entry) included, not sure whether/how it is used, or whether it is even part of the AppImage specification, since it does define a non-standard attribute:

X-AppImage-Version=6.1.0

I have to say, I do like the simplicity of this, at least the way it appears. It fills a gap between native executable and container:

  • Similar to container, it ships all needed files and libraries, so does not depend on anything else on the host system, unless explicitly wanted/excluded on image generation, like libegl1 here (whether intended or not). So it is distro/version agnostic.
  • But compared to a container, it does not require a container engine either, hence runs much lighter, and has one less possible point of failure.
  • It is more flexible than a container: developers can choose freely what to include and what not, hence can also decide to use certain libraries on the host system instead, since host system isolation is not implicit. Similarly, user data and configs can just be written like usual to the host system/user config/data directory structures:
    root@VM-Bookworm:~# ls -l .config/Moonlight\ Game\ Streaming\ Project/
total 8
-rw-r--r-- 1 root root 5199 Jun 29 18:30 Moonlight.conf
    Of course it is just a question how the app within is configured, and isolation is perfectly possible. But it is not implicit, depending on the needs. Managing volumes for variable data like for containers is hence not needed.
  • But of course the missing implicit host system isolation also means that for some user cases, containers are just the better choice. If one has a complex set of servers/services which make use of each other, a container may make more sense, to hide and isolate all the ports and sockets within. Also for an AppImage generation, one cannot just install packages with apt within the container/Dockerfile and configure them like on a native host. Even if there were base OS AppImages like for Docker, one would need to configure every installed software to “stay” inside the AppImage mount, or wrap everything into an own container or chroot like solution (not sure whether there is a common standard or feature in AppImage for this). Also if one does not fully trust the software, or just want to be sure the host system is no/cannot be affected beyond explicitly chosen volumes for security reasons, there is no way around a container.
1 Like