Please do not post a support request without first reading and following the advice in https://retropie.org.uk/forum/topic/3/read-this-first

  • Hi, first thanks for the work put in to this project. I'm using a small pc I had around as a rarely used plex server to play some nes and genesis roms.

    I used debian 10 as my base, because ubuntu 18.04 did not have any sound from my hdmi.
    My pc is a small alfawise brand mini pc with an intel atom x5 z8350. I did a clean debian base install and then followed a post from this forum to get the pc to boot straight to emulationstation like a retropie would.

    Post I used as my guide

    Everything booted up well and loaded, my logitech f310 controllers were set up and I began playing a tecmo bowl rom. It ran at about half speed with choppy audio. After some searching I changed the video_threaded setting to true in the .cfg and the rom was running as it should. After 7-10 minutes, it crashed, and there was no display at all. The pc was still active in that I was still connected via ssh on my laptop. When the emulation was active, about 15-25% of all 4 cores were being used when I looked at htop, so I felt like I had plenty of headroom. After the crash, back to 1% usage with none of the retropie programs running anymore. I tried a contra rom, a super mario brothers rom, a tecmo super bowl rom, all died at the same point 7-10 minutes in after working flawlessly before that.

    My /dev/shm/runcommand.log shows no errors, just shows how the emulator and rom was loaded. I had the same issues on fceumm and nestopia. I had it set to nestopia, but tried fceumm when it first failed. I tried all 4 video drivers in the cfg, only gl worked at all. I have changed nothing else on the default .cfg

    I have some linux experience, and am guessing maybe the window manager is dying since it crashes to no display at all, not even a black screen.

    Thanks

  • Global Moderator

    Remember that most emulators are single threaded, so having multiple cores is not an advantage. Threaded videos has problems with some video drivers, so that's why it was disabled by default on x86 (PCs) - I'd advise to try without it.

    What resolution are you using ? Are you using PulseAudio for sound ?


  • When video threaded was set to False, the emulator ran at half speed with choppy sound, unplayable basically. I had this experience on ubuntu as well. I set the value to true based on some research and then got the emulator working great, smooth, proper speed, perfect for 7-10 minutes, then it crashed.
    Yes I am using pulseaudio. I will have to look at the resolution, I will have to look. I did not change anything in the resolution, so whatever the default is, that would be my guess. Also, I am on a 4k tv if that changes anything.

  • Global Moderator

    @patssox04 said in Retropie x86 crashes during game:

    I did not change anything in the resolution, so whatever the default is, that would be my guess. Also, I am on a 4k tv if that changes anything.

    4K looks a bit much for that system - according to its specs. You might want to lower the resolution to 1080p.

    Do you have any errors in the Xorg.log log file related to the video driver when the crash occurs ?


  • Thanks for the advice, I tried two lower resolutions, going down to even 800x600 and got the exact same result. I looked in the log file, tracking it as the game was running and then immediately after the crash, and there is no input into the log when the crash happens.

    It's just very strange to me how it runs perfectly for 7-8 minutes each time. I'm going to time it next time, because I feel like it's exactly the same time every time. It just dies, the processes are not active anymore, and the screen output dies, not black, just nothing output.

  • Global Moderator

    Can you enable verbose logging from the Runcommand launch menu when you start a game, then post the output ? Try to get the log for the same game/emulator in both cases - when you're running with threaded video on and without the setting.
    Get the /dev/shm/runcommand.log and then post it on pastebin.com.


  • I spent some time digging around and experimenting.

    #1 I timed the issue, it is exactly 10 minutes every time when retroarch is killed, monitored it 3 different times with nes emulator on different roms.

    Knowing that, I searched for configs that may have a 10 minute timer, screensaver maybe?

    I tried /etc/X11/app-defaults/XScreenSaver which has a timeout setting of 10 minutes. I set it to 0 and tried again, same thing, exactly 10 minutes in retroarch is killed.

    I am at a loss as to what could cause this, it was a brand new debian install. I may try one more time or do ubuntu 19.10 just to be sure but I cant imagine it won't end up the same.

    Any ideas what could be killing retroarch after 10 minutes every time?

    Thanks


  • Thanks for the tip, I hadn't seen your post before I made my last post.
    Here is the verbose log

    https://pastebin.com/BuGxwkMr

    I have it on the native 4k resolution, but as stated previously, this same thing happens on all resolutions, even 800x600.

    Also, just to be clear, this is with true set on the threaded video setting. I had to choose that setting to have the games run at a playable speed. I can't play them with it set to false, I just wanted to let you know my settings when I had this issue.

    10:00 minutes exactly as before.

  • Global Moderator

    To be honest, I was rather interested in the output without threaded video set, so that we might see if there's any indication about the slowdown. In the log I don't see any error and the crash - if any - might be logged in Xorg.log, not the RetroArch debug log.
    The log posted confirms you're using 4k as resolution and alsa as sound driver, but that's about it.


  • Thanks. I tried it with the threaded set to false and it was slow and stuttered, however it did not shut off after 10 minutes

    test 1

    In the log I see this-
    [INFO] [X11]: Suspending screensaver (X11, xdg-screensaver).

    That is not in my first log, which would seem to explain my 10 minute issue.

    I attempted another test with the resolution set in the config file for retroarch.

    test 2

    Both times it would seem that I set the resolution (either in that file or within the gui before launching the rom, but it's still using 4K? Maybe I'm reading that wrong.

  • Global Moderator

    @patssox04 It's still using 4k

    ...
    [INFO] [GL]: Vendor: Intel Open Source Technology Center, Renderer: Mesa DRI Intel(R) HD Graphics (Cherrytrail) .
    [INFO] [GL]: Version: 3.0 Mesa 18.3.6.
    [INFO] [GL]: Using resolution 3840x2160
    [INFO] [GL]: Default shader backend found: glsl.
    [INFO] [Shader driver]: Using GLSL shader backend.
    [INFO] [GLSL]: Checking GLSL shader support ...
    ...
    

    How are you changing the resolution ?


  • I changed the resolution 2 different ways, hence the 2 pastebin links. The first was I pushed a when I chose the game, then in the menu set the resolution, I have tried various values here. I also went into the retroarch.cfg file and set the resolution in the section Fullscreen resolution. I put in the desired resolution for video_fullscreen_x and video_fullscreen_y. I see those values in the log where it says

    [INFO] [Video]: Video @720x480.
    

    But I see what you copied there also, so my values are not really changing what I need to change. I will look at the docs and see where I should be changing resolution.

  • Global Moderator

    @patssox04 Try changing from the Xorg env, via xrandr. Exit Emulationstation and open a terminal, then switch the resolution, then start Emulationstation again.


  • Awesome! I set up open box to start with 1280x720, verified it via the log, and it worked perfectly with the threading set false. Looks way better than it did set true, has better response/less lag, and of course the screensaver doesn't kill it after 10 minutes.

    Thanks so much for your help with my problem.

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.