@sleve_mcdichael Thanks for confirming!

@twalls

Hello....
Your thread is probably one of the closest that I can find online for my issue. Any help would be great...

I've built 20 or so arcade 1ups with raspberry pi 3b+ and ran into this problem on the latest NBA Jam build with 4 players. Probably 50% of the time the arcade boots I get a message directly after the emulators load (right when it says done) that emulation station crashed. Talks about changing the theme and if it's the first time loading retropie, etc. Screenshot_20210917-210224_Photos.jpg

I use the same image for every one of my arcades, 4 player and 2 player and have never ran into this problem. I've changed out everything....usb cables, encoders, raspberry pi, surge protector, tried a different outlet, changed the theme, etc. Nothing helps. Sometimes it boots normal and perfectly, but I'd say half the time I get the crashed message. I've tried doing one encoder/joystick at a time and it works fine...all the way up to 3 encoders/joysticks, but when 4 are connected that's when it randomly does it. I've noticed that after I turn on and one of the encoders flashes (red light) instead of staying on is when this happens. And it's random each time of which encoder flashes. Like I've said though, I changed out all the encoders, cables, pi, surge protector. I'm at a loss here and is driving me crazy. Any help would be greatly appreciated. Thanks in advance!

I too notice this error. It looks like a couple things just need a little tweaking in the metadata area. Text wrapping and some spacings.

Thanks again @mitu - You're a life saver! :)

@hiulit

honor to whom honor is due
Goethe (1749-1832)

@erayman Not a bother, and I'm sorry that that is the answer. :|

@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")

Those fields are not shown on current carbon (can't remember if they were on an earlier version).

@sphirst That's why it isn't recording it then dude. I had a similar issue when editing some metadata on a couple of roms. Came back and my changes had reverted. A clean exit from emulationstation resolved it though.