@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

Ok, I give up. The request was simple and would give developers early feedback on real world performance with each release, which seems to be of some value, based on the feedback above on rev 4.3. It would also allow newbies to quickly check their setup against a standard benchmark and take away a lot of subjectivity, saving them and the support team countless hours of chasing problems that do not exist.

Good luck,
MML

@caver01 ok. I was lazy in my wording. It doesn't make me want to read it. It's obviously / hopefully the right log file.

@jonnykesh I don't think you were being rude. I appreciate your help. Don't worry, I am not that sensitive. All advise is helpful.

@nwgalloway So you had the es_systems.cfg in /home/pi/.emulationstation?

If you do, any new system you add will not get added to that file. Just an FYI.

@dziubak how did you transfer your roms?

@morrisav10 you can also try lr-vice from experimental packages. It works great for me.

@josephzink said in system not reading nes or snes files:

Not sure where to start.

Here: https://retropie.org.uk/docs/First-Installation/

@jester83
I found the problem doing the xbox one bluetooth connect linux trick causes input issues in emulation station

@jonnykesh I thought that as well. I was able to access them on my firestick though, so it is still an issue with the pi3 kodi connection.

@meleu said in Powering off via UI while using a Mausberry Circuit:

Do all the steps I showed on that topic and try to reboot your system. Describe here what happens.

And then perform this command: sudo systemctl disable killes; sudo systemctl stop killes and reboot your system. Describe here what happens.

SO, for starters, I have already done what you prescribed in the other thread to build the service and the killes.sh. Mine is till in the ~/bin folder, which is fine by me for now. After setting the killes.sh as executable, it works great! That is to say, I can do a software shutdown from command line for instance, and it definitely saves my metadata. Favorites and custom collections are awesome. Moreover, my additional line which triggers the NPN transistor does indeed let the Mausberry circuit know that a shutdown is imminent and it properly notices the drop on the GPIO it is monitoring and it cuts power. I really like this clever solution.

It also cuts power when I initiate a reboot. That makes sense to me, and for now I am willing to live with it. The point is that software shutdown requests properly exit ES and no longer lock up my Mausberry circuit.

Seems to me, the improvement to this would be to set a conditional statement before my GPIO command to trigger the transistor such that it checks to see if this is a shutdown/poweroff or if this is a reboot. I just don't know what to check to verify one way or the other--yet.

As for your command above, I initiated the command as you suggested and the system immediately did a shutdown, mausberry circuit powered off.

I emailed them. They told me it may got bent. Looked at it the card got bent, don't even know how it got bent. Sigh. Ohh well i gotta get a new card now sigh.

Could someone suggest to me a plug that is 5.1v and at least 3a?
I am having a hard time finding one that is good enough.

@djaay Like the issue says, you could configure it to unzip them in /tmpor in a memory backed folder. In Debian, /tmp is written in memory, so there is no writing to the disk.
As for the other aspect - RAM - I don't think it makes any difference: unzipping an archive to obtain the original ROM file would lead to the same memory used by the uncompressed ROM. The only - extra - memory would be taken by the internal unzipping routine, which should be easily reclaimed by the process once is finished.

@caver01 Thanks for responding!

caver01 "It does beg the question, so I will write it before someone else does: why not consider the libretro version of mame4all for those titles that require the bezel, since most of the work has been done for you?"

My reasons for staying with mame4all are:

I have a known good working set for mame4all The set works great on a non-OC'ed RaspberryPi 3 I haven't managed to get any of the libretro settings to correspond to my default old iPac2. A major issue for me. I don't like to have to spend hours re-configuring if I can help it. I like majority of the roms on my arcade cab to be listed under one menu. I know that you can use the arcade folder but lets face it re-configuring 800+ roms one at a time to work with the best emulator is a pain when mame4all just works.

That is how my mind deals with it. I would love to use the Libretro set but I haven't been able to get the key mappings right.

I was hoping that there would be a default bezel that mame4all could see and know to auto use it but I didd't think that there would be something so simple.

Thanks again!
BC

@caver01

I know it is suggested in the link above, but it looks like you missed the part about deleting the config first. After you delete default.cfg, a new one gets created the next time you launch, and that can restore the ability to use TAB.

yes.. this was exactly my original intention - disregard my second post :) if tab isn't working, delete the default.cfg as the link suggests