Error and GUI terminates back to ES when launching RetroPie-Setup direct on machine (libudev?) - but SSH is ok

movisman

Now, randomly, it is back at the state where it will produce the error I mentioned earlier at the base of the retropie_setup.sh GUI, which is constant, however if I drop out of ES to a terminal and run retropie_setup.sh that way, on first launch it fails, but subsequent attempts it then works. One you finally get in, controls are still totally messed up like the other thread mentions, when using the controller to navigate.

Such a weird problem this. Really have to hit the sack in the next 30 minutes as it's so late in the UK now, but will continue any recommendations you have as soon as I pick them up.

Cheers for all the help so far.

mitu

I have an Ubuntu VM for testing and I see the same behavior - the setup starts, but quickly exits, without doing anything. I'm not sure if it's the same problem, since I don't see the message you reported.
Btw, running joy2key without any arguments like you did - it's probably ok if you're getting that error.

What's funny is that if I start the setup script from a simple xterm (and not Gnome Terminal), then the setup script functions normally. Can you try doing the same to see if maybe the terminal is to blame ?

EDIT: it seems that even if setup works fine from an empty xterm, but if I start ES from the xterm and then access the setup it still doing the same thing - so scratch the test. But for now I know it's not from gnome-terminal.

movisman

@mitu

Hey,

Thanks for the reply. Bit of a classic, stayed up so late trying to resolve the issue I was a bit late for work - whoops!

That was a really interesting theory with the terminal - I didn't think of trying that. I saw your message this morning and planned to test but then saw your edit, so I haven't done anything with it yet as it doesn't sound terminal related.

I am glad you were able to replicate it though, at least it means it is not likely to be something with my setup, also that other thread sounds like a similar thing - I am pretty meticulous about keeping my Ubuntu instance clean for RetroPie - the little machine it runs off doesn't actually do anything else but run Ubuntu Server with RetroPie on top, plus all the emus of course. So it has minimal apps on it as a whole really, and anything I do install which is temporary, I do try to remove as I go.

Thanks

mitu

@movisman Yeah, the thing is I don't get the error with

Exception AttributeError: "'Context' object has no attribute '_libudev'" in <bound method Context.__del__ of <pyudev.core.Context object at 0x7fb309ef6d50>> ignored

but I also don't have a controller installed (it might appear only when a controller is connected ?). I also never started the setup script from ES until now, since it's a test VM for me, so I'm not sure if it's an error that was there from the beginning or just started to happen.

I'll keep poking at it - eventually I can test in a real Ubuntu install in the week-end.

movisman

@mitu

One thing to note, is I don't always get that error either.

It is either one or the other, but it doesn't jump between producing an error or not. What I mean, is last night I tried it 20x times and didn't get a single error, it would just load then crash like what you are seeing. Yet on another boot or combination the error would then appear consistently.

You might be right about the controller thing, the Xbox One controller powers off itself after 15 minutes or so and that could be a factor.

Regarding when I first saw the error, I think it was a few weeks back I noticed it, but once I had updated the setup script, it seemed to go away, or so I thought. I've not seen it since (but to be fair I haven't really been into setup via ES) until last night, when I noticed issues straight after doing an apt get upgrade to grab a handful of OS updates, and updating my setup-script so I could update Retroarch to 1.7.6. I then noticed while I was working on changes to the Chiceulo theme. The fact the controls are totally messed up (when it does load) is new thing too, just like is mentioned in the other thread.

Just to clarify though, I have had the Ubuntu Server 18.04.1 instance running since November and this was not an issue up until recently.

If you need me to extract or test anything at all, just let me know. Keen to get it resolved but it's a real strange issue, let me know if you find anything.

I tagged Jools earlier in the thread as I think he has an Ubuntu instance also, however i'm not sure if it's 16.04/18.04/18.10 or even if he actually still has one. I know he is forever getting bombarded with issues so I won't chase him up. However if you guys have any dialog between yourselves maybe it's worth mentioning to see if he can replicate it also.

Thanks for all the help so far!

psyke83

I can't reproduce the issue, but I do have a few suggestions to help troubleshoot.

I added some debugging to my script, and ran it manually with these arguments:
/opt/retropie/supplementary/runcommand/joy2key.py /dev/input/js0 0x00 0x00 kich1 kdch1 0x20 0x71

It's clear that the get_button_codes function (which is the only function that utilizes the pyudev's Context()) will not be called if there's no device present (in this case, /dev/input/js0).

