ES lag after updating underlying OS
-
@gaavoid The exact shit happened too me they might need to test updates privately before throwing them to the public now they have more to work on then they updated but however I will admit they finally did the favorites and that is a 👍👍👍
-
@tundra Emulation station isn't the issue exactly here. The newest ES for retropie is working perfectly on the raspbian version that was current for when retropie 4.2 was released, but now having issues with an updated version of raspbian which is available to download/update through the retropie setup since at least 4.2.8 (now 4.2.10) when selecting update all packages/update underlying OS (kernels etc).
-
I've figured out where the terminal logs are. I'm going to reflash my 4.2 build and update everything. It will take a while, but will post when it's done.
-
@pjft After a few shutdowns and reboots, the lag seems to have stopped when scrolling through the game lists (not sure why this was necessary). Also, good advice on changing the vram limit to 80: this stops the white screens happening. I did save the log but seems redundant to post now, as everything seems ok.
Thanks for the help.
Also, just a query. Does adjusting the vram limit in ES affect retroarch in anyway?
I'm guessing the white screens occur when there's not enough memory to load the images when scrolling quickly through the systems.
-
@gaavoid Thanks for the update - good to hear you're not having many more problems these days.
The VRAM setting doesn't affect RetroArch in any way - when you exit EmulationStation, all textures will be unloaded from memory, so the emulators have access to as much memory as possible. That's also why sometimes after returning to ES from an emulator you may see some images missing and loading for a split-second - as it's trying to load everything back at once.
The white screen would happen in the past when trying to load images when scrolling quickly through the systems. It shouldn't happen in principle these days, though I know of a place where it does, after a recent change, and I have that on my shortlist to address.
I have no clue as to why the lag would have stopped after a few shutdowns and reboots, honestly.
I may get VRAM to be set to 80 as a default, and truth be told we should be able to limit that as every now and then I read about people setting it to 300 or so which is just a recipe for disaster.
-
@pjft I always thought increasing the vram would increase the amount of images loaded at once and improve ES performance. In fact before I asked this question here, I did increase it to 200 to see the results and ES basically crashed .
I wouldn't have thought to reduce it until you suggested it.
80 as default is a good idea. -
@gaavoid Updating all packages and kernel worked alright? I wanted to update today but didn't want to risk breaking anything if the current OS version is conflicting somehow.
-
@thewinterdojer Honestly seems fine. When updating it was stuck on -
"Unpacking raspberrypi-kernel-headers (1.20170703-1) over (1.20170303-1)"
for over an hour, so just warning it'll take some time.
Directly after that had finished the next line was -
"dpkg: warning: unable to delete old directory '/lib/modules/4.4.50-v7+': Directory not empty"
Not sure if that's anything to be concerned about (anyone?).
Other than this, the OS update installed fine, and after shutting down the system (twice I think) there was no lag. It could be that when I updated previously, something went wrong (or maybe I didn't shut down my Pi after and I assumed something was wrong).
I had about 1.8gb of space left on my 64gb micro sd. The last (final) time I reflashed my image and updated, I deleted all of my FBA roms as there is a new rom set for the newest FBA. I don't know if freeing up more space is the reason the lag stopped but is a factor to think about.However, it does seem necessary to reduce the vram limit in ES to 80 when using themes like comicbook and retrorama. Pixel is fine on 100.
This didn't seem to be needed on the previous OS version, but I may not have done enough testing to realise the issue was present there too. -
@gaavoid Awesome thank you. Even though it's not necessary I always want to be on the latest and subjectively, the greatest. That is strange though, updating packages and OS has always taken me less than 20 minutes, but maybe because I update a lot so it doesn't have a lot to go through. Also, I'm not sure if you know this but when we use the update all packages option is that updating from source or binary?
-
@thewinterdojer Binary, I believe.
I haven't updated at all since March until now, so could be why it took so long. Emulators/Emulationstation/Retroarch etc. only took about 20 minutes to update.
It was just the kernel headers which took a very long time.
Contributions to the project are always appreciated, so if you would like to support us with a donation you can do so here.
Hosting provided by Mythic-Beasts. See the Hosting Information page for more information.