moonlight: request for comments and testing

LeSabotageur

I have a general question about moonlight : how can I prevent any controller plugged to the pi of being used ? As told earlier, I'm using VirtualHere and too often moonlight maps a controller on the pi, therefore screwing up my configuration. I've not found a reliable solution yet (commenting *.dll files in the Gamestream folder doesn't work), so I'm wondering if anyone here knows ?

hhromic

@LeSabotageur try adding input = /dev/null to /opt/retropie/configs/all/moonlight/global.conf.
This should make moonlight only use a null device as sole input and therefore should ignore all real controllers connected to your Pi locally.
I haven't tested it myself (not at home at the moment), but I suspect it could work. Please let us know if it worked.

Also, for this option to work, you should be using the autogenerated game config files that include the line config = /opt/retropie/configs/all/moonlight/global.conf to include the global conf.
As an alternative you can include the input line directly on your config files, but I think the global option makes it easier and more tidy to configure.

Silent

Generally it seems to work flawlessly! Moonlight itself is working OK but until now I've been using a different setup to get it running with RetroPie - that is, a modified retromoonlight. Your approach seems better however, most notably because it actually uses runcommand, unlike retromoonlight.

Two things to note:

Generated filenames still contain : in them, which greatly confuses Windows when previewing roms\steam directory from a network share. Maybe cut them, like retromoonlight does?
Some games listed by Moonlight have ™ (maybe also © or ®) in names and this confuses some other software. Maybe they also could be omitted from filenames.

LeSabotageur

@hhromic sadly, it doesn't work

Executing: /opt/retropie/supplementary/moonlight/moonlight.sh stream -config "/home/pi/RetroPie/roms/steam/Steam.ml"
No mapping available for  (00000000000000000000000000000000) on /dev/null
EVIOCGRAB failed with error 25
libevdev error in libevdev_next_event: BUG: device not initialized. call libevdev_set_fd() first
Error: Bad file descriptor

And then it goes back to retropie.
That's not a major issue, though, as I have some workaround for it (Steam allowing to change the order of the controller for instance. That would have been a quality of life improvement :)

seriously24

@LeSabotageur I am no specialist here, but the

No mapping available for  (00000000000000000000000000000000) on /dev/null

awefully looks like something similar than what I had a few posts ago. Have you tried the solution from @hhromic to use a custom controller mapping file ?

@hhromic said in moonlight: request for comments and testing:

Instead, the recommended way is to create your own custom controller mappings file (as you already did) and place it somewhere handy (for example in /opt/retropie/configs/all/moonlight and then reference it in the global.conf file that is also in that recommended folder using the mapping option. When doing this, please use the full path to the mappings file in the option, even if the global conf file and the mapping are in the same directory.

In this custom controller mappings file (source can be found here ) you can try adding a new line with ID 00000000000000000000000000000000, the name of your controller and finally the mappings of the buttons. Since you don't want to use this controller, I guess the mappings don't matter, so just copy the mapping of another controller.
Once the file is ready, to use it simply add a mapping = <yourfile> command in your .ml files.

Hope this helps :)

MightyHandy

@hhromic - this is awesome! Given that there is now a brand new experimental "steam-link" package... would it make more sense to store the ml files under:
/roms/moonlight
In order to eliminate the ambiguity.

Silent

@MightyHandy said in moonlight: request for comments and testing:

@hhromic - this is awesome! Given that there is now a brand new experimental "steam-link" package... would it make more sense to store the ml files under:
/roms/moonlight
In order to eliminate the ambiguity.

I don't agree. By using 'steam' you're playing nice with scrapers and ES themes (lots of them have a 'steam' theme). Moonlight is just an "emulator" used to play those, steam is "platform".

MightyHandy

Tested width, height and FPS options and worked great. Is there a list of other options? You listed examples of app, controller config too. Was gonna check vsync.

MightyHandy

@MightyHandy nevermind... found this:
https://github.com/irtimmer/moonlight-embedded/wiki/Usage
I assume you are just passing the options through.

hhromic

@Silent said in moonlight: request for comments and testing:

@MightyHandy said in moonlight: request for comments and testing:

@hhromic - this is awesome! Given that there is now a brand new experimental "steam-link" package... would it make more sense to store the ml files under:
/roms/moonlight
In order to eliminate the ambiguity.

I don't agree. By using 'steam' you're playing nice with scrapers and ES themes (lots of them have a 'steam' theme). Moonlight is just an "emulator" used to play those, steam is "platform".

I agree with @Silent , steam is a defacto standard and that's why I chose to use it :)
And yes indeed I designed the integration for Moonlight to just be an "emulator" for "steam".

hhromic

@MightyHandy said in moonlight: request for comments and testing:

@MightyHandy nevermind... found this:
https://github.com/irtimmer/moonlight-embedded/wiki/Usage
I assume you are just passing the options through.

Almost. The options are actually the ones that can be set in a moonlight.conf file.
The supported options (and their names) can be seen in the template config file from Moonlight here: https://github.com/irtimmer/moonlight-embedded/blob/master/moonlight.conf

hhromic

Hi all, I've been away for some time and I'm still busy nowadays :(
However I haven't forgotten about Moonlight and finishing the scriptmodule to be included in RetroPie officially. I will be working on some extra improvements after all the feedback you have given so far. Thanks for all the input guys, some ideas are very nice!

@Silent said in moonlight: request for comments and testing:

Two things to note:

Generated filenames still contain : in them, which greatly confuses Windows when previewing roms\steam directory from a network share. Maybe cut them, like retromoonlight does?
Some games listed by Moonlight have ™ (maybe also © or ®) in names and this confuses some other software. Maybe they also could be omitted from filenames.

I understand how this is problematic for your use case. However I think I have an idea on how to solve it nicely for both, you who can't use full names and also others (like me) that prefer the full names in filesystems that supports it. To help me (later) develop this, I would be very thankful if you can provide me with the your list of games so I can study what kind of characters are there.

Therefore, can you please send me the output of this command?

/opt/retropie/supplementary/moonlight/moonlight.sh list

Cheers!

Silent

@hhromic said in moonlight: request for comments and testing:

Therefore, can you please send me the output of this command?

1. Spintires MudRunner
2. Run PCSX2
3. Grand Theft Auto Vice City Stories PS2
4. Grand Theft Auto Vice City PS2
5. Grand Theft Auto San Andreas PS2
6. Grand Theft Auto Liberty City Stories PS2
7. Gran Turismo 4
8. Crash Bandicoot N. Sane Trilogy
9. BattleBlock Theater
10. American Truck Simulator
11. Worms W.M.D
12. Portal 2
13. GRID 2
14. Steam
15. Grand Theft Auto V
16. Fallout 4
17. Sid Meier's Civilization V (DX 11)
18. GRID
19. Driver San Francisco
20. DiRT Showdown
21. Left 4 Dead 2
22. Saints Row: The Third (DX 11)
23. Saints Row IV (DX 11)
24. Deus Ex: Human Revolution
25. Hitman™
26. Double Dragon Neon
27. DiRT 3 Complete Edition
28. Hitman 2
29. Hotline Miami 2: Wrong Number
30. Mafia III
31. Overcooked
32. Broforce
33. DiRT Rally
34. L.A. Noire
35. I am Bread
36. Rocket League
37. The Expendabros
38. The King Of Fighters XIII
39. Max Payne 3
40. Euro Truck Simulator 2
41. DiRT 4
42. Agents of Mayhem

Silent

Also something I am not sure which was brought up in the past, but I think it is worth to broadcast a moonlight quit message on closing Moonlight emulator, so killing the session on pi also shuts it down on host.

What I did was add this to runcommand_onend.sh:

#!/bin/bash
if [[ $2 == 'moonlight' ]] ; then
	/opt/retropie/supplementary/moonlight/moonlight.sh quit
fi

Also, Moonlight works great as a PS2 "emulator" too, by streaming PCSX2 games from the PC =) GeForce Experience preserves shortcut arguments for shortcuts you add, so it's just a matter of preparing proper ones for PCSX2 games and adding them.

hhromic

@Silent yes I'm very aware of that "issue" and it was briefly mentioned before. This happens to me as well and I understand how annoying it can be, specially when you stream the "desktop" and the computer is left with the audio unrestored. I have seen this reported multiple times in multiple places, so it is not an isolated case.

The "problem" is that when you quit the streaming session, Moonlight simply terminates without any further network messaging. Then, the GFE server on the remote computer never realises that the client vanished. That's why when you send a formal "quit" message (like you do in your "onend" script) it quits gracefully.

In my honest opinion this is an issue that GFE should address because it should be the responsability of the server to cleanup the session if the client dissappears. This can happen on network disruptions or any other cases too. However I don't really expect NVIDIA to change anything.

I've been working on a native solution since some time (I don't have much time nowadays so testing is going slow for me). My solution is implementing a new key combo to send a "quit" request to the server (like you do on your solution) from inside the streaming session but do not quit immediately. Once the server gracefully terminates the session on its side, Moonlight receives the termination packe tand simply quits itself cleanly too. This is the way it should work.

