Mausberry Shutdown Script Doesn't Save Metadata

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! :-)

hansolo77

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 valid true 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? :)

meleu

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

Exit from ES normally after playing a game
FAIL - Metadata did not save (although system did shut down)

Did you succeed saving metadata in this scenario with some other script?

I'm asking because several posts above I said that killing ES wouldn't save metadta and, If I understood well, @cyperghost said that you succeeded.

I think I misunderstood his answer.

anybody know how to make a profile in Putty so it can automatically log in

Maybe this can help.

lostless

@meleu I can confirm the 1.2 script works fine if you shut off from emulation station. But not from game

meleu

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

@meleu I can confirm the 1.2 script works fine if you shut off from emulation station.

Just to be really sure: "works fine" means "saves all new games I added to Favorites and/or Last Played", right?