Viewing 12 posts - 36 through 47 (of 47 total)
  • Author
    Posts
  • #94243
    ceuse
    Participant

    [quote=94233]Default gamelists are sent here:
    /home/pi/.emulationstation/gamelists/{systemname}

    If you dont use ES to scrape, the gamelists will often be in the rom dir.
    [/quote]

    I put them in the Rom dirs. I dont know if they are handled diffrently then the ones in the gamelists folders but i think it shouldt.
    Just wanted that info for the sake of completing the information to reproduce the issue :-)

    #95585
    paradroyd
    Participant

    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.

    #95606
    ceuse
    Participant

    [quote=95585]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.
    [/quote]

    I cant wait that long :-( whats the trick

    #95628
    Anonymous
    Inactive

    I’m wondering if this is related at all to this issue:
    https://github.com/Aloshi/EmulationStation/issues/172

    Specifically, the part where Aloshi says that the lack of a particular video card feature (missing on the Pi1B, don’t have a Pi2 yet to confirm), combined with the lack of texture caching in EmulationStation, would likely cause errors with too many systems enabled.

    #95653
    paradroyd
    Participant

    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.

    #95675
    ceuse
    Participant

    Mh that kinda proves my suspicion. but yeah your right without any theme / gamelist new system should be addable almost unlimitled (although the font/tab itself will cost some graphical power). im betting you though that if you would add gamelists / expand your gamelist.xml files your number of systems would go down.

    Its a matter of unoptimised code / handling of the data wich fills the ram with alot of unnececary stuff you wont need/only need later.

    i hope they change the behaviour to something Kodi like where the metadata gets loaded after you actually enter the according menue / when you scroll to the specific film.

    #95684
    paradroyd
    Participant

    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.

    #95857
    taalas
    Participant

    Just wanted to chime in as I am experiencing this issue as well when adding another emulator on RPi2, latest ES from binary installation.

    #95907
    ceuse
    Participant

    a push on my github issue would be apreciated then ;-)

    #95963
    taalas
    Participant

    bumped your issue on GitHub

    #101437
    ceuse
    Participant

    Bump after quite some absence (completly reinstalling/reconfiguring after a sd card crash sucks so i took a break). is this bug fixed with beta 4 now? and what are the overall changes :-)

    #101489
    sselph
    Participant

    Emulationstation hasn’t seen much development since Aloshi got a job in March so I don’t think there has been any change to this issue.

Viewing 12 posts - 36 through 47 (of 47 total)
  • The forum ‘Everything else related to the RetroPie Project’ is closed to new topics and replies.