Need alpha-testers for moonlight on Vero 4/5

Testing
1

Moonlight-embedded has come far enough to start testing in wider environments. Depending on streaming servers capability we have seen odd results. Before majority of the focus is set on the client side, it would be good to have a list of issues to work out.

ex.:

  1. 60hz 4k, with Nvidia-gpu server, just needs 1 patch and works almost flawlessly.
  2. 60hz 720p, with Intel gen4 iGPU server, needs multiple patches and “works”.

Need to test multiple server encoders hardware/software. Intel/AMD/Nvidia and h264/h265…

If we get to a point where we can identify most problem, we should be able to code solutions for the AML bits. How it works for OSMC on Pi i can’t speak of yet, due to lack of hardware. But I’m not a stranger to folks reporting issues here as well, but no promises made.

Plan is to make a OSMC-launch script and utilize Luna launcher for the gui. But before we have a clear eye on the possible issues depending on server-encoding, it might be a fools errand to make a launcher work when the client isn’t even stable on 25% of cases.

In order to keep the OSMC-Vero part isolated to the main tree, I’ve forked moonlight-embedded and renamed it.

Install instructions:
When ever you see [some text], it’s a description of what is supposed to be there with out the [ ]

sudo apt-get update
sudo apt-get install git libopus0 libexpat1 libasound2 libudev1 libavahi-client3 \ 
libcurl4 libevdev2 libssl-dev libopus-dev libasound2-dev libudev-dev \
libavahi-client-dev libcurl4-openssl-dev  libevdev-dev libexpat1-dev libpulse-dev \
uuid-dev cmake make gcc g++

Depending on your client hardware change the userland:

  • vero3-userland-dev-osmc for Vero4(k)
  • vero5-userland-dev-osmc for VeroV

sudo apt-get install [correct userland-dev for you] libamcodec-dev-osmc

git clone https://github.com/zjoasan/moonlight-embedded.git
cd moonlight-embedded
git submodule update --init --recursive
mkdir build
cd build/
cmake ../
make -j4

Next step would be to install, but there are some path dependencies that isn’t working for OSMC right now, this might change.

------[instead of make install ...]------
mkdir /home/osmc/moonlight
cp moonlight /home/osmc/moonlight/
cp libmoonlight-aml.so /home/osmc/moonlight/
cp ../moonlight.conf /home/osmc/moonlight/
cp ../third_party/SDL_GameControllerDB/gamecontrollerdb.txt /home/osmc/moonlight/
------------------------------------------------

This changes in moonlight.conf are made for ease in error checking:
#address = 1.2.3.4 /remove # and input the IP-number of your streamsever
#platform = default /remove # and put aml instead of default
#app = Steam / remove # and change to Desktop

Now that you have edited the .conf file it’s time to pair and start trying.

In console (ssh), navigate to your moonlight directory:

./moonlight pair [your sunshine servers ip-number]
./moonlight stream -app Desktop

Later fps, resolution, bitrate might be edited for test purpose.

Next step will be Luna launcher, but it will be worked on mean while we are testing this.

2

On my vero4k I can only get audio working, gives just a black screen. I did try other resolutions / codecs but none seemed to work. I can succesfully use moonlight client on my android phone or the flatpak version on a linux machine, host is windows 11 with sunshine v0.23.1, nvidia rtx 3070

osmc@osmc:~/moonlight$ ./moonlight stream -app Desktop
Connecting to 192.168.1.10...
RTSP port: 48010
Initializing platform...done
Resolving host name...done
Initializing audio stream...done
Starting RTSP handshake...Audio port: 48000
Video port: 47998
Control port: 47999
done
Initializing control stream...done
Initializing video stream...done
Initializing input stream...done
Starting control stream...done
codec_init amstream version : 2.0
set_decoder_config
Starting video stream...VFM map: [00]  default { }
done
Starting audio stream...done
Starting input stream...done
EVIOCGRAB failed with error 16
Received first video packet after 100 ms
Received first audio packet after 400 ms
Initial audio resync period: 500 milliseconds
Requesting IDR frame on behalf of DR
IDR frame request sent
Waiting for IDR frame
Requesting IDR frame on behalf of DR
IDR frame request sent
Waiting for IDR frame
Requesting IDR frame on behalf of DR
IDR frame request sent
Waiting for IDR frame

