Emulationstation Freezes

ghost commented 11 years ago

Hello,

I got two problems, the first is being that i can't control the menu with my gamepad. sometimes when i try with my keyboard it controls at first then freezes and stops working

second is that when i went and looked in es_log.txt i found an Error - font size exceeded texture size! if you were doing something reasonable, tell aloshi to fix it!

I'm very new to this kind of things, i looked up in the past threads and can't seem to get a hold on that and do the things either with the sleep command for the gamepad or editing the font for the error.

Thanks a lot for your patience and help !!!

HorstBaerbel commented 11 years ago

Try the latest version, delete your es_input.cfg.

ghost commented 11 years ago

i got the retropie image 1.6.1

HorstBaerbel commented 11 years ago

Try to update to the latest version of EmulationStation using git (You might need to delete you es_input.cfg and es_settings.cfg after that to reset them to default values after this):

cd EmulationStation
git pull
cmake .
make

ghost commented 11 years ago

everytime i try git pull it tells me : Fatal: Not a git repository (or any of the parent directories) : .git

HorstBaerbel commented 11 years ago

Are you in the EmulationStation folder? If yes, it seems like retropie didn't include the git repository data. Try to create another folder in home called e.g. ES_current, go there and try to get the current version using:

git clone https://github.com/Alosi/EmulationStation ES_current
cd ES_current
cmake .
make

ghost commented 11 years ago

UPDATE : i did the git clone, everything went perfect but when i use cmake . it tells me : CMake error at cmakelists.txt:63 (message) : you need at least g++ 4.7 to compile EmulationStation.

so i went and tried to update g++ by apt-get install g++ and it tells me i got the latest version ... what should i do now ?

HorstBaerbel commented 11 years ago

Try this

HorstBaerbel commented 11 years ago

From here:

You can use the RetroPie Script to download and compile the most recent version of every component: You need to use the "source-based installation" and select only the components that you would like to be updated.

ghost commented 11 years ago

I will try this tonight and post the results !!

petrockblog commented 11 years ago

