Wired SN30 Pro not detected

Stuffu

@mitu I restored es_input.cfg so everything is fine there.

None of the libretro emulators work, when launching a game, a black screen appears and then quits back to the emulator. Nothing odd in runcommand.log but it's for sure related the controller settings.

When wired, the controller is identified as Xbox 360 controller and libretro works. When wireless the controller is identified as SN30 Pro and no libretro emulators work.

Just to clarify, this was also the behaviour prior to removing es_input.cfg

As I mentioned earlier, if this is something only affecting me, it's not that important and I know you have better things to do instead of troubleshooting this :) I can go back to Switch mode and just sit very close to the RPI :)

mitu

@stuffu said in Wired SN30 Pro not detected:

None of the libretro emulators work, when launching a game, a black screen appears and then quits back to the emulator. Nothing odd in runcommand.log but it's for sure related the controller settings.

Shouldn't be, since RetroArch can work even without a controller. If you get a verbose log, post it on pastebin.com

When wired, the controller is identified as Xbox 360 controller and libretro works. When wireless the controller is identified as SN30 Pro and no libretro emulators work.

Does RetroArch pops up a notification saying that the controller is detected, but not configured ? If so, the auto-configuration file is missing - that's created automatically by EmulationStation after the input configuration. You can check in /opt/retropie/configs/all/retroarch-joypads and see what configuration files are there, there should one for each controller type (name) you have configured in EmulationStation.

Stuffu

@mitu In the verbose log there is something odd. https://pastebin.com/6ZzDcBwC

[INFO] [CONTENT LOAD]: Loading content file: /home/pi/RetroPie/roms/nes/Super Mario Bros. (JU) (PRG0) [!].zip#__MACOSX/._Super Mario Bros. (JU) (PRG0) [!].nes
[ERROR] [CONTENT LOAD]: Could not read content file "/home/pi/RetroPie/roms/nes/Super Mario Bros. (JU) (PRG0) [!].zip#__MACOSX/._Super Mario Bros. (JU) (PRG0) [!].nes".

I don't see any reference to macosx somewhere in any file but this doesn't seem to have anything to do with the controller... Seems there are two different problem that at first seemed related but aren't...

There is no RetroArch popup saying it's not configured. I noticed the names of the different inputs when configuring wired/wireless.

Also, there are both 8Bitdo SN30 Pro.cfg and Microsoft X-Box 360 pad.cfgin retroarch-joypads

mitu

@stuffu said in Wired SN30 Pro not detected:

@mitu In the verbose log there is something odd. https://pastebin.com/6ZzDcBwC

[INFO] [CONTENT LOAD]: Loading content file: /home/pi/RetroPie/roms/nes/Super Mario Bros. (JU) (PRG0) [!].zip#__MACOSX/._Super Mario Bros. (JU) (PRG0) [!].nes
[ERROR] [CONTENT LOAD]: Could not read content file "/home/pi/RetroPie/roms/nes/Super Mario Bros. (JU) (PRG0) [!].zip#__MACOSX/._Super Mario Bros. (JU) (PRG0) [!].nes".

Yes, it's unrelated. The .zip file contains a __MACOSX folder, usually added by the Finder in macOS to store additional data about files and RetroArch tries to load the first file from the archive, which happens to be ._Super Mario Bros. (JU) (PRG0) [!].nes. You should either unzip the archive and use the .nes ROM or clean up the .zip file(s).

Related to the gamepad not working in RetroPie setup, a similar thing happened to me because of the same Finder behavior. Editing/opening a gamepad .cfg in the macos Finder would create a similar file in /opt/retropie/configs/all/retroarch-joypads (._8Bitdo SN30 Pro.cfg), which would be picked by the joy2key (the utility that translates the gamepad inputs to keyboard keys and thus enabled navigation of the setup scripts with the gamepad) and would render the gamepad navigation unusable. Check for any ._XYZ.cfg files in /opt/retropie/configs/all/retroarch-joypads and remove them - you'll need to use Linux for that, since the Finder won't show them.

Stuffu

@mitu

