System Troubleshooting

When an emulator fails to launch, you will be immediately returned to the game list in EmulationStation. Most of the time when this happens, you will find some useful information in /userdata/system/logs/es_launch_stderr.log and /userdata/system/logs/es_launch_stdout.log (also known as \\BATOCERA\share\system\logs\es_launch_stderr.log and \\BATOCERA\share\system\logs\es_launch_stdout.log from the network shared drive).

If you're having issues with only a particular system, first refer to its respective system page, as it may mention common problems and their solutions there instead.

If there's an issue with EmulationStation itself (such as the menu freezing or some function failing), ES's logs can be found at /userdata/system/configs/emulationstation/es_log.txt (\\BATOCERA\share\system\configs\emulationstation\es_log.txt from the network shared drive).

In many cases, one of these logs will contain a self-evident error message such as missing BIOS files, a bad ROM format, etc. If not, come to the Discord channel with this file, and you'll usually get some pointers as to what's wrong.

If there isn't an obvious error message and you'd like to try some things in the meantime:

  • Remove any unnecessary devices plugged into your machine and try again. This includes any additional controllers, Wi-Fi dongles, Bluetooth devices, etc.
  • Remove any custom scripts in /userdata/system/scripts/ (or rename the scripts/ folder to backupscripts/ to temporarily disable them).
  • If you are using any custom es_systems.cfg, try removing/resetting that first. This includes anything you may have set with custom overlays.
  • If using an exotic storage option (such as a NAS), try resorting back to using the userdata partition on the Batocera drive itself.
  • Your storage medium (read: a cheap USB stick) might be too slow to be usable. This is rare, but certain USB sticks can't transfer at a rate faster than 1 MB/s, which could lead to problems. This is irrelevant of what “type” of USB version it supports, there can still be crummy USB 3.0 sticks. Try again by first plugging the drive into another port, and if it still persists try with Batocera flashed to another USB stick/storage medium. Sandisk and Samsung USB sticks are typically reliable, but even they can degrade over time.
  • For weaker SBCs, you can also try turning on interface preloading in SYSTEM SETTINGSDEVELOPERINTERFACE PRELOADING. You can also try “hiding” EmulationStation in the background by enabling HIDE WHEN RUNNING A GAME in that same submenu.
  • Perform a factory reset to revert to the default settings and try again.
  • If using the official Nvidia drivers, try disabling them and use the default Nouveau drivers.

Batocera only shows systems for which games have been added. First, try adding your games and then go to GAME SETTINGSUPDATE GAME LISTS to refresh the list.

All available cores are always installed by Batocera; you never need to “add” cores. There is a compatibility chart on the main website.

If your games/systems/options still aren't appearing, check for the following:

  • That the games are in an acceptable file format. The included _info.txt file will indicate which are compatible with that system.
  • If you are using any custom es_systems.cfg or custom features es_features.cfg in /userdata/system/configs/emulationstation/, try removing/resetting that first. This includes anything you may have set with custom overlays.
  • Remove any custom scripts in /userdata/system/scripts/ (or rename the scripts/ folder to backupscripts/ to temporarily disable them), /boot/boot-custom.sh and/or /userdata/system/custom.sh.
  • If using an exotic storage option (such as a NAS), try resorting back to using the userdata partition on the Batocera drive itself.

The following systems will not work when using a NAS of any filesystem:

If you want to continue using your NAS for the majority of your games, but to use your internal storage for these affected systems so they can continue to work (not being on your NAS, obviously), save the following script as /userdata/system/custom.sh:

custom.sh
#!/bin/bash
# This allows you to still use Windows/Flatpaks even while using a NAS.
 
case "$1" in
    start)
        mkdir -p /media/SHARE/saves/flatpak
        mount --bind /media/SHARE/saves/flatpak /userdata/saves/flatpak
        mkdir -p /media/SHARE/saves/windows
        mount --bind /media/SHARE/saves/windows /userdata/saves/windows
        mkdir -p /media/SHARE/roms/windows
        mount --bind /media/SHARE/roms/windows /userdata/roms/windows
        ;;
esac
 
exit $?

Batocera v36 and below do not require the --bind option for the mount commands.

