EmulationStation often crashing when using themes other than the default

pjft

@viperacidzx Thanks. Of course, apologies. I'm referring to the ES log file. You can find it on

/home/pi/.emulationstation/es_log.txt

Also, if you can send over your settings file, it may shed some light into what's happening there.

/home/pi/.emulationstation/es_settings.cfg

and, while we're at it, the previous session's log:

/home/pi/.emulationstation/es_log.txt.bak

To be clear, this happens on load, is that it? The clearer it gets, the easier it will be to replicate on my end - as I was commenting elsewhere, I have unfortunately been running the latest ES for several months, not on Carbon either, but I haven't experienced any crash, so the more details I can get to get to the same state as you the easier it'll be to sort it out.

I think the only difference I have on my end is that right now I'm on a Pi4, but hopefully that's not a factor. If it is, I suppose I can dig out an old Pi3 and reinstall RetroPie to test it out.

Thank you!

ViperAcidZX

@pjft Yes, it happens on load as soon as I boot the Pi, or in the other instance I mentioned, when switching themes. Here's the contents of both EmulationStation logs as well as the settings file.

pjft

@viperacidzx Can you edit, in es_settings.txt, "ThreadedLoading" to false and see if that changes anything?

Change

<bool name="ThreadedLoading" value="true" />

To

 <bool name="ThreadedLoading" value="false" />

I also saw several warnings from the theme but I'll assume they're not related for now.

ViperAcidZX

@pjft Setting Threaded Loading in the ES settings file so far seemed to have fixed the crashing at the moment. I have resetted my Pi about 10 times in a row and it hasn't crashed, and I also done full shutdowns and reboots on the Pi to further test if Threaded Loading was the possible cause and it hasn't crashed either.

pjft

@viperacidzx Sounds good. Keep us posted if anything changes on your end, and at least this gives us some suggestion of what to look at.

pjft

@ViperAcidZX to confirm, it also solved the crashes when switching themes? Just to infer whether they had similar causes or are two separate issues.

ViperAcidZX

@pjft I just tested switching to various themes I have installed — Pixel, Simple Big Art, SNES Mini, GBZ35, Carbon, Carbon (2021), and installed the PlayStation theme — and cycled through them a bunch of times to be sure and so far that also has not caused EmulationStation to crash since turning off Treaded Loading. Thank you for the help and I'll keep an eye out if anything else happens.

Genos98

@pjft What does threadedloading do?

wmarcio

@genos98 I can't say, but it seems to choose a processor core to load the emulationstation.

Genos98

@wmarcio thanks. Yeah I've also noticed that es would crash randomly on start up but it also doesn't happen a lot. But it's pretty frequent with the snes/nes mini theme by ruckage that's why I avoided using the theme for a while.

pjft

Thanks for confirming, and apologies for missing the replies. Threaded Loading was a change that intended to boot ES faster by using parallel threads for loading the different assets. It seems that it's causing some issues, so we now changed it to default to OFF, and will look into fixing it.

Would any of you be able to test out a build with a potential fix, if we provide the instructions?

WeirdH

@pjft said in EmulationStation often crashing when using themes other than the default:

@viperacidzx Can you edit, in es_settings.txt, "ThreadedLoading" to false and see if that changes anything?

Change
<bool name="ThreadedLoading" value="true" />
To
 <bool name="ThreadedLoading" value="false" />

Oh wow, after preliminary testing, this seems to have fixed the only issue I was still having with my cab: occasional lock-ups when quickly scrolling through ES...!

I didn't even have the 'threaded loading' entry in my es_settings.cfg, so I just added it, hopefully it won't mess anything up.

EDIT: alas, I celebrated too soon. Still froze today, unfortunately.

ViperAcidZX

@weirdh Are you using the standard or Dev build of EmulationStation? I've been using the Dev build of EmulationStation and it has the threaded loading setting in my configuration file and turning it off seemed to have fixed the problem so far for me.

