Slow boot and shutdown compare to 3.2.1

[chillimonster]

Evening

I’ve recently done a clean install of 3.5, installed all the same rom folders / configs / settings etc so its idetical to my 3.2.1 setup, but it takes an AGE to boot or shutdown.

Whats changed to make it so slow?

At first i thought it was something i’d done so started from scratch and same result.

Any help or suggestions appreciated

Chilli

[herbfargus]

It writes all your changes on shutdown like it should, where it would not before as there was a bug. If you’re a romhoarder then it will take significantly longer just because it’s writing all the changes for all the roms it’s just how emulationstation is coded. You can shut it down over ssh but it won’t save any changes (last played metadata etc.)

[shmoopty]

herbfargus, is there policy posted anywhere regarding pull requests to RetroPie’s fork of EmulationStation?

I appear to be a ROM hoarder too, but I’m not above taking a crack at improving that quitting time.

Related – I know that XML is popular here, but a single SQLite file could be written to as these changes happen rather instantly. Has that idea been raised/dismissed yet?

[herbfargus]

Policy is we don’t really want to maintain emulationstation with everything else as we still have hopes it will be picked up upstream.

We already have a branch that is built off of sqlite but the jury is still out on the benefits of it- it would require lots of testing and discussion for us to determine it is a viable enough improvement for us to make that change.

[shmoopty]

Keep me in mind if you need to throw bodies at it.

– Shmoopty

[herbfargus]

I don’t have the time currently with uni for any testing but I’d be interested in seeing results with the sqlite branch (especially as you have a large collection of roms) in comparison to what we have now.

[chillimonster]

Thanks for the reply :-)

So the issue is the 14,000 roms (29,000 if you include C64, Spectrum and the other computers)

I’ll probably stick to 3.2.1 for now then .

:-)

[zigurana]

There certainly are benefits of going to the gamesdb branch, as is would allow for much more flexibility in how ES presents its lists of games. Filtering, sorting, across platforms, per publisher,etc. These things are now completely out of the question.

What it does *not* necessarily mean though, is performance improvements over the current xml approach. It will need a strongly optimized implementation to even break even. Like Herb said much testing and discussions on how we would like to see this implemented.

I would argue that we could start the discussion already, and see if there is some kind of consensus on what improvements we need/expect for this significant step.

[herbfargus]

It’s a fundamental issue of the coding at this point. There is a simple workaround where we could add another shutdown option in emulationstation like a quick shutdown that doesn’t save metadata but of course that really isn’t a solution, rather if anything it would just make the menu more confusing.

[labelwhore]

SQA Testing is what I do. So I’m here if and when that’s needed.

[herbfargus]

I’ve posted an official ticket on github here:

https://github.com/RetroPie/EmulationStation/issues/34

Just gives an official place for discussion and testing on the aformentioned issues.

[shmoopty]

Agree that another shutdown option would just be option bloat. RetroPie has an unusually clean interface and that’s just beautiful.

I haven’t pulled down the SQLite branch yet, so I don’t yet know if that branch imitates the main branch in saving ALL metadata when it quits, or whether it just saves changed metadata as it changes. If it’s the later (now or in the future) I suspect that quitting would be very fast.

[Author]

Posts