>5s delay when starting each arcade game
-
Thank you again!
Here's runcommand.log in pastebin: https://pastebin.com/rMDfci9D
When EmulationStation loads, it briefly displays each system in es_systems.cfg. It takes a few seconds to zip through the list. The systems are not displayed when I scroll left and right. It only saves a few seconds on startup.
-
@hsamuels said in >5s delay when starting each arcade game:
Apple keyboard.
Is it some kind of bluetooth keyboard ? Does it still happen if you remove it ? I remember seeing similar bug reports with bluetooth controllers.
-
Just a USB keyboard. The delay happens whether or not the keyboard is plugged in.
For what it's worth, the install was done on a Windows machine. I just happened to have an Apple keyboard lying around.
-
I think @barbudreadmon was thinking of this issue and I admit I was thinking something similar may be causing this.
The log file doesn't show anything abnormal. I still can't reproduce the timeout you're mentioning - first launch may be around 5 sec to get something on screen, but subsequent launches are faster and under 5 sec. Just by looking, more time is spend after RetroArch starts, then before (duringruncommand
processing).
Does the issue happens with other cores also (lr-mame2003-plus
,lr-fbneo
) ?NB: I'm doing the test on a 4.8.6/ Pi3 with same 1080p resolution. The only difference to your case is I have an updated system and RetroArch - which I recommend you try also (updating everything).
-
@mitu OK, time to pull out the stopwatch.
emulator to launch menu to USB controller notification (launch menu turned off) FBNeo 5.5s 8.5s Mame 2003 5.5s 10.5s (sorry, I can't format a table here)
It seems that the time to get to the launch menu doesn't care which emulator is selected, which makes sense. But 5.5s to get to that point seems long.
Then with the launch menu disabled, it takes 8.5s for the first thing to appear in neo, and 10.5s in 2003. So there is an appreciable difference between emulators.
The system was just installed from scratch on 1/2/2024. Retropie version 4.8. Does the installer point to the latest RetroArch image?
-
Reformatted the table for you.
The system was just installed from scratch on 1/2/2024. Retropie version 4.8. Does the installer point to the latest RetroArch image?
You just run an update of RetroPie-Setup and the installed packages in order to get the latest versions.
-
@mitu Thank you for formatting the table.
Boy, the Raspberry Pi worked hard for about a half hour updating things. Unfortunately it still takes 10.5s to load the game in Mame 2003.
Do you have any other thoughts or suggestions? It isn't the end of the world, but it's frustrating that I know it shouldn't take so long to load each game.
-
@hsamuels said in >5s delay when starting each arcade game:
Do you have any other thoughts or suggestions? It isn't the end of the world, but it's frustrating that I know it shouldn't take so long to load each game.
Try using another mSD card if you have a spare - just copy the already configured image over.
-
@mitu Shoot. I used Win32DiscImager to backup to my computer, then to write to another micro SD card. RPi won't boot on the copy.
-
@hsamuels Whence selecting the drive, you've choosen the "boot" partition (not the ext4-/other one (the one windows won't recognize)), haven't enabled read allocated partitions only and the filesize of the resulting image is ~= to the size of the SD-Card? A "yes" on all three should result in a valid/useable image.
-
@Ashpool I believe the answer is yes for all three.
No matter, I'm going to start on a new SD from scratch. I've done it enough recently that it's a pretty smooth process!
-
I rebuilt the system on another SD card (actually, the one I was using on a different system that worked perfectly) and it still takes 10.5s for the game to load.
-
@hsamuels Just out of curiosity(!) -> if you have a spareable USB stick at hand [1], could you try the "retropie-mount" method?
1: In my experience with 32/64GB SanDisk and some "NoNames": Sometimes USB2 Sticks are performing faster on an USB2 Port compared to USB3 sticks from the same Brand/Label/Size (though those are faster on an USB3 Port) - so, if possible, it may be worth to try out both variants.
P.S.: I am now puzzled what normal/expected loading times would/should be -> Just taken some rough meassurements (subsequent starts, not initial 1st one) on my old Pi3B (no plus) official PSU/retropie build from official 4.8 and last updated maybe +-5 month ago on a few roms (run from usb-stick) in FBNeo (.7z) and lr-mame 2003 (.zip) (plus is my choice, but for the tests I've used pure 2k3) -> first time is from blank screen after starting rom to appearance of the "press key to configure"-OSD-box, second time is from thereon to the dissapearance of said box/rom starting.
For lr-mame2003 the times where ~ +-5.5s/7.5-8s (total ~12-14s) and for FBNeo ~ 5.5-6s/5-6s (total around 10-12s) -
@mitu Can you suggest any debug things to try? For example, I could put an echo statement in runcommand-onstart.sh. What happens between the game select button being pushed and the launch menu appearing?
-
@hsamuels Try running the command to start the emulator outside EmulationStation and see how long it takes to start the actual game.
/opt/retropie/emulators/retroarch/bin/retroarch -L /opt/retropie/libretrocores/lr-mame2003/mame2003_libretro.so --config /opt/retropie/configs/arcade/retroarch.cfg "/home/pi/RetroPie/roms/arcade/1941.zip" --verbose --appendconfig /dev/shm/retroarch.cfg
-
For lr-mame2003 the times where ~ +-5.5s/7.5-8s (total ~12-14s) and for FBNeo ~ 5.5-6s/5-6s (total around 10-12s)
It looks like you are seeing the same 5.5s between pressing the game select button and the launch menu dialog that I am.
I didn't measure the time between closing the launch dialog and the first signs of game starting. Rather, I disabled the launch menu dialog, and measured the total time between pressing the game start button and the first signs of life.
Either way, it seems much longer than what I had from a 2019 build on a Retropie 3 (not B). Unfortunately, I didn't measure that time. But the current launch time was long enough that I thought the thing was broken. And my son said the same thing.
In any case, we now have two users experiencing 5.5s from game select to the launch menu. Would anybody else care to time their systems and share the results, along with the SW and HW versions?
-
@mitu said in >5s delay when starting each arcade game:
@hsamuels Try running the command to start the emulator outside EmulationStation and see how long it takes to start the actual game.
/opt/retropie/emulators/retroarch/bin/retroarch -L /opt/retropie/libretrocores/lr-mame2003/mame2003_libretro.so --config /opt/retropie/configs/arcade/retroarch.cfg "/home/pi/RetroPie/roms/arcade/1941.zip" --verbose --appendconfig /dev/shm/retroarch.cfg
Thank you, @mitu. I tried a couple of different games, each one measured several times. They all clocked in at about 3.8s from hitting enter to first sign of game life (no launch dialog). This feels much closer to what I remember from my earlier build.
-
@hsamuels said in >5s delay when starting each arcade game:
Either way, it seems much longer than what I had from a 2019 build on a Retropie 3 (not B). Unfortunately, I didn't measure that time. But the current launch time was long enough that I thought the thing was broken. And my son said the same thing.
This is before support for Pi4 was introduced - there have been quite some changes since then. Looking at the
runcommand.sh
times, 5s seems about the time it takes to:- analyze the current resolution and change it if needed
- set-up Retroarch's temporary config
- start the emulator
- exit the emulator.
- cleanup-up
Now, it's probably less than 1 sec it takes ES to close down and invoke theruncommand
, but I can see that adding up.
Looking at the a breakdown on times, I think the most time is spent running
modetest
to detect the current and available resolutions - used for Pi4 or otherkms
based systems. This takes less time on akms
system, but on a Pi3 that's not the case.Short of maybe removing
modetest
or maybe puttvservice
before it - to detect the current resolution - I don't see a considerable room for improvement here. Replacingmodetest
with something lighter is on my TODO list and maybe will be done as part of the Pi5 support additions. -
@mitu Thank you!
It's good to know that I'm not just doing something wrong.
Does modetest need to check the current and available resolution each time a game starts up? Can it happen once at power-up?
-
I'm back on the original system, which now sports a Pi4. It has LED buttons, and a pacdrive tells which buttons to light up for each game. This happens in the last line of runcommand-onstart.sh.
It takes 3s between the game select button press and the LED update. But slightly faster than my Rpi3 system, about 8s, to get to the joystick message from the game select button.
Contributions to the project are always appreciated, so if you would like to support us with a donation you can do so here.
Hosting provided by Mythic-Beasts. See the Hosting Information page for more information.