WeirdH

@viperacidzx Probably just the standard. Where could I check up on this?

yewox50273

@weirdh said in EmulationStation often crashing when using themes other than the default:

I didn't even have the 'threaded loading' entry in my es_settings.cfg, so I just added it, hopefully it won't mess anything up.

some guesses:

a) there is a ThreadedLoading entry that you missed, or
b) you're looking the wrong es_settings.cfg (some other path)

sleve_mcdichael

@weirdh said in EmulationStation often crashing when using themes other than the default:

@viperacidzx Probably just the standard. Where could I check up on this?

Did you manually install the -dev version from experimental packages?

You can check in:

RetroPie-Setup > Manage packages > Manage (core/experimental) packages > emulationstation(-dev)

Only one should say "installed" since whichever one you do install will remove the other version first.

yewox50273

@sleve_mcdichael said in EmulationStation often crashing when using themes other than the default:

@weirdh said in EmulationStation often crashing when using themes other than the default:

@viperacidzx Probably just the standard. Where could I check up on this?

Did you manually install the -dev version from experimental packages?

You can check in:

RetroPie-Setup > Manage packages > Manage (core/experimental) packages > emulationstation(-dev)

Only one should say "installed" since whichever one you do install will remove the other version first.

it wont' matter I think. dev build simply makes ThreadedLoading to false by default when the entry isn't there. if you explicit set ThreadedLoading to false then dev or not it will still take effect.

pjft

Hi all.

If you currently install the emulationstation-dev package from source and turn on threaded loading again, we just pushed a fix that we hope has addressed the previous issues.

If someone who used to be able to replicate this consistently can try it out we'd love the feedback as we can't replicate it on our end.

WeirdH

@pjft Sorry, lost track of this topic, mostly because my freezing was solved months ago by setting 'only parse gamelists' to on. I only just installed the -dev version yesterday, now with threaded loading set to true. Will report back if I encounter anything of note.

Lolonois

If I connect the dots here and in addition to the merged changes [1] @pjft was referring to, I see also the option that the file log might choke caused by a specific combination of many log writes, threaded loading and slower file operations by rpi3 and/or sd-card (or even undervoltaging, which is crucial to sd-card operations).

While I am unable to reproduce it, it might be considered to reduce the log output of missing theme resources by lowering the log level (WARNING to DEBUG). It would reduce the probability of file log chokes and would also speed up the normal ES boot:

diff --git a/es-core/src/ThemeData.cpp b/es-core/src/ThemeData.cpp
index cb1b265..45b54a6 100644
--- a/es-core/src/ThemeData.cpp
+++ b/es-core/src/ThemeData.cpp
@@ -517,11 +517,11 @@ void ThemeData::parseElement(const pugi::xml_node& root, const std::map<std::str
                        if(!ResourceManager::getInstance()->fileExists(path))
                        {
                                std::stringstream ss;
-                               ss << "  Warning " << error.msg; // "from theme yadda yadda, included file yadda yadda
+                               ss << "  Message " << error.msg; // "from theme yadda yadda, included file yadda yadda
                                ss << "could not find file \"" << node.text().get() << "\" ";
                                if(node.text().get() != path)
                                        ss << "(which resolved to \"" << path << "\") ";
-                               LOG(LogWarning) << ss.str();
+                               LOG(LogDebug) << ss.str();
                        }
                        element.properties[node.name()] = path;
                        break;

Additionally a mutex for log file write operations might be used as outlined here [2] to make fprintf() [3] thread safe.

[1] github.com/RetroPie/EmulationStation/pull/774/files#diff-20f861dd5841312f45eb90d5a56cd5addad0657c66605d6235696a345907e15d
[2] https://stackoverflow.com/questions/43427405/c-writing-to-a-file-in-multithreaded-program
[3] https://github.com/RetroPie/EmulationStation/blob/52c04d77864287aa0ae7f484460966d8253079df/es-core/src/Log.cpp#L77