First thing to check, is to make sure you have a reference. It could just be that the game on the emulated system takes more resources than expected due to the nature of being emulated. For instance, emulating the PS2 requires a fairly beefy system, despite being an old sixth generation console. You can typically test for reference with how well the emulated game performs on Windows on the same computer, or for other devices other distributions. It's also possible to see performance for that particular game online, do your research.

Once you're sure that your game's poor performance is abnormal, and your system is ordinarily capable of much better, here are a few things you can try:

  • Reset all your settings back to “AUTO”, these use sane defaults which should perform well in most circumstances.
  • Change the graphics API being used by your emulator; each piece of hardware may prefer or run slower with any given API. This can typically be found in the system's advanced settings. Not all emulators have access to all APIs. From newest to oldest: Vulkan, GLCore, OpenGL.
  • Ensure that your audio buffer isn't being choked; if your system is unable to process audio frames as quickly as they are being produced, this could put a throttle on the device's performance. Try increasing the audio latency setting in the advanced system options.
  • Remove any custom scripts in /userdata/system/scripts/ (or rename the scripts/ folder to backupscripts/ to temporarily disable them), /boot/boot-custom.sh and/or /userdata/system/custom.sh.
  • Lower the resolution of your game. This is especially so if the system isn't normally meant to be upscaled, like fifth generation and below consoles.
  • If using Nvidia hardware and on Batocera v33 or lower, activate the official Nvidia drivers. If on Batocera v34 or higher, or using hardware other than Nvidia (such as AMD), this is all automatically handled and no action is required.

If you're still having poor performance after checking all of the above, come to the Discord server along with your logs (preferably, with a video of the low performance in action) and you should get some pointers.

If trying to use HDMI sound on a Radeon GPU, first check that you have enabled the setting in the boot line. If on a Nvidia card, make sure your official drivers are activated.

When that's all clear, first experiment with different settings in MAIN MENUSYSTEM SETTINGSAUDIO PROFILE. You should get sound immediately when exiting back to the MAIN MENU (there is background music playing by default). If you're still not able to get any sound, try also manually setting an AUDIO OUTPUT device (they change with each different profile, you need to exit back to MAIN MENU to update the list). To rigidly test all your hardware's possible audio output modes (this may take a lot of trial and error, but only needs to be done once):

  1. Go to MAIN MENUSYSTEM SETTINGSAUDIO PROFILE and select the first profile, then back out to the MAIN MENU.
  2. Go back into SYSTEM SETTINGSAUDIO OUTPUT and test all available outputs, exiting to the MAIN MENU between each change.
  3. If none of the AUDIO OUTPUT options worked, repeat steps 1-2 for a different AUDIO PROFILE. Your AUDIO OUTPUT options might change depending on the AUDIO PROFILE selected.

Batocera v32 reworked the way it handles audio, so most issues are now resolved by simply selecting the right device and profile in the settings menu. If you're still having issues or are using an older version of Batocera, audio issues is on its own page.

Batocera puts a lot of the large “virtual file system” files like hard drive images, game package installation files and compiled shaders into the saves/ and system/<emulator>/ subfolders. These can easily become in excess of several GB with the launching of multiple games for 7th gen and above systems (GameCube/Wii, PS3, 3DS, etc.). It's worth checking their folder sizes to see if they can explain unexpected shortages of free space.

Perhaps the Trash folder still has your files stored on the drive? You can clear these out by going to the file manager ([F1] on the system list), clicking Trash Can and clearing it out.

If you've already done that and still get the error, it could be that Trash Can has failed to actually removed the files. If so, you can forcefully remove the files by navigating to /userdata/system/.local/share/Trash/files, selecting everything and pressing [Shift]+[Del] to delete all the contents. You can also do this via SSH by running rm -rf /userdata/system/.local/share/trash/. The rm -rf /path/to/somewhere command is capable of destroying your hard-drive, so be very careful with your spelling on this. Batocera Nation's video demonstrating this procedure.