Yes, it's unrelated. The .zip file contains a __MACOSX folder, usually added by the Finder in macOS to store additional data about files and RetroArch tries to load the first file from the archive, which happens to be ._Super Mario Bros. (JU) (PRG0) [!].nes. You should either unzip the archive and use the .nes ROM or clean up the .zip file(s).

Oh no, this is a disaster... But I don't really get it. The .zip files did work before and are untouched and unzipping them (also showing hidden files) just shows the .nes file, nothing else. Could it be something else? (fingers crossed)

Related to the gamepad not working in RetroPie setup, a similar thing happened to me because of the same Finder behavior. Editing/opening a gamepad .cfg in the macos Finder would create a similar file in /opt/retropie/configs/all/retroarch-joypads (._8Bitdo SN30 Pro.cfg), which would be picked by the joy2key (the utility that translates the gamepad inputs to keyboard keys and thus enabled navigation of the setup scripts with the gamepad) and would render the gamepad navigation unusable. Check for any ._XYZ.cfg files in /opt/retropie/configs/all/retroarch-joypads and remove them - you'll need to use Linux for that, since the Finder won't show them.

I will look into that as well.

Thanks for the suggestions and help here, invaluable as always! :)

G30FF

@stuffu As someone who also owns this controller (well, SN30 Pro+) and tend to use it wired, I tend to use it in D-input/Android mode (Start+B). It works just fine for me, with all buttons working correctly. It uses the same mapping as when it's connected via Bluetooth in this mode.

As someone who also uses a Mac, I have encountered this problem before. Zipping files with the right click -> Compress action in Finder will zip up hidden files like __MACOSX. Unzipping a file created in this way on MacOS will not show the hidden __MACOSX folder. I had a bunch of files created like this (romhacks mostly) that stopped working after a recent RetroPie update with all OS packages. I assume it's an update for Retroarch that caused it to no longer work. Fortunately, you can clean up your zip files created like this by opening Terminal and running the following command:

zip -d "FILE.zip" __MACOSX/\*

That will delete the __MACOSX folder and all contents from the specified ZIP file. Zipping files using the "zip" command on the command line will avoid zipping hidden files like __MACOSX or .DS_STORE in the first place. You could also create a shortcut in Automator that will let you compress files without hidden metadata files from the right click menu.

Stuffu

@g30ff Thanks for responding and for the suggestion! I suspected that something changed recently that made this problem occur. Will try out the Start+B option as well as the zip files. However, I have a lot of zip files! :) Can you apply it to all .zip files in a specific folder?

G30FF

@stuffu I have tons of zip files as well, so I wrote myself a shell script to do it for multiple folders. If you know how to use shell scripts, take this script, and save it as a .sh file. I've used it myself, but run at your own risk.

#!/bin/bash

for d in ./*/ ; do
	cd "$d"
	for zipFile in *.zip; do
		echo "Cleaning up ${zipFile}..."
		zip -d "${zipFile}" __MACOSX/\*
		echo "Done"
	done
	cd ../
done

echo "All done."

Assuming your rom folder is organized, for example, /roms/nes, /roms/snes, /roms/megadrive, etc., you would place the shell script in /roms, and then run it. The script will check all subfolders of the current directory for zip files and run the cleanup command on them, if they have __MACOSX folders contained in them.

ClassicGMR

This probably won't add anything to the conversation but here's what happened to me today - sounds almost the same.

My older SN30 controllers were connecting via Bluetooth and in Emulation Station they would work fine. All buttons did what they were supposed to. When I tried to play a game with them the D-Pad worked BUT ABXY weren't even registering and for some reason START was acting like B. Turns out my controllers were on 3.00 Firmware. I updated them to 4.20 (looks like the SN30 Pro latest firmware is v1.34), deleted the Bluetooth entry, rebooted and then paired them again using the 8BitDo guide. Now they work exactly as they should. It was just a firmware issue for me. I didn't see it mentioned in the thread so just putting in my 2 cents. :)

Good luck!

Stuffu

@classicgmr thanks for the input, i think I have ruled out fw as the issue. Mine is on latest 1.36. But always good with some alternative options. any help is welcome :)

Stuffu

@g30ff YES! That was the best advice someone could give me at this moment! It worked! Big thanks!

Edit: Regarding the shell script. Should have quoted...