...
... IDR frame messages keep repeating ...
...
3

I’m so sorry, will have to check which commit i must have missed, since i had it running here before I commit “all” the changes to a fresh fork on Github. I suspect I know, what’s missing. I’m a bit out of time tonight, but I’ll ping you here when I made another round of test locally.

4

Ugh, maybe it was because I didn’t reboot the vero… now it works!

I built moonlight (without make install) from the official repo and noticed that in their wiki it says to boot the machine.

Is there any way to display the decoding times on moonlight-embedded? I didn’t find any option for this. It feels that your fork works a little bit better regarding on the decoding time but it seems to be “pulsing” like every 2 seconds and the image gets a little bit choppy. (2560x1440@60 h265 bitrate 20 000)

the build from official repo doesn’t have this intervalled choppines but the decoding time seems to be worse, I’d say unplayable where as your fork feels like almost playable?

5

Thank you for the feedback, when it comes to the actual streaming, i lack the resource currently to work with those resolutions or codec.

I had no luck in recreate the issue on my vero4k so thanks for that aswell.

If you don’t mind a re-compile, locate a %20 in aml.c under src/video, and try to tweak the 20 value up or down, it’s a tweak to lessen the load on the frame buffer, theoretically 20 is a third if 60, and it works for me with lower res and another codec. But another moderator here had 4h res 60hz and h265 on a Vero5, “playable” as I understood.

6

Hi @joakim_s, I have a Vero V and am currently testing out Moonlight Embedded with Sunshine as alternative to Steam Remote Play. My main gripe with SRP is that it doesn’t support Linux (as game server) that well and Moonlight looks very promising together with Sunshine!

My journey has been a bumpy one, but I’ve had some success as well. Running the provided moonlight-embedded binary as-is resulted in a black screen. This comment on GitHub in particular helped me to get the basics working.

After that I looked for a Kodi addon to go with Moonlight. My luck continued, because someone had updated the old Luna addon, as mentioned in this post. I did need to make some adjustments to make it work. I hope to be able share those in a fork soon. Just to check, is GitHub - TheChoconut/Luna: Luna Script for Kodi considered the mainline source for Luna now?

As for my server hardware, it’s all AMD: Ryzen 5600X and Radeon RX 6700XT. I haven’t looked into any codecs or hardware acceleration yet. I also run usbip as a server on the Vero and as client on my game server, so that Steam recognizes the Steam Controller instead of a virtual Xbox Controller. This is all configured from the terminal, so no Kodi integration or anything.

One thing I’m curious about is whether Moonlight Embedded has any performance statistics. With Moonlight QT you can press Ctrl+Alt+Shift+S to bring up a stats overlay, but evidently this doesn’t work in Embedded. Did you find out anything about this?

If I need to test anything in particular, please let me know.

7

@cavejohnson thank you for your feedback. I’ve been setting this project on the back burner since the lack of feedback. I would love to see those modifications to Luna, but I in no hurry. Was hoping to build a complete Moonlight client solution for OSMC, bundling the addon and the ml-emb compiled.

Regarding your question, i do believe that is a ML-QT feature, as I understood most of the “fancy features” are ripped or disabled in ml-embeded. You can probably fiddle with the code to get the info, but I’m unsure about an overlay on the screen(above my paygrade).

Feel free to pm me the alterations you did to Luna, and which version you were using. I’ll gladly credit you if the is a packaged solution.

8

I understand, lack of feedback is a bummer. I do appreciate your call for testers and I’m willing to test with whatever resources I have.

I’ve created a PR with my changes here: Add OSMC launcher & some small fixes by agboom · Pull Request #2 · TheChoconut/Luna · GitHub
It’s kind of a grab bag of things I fixed to get it working, but I think it’s a start. Now to wait for the feedback.

