EmulationStation often crashing when using themes other than the default

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