It turns out that md_lbl and md_ need to have seperate size values for the "X" for some reason... it seems to be fixed now:

Should be fixed now, just update your RetroPie-Setu script and re-install (from source).

@Lolonois The PR has some users adding their metrics for the PS feature. Since then there have been more Pis released and every Pi that's more powerful than the previous one will use less cpu % while ideling. The main concept of is is that is allows switching from a vsynced rendering to an event driven rendering. It makes no sense to keep rendering the same screen if no changes are present. Thus saving cpu cycles and increasing the battery life. on PiZero there are significant savings (40-60% based on theme). I implemented this feature cos my handheld build was overheating while doing nothing but ES. Animations are not a priority on a battery life focused build and Instant PS mode almost doubled my standby time. ie time spend browsing games on ES. Please refer to the PR and https://retropie.org.uk/forum/topic/11304/testers-needed-power-saver-features-pr-172 where we have had extensive discussions and testing for the same

Thanks for providing the log file. I don't notice anything different between the 2 runs, so it's not something related to a configuration. Try removing pulseaudio completely then reboot the system, this might get rid of any PA interference.

@BuZz : I saw this menu, but it provides me only with the choices "bookmark" and "share". In fact the first post is not editable, but other ones are editable (I just edited this one)

@Styleshift Please open a new topic and add the info from https://retropie.org.uk/forum/topic/3/read-this-first. You shouldn't get the error in the topic unless you've manually downgraded the libsdl2(-dev) package.

@pamput Yes it does indeed appear to be fixed now

Yes, other games are fine. I am quite sure it's a bug and proposing a fix here: https://github.com/RetroPie/EmulationStation/pull/592

@BuZz Pi Model: 3B Power Supply used: Official Built From: on top of existing OS You’re right, it’s a custom image. I downgraded the firmware to 1.2019401-1 via rasbiantools in retropie_packages. Now everything works fine. I suppose this is some bug in the vc in newer firmware.

@webodan EDIT: OK, so I double-checked the md5s of the bios files that i have downloaded BEFORE and AFTER sending them to the pi (just in case they would get corrupted as they were sent or something) they matched on winmd5 just fine. lr-pcsx-rearmed can use only scph5501.bin from the list of BIOS files you have, and that file has a wrong MD5 in your screenshot - it's not what's in the docs or what the core expects. Unfortunately I can't get a copy of the game to test, but can you just get a RetroArch log file and put it on pastebin.com - enable Verbose logging in the Runcommand launch menu, run the game for a while, then upload the /dev/shm/runcommand.log log file to pastebin.com and paste the URL here.

@Lumbeechief081 I don't have such contraption to test, sorry, but take a look here and here for an explanation on what those numbers are and how they can be generated.

@Lumbeechief081 So, if you don't do it already, now that you've learned how quickly you can lose all the work you did is the perfect time to start making backups. 😉

@Boa are you using the standalone mupen64plus or lr-mupen64plus?

Thanks you for sharing the solution. I have fixed the link to the Libretro assets page in the Wiki, hopefully in the future this will be useful for people trying out the Game & Watch emulator.

@mitu @clyde okay thanks

@mitu Nope, I'm using the dev build on my Pi as well. And the other two setups on my PC, which worked, used the same build. I assume it has something to do with my es_systems.cfg and/or the way I've set up the dummy files. Maybe I see if I can rework the setup but like I said, I currently don't care.

Thanks for your help :-)

I ran into the same issue trying to get triggerhappy to process the VOLUME_UP and VOLUME_DOWN events from my Dell AC511 soundbar. No matter whether I set the user to run the process as in /etc/defaults/triggerhappy, or /etc/init.d/triggerhappy, it would always run as user nobody. The process would run, but because nobody doesn't have privileges, my commands to amixer would not run. The solution I found was to edit /etc/systemd/system/multi-user.target.wants/triggerhappy.service and set the user in there to pi. After doing that and restarting the daemon, the triggerhappy process ran under user pi and everything worked. Edit: Future updates my overwrite changes to this file, I don't know.