Retropie detects 2 gamepads when I connect the Teensy with the 2 analog sticks, but I can't configure any input when I move the PSP sticks. Any idea? :/

please, anyone know something? i still cant configure the pad

@retrofreak89 are you overclocking?

Package is removed on my 17.10 Ubuntu - need to update the module to change dependency to just vlc. Should be ok on 17.04 though - you definitely not using the latest beta of Ubuntu?

@possum-master said in Tried updating the script...now i have a big problem :/:

So...i watched a you tube video by ETA prime and he showed how to add more emulators to your pi and he suggested that you update the script first before you add the emulators and i did just that but now i just get a black screen with a bunch of small text letters that show up over and over and over again. They wont stop running and i have no clue at all how to stop this. I cant find any videos or threads about this error. Oh yeah....i can still run and play my games but when i go to retropie configuration on the main screen every option i choose ( you know the list of blue tooth, audio, file maintenence, etc.) this black screen with the white text is on ever single option on the configuration screen. I cant get it stop. its been over a week now. Thanks for helping if possible.

can you please post a screenshot/photo?

actually, I managed to solve the problem simply removing the .bak extension. I have now two configuration files for the two controllers and everything seems to be working fine even in games.

Thanks anyway!
Francesca

@meleu said in ensuring ES gracefully finish ... annother approach:

@caver01 it wouldn't work for any shutdown. And I'm afraid it wouldn't work in any case. And you guessed the reason: "those files created by ES too short-lived".

edit: as you can see in emulation.sh script, those files are removed right before calling reboot|poweroff, then killes.sh won't be able to see them.

Correct - the files are not living to long to check via testcommand fileexistance!
Therefore the incron job triggers existance of files and gives feedback to script!
This works in any cases!

I did long testing with this and all files ... even if they were created and removed like

touch /tmp/testfile.dat && rm /tmp/testfile.dat

The script was always triggered. So YES this solution is working as else. But I was in need to use two more files... that give "feedback" what was triggered now?

Is it a shutdown via software? >> action_software-file is created and checked
Is it a shutdown via hardware? >> action_hardware-file is created and checked

So how does a software shutdown + GPIO triggering works?

Quit Menu -- ES Shutdown ES creates file /tmp/es-shutdown incron triggers script and realizes "action_software" /tmp/es-shutdown is removed by ES shutdown script .... incron trigger is still active incronscript triggers GPIO and set transistor to high Now... the button shutdown script from Mausberry, bash, python... as you like is triggered (as a button press is recognizes) This button shutdown script calls again the incron script /home/pi/incrontrol.sh button-shutdown in the incrontrol.sh is a check for file ... "action_software" for usecase button-shutdown > Exit in background the ES shutdown is still performed GPIO is triggered, mausberry is off, regular shutdown performed

@meleu said in ensuring ES gracefully finish ... annother approach:

@caver01 the simplest solution I can think is to use a systemd trick again. Let's discuss on your thread to not mess this one.

As I said in OP ... the systemd trick is a general solution and seems easier to maintain.
But there are always many roads that leads to rome: Let us collect experience

Ok, I give up. The request was simple and would give developers early feedback on real world performance with each release, which seems to be of some value, based on the feedback above on rev 4.3. It would also allow newbies to quickly check their setup against a standard benchmark and take away a lot of subjectivity, saving them and the support team countless hours of chasing problems that do not exist.

Good luck,
MML

@caver01 ok. I was lazy in my wording. It doesn't make me want to read it. It's obviously / hopefully the right log file.

@jonnykesh I don't think you were being rude. I appreciate your help. Don't worry, I am not that sensitive. All advise is helpful.

@nwgalloway So you had the es_systems.cfg in /home/pi/.emulationstation?

If you do, any new system you add will not get added to that file. Just an FYI.

@dziubak how did you transfer your roms?

@morrisav10 you can also try lr-vice from experimental packages. It works great for me.

@josephzink said in system not reading nes or snes files:

Not sure where to start.

Here: https://retropie.org.uk/docs/First-Installation/

@jester83
I found the problem doing the xbox one bluetooth connect linux trick causes input issues in emulation station

@jonnykesh I thought that as well. I was able to access them on my firestick though, so it is still an issue with the pi3 kodi connection.

@meleu said in Powering off via UI while using a Mausberry Circuit:

Do all the steps I showed on that topic and try to reboot your system. Describe here what happens.

And then perform this command: sudo systemctl disable killes; sudo systemctl stop killes and reboot your system. Describe here what happens.

SO, for starters, I have already done what you prescribed in the other thread to build the service and the killes.sh. Mine is till in the ~/bin folder, which is fine by me for now. After setting the killes.sh as executable, it works great! That is to say, I can do a software shutdown from command line for instance, and it definitely saves my metadata. Favorites and custom collections are awesome. Moreover, my additional line which triggers the NPN transistor does indeed let the Mausberry circuit know that a shutdown is imminent and it properly notices the drop on the GPIO it is monitoring and it cuts power. I really like this clever solution.

It also cuts power when I initiate a reboot. That makes sense to me, and for now I am willing to live with it. The point is that software shutdown requests properly exit ES and no longer lock up my Mausberry circuit.

Seems to me, the improvement to this would be to set a conditional statement before my GPIO command to trigger the transistor such that it checks to see if this is a shutdown/poweroff or if this is a reboot. I just don't know what to check to verify one way or the other--yet.

As for your command above, I initiated the command as you suggested and the system immediately did a shutdown, mausberry circuit powered off.