Mausberry Shutdown Script Doesn't Save Metadata

meleu

@cyperghost it can be useful for debugging. I prefer to keep it even after the emulator has finished.

cyperghost

@meleu And why do you check presence of runcommand.info in your script? Don't get me wrong but I think the filecheck only makes sense if you remove that after emulator call ends? Because you will always run the "sleep 4"-command even if you are only in ES :)

meleu

@cyperghost because if the file doesn't exist that sed will fail and print nothing (empty string).

Just for fun do the following

save all important file you have open.
perform this command: pkill -f ""
cry (well, if you saved the files you don't have to cry. as I didn't saved, I cried)

Explaining: using an empty string as the pattern matches "everything". And the result is pkilling every single process owned by the pkiller!

I noticed it on an unpleasant way. :)

cyperghost

@meleu Okay ... what about this one?
It's pretty save and finds out PID of every emulator :)

#!/bin/bash
emucall=$(sed -n 4p /dev/shm/runcommand.info)
emupid=${emucall#* }
pos=$(expr ${#emucall} - ${#emupid})
emupid=$(pgrep -f ${emucall:0:$pos})
kill $emupid

Then if PID is a true value kill first the emulator and then kill ES in seconds instance... Thank your for every suggestions - I learn really a lot of your examples!

meleu

@cyperghost said in Mausberry Shutdown Script Doesn't Save Metadata:

@meleu Okay ... what about this one?

#!/bin/bash
emucall=$(sed -n 4p /dev/shm/runcommand.info)
emupid=${emucall#* }
pos=$(expr ${#emucall} - ${#emupid})
emupid=$(pgrep -f ${emucall:0:$pos})
kill $emupid

Wow! It's a bit complex, isn't it?

Yeah, using parameter substitution is a good solution here. But I would simplify it with this:

emucall="$(sed -n 4p /dev/shm/runcommand.info)"
[[ -n "$emucall" ]] && pkill -f "${emucall% *}"

By the way, sometimes I feel like we are messing @hansolo77 's thread with all those bash snippets. I'm going t open a bash thread for us. :-)

EDIT: topic created https://retropie.org.uk/forum/topic/11900/shell-scripting-topic

lostless

@meleu i think it's all relevant. I'm a mauseberry user as well and I find it interesting that I can make it finally function the way it needs to in a retropie setup. If we can get it to quit an emulator, save the sram And then save the meta data for emulation station, the better. I'm elated that my switch now saves meta data when in emulation station. I've had to redo scrapping so many times. 👍

hansolo77

Here here! Thanks @lostless :) I knew I wasn't alone in this. And yeah, you guys are just leaving me in the dust with all these snippets. I'd love to learn how to do all that on my own too, but until I do I have to rely on you guys coming up with solutions for me to test and try.

I hate to say, I have a migraine again tonight, so I'm not gonna be much help in troubleshooting a new method/addition. But I will try to do it tomorrow since I'm off work.

NamErehWon

Correct me if I'm wrong, but it appears that the script monitoring the GPIO isn't debouncing the input. You would have to hold the button for up to a second depending on where in the sleep you hit it. This should cover debouncing and make it so you could require a hold of a specific length of time.

 #GPIO init stuff here
 previous_power = 0
 while [ 1 = 1 ]; do
    power=$(cat /sys/class/gpio/gpio$GPIOpin1/value)
    if [$power != $previous_power]; then
       sleep 0.05 #might need to be tweaked. You can make it 1s+ to require a hold
       power=$(cat /sys/class/gpio/gpio$GPIOpin1/value)
       if[$power != 0];then
          #shutdown code here
       fi
    fi
    previous_power = $power
    #you can put a short sleep here if need be
 done

meleu

@namerehwon I don't know the details about this GPIO thing, but I don't think that an infinite loop like that would be a good approach.

Maybe you can improve your script above using inotify-tools like in that script you saw on another thread.

cyperghost

@namerehwon Well that's out of our focus. We want to

Reboot ES proberly
Save metadata in all situation
2.1 In ES mode (solved with version 1.2)
2.2 If any emulator is running (@meleu and @cyperghost coproduction)

But it's a good thing to debounce GPIO keypress but is that needed?
It isn't necessary imho because one keypress will effect an action >> Reboot.
There isn't a toggeling or keypress needed. So it doesn't matter if the signal is produces 1 times or 100 times :) - my personal opinion

caver01

@cyperghost but isn't @NamErehWon saying that in the current config, because of the loop timing it may not pickup the button press unless you hold it long enough for a cycle to see it? I have noticed this with my mausberry before I shifted to a python script using edge detection.

Better detection of the button press seems like a good improvement on the script to me even if it expands the scope of the thread a little.

cyperghost

ah okay - thx

caver01

That said, once we have a better shutdown procedure, would those of us using mausberry be better served with Python than a bash loop? I have read other posts that say yes. I have also asked this of Mausberry directly, but they are not responsive on their own support forum. In any case, I don't want to hijack the progress being made hear in any way, but I wonder if others are considering Python for this too.

cyperghost

@caver01 Well I think the bash script is downloadable by mausberry so the usecase is more on the bash side. I have to agree - I never watched the GPIO part. Feel free to post your python script here. We are open for every suggestion.

@hansolo77 and @lostless

Introduction v 1.5 of the shutdown script here

Much greetings to @meleu for his great help

NamErehWon

@meleu I was going off the script that was posted earlier in the thread. It could be easily changed to use inotify to check the "file" that is the GPIO value. I haven't had a chance to play around with the inotify stuff yet, but I can write something up once I've tried it.

@cyperghost The debounce also helps with preventing unintended shutdown due to the wires/traces picking up rf and registering a high on the GPIO pin. You know, make sure you have an actual rising edge and not a blip. I know that the GPIO pins have a mode where they report back rising or falling edges, but I haven't experimented with it to see if that is debounced already. If so, then switching to checking for a rising edge would negate the need for debouncing in the script that triggers your shutdown script.

cyperghost

@NamErehWon Can you please check out. Detecting flanks on GPIO within bash would be fine. I know it works with wiringPi...
So you can speed up GPIO change detection via IRQ - but I think that will be better discussed here

hansolo77

I wonder if you guys are just making it more complicated than it has to be. I also have a reset button wired up to the GPIO to act as a failsafe way to exit out a running game. The scripts are located here:
https://www.reddit.com/r/raspberry_pi/comments/2yw4fn/finally_set_up_retropie_complete_with_a_gpio/cpdhtpu/
So why not just incorporate that into the script? Just execute the escape script then initiate the shutdown? Of course if you wanted to make it beneficial for everybody, you'd probably want to add it into the Mausberry Script. The only problem I think is the type of scripts being used (shutdown is BASH why escape is PYTHON), so I don't think you can add it into the same script all at once..

cyperghost

@hansolo77 No it isn't more complicated. You asked for a bash script. With C or python it is indeed an easy approch :) because string operations are much easier to do.

You can see the results in different codestyle if you compare mine and @meleu.
meleu use the tools (commands) every unix offers in an elegant way. I don't know so much commands so I'm poking around with stringscuts and string compare. That's exact the way you would do it in any coding language.

BASH is immense powerful in working with files and data. As in every unix system hardware/devices are mounted into filesytem you can "communicate" to these devices via file manipulation :) So for fast results you can use BASH.

Of course you can use the same bash-commands to work in python and do not need the shutdown script anymore. Or you can use commands like emupid=$(pgrep -f ${emucall:0:$pos}) to extract emulator calls. There are 1000 solutions.

Our intention is to get an ultimate shutdown without using annother process in background to finsh ES and it's emulators (if they are running) as far as I see the python code it just kills obtained PID, like we do in version 1.5 of our bash script.

EDIT:
The python script will not work for zDoom for example. Because it just asks for "/opt/retropie/emulators/" path.

@meleus intention works in this case as long as the call is initiated by runcommand.sh (and this is the normal usecase)

hansolo77

And knowing is half the battle! -G.I.Joe!

meleu

@cyperghost said in Mausberry Shutdown Script Doesn't Save Metadata:

With C or python it is indeed an easy approch :) because string operations are much easier to do.

I doubt it! :-)