While the solution you post using the "onend" script in runcommand works (and is not a bad temporary fix), I don't think is the proper solution because a race condition is created between terminating the session and sending the quit request. I prefer to do it natively the other way around for robustness.

Currently I have it implemented, compiled and working on my system but I want to clean it a bit more before publishing here for wider testing. Let me know if you are interested on testing, that would speed-up things a lot on the development side! I intend to send this to upstream so it's official.

Thanks for the patience, and be sure I am definitively working on a solution.

Silent

@hhromic said in moonlight: request for comments and testing:

Currently I have it implemented, compiled and working on my system but I want to clean it a bit more before publishing here for wider testing. Let me know if you are interested on testing, that would speed-up things a lot on the development side! I intend to send this to upstream so it's official.

Of course! I stream plenty of games to my pi, so I'd definitely be able to help with testing.

Also, you are right about this 'race condition' - however I'm yet to experience any issues from that.

hhromic

@Silent, @seriously24
I have a solution for the quit issue ready for testing now :)
Initially I was crafting a more complicated solution but recently I had an epiphany and turned out to be very simple to implement after all.

It works like this: I added an option for automatically sending a remote app quit request when you quit the session with the same quit keys combo. This option is activated by default. So you won't need to change any config for it to take effect.

If you want to disable it and return to the old behaviour (quitting the streaming session does nothing to the server) you can simply use a new -noquitappafter cli option or quitappafter config file option.