So, try the above command while your controller is connected (making sure to substitute the device name for your actual controller, if it's different).

If the script works correctly, nothing will display, but pressing buttons on your controller will trigger control codes to print on the terminal.

mitu

@psyke83 How does the script work without a joystick present ? In my tests I only have a keyboard (mapped as a gamepad in ES) and it's randomly failing or working - similar to how @movisman experienced - and it doesn't matter if it's started from ES or not.

The failure is 'consistent' - if it fails once, then it will fail again until either I restart ES or the terminal I'm using to start it.

BuZz

It's strange as even if the joy2key fails, it shouldn't cause retropie_setup to exit.

BuZz

Might be worth checking if there is anything additional logged in logs/ after it quits.

mitu

It manifests as you press Cancel on the dialog page. @psyke83 can you share your modifications to the script that prints the event codes ? I can repeat the tests tomorrow (I don't have right now access to the Ubuntu machine I was testing today) and see if something is logged.
My next line of test would be also to change the DE to something simpler.

@buzz In my tests, there's nothing logged, although I see the setup menu screen briefly before closing in.

BuZz

@mitu can you roll back retropie-setup a year and see if that makes a difference ? If so, it's worth bisecting. Just to rule out something in the script triggering it (eg the way we changed how we trap errors and output logs)

mitu

@BuZz I can do that - will try this avenue also. I guess you're thinking of this.

BuZz

@mitu Yes. I don't see why it should be but it's worth a go I guess.

psyke83

@mitu said in Error and GUI terminates back to ES when launching RetroPie-Setup direct on machine (libudev?) - but SSH is ok:

It manifests as you press Cancel on the dialog page. @psyke83 can you share your modifications to the script that prints the event codes ? I can repeat the tests tomorrow (I don't have right now access to the Ubuntu machine I was testing today) and see if something is logged.
My next line of test would be also to change the DE to something simpler.

@buzz In my tests, there's nothing logged, although I see the setup menu screen briefly before closing in.

No modifications are needed to print codes - the arguments supplied will map axis and face buttons to keyboard codes. So if you use the arguments I listed in my other reply, pressing up/down/left/right will trigger codes on the terminal.

The debug code I was referencing was merely to print some text in the beginning of get_button_codes; the function will not trigger when the device is not present. I even commented out the from pyudev import Context line, and the script won't complain about pyudev being unavailable if the controller/device is not present.

P.S. Not sure if it was mentioned yet, but @buzz made changes to the script so that joy2key doesn't execute in an SSH session, so you should test the RetroPie script for this issue on a native framebuffer or terminal in a X session.

mitu

@psyke83 said in Error and GUI terminates back to ES when launching RetroPie-Setup direct on machine (libudev?) - but SSH is ok:

P.S. Not sure if it was mentioned yet, but @buzz made changes to the script so that joy2key doesn't execute in an SSH session, so you should test the RetroPie script for this issue on a native framebuffer or terminal in a X session.

I know, and actually @movisman reported the same thing - running the script via SSH is always fine. My testing was always in the X11 terminal (independent or started from ES) - I don't think there's a framebuffer option for Ubuntu PC (?).

movisman

Hi all,

Thanks everyone for stepping in to work this issue out. I am away from home this evening as I have plans, however I'll be back in a couple of hours so if you want me to run some tests let me know.

SSH is always working perfectly, it's just via terminal on the machine directly or when it's called within ES. I will add, that on the rare occasions it does load (which hasn't happened for a bit now), it will work consistently until I reboot, but the controls are also messed up on the controller within the GUI (not ES), like the person mentioned on that other thread. Mostly though it just doesn't work and chucks you straight back around a second after the screen content loads (controls don't work at all for that brief moment)

Cheers

psyke83

I can reproduce on Ubuntu 18.10, and know why it's not reliably reproducible.

After the first error, joy2key will remain running after the Retropie-Setup script exits, and subsequent runs of the setup script will not spawn a new instance of joy2key due to the existing (albeit non-functional) instance already running. Will do more testing when I've got time.

psyke83

OK, it should be fixed by: https://github.com/RetroPie/RetroPie-Setup/pull/2606 (already merged).

Make sure to kill any leftover joy2key processes after updating the script (or just reboot):

sudo kill $(pgrep joy2key)

movisman

@psyke83

Wow!
I just sat down at my computer to see if there were any updates to this thread - let me update the script and reboot now, and will let you know my findings. I wonder if this will also fix the screwy controls, will soon find out!

Will report back shortly.

Cheers

movisman

@psyke83

That totally fixed the problem, after an update of the script and reboot, all the menus now work within ES or a standalone terminal on the machine directly, and of course SSH works as it did previously. Haven't had it crash out on me yet.

Also the controls are no longer screwy, A and B on the controller now perform 'action' and the dpad correctly navigates around the menu. Just to confirm i'm not going mad, the RetroPie GUI never supported 'action' and 'back' on a controller did it? For some reason I thought in the past I could use A to action a command, and B to go up a menu while in RetroPie-Setup on a controller. It really doesn't matter of course, i'm just curious.

Thank you so much for getting to the bottom of this and fixing it up so rapidly. I am really grateful for all the time you guys spend on the project and helping people like me.

Out of interest - any idea why that would have started happening? Do you think script adjustments caused it, or an OS update caused this strangeness? It certainly wasn't something which happened out of the box when I installed 18.04.1 in November, it was working fine up until fairly recently.

Thanks!

PS. Also - thanks for fixing the "Directory: /usr/src/hid-sony-0.1.1 does not exist." error when updating RetroPie-Setup, I noticed this last night after you pushed one of the commits, and was going to mention it in passing - but it's all good now, I guess the commits you made a few hours ago fixed that too.