moonlight: request for comments and testing
-
@hhromic said in moonlight: request for comments and testing:
You are having issues when autogenerating the config files for some games? Which ones? Can you describe what happens? Errors?
I didn't get any errors or anything, I just don't understand the list of games it imported. On the Geforce Experience interface, the "discover games" button finds no more than 5 games, when your script finds 10ish. Though, I have 25-30 games installed on Steam. For example, Hotline Miami 2 was imported correctly, but Dragon Ball FighterZ wasn't.
It's not really a big deal, as I can add them manually the same way I added the Remote Desktop app, I just don't understand how it works :)So far my patch is working fine for me here locally, but I wanted to do some more code cleaning before putting into this scriptmodule for testing. So just a bit of patience and you will be able to test it yourself.
I already sent part of the patch to the moonlight repository, and eventually I want to send it entirely. However the maintainer doesn't seem very active so can take a while.Be sure that I can't wait to see and use it.
By playing a bit today with Retropie and Moonlight, testing things and stuff, I saw that the games in the Steam menu in Emulation Station are only added, never removed. I modified the name of my "Remote Desktop" app in the Geforce Experience, but it only got added as a new game when I relaunched a new "autodiscover of games" through the GUI. Is this on purpose ?
Finally, I got a bit overconfident about all this and tried to use my HORI Real Arcade Pro N on the RetroPie, and it surprisingly was recognized, but only as a Generic Xbox Controller. The input configuration and jstest works amazingly well, but on moonlight I get really messed up controls. My "R2" button becomes start button and things like this. Any advice on how I could investigate this further ? Or maybe an idea about how/why it fails ?
Edit : Doing some research on moonlight-embedded github, it looks like it uses a default mapping file which probably doesn't work for the stick, recognized as an Xbox controller. Will try to use the
-mapping
or a custom gamecontrollerdb.txtEdit2 : It worked with a custom-made game controllerdb.txt. Tricky part was to find the GUID of the joystick, but it now works like a charm with this workaround.
-
@seriously24 thanks for all the testing! sorry for the late response, I've been a bit busy nowadays.
I didn't get any errors or anything, I just don't understand the list of games it imported. On the Geforce Experience interface, the "discover games" button finds no more than 5 games, when your script finds 10ish. Though, I have 25-30 games installed on Steam. For example, Hotline Miami 2 was imported correctly, but Dragon Ball FighterZ wasn't.
It's not really a big deal, as I can add them manually the same way I added the Remote Desktop app, I just don't understand how it works :)
It is very simple actually. The script uses moonlight's
list
command to fetch available games from the host computer. Note that these games are the ones configured in GFE, not Steam. GFE should add supported games automatically and expose them to moonlight. That's all concerning the script.
If the script is adding games that are not in GFE's user interface, then there is something weird indeed. Just for debugging, can you execute:/opt/retropie/supplementary/moonlight/moonlight.sh list
And verify the list you obtain there is the same list generated by the script? If the list doesn't match your installed games in GFE, then you have a further issue on the host computer. If the list doesn't match the generated games, please post the list here so I can take a look. Thanks.
Be sure that I can't wait to see and use it.
I will add it soon to the current script for you to test. Will update this topic when is there. Thanks for the patience!
By playing a bit today with Retropie and Moonlight, testing things and stuff, I saw that the games in the Steam menu in Emulation Station are only added, never removed. I modified the name of my "Remote Desktop" app in the Geforce Experience, but it only got added as a new game when I relaunched a new "autodiscover of games" through the GUI. Is this on purpose ?
Yes, this is on purpose. The reason is that users might have done customisations to these config files, hence it is best to not blindly overwrite them or delete them on game refreshes. Therefore, the game discovery mechanism only adds new games and does not change any existing config file. Currently, if you want to do a complete re-sync, you should manually delete all the files in the
steam
rom folder.
However I understand your use case too. Perhaps I can add a GUI option to do this so you don't need to get a console or external computer to do this. Will think about it.Edit : Doing some research on moonlight-embedded github, it looks like it uses a default mapping file which probably doesn't work for the stick, recognized as an Xbox controller. Will try to use the -mapping or a custom gamecontrollerdb.txt
Edit2 : It worked with a custom-made game controllerdb.txt. Tricky part was to find the GUID of the joystick, but it now works like a charm with this workaround.Yes, exactly. It uses a default shipped controller mappings file. This script installs it under
/opt/retropie/supplementary/moonlight/share
folder. However, I don't recommend changing that file because it will be re-installed on updates.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 theglobal.conf
file that is also in that recommended folder using themapping
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.Using this approach, all your autogenerated game files (current and future) will benefit from this configuration automatically as every config file loads the global conf by default.
Thanks for all the feedback and the testing! I will think about the suggestions and incorporate them in the next update. Happy game streaming!
-
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 ?
-
@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 theinput
line directly on your config files, but I think the global option makes it easier and more tidy to configure. -
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 previewingroms\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.
- Generated filenames still contain
-
@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 :) -
@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 theglobal.conf
file that is also in that recommended folder using themapping
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 amapping = <yourfile>
command in your .ml files.Hope this helps :)
-
@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. -
@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".
-
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 nevermind... found this:
https://github.com/irtimmer/moonlight-embedded/wiki/Usage
I assume you are just passing the options through. -
@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". -
@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 -
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!
-
@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
-
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.
-
@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.
-
@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.
-
@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 orquitappafter
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 inruncommand-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!
-
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.
Contributions to the project are always appreciated, so if you would like to support us with a donation you can do so here.
Hosting provided by Mythic-Beasts. See the Hosting Information page for more information.