Mausberry Shutdown Script Doesn't Save Metadata

meleu

@cyperghost I found the problem: that line from runcommand.info has some double quotes wich is confusing the pkill. Here's my current solution:

rcinfo=/dev/shm/runcommand.info
[[ -f "$rcinfo" ]] && pkill -f -9 "$(sed -n 4p "$rcinfo" | cut -d' ' -f1)"

I tested on my retropie here and it seems to work. Please test it when you have a chance.

Cheers!

hansolo77

You guys are just talking gibberish again. For somebody who's unfamiliar with all of this, I'm completely lost. RetroPie is only my 2nd ever Pi project, and really only my first exposure to the scripting side of it. I'm eager to learn, but throwing out seemingly random lines of code without reference or instruction on where to place it doesn't help me any. :) No biggie, I'll get there. I'm just totally unfamiliar with the commands. set sed, IFS.. totally new to me. I only just learned about top like 4 days ago. ^_^

So tomorrow after work, would you rather I test @cyperghost's v1.4 or replace that section with @meleu's? Or would it be better to just wait and let ya'll hash it out some more?

meleu

@hansolo77 haha... sorry for the nerdy stuff. :)

my suggestion is to try this:

espid=$(pgrep -f "/opt/retropie/supplementary/.*/emulationstation([^.]|$)")
if [ "$espid" ]; then
    [[ -f "/dev/shm/runcommand.info" ]] \
    && pkill -f -9 "$(sed -n 4p "/dev/shm/runcommand.info" | cut -d' ' -f1)" \
    && sleep 4
    touch /tmp/es-shutdown && chown pi:pi /tmp/es-shutdown
    kill $espid
fi

hansolo77

Ok cool. I'm going to bed soon so I will test this tomorrow when I get off work. If not right away, I'm off Thursday, so plenty of time then.

cyperghost

@meleu
You can even improve :)

Edit runcommand-onend.sh and add

sudo rm /dev/shm/runcommand.info

or make PR to runcommand.sh :)
Because runcommand.info isn't removed if emulator ends by start+select button :) It isn't really needed but it's a nice cleanup and definates the addition to the GPIO script you made with more sense.

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.