Viewing 12 posts - 36 through 47 (of 47 total)
  • Author
    Posts
  • ceuse
    Participant
    Post count: 96

    [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 :-)

    paradroyd
    Participant
    Post count: 5

    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.

    ceuse
    Participant
    Post count: 96

    [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

    Anonymous
    Inactive
    Post count: 67

    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.

    paradroyd
    Participant
    Post count: 5

    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.

    ceuse
    Participant
    Post count: 96

    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.

    paradroyd
    Participant
    Post count: 5

    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.

    taalas
    Participant
    Post count: 56

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

    ceuse
    Participant
    Post count: 96

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

    taalas
    Participant
    Post count: 56

    bumped your issue on GitHub

    ceuse
    Participant
    Post count: 96

    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 :-)

    sselph
    Participant
    Post count: 170

    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.