To test the new option/functionality, you need to edit the scriptmodules/supplementary/moonlight.sh file and replace the line:

gitPullOrClone "$md_build" https://github.com/irtimmer/moonlight-embedded.git

With this one:

gitPullOrClone "$md_build" https://github.com/hhromic/moonlight-embedded.git add-quit-app-after

Then just re-compile/re-install Moonlight using the scriptmodule and you should get the improved binary ready to go. To verify you are using the new binary, just run:

/opt/retropie/supplementary/moonlight/moonlight.sh help

And check that there is this line in the help:

-noquitappafter         Do not quit remote app after quitting session

I would really appreciate if you can test this patch and report back if all works as expected: when you quit the session in Moonlight, the remote computer should go back to normal gracefully.
Don't forget to disable any script in runcommand-onend that sends the quit request externally. This patch makes that obsolete.

If all goes well, I will be sending this patch upstream so it's officially added to Moonlight.

Thanks for testing!

hhromic

Update

Ref: @Silent @seriously24 (all)

I tested now the "quit app after" option and is working very nicely. When activated, when I quit the streaming session using the exit combo, GFE on the remote server gracefully restores the audio/video settings to normal.

For example, I can start a YouTube video on the computer, launch Moonlight and stream the Desktop, audio and video are now forwarded to my TV, then I can quit the streaming session and audio/video are back on the computer without any interruption nor intervention. Keyboard/mouse is also properly restored.

However I did a small change compared to what I wrote in the above post. The option is now disabled by default (to keep the current behaviour) and needs to be enabled explicitly in the config file or command line. I modified the Moonlight scriptmodule to enable it by default automatically on the global config file. You can add it yourselves too, the option is quitappafter = true.

I just sent a PR upstream and hopefully this enhancement will be integrated officially in Moonlight and you can start using it. Will keep you updated.

hhromic

Update

The "quit app after" feature is now merged upstream in Moonlight :)
I updated the experimental scriptmodule to add quitappafter = true by default to the global.conf config file on new installs. This is an option many will want by default.

Thanks all for the testing and feedback, I still have some good ideas from you to implement into the scriptmodule, just looking for some time to do them.
Hopefully soon the scriptmodule is mature enough to include in RetroPie \o/

Silent

Cool stuff! I'll give it a try later today :)