@mitu argh! Fantastic - thank you! It was indeed the incorrect x character. 2 Player Virtual Fighter on the arcade cabinet here I come

@tango said in SDCard Unreliable - Move all RP to USB card? Or fix SD?:

Or does it do that because I have no boot sector or boot programs on my USB stick?

If you haven't programmed the OTP bit for USB boot, the Pi will always boot from sdcard.

@jambo069 said in Flycast hotkeys for retroarch:

So should I just delete the retroarch cfg and see how it goes?

Rename the retroarch.cfg from the dreamcast system (/opt/retropie/configs/dreamcast) and then immediately re-install lr-flycast, this will re-create the default configuration for the system.

There is some configuration that can be done by modifying the ALSA configuration file ($HOME/.asoundrc), but looks complicated and there's no 'one-size-fits-all' solution (depends on the devices present on the system).

You could try installing PulseAudio and configure the module-combine for simultaneous output.

@yfzdude said in Should i get Debian x64 ?:

@crush
Dolphin does require a 64-bit operating system. To fix that you need to reinstall using the x86-64 or amd64 version of the installer or image.

When any documentation here mentions x86 it is simply using it as a term to indicate PC/Laptop hardware as opposed to ARM based hardware.

Ok thanks, i had misunderstood then, and you're right, it works fine now on the x64 distribution.

Check if you haven't got PulseAudio installed. If you go into the Audio settings in RetroPie - does it show PulseAudio at the top ?

@questionmark said in Splashscreen images not displaying | omxiv erroring out:

So will this cause performance to dip?

No, it will not.

In case anyone googles and finds this ... I did get to the bottom of it by looking into the source code (by source code I mean the RetroPie ES version, stable branch)

You can see here in VideoPlayerComponent.cpp where it launches omxplayer with a bunch of args:

VideoPlayerComponent.cpp:

// Run the omxplayer binary execve("/usr/bin/omxplayer.bin", (char**)argv, (char**)env);

Now if you fire up ES, launch the screensaver, and take a look in the process list while its running (in ssh session, ps -ef) you'll actually see all those args, something like this in the process list:

pi 2143 1 7 01:16 ? 00:00:08 --layer 10010 --loop --no-osd --aspect-mode stretch --vol -3885 -o alsa --win 0,0,800,480 --orientation 0 /home/pi/RetroPie/roms/neogeo/media/videos/trally.mp4

What I noticed is the volume is set to -3885. Now if I run that on the command line to simulate the screensaver I can play with the volume. For omxplayer, volume 0 should be 100% as it's measured in millibels according to the omxplayer help.

So I quit es and ran this:

omxplayer.bin --layer 10010 --loop --no-osd --aspect-mode stretch -o alsa --vol -0 --win 0,0,800,480 --orientation 0 /home/pi/RetroPie/roms/neogeo/media/videos/trally.mp4

ok great I can hear it now! I researched %vol to db and the formula is db = 20*log(%vol) and that checks out because I had es at roughly 65% volume which equates to about -3742 millibels.

So I went back into es and set the volume to 100%, and now I can finally hear it on a default RetroPie install. The issue is the drop off is really steep (must be some bug in omxplayer on pi, that their millibels to volume curve is off) because if you set the volume level at say, 60% you won't hear much of anything from the speakers. I think this is also compounded by the fact that when you're playing around with the audio settings in es, many times it resets the volume back to zero because it's trying to sync up the level with alsa.

Anyway, hope this helps someone get their head around the screensaver audio.

p.s. also, in es audio settings, make sure you set the "omx player audio device" to alsa (or whatever works on your pi, or in your command line experiments), as that drives the argument sent into omxplayer above.

Well I finally found another image viewer that lets me specify something to display on the second hdmi port: vlc!

But although it worked fine on FKMS, nothing showed up when I ran it with KMS... not sure if I’m doing something wrong or if that is expected.

@roslof
I have the exact same problem but I can't find mame 2016 folder under the bios folder on my image-virtualman 128gb arcade but it must be there as it is an option to use to open the rom file!
Any idea why, or where it could be??

M

@greenhawk84 to be clear they’re never going to fix dispmanx/omx support. these utilise features of the original closed source gpu firmware that they have replaced with an open, more standard linux solution. it’s not all bad news, though, as there’s typically an alternative solution (eg vlc rather than omx, but you may have to re-encode/replace your videos).

Parallel-n64 barely works on raspberry pi and it looks like it's having segfault issues again. I would try out lr-mupen64plus-next if I were you as it is much more compatible with raspberry pi and it also offers 64DD support iirc.

@mitu Thanks again for your help.
It appears to be every Emulator, nothing is working now. Will start again and hope it works.

Update your Retropie-Setup script - make sure you're using the latest version - and see if you get the same issue during update.

@citaria that's great 👍

@uberlumby I have one img for CRT and composite. If possible Go to my Chanel on YouTube, have link to download.
Chanel name: Granny Games.

@bmjohnsn said in White and grey screen when opening emulationstation:

@mitu said in White and grey screen when opening emulationstation:

@bmjohnsn said in White and grey screen when opening emulationstation:

lvl2: EmulationStation - v2.0.1a, built Mar 4 2021 - 19:57:50

That's not the RetroPie version. You may be installing it through RetroPie-Setup, but you're starting another version.
RetroPie maintains a fork of the original EmulationStation, which is installed in /opt/retropie/supplementary.

How exactly are you starting EmulationStation ? When installed via RetroPie-Setup, the main binary is in /opt/retropie/supplementary/emulationstation/ and an emulationstation script is copied in /usr/bin. Check if the script points to the correct EmulationStation binary.

You are right. When I run EmulationStation from the /usr/bin folder, it runs correctly.

That poses another question... When I call 'emulationstation' in the terminal, how can I get it to point to the right script?

Actually, I found the version that was running incorrectly in /usr/local/bin.

Upon deleting emulationstation from this folder, all works well.

Thank you for your help!