Mausberry Shutdown Script Doesn't Save Metadata
-
@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 :)
-
@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. :)
-
@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!
-
@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
-
@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. 👍
-
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.
-
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
-
@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. -
@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 -
@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.
-
ah okay - thx
-
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.
-
@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
-
@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.
-
@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 -
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.. -
@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)
-
And knowing is half the battle! -G.I.Joe!
-
@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! :-)
-
Testing v1.5 from here now....
- Exit from ES normally after playing a game
FAIL - Metadata did not save (although system did shut down) - Exit from running screensaver after playing a game
FAIL - Metadata did not save (although system did shut down) - Exit from playing a game (RetroArch)
FAIL - Metadata did not save (although RetroArch did close, return to ES, then shutdown.. Suggestion: shorten the wait time after returning to ES. I didn't know if it was working until it shut down lol) - Exit from playing a game (SuperMarioWar)
FAIL - Metadata did not save (although SuperMarioWar did close, return to ES, then shutdown. I also discovered that my Streets of Rage Remix game isn't working (crap) so I have to fix that soon)
Take away - Looks like the script is properly closing out of the game I'm playing and returning to ES for a shutdown, but it's not saving the metadata when it shuts that down. I wonder if it's getting hung up in the
if
functions, not finding a validtrue
and going to the bottom of the script to the original poweroff without exiting ES first...So quick question... anybody know how to make a profile in Putty so it can automatically log in (username/password) so I don't have to keep typing it every time I try one of these tests? :)
- Exit from ES normally after playing a game
Contributions to the project are always appreciated, so if you would like to support us with a donation you can do so here.
Hosting provided by Mythic-Beasts. See the Hosting Information page for more information.