If you'd like to avoid this issue in the future you can tell the file manager to not use your trash folder and default to instantly deleting files. Click on Edit in the menu bar located at the top of the screen in the file manager, then go to Preferences and uncheck the “Move deleted files to “trash can” instead of erasing from disk” checkbox. Click Close to save the setting. Files that are deleted via the network share aren't sent to the trash can. Video link to this procedure.

If you were managing files from an external source such as another computer, ensure that its Trash bin is emptied as well while the drive is connected. This can usually be checked for by searching for a hidden “Trash” folder on the connected drive (this will vary for each OS):

Usage of the trash utility for removable drives can (usually) be configured from the respective OS. Most should have this disabled by default.

Open xTerminal or access batocera via SSH .

Run df -h to verify the available disks and amount of free space on each:

[root@BATOCERA /userdata/system]# df -h
Filesystem                Size      Used Available Use% Mounted on
/dev/sdb2                22.0G     20.6G      1.4G  94% /userdata
/dev/sdb2                22.0G     20.6G      1.4G  94% /media/SHARE
/dev/sda1                 1.8T      1.7T         0 100% /media/2TB

In this example, the external HD shows 0 free space and 100% used.

Run ncdu /userdata to analyse which folders and files are consuming the most amount of space.

Files can be removed directly from ncdu. Highlight it and press [D] to delete.

Now running df -h again we can finally check we have free space again!

/dev/sdb2                22.0G     20.6G      1.4G  94% /userdata
/dev/sdb2                22.0G     20.6G      1.4G  94% /media/SHARE
/dev/sda1                 1.8T      1.7T     19.2G  99% /media/2TB

It could be that you're using an extremely slow USB drive (like 1.0, though all of those are likely to have already died due to their age), have a faulty SD card, or if using a USB connected portable drive are using an cheap SATA-to-USB cable which does not support the USB Attached SCSI protocol driver (UAS).

If the latter, you can check what driver has been loaded to use your USB with the lsusb -t command. It will output something like so:

[root@BATOCERA /userdata/system]# lsusb -t
...
/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/6p, 5000M
    |__ Port 2: Dev 3, If 0, Class=Mass Storage, Driver=uas, 5000M
    |__ Port 4: Dev 5, If 0, Class=Mass Storage, Driver=usb-storage, 5000M
...

In this example, device 3 (Driver=uas) is UAS-capable, while device 5 (Driver=usb-storage) is not. If UAS isn't supported by your SATA-to-USB cable, you may experience intermittent access issues with that portable drive.

You can first check for the BIOS settings on the install Batocera page. Then, check for the following:

  • You may need to change your BIOS to allow legacy/unsecured boot, as some motherboards may only allow Windows to boot on UEFI.
  • If the system has a UEFI BIOS, and Secure Boot can't be disabled, and legacy boot is not available, see the Secure Boot page for setup instructions.
  • If the system has a Trusted Platform Module (TPM) that is enabled, Batocera v39 and higher will display Boot Option Restoration and reboot after five seconds, repeating until the required TPM Configuration is performed.
  • If using Grub bootloader on UEFI to chainload the Batocera bootloader, ensure that the correct path is being chainloaded:
    • For Batocera v39 and higher: /EFI/batocera/bootx86.efi
    • For Batocera v38 and lower: /EFI/BOOT/bootx86.efi
  • If also using Windows on the same machine, ensure that Windows isn't hibernating or otherwise holding the system access hostage by some means (fast boot, quick start, etc.)
  • Unplug any other storage devices (such as your internal drive with another OS on it) or controllers.
  • The Batocera image may not have been flashed correctly, try reflashing with Etcher and make sure the validation says “successful”.
    • If flashing the image using Windows onto a USB drive, a bug within Windows prevents it from seeing other partitions on a hardware level. If the drive initially has multiple partitions, it may need to be completely wiped first before Windows is able to completely see it. An alternative would be to flash Batocera using another operating system.
  • If using a SATA-to-USB cable for a USB hard drive or SSD (all 2.5“ and 3.5” hard drives use them, even if they hide it in the case), your cable may not support TRIM which is required to properly boot; try a different SATA-to-USB cable or a different drive.
  • Some USB drives (particularly USB 3.0 and above ones) may not be properly read/compatible with your motherboard's chipset, try another drive/port.
  • Try disabling/enabling the IOMMU setting in your BIOS.
  • Try switching AHCI/SATA/NVMe settings in your BIOS for the drives in question (some BIOS only have this as a global setting).
  • If your motherboard's EFI shell is unable to load or select Batocera's EFI partition (common on Mac hardware), consider replacing it with the more universal rEFInd Boot Manager. It's recommended to read through the entire page and understand it first before going through with the process.

