[chillimonster]

#118104

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]

#118107

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]

#118161

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]

#118196

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]

#118201

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

– Shmoopty

[herbfargus]

#118203

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]

#118214

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]

#118218

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]

#118236

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]

#118241

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

[herbfargus]

#118250

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]

#118270

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