I think it's a bug - already reported to the lr-prboom project here.

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.

To me Pole Position I and II both work fine with lr-mame2003. Check configuration here.

I am using 2 iBuffalo SNES controllers plus an arcade stick too, which are connected all the time through usb. And I don't have this problem, just saying it. What I don't understand, why do you use xboxdrv? These gamepads are working out of the box. I also use RetroPie joystick-selection script, which lets you set the gamepads as player 1, 2, 3, 4 in what order you want. After restart, this selection remains. Now, when I think back, I installed this because I had the problem after restart the order wasn't fixed without this script. It was randomly changed. This script gives fixed order, either system wide or even different settings for each emulator. Not sure if I did understand your problem and if you already use this script.

@mitu said in Choose Emulator & Video mode screen menu now bugging?: To quiesce those messages, either start the script independently (not part of the autostart.sh) or redirect the script's messages to /dev/null: my_script 2>&1 1>/dev/null & Thanks, yes i add this to hide the script messages. And i add the line before emulationstation, like that it works. I don't understand before that this file output are appearing on the user's terminal. sudo bash -c 'echo 1 > /sys/module/bluetooth/parameters/disable_ertm' python /home/pi/retropie_bgm.py 2>&1 1>/dev/null & emulationstation

But I was enjoying my forum vacation!

Blimey, blimey, blimey, blimey, blimey and blimey again! I swear that I'm not a paranoid schizophrenic, but I deleted the config files in /opt/retropie/configs/mame-mame4all/cfg/ rebooted a few times and the erroneous behavior was gone and my settings were not gone even though I deleted the settings files... Now for that weird behavior from pcsx-rearmed. Maybe that will disappear itself too.

I got the same crash with another game in another system: Alex Kidd in Shinobi World (USA, Europe).sms. Renamed it to Alex Kidd in Shinobi World (USA).sms and the problem went away. The only common thing I found is that they both don't have either image or video, in the middle of other games that do. My current theme (Chicuelo) displays both image and video.

Hi, There are free utilities that can search an entire folder and remove that one character from all file names. Pretty sure it’s called Bulk Rename Utility. I used it to tidy up all my file names Dwarfboysim

@joabro One possibility: usually ROMs are either European or American, and these regions have different video systems compatible with the TVs of their respective markets. The former games are PAL 50Hz, meaning they refresh at 50fps. The later are NTSC 60Hz and refresh at 60fps, running slightly faster. So one possibility is that if you are from an European country and are loading a set of US ROMs, you may have this perception that it’s all a bit too fast (and they are, indeed, faster than you remember). If that’s the case, I’d say stick to them as this is how the games are meant to be played. People prefer US ROMs even in Europe, so much so that even Nintendo have loaded their European mini consoles with American versions of their games.