N64 crashes after 10 min

dankcushions

@quicksilver said in N64 crashes after 10 min:

@endersenigma https://github.com/mupen64plus/mupen64plus-core

This is most likely the place to report an issue. I too would like a mod/admins opinion though.

if this isn't happening in other graphics cores then it's not a mupen64plus issue, it's a gliden64 issue. please report it here: https://github.com/gonetz/GLideN64/issues, but lets hold fire on that for a while until we have more details

i think a video of the issue would be ideal, and even better would be a stack trace, but that's kinda difficult to explain if you've not done it before. tagging @gizmo98 if you have a moment :)

quicksilver

@dankcushions I will try to get a video of it, it's hard though because sometimes it glitches and freezes faster than I can get my camera ready (I don't have capture equipment). It's easily reproduced though.

EndersEnigma

@quicksilver
I might be able to capture some video this weekend, will update as able.

Bobberella

I think i fixed the glitch by setting "show VI/s counter" to True.

Its in the advanced settings for mupen64 near the "show FPS"

I figured if show fps fixed the last thing then lets try the rest of them.

Im gonna test it a few more times... posting later.

mitu

@bobberella See https://retropie.org.uk/forum/topic/11279/how-to-turn-off-fps-frame-counter-in-mupen64plus-gliden64, seems like known problem.

quicksilver

@mitu Except that the frame counter is on and we are still encountering this issue. So either its not working as intended or this is something else.

Bobberella

@quicksilver

It only worked twice so now im on to messing with different settings.

Bobberella

Seems like if you turn on percentage and vi/s...
The glitches are not so bad and you can make it through them without freezing.

quicksilver

@bobberella Its probably just incidental. A lot of times I can get through the glitch by not moving. If I keep moving and looking around it makes it worse and usually crashes. At this point I think its out of our hands, Im not sure its something we can fix. I applaud your enthusiasm for digging through configs and testing things though!

BuZz

@psyke83 has reproduced the issue. We need to debug it though and it could take some time.

Bobberella

Awesome.

There seems to be no settings in "advanced mupen64 settings" that do anything besides break the emulator or do unnoticible changes.

I think adding FPS, percentage, and vi/s made it more stable but I have no idea.

Hopefully the fix is soon... :)

The people of retropie thank you.

quicksilver

@buzz thanks for the reply buzz. Do you know if a issue was opened for it on the gliden64 GitHub?

BuZz

@quicksilver not yet - I will open an issue if we can track it down to a specific commit. We don't know that it is a GlideN64 bug (Could be the RPI GPU drivers or firmware for example).

BuZz

Currently testing with the intro for Legend of Zelda, The - Majora's Mask letting it run continously. Not seen the problem yet (Running for 18 mins or so). @psyke83 said he saw the issue after 20 mins. Does anyone have a non interactive way of reproducing the issue quicker - so I can leave it running in the background?

quicksilver

@buzz It has happened for me just loading a level and letting my character stand still for 10-20 mins. However, when the glitch occurs it seems to get worse when you are moving and will likely lead to a crash. Sometimes when it occurs I can stop moving and the glitch will pass and I can resume playing. It may be harder to to get it to occur if you are standing still. This is all from my own anecdotal experience. It has happened on just about every game I have tested for glide (I have never tried majoras mask). Diddy kong racing, battle tanx are two games it will happen for me everytime.

BuZz

@quicksilver I got the issue after 22 mins or so. This is going to be very slow progress to debug - I suspect it's some memory leak of sorts as it doesn't trigger for ages. I will test with the latest code on Jessie in case it's related to newer kernels/firmware also

quicksilver

@buzz I appreciate you looking into this buzz. Im sure you have your hands full with a lot of different things and waiting around for 22 mins for a bug to show up im sure isnt your idea of fun. In the meantime I have been using save states as a work around to avoid losing game progress.

BuZz

@quicksilver Thanks. I have RetroPie 4.4 ready to be released but this is holding it up. Always bugs :-) I'm aiming for a quick workaround (as quick as possible anyway), so if for example just rolling back the GLideN64 plugin fixes it for now, I will do that (and we can work out the cause and a fix later).

quicksilver

@buzz I have done a fair amount of researching the issue (here and on reddit) and I can find similar reports of this happening going all the way back to August 2017. Its hard to know for sure if its the same issue but some of the descriptions are uncannily similar. Im sure most people who encountered this issue just chalked it up crappy N64 emulation on the Pi. Im not a programer but if there is any leg work you need me to do to help you out, just let me know.

simonster

Just in-case it helps diagnose it:

I've just fired up some N64 games on fresh Stretch install on Pi3B+ (new 4.3.15 image and then updated this morning), when playing Bomberman 64 on the default settings (mupen64plus-auto) it uses mupen64plus-glide-hires and locked up completely after around 10-15 minutes. I rebooted and forced it to mupen64plus-glide. After 12-13 minutes, I got a visual glitch but it cleared itself within a few seconds and then continued to play fine for over 1 hour.

From a fresh boot, I played WaveRace64 on mupen64plus-auto and this didn't appear to be using glide as it didn't have the fps counter. This played without issue for over 40 minutes.

I did check for logs but it appears the machine crashed out before it could write anything back.