Running PCSX games with bios crash kodi

[matejmosko]

This behaviour started after libretroí compatiblity was upgraded to 1.0.38.107. Before, games worked quite fine.

Starting any game results in black screen, kodi freezing not responding to any buttonclicks and eventually to rebooting. I have tried to delete .sav and .xml files - no change. This is a regression. It worked fine before.

Important: Before the upgrade every first run of a game resulted in a black screen, but kodi didn't freeze. All consecutive runs of a game were successful. Therefore this is not the same as #9

Kodi: Libreelec (Milhouse's build 715)
System: RPi3
Kodi log
Crash log

[garbear]

I think I fixed this a while ago, but can't find the commit now. IIRC the problem was that audio packets were arriving too early. @lrusak did you hang onto that commit?

[garbear]

xbmc/xbmc#14194

[matejmosko]

Unfortunately, it didn't help. I upgraded to milhouse's 718 and the result is same.

Log: http://paste.kodi.tv/vimorayoze
Crash log: http://paste.kodi.tv/sikokekahi

[garbear]

Can you try xbmc/xbmc#14203?

[GTechAlpha]

Also libretro/pcsx_rearmed#178 .

[matejmosko]

Ok, so I will wait until cores are updated again sometime in future.

[matejmosko]

Bad news. It didn't help. All necesary PRs are finally in milhouse's libreelec build (pcsx is updated as well), but psx games still freeze and crash kodi on libreelec.

Kodi log: http://paste.kodi.tv/atutaxuviy
Crash log: http://paste.kodi.tv/hadamusepi

@garbear, @GTechAlpha, any ideas?

[GTechAlpha]

The stack trace in your log is identical to what I experienced before libretro/pcsx_rearmed#178 was applied. I think the fix somehow didn't make it in to the build you're using.

[matejmosko]

I am not sure how it is possible. According to this commit LibreELEC/LibreELEC.tv@88dc980 pcsx in libreelec now includes all commits including yours. I have double checked, my pcsx addon is updated to this version.

Moreover my latest kodi log is different to what it was before the update of pcsx addon.

[cdu13a]

For consistency I just tried this on milhouse's latest build for the pi #0809. I got the same crash and restart behavior.

This behavior only happens if the bios file is located. If you delete the bios file then the game plays, but occasionally has issues, where after a bit of game play framerate drops to frames per minute(or sometimes screen just goes black and game play stops) and the cpu usage spikes. Will Try to get a complete log of this alternate behavior using the milhouse build. edit: Log from when bios is not found

Logs and Configs: http://ix.io/1jPQ

[matejmosko]

Thanks @cdu13a, renaming bios folder so games run without bios makes them work on milhouse's libreelec. I haven't encountered any stuttering yet. However it probably depends on the game.

EDIT: Stuttering is here :)

[matejmosko]

Just for future reference, ghizzu reported similar issue on retroplayer forums (windows build) post 2080

Ghizzu's log

[garbear]

Ghizzu's error is fixed: xbmc/xbmc#14313

[cdu13a]

thanks, @garbear
Just did a test build and xbmc/xbmc#14313 fixes the games crash on launch problem.

[garbear]

Nice. Can this be closed?

[matejmosko]

Not yet confirmed on libreelec. Tomorrow I will test new milhouse's build and report.

[cdu13a]

@matejmosko sorry I wasn't more specific. it was a build of libreelec I tested this on.

[matejmosko]

@garbear, this issue is not solved for me.

I have tested milhouse's build 817 now. For me it didn't help at all. The behaviour is still the same. Playing with bioses crashes kodi, playing without them suffer from stuttering. @cdu13a , have you done anything else except upgrading?

Logs with bios (game freezing after a second, than kodi crashing)

• crashlog
• kodi log

Logs without bios (game runs, but stuttering makes it unplayable)

• kodi log

The game was working fine on the same device (RPi3) back in ~ march releases.

[matejmosko]

I have found a way to make psx games with libreelec to temporarily work. Even though the stuttering - random slow downs and bursts of quick movement - is still an issue even with a bios. In march releases I have not encountered such behaviour in psx games on same device.

1. Start Kodi
2. Uninstall pcsx-rearmed
3. Install pcsx-rearmed
4. Start any psx game to force the core to create folder in addon_data The game works (with stuttering)
5. Exit game.
6. Move bioses in correct folder.
7. Start any psx game. The game works. (With stuttering)
8. Exit game and reboot kodi.
9. Start any psx game. Kodi crashes after a second.

Kodi log for steps 1-7

Kodi Log for steps 8-9
Crash Log for steps 8-9

[cdu13a]

@matejmosko I just did the same thing on milhouse #817 as I did on my own test build.

deleted the .sav files
uninstalled the game addons(removing settings)
updated libreelec
reinstalled game.libretro and game.libretro.pcsx-rearmed both from the libreelec addons repo
added bios files,
loaded several different games, played a bit. (all games bin/cue format)
played crash bandicoot for 30 min

This was on a pi2. So did not get full speed from the games. A bit of a lag and some audio issues. However other cores also don't hit full speed on the same device, and other parts of kodi are slow as well so that's probably not pcsx specific. (At least not while using a bios file)

[matejmosko]

Some news on the issue.

1. Stuttering is probably related to undervoltage of my adaptor. Whenever the game slows down, RPi complains about low power. High power demand is probably related to cpu hogging (~160%) of pcsx emulation. Consider this unrelated to bios issue.

2. I have found out that I don't have to reinstall pcsx everytime after reboot. But what I have to do is really strange. First I have to delete all bios files, then start any psx game without bios, exit game, move bios files into right folder and then run the game. If I don't do this after each reboot, psx games with bios crash kodi immediately.

