Please Test: Adding support for "All", "Favorites" and "Last Played" systems

cyperghost

Binary for official branch of favorites was compiled - that was EUREKA hard
download for PI2/3 system is here!

https://github.com/crcerror/emulationstation-binary-archive/blob/master/PI2and3/emulationstation2.3.2RP_favorite

@pjft Thank you for your efforts. That seems to work very very nice.
But we @red2blue and me ran into diffculties to compile that.
I manually cloned the git master and then used cmake & make. No chance for official way or script @hex and @meleu

meleu

@cyperghost I'm gonna try here.

pjft

As mentioned in several occasions across the forums, you really need quite a bit of memory to compile ES, so you need to exit ES in the first place, and then run RetroPie-Setup and update from source.

cd ~/RetroPie-Setup
sudo ./retropie_setup

And then choose to Manage Packages > Core Packages > EmulationStation > Update from Source.

The Binary should not be updated.

cyperghost

@pjft I did this
Entered via SSH and killall emulationstation
checked also with ps -a there was no running process in relation to ES
and then used sudo ./retropie_setup

My PI compiled to 100% and did not link the binary. Then I lost network connection and the status LEDs were green and red were permanently on! Maybe bad current! But I just had success by manual steps. Can someone please provide checksum of binary?

Mine is 4,803,320 byte
CRC32: 7B30D56E
MD5: a829b90d9ebaf3745f48c7c4fa259c10

Zigurana

To comment on the stalling compilation when updating from source:
I've tried compiling on my Pi3 and stopped when it appeared to hang at 87% after an hour or so.

When I set the CPU/GPU memory split to 16MB for the GPU (via raspi-config), compilation succeeds in about 25 min.

Note that you need to set the split back to something sensible after compilation (256MB for the Pi3).

cyperghost

good catch.
Can you please provide CRC32 checksum?

pjft

Yeah, it is stalling at 100% in my case. Will probably submit either a bug, or update the script with a bigger rpSwap.

Thanks.

Zigurana

Here you go, i'm mobile only, so sorry for the pic.
0_1499524849325_IMG_20170708_163915723(1).jpg

cyperghost

@Zigurana Thx... I think I missed a make clean before. Or we have different compilers :(. Our checksums differ. I think there is no time to hurry in the next few days a binary would be provided ...
@pjft Why we are still on version 2.3.2RP?

jdrassa

@cyperghost I believe the version number is only updated when a new binary is generated.

Hex

@cyperghost There is no guarantee that two binaries compiled on different machines with same sourcecode will have same hash. This is due to compiler selecting different approaches to optimize which results in entropy.

TMNTturtlguy

@pjft i saw you posted to the github pull request regarding the swap settings, but i thought it would be better for me to ask my questions here since i am so far out of the loop on the last 2 weeks of development.

My question to everyone is what do we think we are doing to ES that is causing this issue in the first place? It appears that the more we develop, the more issues we are having with the compiling/installation from source. When I first started working with retropie, i never needed to exit ES to update from source. Then a few months back we both found we were stalling out and @BuZz informed us we should always exit ES and update from source from command line. That worked for us, now after a lot more development, we have once again pushed the envelope that even installing from command line causes us to time out.

Hex

@TMNTturtlguy As more code is added to ES the compiler has to keep that many references in memory while linking. The pi is already at its limit with rpSwap 512. This causes slower sd cards to take a long time to compile and results in unnecessary writes to SD. There is nothing that can be done other that thinning the functionality of ES or discarding features which are not required. I am sure many would oppose this but it will be necessary soon as more code gets added to ES.

pjft

@TMNTturtlguy hi! I know, I hope you're not overly busy with work and can at least have some time off every now and then.

@Hex kind of summarized it already, though there's a separate factor here which seems to be that compiling via RetroPie-Setup is optimized for speed, and will start two compiler processes in parallel. While that will speed things up, it will also increase memory by 2x - meaning that for each necessary increase in memory to compile ES, by running two processes at the same time that's double the amount.

So right now there are two options - either increasing the swap, or making it not parallel. When we compile manually via git clone and make, it will succeed.

Hex

@pjft Do you mean 2X for Pi zero too? It makes sense to have it for Pi3 though

pjft

@Hex I don't know, sorry. I wasn't reading the code, just profiling processes and memory usage on my Pi3.

Hex

@pjft I did this in my script


# Find how may processors we can spare for compilation. If running on faster than dual core use 2 less
proc=$(( `nproc` >= 4 ? `nproc`-2 : 1 ))

make -j $proc

pjft

@Hex Thanks.

On a separate note, I just tested your latest build and I do confirm that the description scrolls, as well as long game names on the game list!

The game names seem to stop at the end, which is the same as in the main ES.

I won't oppose, then, if the description stops at the end as well so you only scroll once, though ideally I'd be supportive of both stopping at the beginning, and not permanently looping. But that can be a separate change.

But we can probably discuss this further on the power savings thread :)

Hex

@pjft Agreed. Congrats on getting this merged.

pjft

~~Redacted~~

It's now available via Update from Binary in RetroPie-Setup. Thanks @BuZz - I had compiled the code earlier in the day and it was still 2.3.2 so I didn't know it was updated to 2.4.0.

Thank you!