@cnoto Cool! Glad it worked for you. It's always nice when you can keep plugging away at those pesky little buggers.

@Dinsdale ah got it! Well glad it works now sounds like a really neat set up. On the other hand I would have never thought to use an Alexa powered outlet so I guess teamwork!

@robertybob Check out @cyperghost's shutdown script - https://retropie.org.uk/forum/topic/17415/ - it supports multiple switches and can be adapted to work like you want w.r.t the reset switch.

@mitu @cyperghost I sent an e-mail to RetroFlag the other day describing the issue and from looking at the photo of the wires I sent, they said the colored wires were in the wrong position. They apologized then gave some directions on how to take the wires out and what the proper color order is. I tried taking them out of the black plug but it seemed a bit of a hassle. Fortunately a replacement case arrived from Amazon today and the colored wires in the replacement case are in the correct position. I rebuilt my RetroPie and the shutdown and reset worked right away :). Thanks again for the help. tldr: Original case wires were messed up, replacement worked.

I am having the exact same issue with my Kintaro Kuma 9000. I'm using a retropie image that I downloaded from arcade punks. I had originally used another image which did not have these power issues and booted up fine with the power buttons and showed the red LED light. But then I switched to another image and now have this exact same problem. It starts up and then right when the splash screen ends, it shuts down. Did you ever get a fix for this issue?

@mitu said in Pi overheating and scripts not working: @MisterMints Most likely something hardware, try to return it and get another. Wish it was that simple! My Pi3 is over a year old and was a gift - I treated myself to a new 3B+ and was going to donate the broken one (obviously before it was broken!) to a retro gaming present for my little brother. At least now he gets the same present but with a brand new 3B+ instead

@de_jean125 Something like that, yes. :) My first guess was that it was for your kid(s), by the way. You could even let it get nastier … "Stop or I'll hack into your bank account and send all of your money to homes for retired game programmers!"

@mitu Ho right, 3rd party! Yes that sound fair. Ok thanks!

@sano Bingo!, just never saw the runtime error before. I went into raspi-config and set it to autologin to console and it boots normally into Retropie, thanks!

I had the same issues using my Mausberry switch I had the blue and white cable mixed up.

@cyperghost & @Rion Thanks for the confirmation that the forced shutdown truly is "hardwired". And the GitHub Link to Spapadim was interesting to read (besides (sorry can't restrain myself here) that he is getting milliseconds wrong). Especially this part is something that I hadn't considered as a possibility so far: After a "shutdown" request, the board will wait for a brief period of time and then cut off power anyway. Therefore, it is critical that the system shutdown command is issued ASAP. Unfortunately, it seems that this poweroff delay is hardcoded into the board's firmware. If your shutdown sequence takes longer than 1-2sec (e.g., if you mount network drives that need to be flushed and umounted, for instance), it would be better to avoid using the case's power button to initiate a shutdown. As I am, at the moment, away from home during the next week, i cannot check the time for multiswitch.sh shutdown on my setup & if maybe the only safe way to perform a shutdown via multiswitch.sh initiated by the argon1 script would be using the double tap call (Edit: At least that would take away the 21..22..23...(24.25)...counting fear) P.S.: At least for my retroflag cases (Raspi3B(+)) multiswitch.sh is still in the "sliced bread"-(of usefulness)-league ;)

@drakaen391 About your posted codings.... Does the wait command works in your case? @mediamogul and his while-loop by monitoring PID status is imho better ... wait can only be used on child processes out of the own subshell

@psb The poster hasn't been on this forum for 1 year and bumping old topics is bad forum etiquette. If you have a question, then open a new topic and ask away - don't re-open years old topics.

OK bought everything and built it and it works great. 2tb harddrive would not fit but the 1 tb one does : ) whats words without pics. so here ya go. deleted case ethernet port,case door hinges came out for room, glued closed. had to put dedicated power to the hd to spin right so extra usb port grafted to the drives power wires while data wires go to pie. runs cool enough 50 degrees-ish so far. case closes tighter than pics when screwed together. just took some quick snaps to share. think it turned out pretty good.

@cyperghost ok I figured it out :) it's a little bit of a bug but totally fixable. ES uses both gamelist.xml found at /opt/retropie/configs/all/emulationstation/gamelists/"console"/ and /home/pi/RetroPie/roms/"console"/ so if there's no gamelist.xml in the console folder under roms, it will use the one found in configs. for some reason it doesn't remove entries, only adds them. it will also not untag favorites if you DO have a gamelist.xml in your roms but DON'T have an entry in your gamelist.xml for the tagged favorite game. Best word of advice: scrape like you've never scraped before lol

@matalog I'm not very firm in python. But take a look to this link https://raw.githubusercontent.com/LowPowerLab/ATX-Raspi/master/shutdownchecksetup.sh and to this link https://lowpowerlab.com/guide/atxraspi/assembly-install/ shows how to use a timer to differ button event between shutdown and reboot in accordance of button press time. I think that is your demand....

Solution: Copied emulationstation from /usr/bin to /usr/local/bin and things worked as normal.

@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

@tictac_93 This works in most cases ... yes But look. You take PID of runcommand and use pkill -P switch to kill child PID. That works in most cases but some emulators also just call annother process and this won't be catched by your method. You need at least annother pkill -P call. You should just use your python script and you can use the multi_switch and it's command line options. Therefore use a python call like output = int(subprocess.check_output(['./multi_switch.sh', '--es-pid'])) and you can check if ES is running. If the ouput is 0 then python interprets this as false if a PID is detected the value is grater than 0 - this interprets python as true. So the sniplet in python itself would be look like this. if output: os.system("./multi_switch.sh --es-poweroff") else: os.system("sudo shutdown -h now")