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
