[paradroyd]

With Kodi/Xbmc they don’t really have a choice, as the amount of metadata there is massive..but yeah, it seems like if they just did things a bit differently this wouldn’t be a problem.

On the other hand, on a Raspberry Pi 2 a massive amount of stuff works as-is, so I’m not that worried about it. I’m grateful that the project exists and works as well as it does. It’s come a long way since the early days of the Raspberry Pi 1.

[paradroyd]

Sorry for not just posting what I found outright, but after this “fix”, I started seeing what looked like unrelated lockups. On the surface, it didn’t seem like it could be related to the changes I’d made, but I did similar changes to my second Raspberry Pi 2 with an almost identical configuration and I started seeing lockups there too. The lockups only seem to affect the console port where Emulation Station is running. I can still SSH in and the affected Pi is responsive but no matter what I do, (killing processes, etc) there’s often no way to get the console back short of a power cycle. Sometimes “sudo reboot” issued from another connection will get it back, but often it simply won’t shut down so you have to cycle the power. It almost looks like a hardware problem when it happens, but I’m pretty sure it’s not. As soon as I undid my changes, the lockups went away on both Pis. That’s pretty telling.

This is why I didn’t want to just post this “fix” outright. I will tell you what I tried, in case you want to experiment with it, but make sure you back up your configuration first so you can roll it back!

If you’re not comfortable with the command line / shell, you probably shouldn’t attempt this anyway. If you screw your emulationstation setup up doing this, I’m not responsible. You’ve been painstakingly warned.

I’m posting it in the hopes that someone can get some variation of this to work stably.

FWIW, I used win32diskimager to back up my SD cards before experimenting.

With that said, here’s what I tried …

Once you get to that magic number (whatever the number is for your particular installation), if you add one more system, you will either get the white screen at the end of the first emulation station startup after that, or the next time you quit and start it again. One quick and dirty solution is to disable the theme for any systems you add above whatever your “point of no return” number is. The way I did that was to quit emulation station, then cd to “/etc/emulationstation/theme/simple”. Inside there there’s a directory for each system that Emulation Station / your theme knows about. If you want to add systems above and beyond the number of emulated systems that your system has been supporting, rename the directory of that emulated system and any more you want to add, so that emulation station can’t find it/them.

I personally did this to sega32x by renaming it to “sega32x-INACTIVE”. First I did “cd /etc/emulationstation/theme/simple”, then “sudo mv sega32x-INACTIVE”. (You can later undo this if you want my conversely doing “sudo mv sega32x-INACTIVE sega32x”). If you did it right, no matter how many emulated systems you add after renaming their directories, you should not get the dreaded hang on a white screen.

There’s always a tradeoff…

Besides the instability I noted at the beginning of this post, the other tradeoff here is that any systems you do this for will show up in the systems list with a plain white background and without the pretty banners/fonts. Your game data should still be there though, as this has nothing to do with the actual game lists. The other systems you didn’t rename the theme directories for should look the same as ever, and as I said above, if you do it right, it’s completely reversible.

[paradroyd]

I think I may have found a workaround for this. It’s not pretty but it seems to be working pretty well for me. I need to do a bit more testing and I’ll post here if it turns out to be stable.

[paradroyd]

I’ll have to try that. As it is now, I don’t have much scraped at all. If it turns out that that reduces what I can run, I just won’t scrape anything else until this is fixed.

[paradroyd]

I’m seeing the same problem on 2 Raspberry Pi 2s. The configuration on both is nearly identical because one was imaged from the other, then modified (hostname server ssh keys, etc).

I currently have a 512/512 memory split with the default theme on them. Everything works great as long as I don’t try to have more than 23 emulators active. As soon as I go above that, I get the white screen freeze described above. I can add an emulator as long as I remove one (by swapping out it’s rom folder). It doesn’t seem to matter how many roms any of them have in them, from one to a thousand.

It’s interesting that htop run in another console shows that the cpu cores are mostly idle when the white screen is up.

[Author]

Posts