Maybe Valgrind (http://en.wikibooks.org/wiki/Valgrind) could be useful to debug this 45min-freezing issue? BTW: Here are another two posts of people that describe their observations: http://blog.petrockblock.com/retropie/retropie-downloads/#comment-964762188 http://blog.petrockblock.com/forums/topic/exiting-emulators-leads-to-white-dot-black-screen/

Aloshi commented 11 years ago

Valgrind only works on x86/x64, not ARM, so we can't use it on the Pi.

I think a good test (for those of you experiencing the issue) would be the following:

Either add a dummy system or comment out and change an existing system in ~/.emulationstation/es_systems.cfg to have COMMAND=sleep 3d.
Launch EmulationStation and launch the emulator you changed (game doesn't matter, but you will need at least one present for it to show up in ES).
Wait 45 minutes to an hour.
Press Ctrl-C to kill the script and cause ES to return.
Report if the lockup still happens.

This will change the launch command to just a bash script that waits for three days. You'll manually kill the script with Ctrl-C. When the script terminates, ES should return. This test will hopefully narrow down if it's a problem with just ES, or an interaction between ES and the emulator.

petrockblog commented 11 years ago

I will try your idea with the script.

Regarding Valgrind I found that there was some work going on a few months ago, see http://www.raspberrypi.org/phpBB3/viewtopic.php?t=7689&p=240546. I am not sure what the actual status of that is, though. Nevertheless, Dom mentioned (http://www.raspberrypi.org/phpBB3/viewtopic.php?p=93658#p93658) "efence", which needs to be linked against the binary under observation (http://linux.die.net/man/3/efence). Maybe this might be tool that could help!?

petrockblog commented 11 years ago

I did some tests to narrow down the problem and I have good and bad news. But first of all the description of the tests: For the first two tests I used A Raspberry rev. 1 with the RetroPie Image v.1.7 (which comes with a 128/128 memory split and medium overclocking settings), connected via HDMI, only input a Logitech USB keyboard:

Test 1: I followed the suggestion from @Aloshi (https://github.com/Aloshi/EmulationStation/issues/99#issuecomment-21092840) and started the sleep 3d command from within Emulation Station. I did run the script for about an hour and ten minutes, killed it with Ctlr-C and returned back to ES. Result: I did not observe any faulty behavior.
Test 2: Instead of the sleep 3d command I used the default SNES emulator (RetroArch's pocketsnes) to start Super Mario Kart. I let this run for about three hours and exited via ESC. Result: I did not observe any faulty behavior.

Now I changed the model of the Raspberry to a revision 2 one and used the same SD-card as before (RetroPie Image v.1.7). Again, connected via HDMI, only input a Logitech USB keyboard:

Test 3: Again, I used the default SNES emulator (RetroArch's pocketsnes) to start Super Mario Kart. I let this run for about three hours and exited via ESC. Result: I did not observe any faulty behavior.

Summary: Good news is that Emulation Station worked without any problems in the the above situations. Bad news is that I am not able to reproduce the problem with a freezing Emulation Station when returning from a game after 45+ minutes.

ghost commented 11 years ago

@petrockblog : Which power supply do you use ? maybe that's the problem i got.

Aloshi commented 11 years ago

Thank you very much for the thorough testing, petrockblog!

petrockblog commented 11 years ago

@zahriradil I tested this with a "Belkin Power Adapter" (http://www.amazon.de/Belkin-USB-Netzadapter-iPod-iPhone/dp/B003DN3API/ref=sr_1_8?ie=UTF8&qid=1374249323&sr=8-8&keywords=belkin+dual+charger) and with an "iPod USB Power Adapter".

ghost commented 11 years ago

Hello Everybody !!

As said in the previous message, and as i thought the power supply was the problem. maybe the previous one didn't give enough juice ... got a new power supply with the following specs :

Input : AC 110-240V 0.3A 50/60Hz Output : DC 5V 1500mA (1A)

left my raspberry pi with Retropie working for almost 2 hours, no freezing no problems. works like a charm and smoothly !! thanks everybody for helping !!

petrockblog commented 11 years ago

Glad to hear that!

Would you also post the model and vendor of your power supply here? Might be interesting for others as well ...

HorstBaerbel commented 11 years ago

Wtf... :D

ghost commented 11 years ago

@petrockblog Here you go, this is the one i got : http://thepihut.com/products/usa-micro-usb-power-supply-for-the-raspberry-pi

@HorstBaerbel Truly, that was my reaction when everything woked like a charm with the new power supply !!

Blakwulf commented 11 years ago

Hello.

I bought the above mentioned power supply and i'm still experiencing the crash problem. If i have the emulator running for more than 30 minutes and try to exit, i get the white dot crash screen. Anyone else have any more ideas for this? I'm using the current version (v1.7) of RetroPie.

arimal commented 11 years ago

Is there anything I could do to help isolate the cause of this issue? I can reproduce it almost everytime I run retroarch for more than 45 minutes. I've tried several power supplies all up to spec as far as I can gather with no change in behavior.

Aloshi commented 11 years ago

You could try the test mentioned here and let me know what happens.

HorstBaerbel commented 11 years ago

Idea 1: This has to do with SDL and the event loop. The system() call blocks the main ES thread and something bad happens after some time. A fix is complicated and would involve spawning a thread to run the system command and waiting for it to finish while letting the main loop run from time to time.
Idea 2: AnimationComponents need to catch up on the time passed in their update routine after the system() commands returns. Try adding this to main.cpp line ~190:


        int curTime = SDL_GetTicks();
        int deltaTime = curTime - lastTime;
        lastTime = curTime;
--------snip--------snip--------snip--------snip--------snip--------
        //clamp delta time to maximum. This is a problem when we're returning from running a game.
        //The difference curTime-lastTime is really big and all animating components will need to catch up and block ES
        if (deltaTime > 1000) {
            deltaTime = 1000;
        }
--------snip--------snip--------snip--------snip--------snip--------
        window.update(deltaTime);
        Renderer::swapBuffers(); //swap here so we can read the last screen state during updates (see ImageComponent::copyScreen())
        window.render();

It will screw up animation, but only if the frame time is already above 1 seconds/frame, in which case it will suck anyway and you won't notice... ;)

HorstBaerbel commented 11 years ago

Man. I suck at commenting today... Had to edit this a couple of times ;)

Aloshi commented 11 years ago

For idea 1, SDL gets deinitialized with SDL_Quit() during a game launch, which (supposedly) completely unloads the library - from the documentation, SDL_Quit "Shuts down all SDL subsystems, unloads the dynamically linked library and frees the allocated resources." I don't think SDL can do anything in this state.

As for idea 2, the latest version of ES uses a "normalizeNextUpdate" method to make the max delta time the average delta from the last 500ms of frames. It's used when switching systems (to deal with the theme image loading delay) and when launching games. Relevant code. It's a bit rough, but it's better than nothing.

Also, as far as I know the freeze is a hard system lockup - even ssh will stop working. This leads me to suspect that something very bad is happening...I wonder if it might be a bug deep in the RPi firmware, or maybe the dispmanx stuff isn't being completely deinitialized and this is how it manifests.

I'd like to know the result of that test to see if its tied to the emulator at all, or if its purely ES's fault.

burkey0307 commented 11 years ago

I did the test that Aloshi suggested, and I ran the sleep 3d command for about 1 hour and 30 minutes and the system did not freeze. I am currently running a second test for a few hours just to make sure.

The RPi usually freezes on me when I exit a game after a few hours, so this could mean that Aloshi is correct in thinking that ES is not the problem.

edit: Second test complete, It's been running for 4 hours and it also did not freeze.

Blakwulf commented 11 years ago

Glad to see that you guys are getting somewhere with this.. keep digging! Let me know if i can help out in any way, i want to find a solution to this bug as i can reproduce it 100% of the time.

Aloshi commented 11 years ago

Out of curiosity, are you folks who are experiencing the freeze using the dispmanx SDL library at all (you have to manually enable that)?

burkey0307 commented 11 years ago

If it has to be manually enabled then I'm probably not using it. I didn't really change anything after installing with the retropie image.

streeto commented 11 years ago

I just wanted to report that the freezing happens to me only when using RetroArch emulators (picodrive, stella and pocketsnes cores, all using the latest sources). I left pifba for a couple of hours and no problem returning to ES.

orchist commented 11 years ago

I've consistently had this problem as well. One thing worth noticing is that ctrl c always seems to successfully return to emulation station even after 45 minutes (for me at least). I simply disabled the input_exit_emulator_btn keybind and mapped ctrl+c to the home button of my Xbox controller. This is probably an ugly fix, but I'm not particularly technical and it seems to consistently return to ES and it updates my save files, so I'm happy.

Aside from that, I've tried pretty much everything I could think of to get this working. I've reimaged on multiple cards, tried different power sources, different clock speeds, building from the latest source, different game pads. Nothing on the hardware side seems to fix it.

Hopefully this helps narrow down the issue. Thanks for the great work on ES!

Aloshi commented 11 years ago

If you disable the runcommand script by opening ~/.emulationstation/es_systems.cfg in a text editor, find the "COMMAND=" line for an affected system, and completely disable the runcommand.sh script, any change?

E.g. COMMAND=~/RetroPie/supplementary/runcommand/runcommand.sh 1 "retroarch -L somelibretro.so --config ~/RetroPie/configs/all/retroarch.cfg --appendconfig ~/RetroPie/configs/snes/retroarch.cfg %ROM%" -> COMMAND=retroarch -L somelibretro.so --config ~/RetroPie/configs/all/retroarch.cfg --appendconfig ~/RetroPie/configs/snes/retroarch.cfg %ROM%

EDIT: You can also try this suggestion by @alexbleks: "Open /etc/kbd/config and set BLANK_TIME=0 and POWERDOWN_TIME=0"

streeto commented 11 years ago

Running without the runcommand.sh wrapper does not help, the problem persists. I'll try to add some debug messages to an emulator to see where it fails. Also, the one simple test I did not make was to run emulators outside EmulationStation, but I don't have a proper setup right now (no USB keyboard nor a long network cable to reach the TV and use SSH).

I'll try to do these in the weekend.

Aloshi commented 11 years ago

Awesome, thank you. I'm particularly interested to see if @alexbleks's fix works.

leandromacrini commented 11 years ago

I really don't understand why emulationstation have this "fade to black" feature, it is not created for kiosk or "always on" hardware, it's not needed at all IMHO.

Aloshi commented 11 years ago

Because otherwise EmulationStation will use pretty much all available CPU to keep updating the screen when you're not watching it. It's wasteful and hinders other tasks being done over SSH. You can disable it by setting the "DIMTIME" setting to 0 (or use --dimtime 0) if you don't want it.

streeto commented 11 years ago

@Aloshi it works! I tried the suggestion by @alexbleks, left a game running for a couple of hours, no crash. I'll do more tests to make sure it wasn't a fluke, but it seems he nailed it.

petrockblog commented 11 years ago

The suggestion from @alexbleks also seems to be worth to be included in the RetroPie Script.

KitchUK commented 11 years ago

Finally! This bug has been driving me nuts! Glad to hear there is a potential fix for it.

Blakwulf commented 11 years ago

Is it true? Crash resolved? @Aloshi will the fix be included with a new RetroPie image created and uploaded? Since i had this crash 100% of the time over 30 minutes, i'm eager to try the fix!

streeto commented 11 years ago

ghost commented 11 years ago

@Blakwulf Let me know if it works for you too =)

Blakwulf commented 11 years ago

I'll need the new image to download.. my coding knowledge is severely limited.

ghost commented 11 years ago

Ok, I think @petrockblog is going to add it in the next release.

HorstBaerbel commented 11 years ago

Man. This is an elusivy one... Thanks for the info @streeto! Sound like the Pi does crap out in other places too... Hope the keyboard config solves it.

streeto commented 11 years ago

I played (ahem, tested ;-) a lot last night without crashes. If others can confirm, I call it a fix.

Blakwulf commented 11 years ago

Common new image so i can try!

gardobeson commented 11 years ago

I am also having this issue when exiting Zelda II on the NES emulator. I'll try @alexbleks suggestion this evening and post the results as a follow up.

-Raspberry Pi Model B [Raspbian Distro](900/250/500 Clock) {256/256 Split}

gardobeson commented 11 years ago

Tested @alexbleks fix. Worked. No crashes upon exit of a rom after changes were made to the file. Thanks for the easy fix!

-Raspberry Pi Model B Raspbian Distro {256/256 Split}

Aloshi / EmulationStation

Emulationstation Freezes #99