Open razambon opened 10 years ago
Hmm, this is a new one. What is your memory split? How many systems are visible in ES?
@nilsbyte Did you ever run into this problem with the earlier 2.x versions of RetroPie? I'm wondering if maybe something recently changed with RetroPie.
I had it at default split at first, then changed to 384. Problem persisted. This also happened before I toggled on HDMI_drive=2. Only have a few systems being shown - I actually completely removed anything I definitely won't use from the es_systems file. As of now, only C64, NES, SNES, GG, Genesis, and Atari 2600 display. Total of 10 games in the system across all of those.
Ok, still debugging this. Just switched to my HDTV and am trying to get things working. It seems to work fine (i.e., return to ES) if I force HDMI_group=1 and HDMI_mode = 1. Trying other modes, but HDMI_mode = 4 causes the blackscreen issue. Going to go through more of the modes to see what happens. I'd like to get a fullscreen ES if possible, even if the emulators themselves are run at a different resolution.
This may be a resolution switching thing though.
Have you tried disabling the runcommand.sh script in your launch command (easiest way is setting it to "pass-through mode" - I think changing the number from whatever it is to "3", or you can just remove it entirely)?
I did. I completely removed it from the VICE launch command and it's still occuring. I left it in Osmose's start command so I have a positive and negative control...kind of. :)
Ok, he's something else. Don't know if it's related or not. When it's setup for VGA mode and everything seems to work fine, if I enter and exit a non-Retroarch emulator and then exit ES to the command line, input doesn't work. (I.e., typing on the keyboard does nothing). Really odd.
So, it appears this is only happening to me? So odd...
No, I am having this too. I use a retropie sd image. Whenever I use VICE via ES and then exit VICE, I get the exact same problem as described above. Starting vice via terminal works fine...
I've got the exact same problem too!
So...looks like a definite bug of some sort then!
Oops. Closed by accident.
i think i ran into this issue trying to make n64 work on a pi, never managed to get any roms to actually load so i assumed the emulator locked up, but i did not seem to have the same issue when i ran it via command line... no issues with the gpsp emulator though
@Aloshi, i can confirm that with Vice, after quitting the emulator the screen turns black and nothing happens. I can SSH into the Pi, x64 is running. If i kill it, the screen stays black. sudo reboot
does not work. I have to interrupt power to restart the Pi.
btw: Osmose doesn't run correctly due to an error in the RetroPie es_systems.cfg and quits with a black screen, even in console without ES.
I have the same problem as well. After starting Vice (x64) from Emulationstation and then exiting it, I see only a black screen. Indeed, when I log in using SSH I can see that x64 is still running and emulationstation is not running.
@Aloshi Is this something that additional information can be provided around or is sufficient info available so far? Just want to streamline addressing this bug in anyway possible.
From what I see, this is either a Raspberry Pi-specific bug or an emulator-specific bug. It might have something to do with how VICE handles setting up/tearing down its video/input stuff, or it might not. Unfortunately, I have no idea how to go about fixing it even if I reproduced it - it's probably not something EmulationStation can fix on its own.
That could be the case. However, the problem does not occur when I manually close ES, then start Vice, then exit Vice and then restart ES.
Maybe it is all all a matter of timing. It looks like Vice is not given enough time to close down its own proces and reset the video input stuff before ES tries to reload itself. Maybe a 1 second wait after closing Vice and would help.
Maybe we can try this by editing runcommand.sh to include a wait period after Vice is run? Or create a shell script for Vice itself that pauses for 1 second after Vice is closed. Unfortunately I don't know how to do this ;)
@Aloshi: The wait period I wanted to try in above post did not help.
However, I discovered something interesting. The problem with hanging in a black screen after exiting Vice2.4 disappears completely when I follow these steps:
So the problem seems to occur only when ES is auto started on booting RetroPie.
Can confirm the above does fix things. Interestingly - if you exit ES you can no longer type. The cursor flashes as you hit keys, but nothing registers. I need to confirm, but I think this only happens after going into Vice then exiting.
Even more odd - if you set things to certain video modes (HDMI_group=1 and HDMI_mode = 1 as I noted in a comment above) this issue also occurs when you exit ES after starting Vice once.
The issue is now also reported at the retropie forum.
FYI: I have somehow solved this problem completely on my Raspberry Pi setup. I can now start and exit Vice many times and ES always loads fine afterwards. Don't know exactly what I did, but it was probably a combination of:
So this issue is solved for me.
So, after a bit of an insane month at work I finally tested this. And it does work. AS of now, this is the command to use for running the retropie_packages.sh : sudo ./retropie_packages.sh 310
Also, I think it may have more to do with the sdlbigdepth command than anything else. That may lock things into the same screen setup that won't cause a failure.
Same Problem with fuse-sdl (ZX Spectrum emulator).
I am using fuse-sdl as ZX Spectrum emulator in my Retropie/Emulationstaion setup as described here: http://blog.petrockblock.com/forums/topic/zx-spectrum-emulator-needs-changing-please/
Starting and quitting fuse-sdl in bash works. Starting fuse-sdl with Emulationstation works. Quitting fuse-sdl after launching it with Emulationstation freezes at a black screen. My Pi hangs.
This is exactly the same problem with Vice 2.4.
@razambon: Did you solve this issue? What exactly have you done for resolving this?
It is my understanding that using "sudo ./retropie_packages.sh 310" reinstalls the Samba Rom shares. Is this right? I do not understand why a reinstall of the Samba Rom shares should help...?
(For all retropie_packages take a look here: https://github.com/petrockblog/RetroPiePackages/blob/master/scriptmodules/retropiesetup.shinc)
I resolved it for C64 - and the 310 package, on my install, was SDL 2.0.1. If it's not (I can check late tomorrow or over the weekend) then SDL reinstallation is not needed.
My guess is that fuse-sdl's graphic mode has to be forced to be the same as whatever ES is using. That seems to be the root of the problem.
I have the same problem. I solve this problem for a week. When I set parameters in config.txt: hdmi_group=1, hdmi_mode=1, so it works, but it's only VGA mode and it's not nice picture in ES. But again does not work DUKE3d and other games in PORTS. It's not good solution. My RPI is B+.
the rPi does not support VGA, it has compost, VGA and composite use different colors to make a image
hdmi_group=1 - HDMI type CEA hdmi_mode=1 - resolution VGA in CEA format Where I made a mistake? I found out today that this is a bug in some other emulators. I had done everything I found on this forum, still does not work.
It's VGA resolution over HDMI. The picture quality is not the best that the Pi can do - so I think the issue is that things are being forced to the same resolution/lower resolution and that's whats allowing the fallback to occur.
I actually noted this solved it awhile back...but...it's definitely non-optimal.
Right now I am observing the "failure to return to ES" issue with these emulators on my Raspberry Pi with Retropie installed on it and a 1920x1080p 60 Hz display:
C64 emulator: vice 2.4, depends on sdl1.2-dev (http://www.raspberrypi.org/forums/viewtopic.php?f=78&t=69420)
ZX Spectrum emulator: fuse-sdl, probably depends on libsdl1.2-dev (http://www.agm.me.uk/blog/2014/08/spectrum-emulator-full-screen-on-the-raspberry-pi.php http://www.retrocomputers.eu/raspberry-pi/how-to-compile-the-fuse-zx-spectrum-emulator-on-the-raspberry-pi/)
ZX81 emulator: sz81, depends on libsdl1.2-dev (http://sz81.sourceforge.net/ http://www.raspberrypi.org/forums/viewtopic.php?f=78&t=72142&p=520337#p520337)
It is possible to start the ZX81 emulator with the command line option "-1920x1080". Using this the emulator starts in my native tv set resolution and correctly falls back to ES after quitting. Any other resolution within the command line results in the failure to return to ES. Unfortunately the screen resolution of 1920x1080 is not suitable for this special emulator.
So any of these emulators use sdl1.2. ES uses sdl2.0. Perhaps there is a problem starting an emulator which uses sdl1.2 from a sdl2.0 environment (ES)?
hello, I also have problems to get out of the not RetroArch emulators and return to ES: I see a black screen. After I have to restart the RaspberryPi. My experience is Intellivision, C64 and AmstradCPC. My version of RetroPie is 2.3. I upgraded from sources ES, SDL, Intellivision, C64 and AmstradCPC. I have not changed the configuration files.
Alex (Sorry for my English)
Have the same problem with Atari 2600 emulator :/
now that is odd, did you install from the retropi image or the script i used the image, never had a issue with atari2600
@GM-Script-Writer-62850 retropie image 2.3 , when I press the buttons to exit, it blinks and screen gets black, doens't return to ES.
does it happen with all games? i have played some on there and had no issues can you test a spare sd card, to be sure you don't have something corrupted
in fact, I have tested more system which were functional before, and it's not related to atari emulation, some times I go back from a rom and the ES is just fucked up, everything is blank, thumbs, etc. then I try anything, screens goes black, only start button works. any ideas? do not have spare SD card, but it was perfect before :(
iv seen a portion of that happen before, your sd card is becoming corrupt can you use a USB 3.0 port to power it? (without NO OC) a computers usb 3 port has a nice clean 900ma to power/charge stuff This is the 1 amp block adafruit carries http://www.ebay.com/itm/151270600968 (lowest price i have found for them) some people recommend 2amp units for the pi, but the pi has a 1amp fuse, so as long as you use a quality 1amp block and don't do unsafe poweroffs it should work just fine if you have spare old flash drive you can move your swap file from the sd card to that, that should improve stability
unfortunately I can't buy this since costs me around 55$ to import to my country. :/
I have a working image from couple days ago, maybe I'll try to write it down. thanks for the help.
maybe you can find a seller in your country https://www.adafruit.com/images/970x728/501-03.jpg edit, wow that one on ebay is not the same (diff sticker) i have that one and i know it works though, but i never really stressed it edit: be sure you get one with the right plug for your main power
nope :/ neither of 3 stores have it
maybe you can find a 5v 1 to 2 amp switching charger have a computer PSU around? (you can use the red wire and the black wire next to the red wire on a 4pin molex) once you splice your usb cable into the wire (black to black, red to red) you will also want to short the green wire to and black wire on the 24pin plug (this turns the unit on)
I have 5v 2amp here, not sure if it is the power source, I'll try to format and revert to latest working backup that I have, let's see how it goes.
In /opt/retropie/supplementary/runcommand/runcommand.sh changing the following line:
eval $command
to
eval $command & wait $!
worked for me.
can you explain why backgrounding it and waiting for it to finish would make a difference from the way we launch / wait now ? also is this with the latest runcommand.sh script - please can you provide some more details - thanks.
could you try this change perhaps to runcommand.sh
--- a/supplementary/runcommand.sh
+++ b/supplementary/runcommand.sh
@@ -279,7 +279,8 @@ echo "ondemand" | sudo tee /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
# if we switched mode - restore preferred mode, and reset framebuffer
if [[ $switched -eq 1 ]]; then
restore_mode "$currentmode"
- reset_framebuffer
fi
+reset_framebuffer
+
exit 0
also - if you change the screenmode to 640x480 before launching (pressing M or X) does that fix it ? I suspect since the default for jzintv from retropie is to not change/restore screenmode, jzintv is leaving the framebuffer is an unusable state which is causing a problem. We are likely to change the default to most sdl emulators to use the dispmanx sdl by default also.
@joolswills - moving the reset_framebuffer
outside of the if
block will not work since x64 is exiting before runcommand.sh can reap it, causing the eval to never return...
pi@raspberrypi ~ $ ps --forest -ft tty1
UID PID PPID C STIME TTY TIME CMD
root 2374 1 0 20:15 tty1 00:00:00 /bin/login -f tty1
pi 2381 2374 0 20:15 tty1 00:00:00 \_ -bash
pi 2388 2381 0 20:15 tty1 00:00:00 \_ /bin/bash /usr/bin/emulationstation
pi 2392 2388 26 20:15 tty1 00:00:29 \_ /opt/retropie/supplementary/emulationstation/emulationstation
pi 2400 2392 0 20:16 tty1 00:00:00 \_ sh -c /opt/retropie/supplementary/runcommand/runcommand.sh 4 "/opt/r
pi 2401 2400 0 20:16 tty1 00:00:00 \_ /bin/bash /opt/retropie/supplementary/runcommand/runcommand.sh 4
pi 2430 2401 76 20:16 tty1 00:00:47 \_ [x64] <defunct>
This is what led me to try backgrounding the eval and adding an explicit wait. I have also tried changing the screenmode to 640x480 using the 'm' option but that still results in a defunct process. My system was created using the most recent raspbian image and the RetroPie setup script. Originally I started with the binary install then tried rebuilding from sources to no avail. The only other option that worked for me was booting the pi in 640x480 VGA mode.
moving the framebuffer reset outside helps for other emulators like jzintv it seems.
your first sentence confuses me though - either it exist or it doesn't no? - are you saying the process never returns or I will have a look further anyway but thanks for the explanation. will the wait be triggered even in the case of a zombie process ? ideally we need to fix the crash i think.
I think there are multiple issues here - some emulators exit fine but leave the framebuffer in an unusable state which reset_framebuffer helps with, and your case where you get a zombie process.
when testing with some code that ends up in a defunct state, there was no difference between the previous code and the launching a child process and using wait. Both waited until the defunct process was gone.
it also made no difference when I was testing x64 - x64 is crashing my system when run from console and needs to be looked into further.
Seems x64 leaves the screen in a state where fbset -depth 16 freezes after it exits (at least on my system via composite) - running via dispmanx may be the only viable option really.
Anyway this is all offtopic for emulationstation being related to retropie - perhaps we could continue any further discussion https://github.com/petrockblog/RetroPie-Setup/issues/585
Left this on the RPi forum thread, but figured it would be better to have here.
Having an odd problem - not sure if it's RetroPie or Emulation station - leaning towards ES since everything works fine outside of ES. Basically, if I start Vice via EmulationStation and then exit vice, I just get a black screen. I can reboot the pi via an SSH in and the x64 (vice) process is shown as defunct/dead via my SSH CLI. If I kill the process, the screen stays black. This also happens with Osmose. Retroarch works completely fine.
This doesn't happen when the emulaotrs are run outside of EmulationStation - so not exactly sure what the issue might be.
Some additional items: