batocera-linux / batocera.linux

batocera.linux
https://batocera.org
Other
1.94k stars 500 forks source link

Large .smc / .sfc ROMS fail to write .srm save files with Retroarch / batocera-es-swissknife shutdown scripts #9285

Closed Aelieth closed 1 year ago

Aelieth commented 1 year ago

Running Raspberry Pi 4, using a RetroFlag shutdown script via system.power.switch=RETROFLAG_ADV in batocera.conf. Looking through the git I found the python code for the shutdown, and it uses batocera-es-swissknife to do the shutdown in:

package/batocera/utils/rpigpioswitch/rpi-retroflag-AdvancedSafeShutdown.py

Been testing and playing with some msu1 enhanced .smc (SNES) ROMS and came to find the problem that during the shutdown script it's not giving proper time to write the ROM back to disk when "batocera-es-swissknife --shutdown" occurs. All my .srm files write properly when the .smc and .sfc files are small. Sim City is my MSU'ed game.

-rw-r--r-- 1 root root 8192 Jul 12 17:15 'ActRaiser (USA).srm' -rw-r--r-- 1 root root 32768 Jul 13 19:14 'SimCity (USA).srm' -rw-r--r-- 1 root root 8192 Jul 11 08:31 'Super Bomber Man 5 (Japan).srm' -rw-r--r-- 1 root root 8192 Jul 11 11:35 'Sutte Hakkun (Japan).srm' -rw-r--r-- 1 root root 4096 Jul 10 18:01 'Tetris _ Dr. Mario (USA).srm' -rw-r--r-- 1 root root 8192 Jul 11 23:45 'Wario_s Woods (USA).srm'

The shutdown occurs so quickly I get varying results, sometimes it manages to finish to write a save, sometimes it creates a file with 0 bytes as it's corrupt, sometimes it doesn't even make a file.

Taking a stab in the dark, but I think during

--emukill|--shutdown|--reboot)
    RC_PID=$(check_emurun)
    [[ -n $RC_PID ]] && emu_kill && sleep 2

    ES_PID=$(check_esrun)
    if [[ "${1,,}" == "--shutdown" && -n $ES_PID ]]; then
        /etc/init.d/S31emulationstation stop
        shutdown -h n

It does a good job of making sure the emulator is finished, but doesn't do anything to check to see if writing to the disk is finished during metadata / srm save when it does the init.d portion.

Sorry I'm not really great at coding, I can read some syntax and make sense of stuff and take a guess, hopefully I'm in the right area here.

Workaround currently is to use the reset button to kill the emulator and let it write back to disk, then shutdown the system with the power button.

Aelieth commented 1 year ago

Closing this! Not an issue, it's because a timing relay for the power in my custom hardware that was closing too soon for the SSD when the power-off was initiated. Do think there might be an issue with performance though.

To clarify the issue, I had setup my equipment for the original rpi-retroflag-SafeShutdown.py script. The script halts the system on issued command. Time elapsed to fully shutdown system and write information to SSD was ~2.5 seconds.

rpi-retroflag-AdvancedSafeShutdown.py takes over 6 seconds to complete as it returns to ES and then issues shutdown to begin writing metadata.