Verbose boot

By default Batocera will suppress most of the boot related messages during the boot sequence. If you'd instead like to see these to help with diagnosing your boot issue, enable the verbose boot mode.

To enable the verbose mode in Batocera v36 and higher, repeatedly press the down arrow key on the keyboard while booting, and then select the verbose boot mode. You may need to hold the Enter button down for half a second to register it, as the boot menu polls for input slowly.

For Batocera v35 and lower
To do so, edit the following file:
  • For legacy boot: /boot/boot/syslinux/syslinux.cfg (if on Batocera 5.24 or lower, /boot/boot/syslinux.cfg)
  • For EFI/UEFI boot: /boot/EFI/BOOT/syslinux.cfg (if on Batocera 5.24 or lower, /boot/EFI/syslinux.cfg)

and replace the following line:

MENU SHIFTKEY

with:

MENU HIDDEN

Then, when next booting Batocera, rapidly press the down arrow key to interrupt the boot and open the syslinux menu. Select the verbose option (or press the hotkey [V] on the keyboard) to boot in verbose mode.

Be careful when editing this, as the boot command needs a very specific syntax. Any additional new lines or spaces that your editor might add after pasting could interfere with booting successfully. Make sure to back up the file first just in case!

If accessing Batocera over SSH or through terminal, don't forget you need to put the /boot/ mount point in write mode first.

Legacy boot

On x86_64 legacy boot systems, if the file /boot/boot/syslinux/ldlinux.sys is modified in any way, a situation may be created where future modifications of any kind to the BATOCERA /boot partition (including Batocera version upgrades/downgrades) may trigger a black screen at boot with the message “Boot error”.