First I thought the problems were in settings part, now I really don't know what can cause such a weird behaviour.

[garbear]

A confounding factor could be both in-game saves and memory saves (savestates). In-game saves are placed in userdata, savestates next to the ROM. Maybe the presence of either of these is affecting the results?

[matejmosko]

Ok, I have tried to delete savestates as well as ingame saves now. No difference. Game with bios crashes kodi.

[garbear]

OK, next step we cut kodi out of the equation. Can this be reproduced on RetroArch?

[matejmosko]

I don't have retroarch set up on the RPi, so I tried it on ubuntu (snap version) with same game and same bioses. Retroarch works flawlessly. Is it necessary to try it on the RPi3?

[garbear]

I'll try to reproduce on desktop Ubuntu with Kodi

[cdu13a]

I didn't think of testing after a reboot, to see if it changed anything. After all why should a reboot change anything.

Possibly related is that pcsx-rearmed doesn't respect it's settings, on reset of the core. So it is possible to have the bios/boot logo in the savestate, when the core is not set to show it, which results in a crash on launch of the game. edit: Reset of the core without the bios also results in crashing.

[GTechAlpha]

Reverting xbmc/xbmc@2bbd26f fixes it for me.

[garbear]

Reverting the commit fixes the crash when running PCSX games with a bios? I can look into this, but there seems to be several problems listed in this issue.

[GTechAlpha]

Reverting the commit fixes the crash when running PCSX games with a bios?

Yes.

[garbear]

OK. The bug is logged in garbear/xbmc#80. I'm actually starting a new job soon so time might be a little too tight for me. But at least you identified the offending commit.

[KOPRajs]

Hi,
I've come here to fill in a bug report but it seems I'm late to the party. It looks like the PCSX-rearmed core needs to be initialized without BIOS for the first time. After first run without BIOS you can place the BIOS back and everything works until next Kodi restart. If there is a BIOS file present upon first run it crashes while trying to load it. It seems like there is an uninitialized variable related to BIOS loading.

Users see black screen because LibreELEC launches gdb in background to create a core dump and it takes a while.

[hansbogert]

Hi,
I've come here to fill in a bug report but it seems I'm late to the party. It looks like the PCSX-rearmed core needs to be initialized without BIOS for the first time. After first run without BIOS you can place the BIOS back and everything works until next Kodi restart. If there is a BIOS file present upon first run it crashes while trying to load it. It seems like there is an uninitialized variable related to BIOS loading.

Users see black screen because LibreELEC launches gdb in background to create a core dump and it takes a while.

You sure? In my case just seems to crash on the fact that there is savestate (not in-game)

[KOPRajs]

I'm still not 100% sure what's the root cause of the problem but it seems that moving Streams().Initialize() back to InitializeGameplay() solves it.

@garbear Please look at the patch. If it is safe I can create a PR.
KOPRajs/xbmc@66df811

Also I've discovered another code path where the current master crashes with PCSX-rearmed and BIOS:

1. Restart Kodi.
2. Run any PSX game without controllers connected.
3. Press back on the controllers info screen.
4. Select Exit in the game OSD.

In this case Kodi crashes on RetroPlayer deinitialization. The above patch seems to fix this as well.

P.S. Possibly the BIOS itself is not the cause, more likely the lack of BIOS triggers an error during initialization and that changes the code path and avoids the crash.

P.P.S. From the original PR #14146 description: "A second fix for a potential segfault (only observed while testing) is also included." Not very helpful but that is probably the cause of this issue.

[KOPRajs]

@garbear Do you remember what was the reason to move the Streams().Initialize() from the InitializeGameplay() to OpenFile() in xbmc/xbmc#14146?

[garbear]

Kind of. The libretro API is underspecified as to when these functions should be called. See what information you gleam: https://github.com/kodi-game/game.libretro/blob/master/src/libretro/libretro.h

To see if your patch is correct, you need to map it to which libretro API calls happen when. At the end of the day it's all about libretro. Try to follow the existing code to libretro calls and see if the order violates libretro specification or conflicts with the order expected by the core.

[garbear]

I just re-read the PR and it seems I was very explicit in why the function was moved. Check the individual commit messages. If you still need help I don't have any development hardware but I can follow and explain the source code.

[KOPRajs]

I've read both the PR description and the individual commit messages. It seems that most of it applies to the split of the CGameClientInput::Initialize() to CGameClientInput::Start() and CGameClientInput::Deinitialize() to CGameClientInput::Stop() and to the changed order of related calls to solve the segfault caused by connecting the controllers too early. The above patch does not revert anything of that.

Then there is a statement saying: "This commit also corrects the order of init/deinit for other game add-on resources."
I believe it applies to the move of Streams().Initialize(), Streams().Deinitialize() and a few playstate variables. I can see why the Streams().Deinitialize() and the playstate variables were moved to the if statement but it is not clear why Streams().Initialize() was moved from InitializeGameplay() to OpenFile().

The above patch only reverts the Streams().Initialize(), the rest of the original commit is left intact.

[KOPRajs]

Since everything works for some time now I would consider closing this as solved.

Or are there any known drawbacks related to the revert?

[garbear]

Shall I close?

[KOPRajs]

We have moved Streams().Initialize() back to InitializeGameplay() before Leia release more than 2 years ago and I haven't heard about any related problems since then.

Maybe it is going to be revised when we finally get GL support (I really hope for this to happen as soon as possible).

[KOPRajs]

@garbear Well, it's been 5 years since we fixed this. Time to close? ;-)