Yes that is the Luna error, and the result of the command you gave is “Moonlight Embedded 2.2.0 (EMBEDDED;PI)
Connect to 192.168.80.101…
NVIDIA GeForce GTX 770, GFE 2.11.3.5 (protocol
version 7)
You must pair with the PC first .”
Just did some debugging and found the underlying issue. In the past, moonlight-embedded didn’t verify the PIN challenge response. To put it somewhat simple: the GameStream host gets the key from the client and sends some data back, based on the PIN entered on the host machine, which is supposed to be validated on the client and thus determine if the PIN was actually correct. Leaving out the validation check made it possible to enter ANY PIN on the host machine and still get moonlight-embedded to pair. For me, this made it possible to just generate any four digit number and display it, acting as if it were correct (because technically - for moonlight-embedded - it was).
The fact that moonlight-embedded started to verify the PIN back on the client side basically means that I need to get the PIN from the CLI output again - which is more or less unreliable (because output changed a lot in the recent moonlight versions) and one of the reasons why I ported all the crypto stuff to python. I’ll fix it (again) for now, but I’m not sure how long I’ll support this way of pairing as it becomes tiring really fast - in the time it takes me to figure out if it’s a bug in my code or some changed output I could lay the groundwork for some cool new stuff and I’d rather do that than going back to the same lines over and over again. To make this clear, I’m not mad at irrtimmer, as it’s his project and he can do whatever he likes, whether anyone agrees or not - I’ll always be grateful for his port to embedded systems. Just stating it’s tiring to chase some of his changes which I would deem unnecessary.
Next time I’m updating the installation instructions in the readme I’ll strongly recommend installing m2crypto and pycrypto - plain python is just way easier to handle.
EDIT: @GameOver69Luna 0.6.1 should fix all of the issues you described above. Thanks for taking your time to let me know, really appreciate your support As always, let me know if you need any further support and don’t hesitate to request new features if you feel something’s missing.
So your newest update fixes everything we talked about. Thank you.
I am able to stream games… now I have one last issue… the Xbox controller… wired… the d pad is not mapped properly… up/down is really left/right and vice versa. Also x and y buttons are reversed… everything else seems to be ok. any ideas?
How did you create your mapping file (and do you even have one)? The most simple solution would be to edit the controller mapping and just switch the button codes for btn_north and btn_west.
Here’s my configuration for the right button area, where Y=north, B=east, A=south, X=west: btn_north = 308 btn_east = 305 btn_south = 304 btn_west = 307
If necessary, I can provide you with a fully working X360 mapping as well (I’m using triggers as buttons though).
Regarding the dpad: I had to append --dpad-rotation 90 to my xboxdrv launch arguments to have the it working properly
I do not have one. I set up everything based on this how to, including setting up the .ini for the Xbox controller. I had found a Xbox.map file from a different wiki, but when I applied that via Luna, both my controller and keyboard mouse combo failed to work via moonlight.
So I would just need a proper .map file and I should be ok? I just want my co troller to function same as it does when connected to my gaming PC.
I’m not using an .ini file for Kodi itself (because I’m not using the controller to actually control Kodi), so YMMV on the following:
As soon as you enable custom inputs in Luna, it passes all the devices to moonlight like this: moonlight stream [app-name] -input [all other devices] -mapping [mapping-file] -input [all devices that have a mapping file attached]
To give you an example from my machine: moonlight stream Steam -input /dev/event4 -input /dev/event5 -mapping /home/osmc/xbox-1.map -input /dev/event0 -input /dev/event1
where event4 ist my keyboard, event5 is my mouse and 0/1 are my X360 controllers.
Because the order of input devices is obviously important (the mapping file is used for all following inputs until another mapping is defined) Luna is supposed to order them by their mapping file automatically (i.e.: append all input devices that don’t use a mapping, append all input devices for mapping “A”, append all input devices for mapping “B”, etc…).
Sadly I don’t have a screenshot ready right now (and I can’t take one, I’m on a different feature branch right now which is way ahead anything you’ve seen of Luna so far), but usually I got my two X360 controllers set up and my KB/M combo afterwards. If this doesn’t work for you, you might also want to try to switch the order (having the KB/M combo assigned first and the controller after that; though remember that you still should attach a mapping file, that’s what this option is for (and why it’s disabled for non-controller devices )).
By the way, if no specific mapping is provided, moonlight falls back to its default mapping which is located at /usr/local/share/moonlight/mappings. This file is responsible for the issue your seeing with Y and X being swapped, as it assigns button code 308 to btn_west (which should be 307) and vice versa.
If you have no luck setting up the desired behaviour via Luna I’d kindly ask you to provide me with a screenshot of the failing configuration (i.e. the settings → input → select input devices dialog) so I can have another look at this part.
Again, to provide a fast solution, you should be able to edit the default.conf file in the above mentioned directory (never did, that’s why I’m saying “should”).
I do realize you’re going through a lot right now and even though you’ve stated that this is no inconvenience to you it makes me feel somewhat bad that the whole process of setting this up wasn’t as easy as it should be. Alas, Luna is still being worked on and while she has her quirks here and there I’m trying really hard to improve everyone’s experience. That being said, you also kind of picked a “bad” time to get into this: 0.6.0. was released just a few days back and is one if the biggest changes so far - I’m rebuilding parts of the underlying architecture (which is still not done) and 0.6.0 is more of an intermediate release to get some requested features out to the users as fast as possible, like multi controller support and audio device selection.
Point of this speech being: Luna is still a (mostly) one-man project and I’m really grateful for everyone who decides to use it and in return point out issues they’re having - that’s the only way Luna can grow and become better, since my own resources (especially regarding testing and the time it takes) are limited.
there is no folder for moonlight located @ /usr/local/share/
I did find it here though /usr/share/moonlight/mappings/
I was able to fix the Y and X buttons per your suggestion. How come doing the same for the D buttons has no effect? I thought that was odd. Where would i be able to add your rotation line so that it is automated?
Also somewhat non related, i have an odd issue, where i cant make my own mappings. I also have retropie installed as well. If i use the xboxdrv in osmc, the controller in retropie doesnt work. when i enable the xboxdrv in retropie, it removes the one in OSMC, and installs its own. Then i can use it in retropie, but not in osmc. Whats odd is that even though i left it so that it is working in retropie, i can still use it in moonlight… just not in OSMC/KODI… its very weird.
That being said, im still in OSMC when i can custom map my own controls, but cant because the controller isnt recognized properly. If you somehow know how i can have it working in both, that would be great. But for now, if i could just get it working properly in moonlight i would be happy.
Oh sorry about the ‘wrong’ path - it’s in /usr/local/share for me, but that might just be because the system on that card is pretty f***ed up due to all the debugging Glad you found it though.
You can append options to xboxdrv on its autostart definition - this should either be directly in /etc/rc.local or (if you’ve followed this guide to the letter) might also be in /home/osmc/xbox.sh.
The mapping file has two different definitions for the d-pad: one is straight up button codes (btn_dpad_) and the other one uses axis (abs_dpad_) - from what I could gather so far, the d-pad on an X360 controller is really just another analogue input and as such it uses the axis definition. So switching the abs_dpad_* values should do the trick.
Sadly I’ve no idea about the Retropi / OSMC issue your seeing - never used a setup like this so I really can’t help you out there That being said, there’s also a solution called RetrOSMC which seems to integrate both applications into a single one (?) … again, never used that either, but IIRC @Amivit got that set up, maybe he (or someone else) can share some insight.
Also im using the RetrOSMC already. thats how i was able to integrate it and launch from within OSMC. I have a question out in that forum, but havent heard back yet.
Either way, everything is setup the way i want it. So thank you very much for your time and help! Looking forward to your improvements to LUNA!
PS… have you tested LUNA on the latest beta packages of OSMC that work off of KODI 17.1? Just curious how it works, if at all.
PSS… would you know what I would might need to so to incorporate wakelan into all of this? So this way my pc will turn on if off?
Not much of a genius really, just know my way around some of the stuff - and I’m learning a whole lot of new stuff while working on Luna, it’s just amazing (well for me it is anyway ). And you’re very much welcome, always trying to help whenever I can.
Nope, I generally don’t update any of my Kodi installations until the new version is:
a) available on all of my platforms … I’m using an OSMC, an OpenELEC and multiple OSX clients with a central database, so just updating just one of them isn’t really much of an option
b) stable … I don’t own a spare Pi for development and the Pi 2 which runs my OSMC installation is used heavily. So I’d rather not do any update experiments on that one
However, if none of the dependencies are gone in the Kodi v17 repo, I expect Luna to keep working - especially since Kodi keeps some “old” Python API versions around for some time.
Wake On LAN is being worked on, more or less currently. I just got the multi-host support and mDNS host discovery done(ish). Last night I (re-)wrote the application bootstrapping to improve overall performance (2-3secs to the first view and everything after that is nearly instant). Just need to move all of the actions (like the input selection, which is really just another controller + view) out of the settings since they don’t work anymore (I’ve lost the entire plugin routing and had to write my own routing component which doesn’t - and really shouldn’t - support the way things are currently wired together) and afterwards I’ll build the WoL functionality (via context menu on the selected host though).
Long story short: WoL will probably be available in 0.7.0., at least that’s what I’m currently aiming for. But: no ETA yet, sorry
Similar question here - I tried to install it on Vero and get unmet dependencies which I can’t resolve The following packages have unmet dependencies: moonlight-embedded : Depends: libraspberrypi0 but it is not installable or rbp-userland-osmc but it is not going to be installed E: Unmet dependencies. Try 'apt-get -f install' with no packages (or specify a solution).
It must be compiled from source against either Vero 1 or Vero 2 sources (depending on your module). When My OSMC 2.0 lands, we will include Moonlight in the App Store, and there will be a Vero 1 and Vero 2 version available.
in the meantime, building from source seems a bit complicated.
im failing at installing the .dev sources, what do you exactly mean by using vero2 sources? how to get them?
root@osmc:/# apt-get install cmake
Preformatted text Reading package lists... Done
Building dependency tree
Reading state information... Done
You might want to run 'apt-get -f install' to correct these:
The following packages have unmet dependencies:
cmake : Depends: cmake-data (= 3.0.2-1+deb8u1) but it is not going to be installed
Depends: libarchive13 but it is not going to be installed
rbp-userland-dev-osmc : Depends: rbp-userland-osmc (= 1.4.0-1) but it is not going to be installed
E: Unmet dependencies. Try 'apt-get -f install' with no packages (or specify a solution).
You get this problem because you have half installed moonlight. Updates etc will fail until you resolve this. You need to remove any packages you attempted to install