To recover from this:

  1. Boot from a Linux distribution on another drive (procedure was tested with the live installerubuntu-23.10.1-desktop-amd64.iso)
  2. Get to a root shell (“Try Ubuntu”, start a terminal, sudo -i)
  3. Attach the Batocera drive, if not already attached
  4. Ensure that the Batocera boot partition is not mounted: umount $(blkid -L BATOCERA)
  5. Ensure that the “syslinux” package is installed. For a Debian or Ubuntu system: apt install syslinux
  6. Reinstall the bootloader (Note: It's OK if this produces warnings like “Hidden (2048) does not match sectors (63)”): syslinux -i $(blkid -L BATOCERA) -d /boot/syslinux

This is for if you're struggling to even boot on an SBC, which is a rare occurrence (SBCs tend not to be nearly as modular as standard desktop PCs) and usually only caused by hardware faults/external factors. Here are some general troubleshooting steps to try:

  • It could be running undervoltage and failing to boot (the most intensive task for the CPU). First try unplugging any external USB devices you may be using, including external hard-drives, USB mice/keyboard, controllers, Ethernet cable, etc. Ensure that you are using the official recommended power supply for your SBC.
  • Disable any network shares you may be trying to use.
  • Remove your game's metadata (gamelist.xml and the images and videos folders from the roms/<system>/ directory).
  • As a final resort, try re-flashing the SD card. Some users have reported that a complete reformat of the card to a blank state was needed before Batocera would start booting on that card.

Since the graphics drivers aren't loaded at boot the splash video is rendered entirely on the CPU. If you have either 1. an absurdly high resolution display like a 4k TV, 2. a really weak CPU to begin with then this could cause the boot video to lag. You can solve this by forcing the splash video to render at a lower resolution (say 1920×1080 or 1280×720) by editing the configuration file.

splash.video.resize=1280x720

This can be done in either batocera-boot.conf or batocera.conf.

This is for the less common problem of the small range of AMD Radeon GPUs in the RX 200 and RX 300 series (Southern Islands SI and Sea Islands CIK) choosing the older radeon driver instead of the newer amdgpu. The radeon driver is not compatible with Vulkan, while the amdgpu is.

If you're finding the performance of the automatically chosen radeon driver to be acceptable, no action is required! This is only for if you have very specific needs and don't have a more modern card available to do it with.

By following this procedure, you are going to force Batocera to use a particular driver at a kernel level instead of allowing it to choose the most appropriate driver. By doing this, you may encounter video/audio glitches/absent features, it is not recommended and not needed in most cases (refer to the tip above).

Please note, RX and R cards older than the R7 240 just do not support the amdgpu drivers, period, and doing this while using them will result in your graphics card not being used at all.

Edit the syslinux.cfg as instructed for turning on Radeon HDMI audio, but instead of radeon.audio=1 append this:

radeon.cik_support=0 amdgpu.cik_support=1 radeon.si_support=0 amdgpu.si_support=1

If you are not getting sound output via HDMI after doing this, then you may also have to append this:

amdgpu.dc=1

First, check the supported controllers page. If you're using a controller not listed there, it should still work however, but there may be undocumented issues.

Check the following:

  • Ensure that controllers.bluetooth.enabled=1 is present and not commented out in your system/batocera.conf file.
  • Make sure that you've put your controller into its “Pairing” mode. This differs between controllers, but usually involves holding down a few buttons as you turn on the controller.
  • If failing to re-pair a controller, that you've cleared the previously remembered controllers from memory.
  • That there is no significant wireless interference, such as USB 3.0 drives, Wi-Fi routers nearby, microwaves turned on, a large sheet of metal, a dog barking really loudly, etc.
  • That you're only using one Bluetooth interface. eg. if you have an on-board BT module and a USB-connected BT dongle, they might disrupt each other.
  • Turn off other wireless interfaces such as Wi-Fi.

You can disable a Raspberry Pi 3/4's on-board Bluetooth by adding a line containing dtoverlay=disable-bt to the /boot/config.txt file.

You can try manually connecting a Bluetooth device via SSH/xterm instead of using the menu. It could also be that the BT dongle you're using is too new and unsupported by Batocera; here's a list of confirmed working dongles.

Sometimes, a computer will keep delivering power to a USB slot even if the machine itself is switched off. Some dongles assume this means “freeze and don't work again until replugged”. Try re-plugging the dongle to “reset” it.

You should also try plugging the BT dongle into a USB 2.0 port instead of a USB 3.0 port, as some BT dongles have issues with 3.0 ports (noted in the compatible dongle list).

Some users have reported Bluetooth to stop working indefinitely if the userdata partition ever becomes completely full (such as by scraping), even after freeing up some space afterwards. The only reported solution to this is to reflash Batocera.

If your Bluetooth device complains about requiring certain binary firmware files (check with dmesg), you can put them into /lib/firmware/rtl_bt/ and run batocera-save-overlay after confirming it works.

An example of a BT device complaining about binary firmware files in dmesg:

[    1.797311] Bluetooth: hci0: RTL: firmware file rtl_bt/rtl8761b_fw.bin not found

If you've done this and it worked successfully, let the devs know so they can add it to the next version of Batocera.

First, check the supported controllers page. If you're using a controller not listed there, it should still work however, but there may be undocumented issues.

If you have the option, use a wired connection. Wireless connections have far more things that can “go wrong” to make your controller not work, whereas wired has a much higher chance of working correctly. If you'd still like to use a wireless Bluetooth connection, check the Bluetooth issues section above.

If using a third-party controller, they may have multiple “modes” that they can be put into. Try each of them, replugging the device between switching modes. Typically the X-input mode should work fine, followed by the D-input mode.

If you'd like to get your hands dirty with SSH and evtest, refer to this page for joystick issue diagnosis.

Windows has a tendency to “lock” the hard-drive that it's on when it shuts-down, rendering it inaccessible to any other operating system. Very cool. To test for this, you can perform a proper shutdown by holding down the Shift key while selecting "Shut down" from the Start menu.

To turn off “fast startup (hybrid boot)”:

  1. Open the old Control Panel (icons view), accessible from the Start menu search, and click on the Power Options icon.
  2. Click the Choose what the power buttons do link on the left side.
  3. Click the Change settings that are currently unavailable link at the top (administrator permissions required).
  4. Under Shutdown settings, uncheck the Turn on fast startup box.
  5. Click the Save changes button.

Details for Windows 8 on the eightforums. Details for Windows 10 on the tenforums.

In addition to this, there may be a setting in your BIOS configuration that also needs to be disabled. This can be referred to as “Fast boot”, “Windows 8.1/10/11 boot/feature”, “Hybrid sleep”, etc. Every BIOS is different, refer to your motherboard's manual.

Maybe you have Bitlocker drive encryption enabled? This is a feature of Windows that allows you to encrypt your drive's data such that only Windows can see it. It is not enabled by default, but it could have been unintentionally activated.

First, type “bitlocker drive encryption” into the Start menu and select the identically named option. Make sure your hard-drive says “Off” in its Bitlocker encryption status.

Additionally, individual folders/files may have been encrypted. Locate the “inaccessible” folder/file in question in Windows, right-click → PropertiesAdvanced.. and uncheck “Encrypt contents to secure data”.

If you are a Mac user, you might wonder why you see lots of files starting with ._ and that are duplicates of your actual rom files, or other files. eg. you have a 1943.zip file and next to it ._1943.zip. This is because you accessed your Batocera machine from a Mac, and MacOS leaves this files that are hidden by default under Linux, because they start with a dot, but might still appear in EmulationStation.

In order to list them all, you SSH into your Batocera system and enter:

find /userdata/ -name "._*"

And to remove them all:

find /userdata/ -name "._*" -exec rm {} \;

In case you want to share a snapshot of your system log files to help developers diagnose your machine you can use the menu SYSTEM SETTINGSFRONTEND DEVELOPER OPTIONSCREATE A SUPPORT FILE. It will generate a tarball in /userdata/saves/ named batocera-support-YYYYMMDDHHMMSS.tar.gz (with year/date/time of creation in the filename). You could also create this by running batocera-support from SSH. This tarball might contain sensitive data such as your Wi-Fi/RetroAchievements password in plain-text, so be careful of where you share it to. Your:

  • Wi-Fi SSID and password is in system/batocera.conf and system/batocera-boot.conf
  • RetroAcheivements username and password are in system/batocera.conf
  • ScreenScraper username and password are in system/es_settings.cfg

You could also just use a freshly installed Batocera that contains no such information instead to create the support file.

When things go really wrong, and you want to “factory reset” your Batocera, i.e. putting all the settings to their default values without losing your ROMs, saves and scraped metadata. There are multiple ways to do this, in order of safest to most dangerous:

  • Log in through SSH, then enter:
    /etc/init.d/S31emulationstation stop
    mv /userdata/system /userdata/system.old
    reboot
  • Shut down Batocera, plug its drive into another running OS and access the userdata partition directly. Navigate to /userdata on the SHARE partition, rename the directory system to system.old and then boot up Batocera on the intended machine.
  • Go into the file manager on Batocera. Then, rename the directory system to system.old.
  • Open the file manager so EmulationStation is not holding the system files (if this is not possible, then close EmulationStation via SSH: /etc/init.d/S31emulationstation stop). Then access the userdata partition from the network, navigate to /userdata, rename the directory system to system.old and immediately reboot.

Upon (re)boot, all your settings will be cleared out to their default values. You'll have to re-enter some parameters like your Wi-Fi credentials and so on… or, you can look at what you have in the previous configuration files in the /userdata/system.old/batocera.conf file and all the files in the /userdata/system.old/configs/ folder. Reinsert your settings one by one until you come across the one that causes the issue. This way you can set up your previous configuration without re-entering everything (in particular for batocera.conf, you might have many options set in there), excluding the setting that causes the issue of course.

It is also possible to “undo” a factory reset by copying and overwriting the files in system.old back into the now current system folder.

If not even this resolves your issue, as a last resort you can try re-flashing Batocera. This will obviously wipe all of your userdata (ROMs, saves, etc.) in the process (if stored on the same drive).

Here are a few other topics with notable troubleshooting sections:

  • troubleshooting.txt
  • Last modified: 4 months ago
  • by maximumentropy