Having a complete ML solution that bundles or auto downloads from Kodi would be awesome indeed! For that I think the provided binary should work out of the box first (i.e. Vero 4K support · Issue #573 · moonlight-stream/moonlight-embedded · GitHub), but otherwise we could invoke the package manager or even just a wget of the GH release and unzip from the addon?

I’ve some other ideas that are still in rough shape:

  • Be able to set a default app so you can quick launch from the menu without having to select from the list popup.
  • Be able to add an app to the home screen (in the games category) for another quick launch experience.
9

As a side-note: I’ve also tried moonlight-qt on Vero, but that didn’t work out too well. I was able to start ML with moonlight-qt -platform linuxfb, but the stream would not start after selecting an app. I don’t have the logs anymore, but I can whip them up if needed. It would be nice if this works though, because there’s a well maintained Kodi app for ML-QT: GitHub - veldenb/plugin.program.moonlight-qt: A launcher and updater for running Moonlight-qt on LibreELEC.

10

Nice, I will try to “look at”(test) your PR to Luna. If time allows, even start looking if we can get QT running, but I’m having some serious doubts. Thinking it’s doing overlay on the accelerated video stream (above my pay-grade), which I know was one of the “killers” for embedded.

But I’m in the middle of helping in the development of VDDbyMTT, just got a bunch of my PR’s accepted in their latest beta, like auto select best gpu, xml parser and a few bit’s for use later down the pipe line. And I’m learning WixToolset to make an actual msi installer for the software instead of manual instructions.

But the reason I got into VDD was to be able to match like “an emulators resolution” to a full screen, and then get sunshine to send that full screen. And I do believe you can send that info to the client, and next step would be to make the aml.c to take server suggested resolutions or close to (if possible). And/Or set resolution via Luna, like you have in your PRs, but I want i more fluent.

edit: Seems like I got the info the wrong way around, it’s the moonlight client that tells sunshine which resolution it accepts, so right now we lock resolution for ml-embedded, like you do in your PR. I was hoping have it the other way around, but since that’s the case I’m thinking about making a “settings from Kodi” to configures the resolution ml-em starts with. But that means to probe the system for available resolutions of the attached screen and make you chose from them either when Luna starts, or a settings page for Luna. Anyway, there is a special solution in Moonlight-Switch, but I haven’t looked that deeply into it yet.

1 Like
11

That’s very interesting, I never heard of VDD or the project you mention. I’m out of the loop here, but if I understand correctly is your goal with VDD to be able to match the emulator resolution with the client resolution or vice-versa? Would that create a clearer image or are there any other advantages? I might be way off, but just trying to understand your expertise :sweat_smile:

I think what Luna does is create a config file for moonlight and put it in a directory where ML will read it as described here. However, Luna falls back to the addon path (~/.kodi/addons/script.luna) if the wanted paths are not writable, and I’m not sure that moonlight looks in the addon path for a config. I need to check that.

IIRC Luna has a settings page where you can adjust the resolution (default is 720). This resolution is written to the config file. Is that what you mean?

12

??? LoL…

Well since I’m a wannabe and had it backwards, my train of thought was erroneous. I wanted the stream to have the same resolution as the software that was streamed, eg less pixels to encode i my line of thinking. Via VDD it’s solvable.

I’m still a newbie to Sunshine and don’t really know if that would improve anything.

Regarding settings in Luna I figured as much, but I’m still in the mindset of having a more customizable resolution list. Train of thought, when installing the “possible OSMC Moonlight solution” it checks the “Vero” for all supported solutions of your connected display and creates a list of them for you to chose from. And perhaps a toggle to run that script and regenerate that list. I’ also just a beginner when it comes to addons and what is possible, but I can also imagine having a default list, and changing that via a script/toggle.

But I’m still to new to this, and I probably have my mind turned sideways regarding en/decoding optimization. I just know with my i7(4790) SFF(no GPU) I have a hard time generating a stable h264 stream at 720p even.

13

FWIW I’m also a beginner in this area, so I guess we’re learning from eachother :slight_smile:

It sounds like a reasonable approach to be able to reduce the number of pixels to encode and stream. Since VDD creates a virtual display, you should be able to configure it as Sunshine output (it should turn up in the Sunshine logs like this and then you can set the output in the Sunshine configuration.

Having a list of resolutions supported by the connected display sounds possible. I’m not sure if it’s worth the effort though, because the current list in the settings has all the common resolutions and a user should have to configure it only once and never look at it again.

My biggest wish for Luna right now is to be able to quickly select a game instead of going 3 levels deep. Otherwise any stability improvements also on my mind. I just need to start using it more right now.

The i7 4790 has a Intel HD 4600 iGPU. I’m not a hardware guy, but it does seem to meet the minimum requirements for Sunshine. Do you have the same stability issues when connecting from another client with Moonlight?

14

Not to the same extent, but I’m guessing that it’s a bit of two factor thing. My phone works “alright”, with the occasional lag. So it’s a bit of hardware issue at host end. Then AML’s vpu is a bit sensitive too. But my phone isn’t Mali based but “MediaLabs”?

15

Hmm, do you have the Sunshine logs from when this occurs? It could be because of limited hardware, but it never hurts to check the logs for anything out of the ordinary.

It might also help to fiddle with the Moonlight settings like bitrate or fps, though I’m not sure if that would mitigate any rendering issues.

I actually never heard of MediaLabs and Googling doesn’t seem to bring up any hardware related results. Did you mean MediaTek maybe? They have SoCs with Mali GPUs.

16

BTW, might this be of any help with your emulator use case? GitHub - Nonary/ResolutionAutomation: Automates changing the host resolution to match the client resolution of Moonlight, with capabilities of supersampling if required

edit: my bad, this is for adjusting the host resolution, but you want to adjust the client resolution.

17

You are entirely correct MediaTek (probably got it mixed up with Creative labs or something, just didn’t feel right). And I knew MediaTek had some non Mali based gpus (PowerVR), but my phone is qualcombased and anderno 640. So Iwas up in the clouds in more ways then one…

On the other point yeah, my wish was for sunshine to handle / send as little data as possible. I thought you could limit the resolution from the server, but it is as you might say client rules.

18

I did some more testing and found out the following things:

  • When moonlight.conf is written to the addon path, MLE does not pick it up automatically. This is consistent with the docs. I can fix this by passing the configuration path from the addon explicitly to moonlight -config. This also explains why I had to pass the IP address explicitly every time. I’ll update the PR accordingly.
  • When I start MLE either via Luna or directly, sometimes I get a black screen (with audio) and this doesn’t resolve when I restart MLE. However, it does resolve when I reboot the Vero device. It occurred to me that it happened after I watched a video. So I reproduced this by starting another video and starting MLE et voilà: black screen again. I’ll share these findings in a GH issue.

Building on the first point: since a config file is written by Luna, I think the platform option can be added as well so that we can set aml there. In the future we may want to autodetect this, but for now a setting option is fine. Another setting that I would find useful to have is quitappafter. This sends a quit app request to the host to stop the application automatically after the stream has stopped. I don’t really have a use case for keeping the application running, but I think it’s nice to have it configurable for multiple use cases.

19

@cavejohnson Thank you again.

That is why i had a .sh for starting ml-em via cli, pointing to the conf path, where i indeed did the hard coded server, platform, resolution and i think i played around with packetsize, preferred codec and alot of stuff. Never really got the app closed on the server though, probably a PEBKAC.

Black screen is probably since video can trigger OSD, and I had this issue. And my first trials with Vero4k, it wasn’t a problem, then VeroV released and i got back to Vero4K too and both had the issue. Put a fix in aml.c, but I unsure if there is some registry that gets set when playing video that has to be changed directly in order to reset it, and get reset via reboot. “Smells” like the video issue when X was started on the Vero4k, and playing video had color issues unless restarted. But it was intermediate. And hard to track down, eventually I found out there was changes in alpha value representation and i could sometimes reset it without reboot.

If you want to look in he ml-em code, there is references to /dev/fb0|1 blank, which messed up aml.c for Vero, which where changes added between vero4k working and not.

This is mostly an “educated” guess… Since my limited experience with hardware-coding in general.

20

Thanks for replying, I think I applied this workaround in src/platform.c, where I commented out this line:

write_bool("/sys/class/graphics/fb1/blank", true);

So my black screen happens even with that removed.

The fix in aml.c you’re talking about, is that the one mentioned in this comment? Vero 4K support · Issue #573 · moonlight-stream/moonlight-embedded · GitHub
I’ll try this later, but I don’t have an Intel card and to me the snippet checks against a hardcoded value, so I don’t really understand the if statement? I’ll try it anyway, maybe I’m missing something.