@deltagemini Strange but good it's resolved!

@mitu amiga.opt removed and looks like it works with menu widgets enabled,will test it

@mitu can I add this manually?

Not likely, the version used in Batocera is further modified than the RetroPie's fork and it's not a matter of configuration.

Or recommend to developers of retropie/emulation station to add this function?

Sure, you can add a request.

If a hotkey_enable button or key is defined, no hotkeys will function unless the "enable" button is also pressed at the same time.

By default, there is no hotkey_enable keyboard key defined. With only the keyboard connected, the hotkeys will work individually.

But when you connect a USB gamepad, that gamepad's autoconfig is applied. The autoconfig does define a hotkey_enable button on the gamepads (usually Select).

In order to use keyboard hotkey functions when the gamepad is connected, you must either:

press the gamepad's hotkey_enable button while you press the keyboard hotkey key, or define a keyboard hotkey_enable key and use that, or remove or #disable the hotkey_enable function from your gamepad's autoconfig (you'll also need to remove or disable all other hotkey functions that share a button with any game action buttons), or unplug the gamepad.

Hotkeys only work on the keyboard or on P1 gamepad. If the gamepad is anything other than P1 it won't work, but it still defines the hotkey_enable so you still have to use it, one way or another, while the pad is connected.

@standarsh14 said in RetroArch won't distinguish between two controllers:

It seems like either controller will work with one registered bluetooth connection - which confuses me because I thought that with separate Serials, only the one registered would work.

That's unexpected, the controllers should have different MAC addresses (they appear in the pairing dialog) so the OS would be able to tell them apart and some pairing info to be also stored on the device itself. Deleting the device from the list of paired Bluetooth devices in RetroPie should force the gamepad to be re-configured.

With both devices connected, can you run

cat /proc/bus/input/devices

and post the output ?

You can also test with jstest if the controllers are acting separately. Run:

jstest /dev/input/js0

and press the buttons on 1st, then on the 2nd controller. Only one controller should yield any events/output on the test.

@dankcushions

Ah!

I'm not working with the best screen and, with black on gray, that's just looked - well it was unclear to me. 2 years ago I'd have probably remembered it, from the other system I've mentioned, but on the screen I'm using now (usually devoted to something else), it's hard to see. (I have to change terminal settings on most of my systems to use something like green on black that look like the old phosphor monitors so there's good contrast.)

Okay, I'll use that later today when I'm at over where I have that system.

(This is a temporary environment for it - I'm setting it up to send to a relative who has just moved out of his house, so this is something for him to do when he's stuck in his apartment at night, alone, without a wife or kids anymore. He has some game consoles, but has never had anything like RetroPie.)

Just wondering - is there a reason that notification is in something lower contrast like black on gray instead of something like red or green for the text? (I realize it's on a black screen, so you can't use black as a background.)

@mitu Thanks, I found it.

@mitu thanks for all you help and tuition on command line earlier. FYI the recently purchased Retoflag Controller IS detected by Retopie and it allows me to set this up. Two buttons aren't being detected in the configuration but are in jstest so one for me to delve into but think I have half a clue what I'm doing now thanks to you.

Morale of the story here is make sure you purchase a recognised, compatible gamepad first....

@GreenHawk84 which version of Emulationstation are you running?

There has been a corner case [1], which escaped my mind in the first place, but then has been corrected by @pjft .

If your ES is below 2.10 (which I assume):

Either update to 2.10 onwards If you don't want to update use this workaround: Edit your ~/.emulationstation/es_settings.cfg while ES is not running and check the value of SlideshowScreenSaverCustomImageSource. Make it read false (you can also do it during ES is running in the Screensaver Options Menu).

Rationale: Your behaviour can happen on ES < 2.10 if you set your slideshow screensaver to use a custom image source and then switch to video screensaver (without disabling the image source flag).

Please report back if it solves your issue. And if it does, mark this topic with [solved] in your initial posting header.

[1] https://github.com/RetroPie/EmulationStation/commit/a8ccd0a75ba81b3e4af88ed3ebcfe08e57520ab6

@deskjobo

@deskjobo said in SAVE STATE STUCK AT 0% ISSUSES:

@theotherdan Thank you so incredibly much for your response. I followed both sets of steps you gave, and my results are as follows:
After using df -h my available storage is shown to be 785M out of 3.3G size.
For the command ls -al /home/pi/RetroPie/roms/ all the emulators appear to have 'pi' in both the user and group, as well as all the correct modebits.

Is 785M enough of an available storage or could that be the cause of the problem?

ps. All my roms are stored in a usb drive instead of in the sd card with the image.

@deskjobo
785M will be 785 Megabytes, so a decent amount of space. For save states, I would say that space is not an issue..
Now, since you are not using the default location for saving, you will need to adjust the process a bit.
You can look at /opt/retropie/configs/all/retroarch.cfg by running 'cat /opt/retropie/configs/all/retroarch.cfg'. This file should show you where the save states and saves games are stored:

#Save all save files (*.srm) to this directory. This includes related files like .bsv, .rtc, .psrm, etc ...
#This will be overridden by explicit command line options.
savefile_directory = "/media/usb0/savefile" <--

#Save all save states (*.state) to this directory.
#This will be overridden by explicit command line options.
savestate_directory = "/media/usb0/savestate" <--

Based on the output, and where the USB device is loaded, you will have to append the command to meet it:

sudo chown -R pi:pi /media/usb0/<emulator>

Let me know how that turns out.

Use the Show IP entry in the RetroPie system and it will show you the available network adapters, with their MAC:

...
3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DORMANT group default qlen 1000
link/ether dc:a6:mm:aa:cc brd ff:ff:ff:ff:ff:ff

The apidocs are also available at https://retropie.org.uk/api/.

@sleve_mcdichael Thanks! Removing those lines fixed it.

I am looking for an older lr-flycast core for RPi3 B+ , if anyone has it, please share it. Thanks.

@theotherdan

Thank you. This was caused by the environment though. I was booting into PIXEL desktop before launching EmulationStation. This configuration prevents quite a few things to function as expected.

How do I know when it's finished updating, since I can't see anything? I have SSH setup, but no way of viewing the local output that I know of.

Check the latest log file under $HOME/RetroPie-Setup/logs, every install/update has a log file.

How do I prevent my monitor doing this again?

What kind of monitor do you have ? Does this happened before or just this once ?

@sleve_mcdichael Thank you, that was helpful. Finally getting my head around the quirks of Retroarch and managed to get it working :)

@tinyunknown156 The weirdest thing here is that you are gonna use a mame version from 22 years ago on a pi4 : the older the glitchier. While mame2003+ has a good balance between supported games, fixed bugs and performances on a pi4, the same is not true about the other vintaged mame cores from over a decade ago.

@bk said in Sound not working with HifiBerry:

Concerning the alsamixer, I assume I have to type "alsamixer sndrpihifiberry" or "alsamixer snd_rpi_hifiberry_dac"? If so, both give me "cannot open mixer: No such file or directory".

No, you should just type alsamixer and note the mixer's name (4th row on the top left menu). For instance, in the screenshot below the mixer is named Headphone.
6e169b26-75f2-459a-8dc8-8f15484be18f-image.png.
However, based on the error you're receiving (cannot open mixer) it looks like the device has no hardware volume control (mixer). You may be able to add a software volume control, following the instructions from this page.

@nifmus Were you able to fix it? I just found it.
Changing the line in autologin@.service doesn't change anything with the prompt. (I changed the autologin to username USER and it didn't change)
The system is still looking at the original autologin in the getty folder.
If you modify it there, it will take.
/etc/systemd/system/getty@tty1.service.d/autologin.conf
Not sure if it's even reading autologin@.service