ES lag after updating underlying OS

pjft

Huh.

That's not good. What about the emulators, do they run well?

If any of you are particularly comfortable with using SSH or so, I'd be keen in your impressions of running "top" via SSH and seeing if any particular process spikes when those freezes happen.

As for the white screens, though, that would hopefully no longer be the case. What ES version do you have? And what VRAM value do you have in the settings? Lower it to 80 or so and restart ES.

Best.

Riverstorm

I just updated to 4.2.10 and then after all packages including underlying OS. ES seems fine, scrolling through game lists seems fine too (arrow or page) but I haven't done anything extensive. Here's a screenshot while scrolling left and right in ES. I wasn't seeing any lag. Out of curiosity is it a good idea/practice to update underlying OS when updating installed packages or do you guys leave it unless there's a needed patch?

top - 10:55:50 up  1:35,  2 users,  load average: 0.57, 0.85, 1.14
Tasks: 129 total,   2 running, 127 sleeping,   0 stopped,   0 zombie
%Cpu(s): 11.2 us,  1.9 sy,  0.0 ni, 86.9 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
KiB Mem:    750636 total,   716548 used,    34088 free,   109228 buffers
KiB Swap:   102396 total,        0 used,   102396 free.   465128 cached Mem

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
 2633 pi        20   0  147460  56588  19260 R  44.8  7.5   1:04.76 emulations+
   82 root       1 -19       0      0      0 S   2.0  0.0   0:08.96 VCHIQr-0
   81 root       1 -19       0      0      0 S   0.7  0.0   0:05.10 VCHIQ-0
  114 root       0 -20       0      0      0 S   0.7  0.0   0:00.92 kworker/1:+
  129 root      20   0    8712   4692   4428 S   0.7  0.6   0:05.24 systemd-jo+
 2613 pi        20   0    5112   2564   2192 R   0.7  0.3   0:01.77 top
  448 avahi     20   0    3876   2600   2324 S   0.3  0.3   0:01.28 avahi-daem+
  475 nobody    20   0    2292   1460   1340 S   0.3  0.2   0:00.16 thd
 2273 pi        20   0   11480   3904   3264 S   0.3  0.5   0:01.11 sshd
    1 root      20   0   22848   3944   2788 S   0.0  0.5   0:03.70 systemd
    2 root      20   0       0      0      0 S   0.0  0.0   0:00.00 kthreadd
    3 root      20   0       0      0      0 S   0.0  0.0   0:01.00 ksoftirqd/0
    5 root       0 -20       0      0      0 S   0.0  0.0   0:00.00 kworker/0:+
    7 root      20   0       0      0      0 S   0.0  0.0   0:02.94 rcu_sched
    8 root      20   0       0      0      0 S   0.0  0.0   0:00.00 rcu_bh
    9 root      rt   0       0      0      0 S   0.0  0.0   0:00.09 migration/0
   10 root       0 -20       0      0      0 S   0.0  0.0   0:00.00 lru-add-dr+

pjft

I personally avoid updating anything unless there's anything I really need.

I mostly update EmulationStation, sometimes a few emulators, but the underlying OS is a trickier proposition without a backup. I've heard stories of PS3 controllers no longer pairing, etc, so in my case, if it isn't broken, I won't touch it. :)

Riverstorm

@pjft said in ES lag after updating underlying OS:

I personally avoid updating anything unless there's anything I really need.

Ok thanks pjft I was never quite sure so I'll leave it in the future unless specified. That seems to be the longest part of updating it all anyway. :)

theWinterDojer

@pjft Is updating the underlying OS the same as running:

sudo apt-get update
sudo apt-get dist-upgrade

I normally run that above, then update all packages without updating underlying OS. Wondering if I can skip that first step and just select "yes" to updating underlying OS.

BuZz

@thewinterdojer yes.

theWinterDojer

@buzz I think I may have asked that before, my apologies if I did, but thank you!

gaavoid

@pjft ES version is the newest binary (2.4.1? Sorry not at home to check). Haven't touched the vram limit which I think is set to 100. Pi isn't overclocked. I have about 20 or 25 systems, which is fine with all themes tested without updating the OS.
However with the updated OS, older less ram instensive themes like pixel/carbon were fine except for scrolling through games lists where I would experience 5-10 second freezes. My ROMs are fully scraped too, so might be more of an issue loading the scraped images or metadata (this was worse/more frequent when using retrorama/comic book).
The white screen isn't the same as the old white screen of death we used to get. It's just white for the image of the one system. Scrolling back to it seems to make it reappear so seems like a ram issue.
With comic book theme, the outline for the comic frame was still there but no images, just the name of the system on the carousel.

I did test some ROMs on Neo-Geo and PC-Engine and they seemed to work just fine.

theWinterDojer

@gaavoid I updated the OS last night and have about 2,000 titles scraped, and I have not experienced any slow down or lag when browsing the menus. It could be because of all the systems you have, I remember reading before that scraping too many ROMs can lead to slowdown when shutting down or quitting but thankfully I have not had that happen to me yet. Hopefully someone more knowledgeable can chime in.

gaavoid

@thewinterdojer start up and shut down time is fine for me on the previous OS version but was slower on the updated one. I forgot about that.

What image/RP version have you built from?

gaavoid

Also, not sure if it matters, I have an edited es_themes file with extra themes like supergrafx and pc-engine/turbografx 16 set as separate systems; same with genesis/mega-drive, SNES/SFC etc, each set up with their own config file.

theWinterDojer

@gaavoid I'm sorry if I don't understand your question exactly, but my initial Pie install was done on the latest 4.2 image. Do you mean my Raspbian version?

pjft

@gaavoid thanks. Try reducing VRAM to 80 and see if it helps with the white screens. Was everything scraped and working well prior to the update?

Do you have everything running from an SD card? It might be that the SD card got corrupted, if it is a data IO issue.

We'll see.

gaavoid

@pjft yes worked perfectly as it is now without updating the OS. Everything is running from a sandisk ultra 64gb micro SD.
I think I'll stick with using the previous OS version from the initial 4.2 update as it all seems good. Then when we get round to a 4.3 release I'll setup a new build from scratch as I feel it could be a conflicting issue from building it from 4.1.
Through SSH, is there a log I can access with the terminal info that was on screen during the update? I remember reading there was a file that couldn't be removed and it wasn't empty. This happened each time I updated the OS. There was also something in the update that said 'unstable' but I really don't remember what it was. If I can get that log, I'll update the OS to recreate the issue and post here.

Tundra

@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 👍👍👍

gaavoid

@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).

gaavoid

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.

gaavoid

@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.

pjft

@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.

gaavoid

@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.