Pi Zero Process or Processes Seem to Hang After Exit

[slappymcphee]

Since I am so new to omxplayer and not too great with linux just yet, I am hoping to get clarity on an issue that I am seeing with my Pi Zero W when using video previews in EmulationStation. I notice that no matter how I encode my mp4 files (res, fps/bitrate, audio embedded/pass-thru, etc) that when a video plays my CPU maxes out during that time and then when I exit back to say the system carousel screen the CPU still stays pegged at 100%. The only way that it drops is if either A) the screensaver kicks in (set to dim), B) I enter into an emulator, or C) reboot the system. Also if I just restart ES the CPU stays pegged. I am also trying ascertain how to get that CPU utilization to lower so that temps down steadily climb as I keep reading that omxplayer is able to play HD video on the Pi Zero just fine
!
. Thanks in advance for your input!

Example of how you can see the CPU spike. It then falls once the screensaver dims the screen and then once attempting to play a video again it spikes regardless of where I navigate within EmulationStation.

test 2

[jehutting]

Try to run in a terminal window the ps aux command while you are previewing and after the previewing. Can you post the output of the command? Maybe it shows omxplayer as a process so we are sure that EmulationStation is using omxplayer to view the videos. And if omxplayer is actually used for the previewing, I doubt it that omxplayer is to blame for the high CPU usage.

[slappymcphee]

Will do.

[slappymcphee]

I can share the following that I have done so far:

Below you will see the results using htop. As you can see even with the CRT theme the CPU immediately pegs the CPU with PID process 640. Then once I leave the system menu and move back to the systems carousel screen the CPU still stays that way until A) the screensaver kicks in (set to dim), B) I enter into an emulator, or C) reboot the system.

[jehutting]

I would say an issue for EmulationStation...
Why do you think omxplayer is the problem? Or, where do you see/find out that omxplayer is used? In an EmulationStation configuration file?

[slappymcphee]

It is configured in the es_config file. value is set to true:

I still need to perform the task you requested with using ps aux command. It is possible that this could be an ES issue however I am attempting to rule out the OMXplayer itself. Currently the ES default for video snaps/previews is VLC however the Pi Zero apparently doesn't have the horsepower for it or the programming for VLC isn't fully compatible with the chips or firmware on it therefore this is reason why I am exploring OMXplayer because it runs beautifully on other Pi boards.

[jehutting]

I agree to your quest in excluding omxplayer :-)

I would expect to see dbus-daemon --fork --print-address 5 --print-pid 6 --session in htop (as well as in ps aux) as that is mostly run when using omxplayer. And if my eyes don't deceive me I don't see it in your htop screenshot.

So I am curious when you preview a video, how your ps aux looks like.

[slappymcphee]

Looks like your suspicions are correct. It appears that the process that is going silly is indeed emulationstation?

[slappymcphee]

I may have spoken too soon. I didn't have both ps aux and htop running at the same time. Now with them both running you can see that something is not right as well with OP as there are multiple instances open? Could it be that ES is making multiple calls for the OP process to run??

[jehutting]

Well, htop is a more interactive process viewer, while ps only shows the overview of the running processes; no need to run them both at the same time :-)
With htop you can press the F5 = Tree button which gives you a kind of parent/child grouping of the processes. Just try it out.

Strange that only the omxplayer options are shown, and not omxplayer(.bin).

[slappymcphee]

Strange that only the omxplayer options are shown, and not omxplayer(.bin).

Is there any reason that could possibly be that you are aware of?

[jehutting]

No, I don't. But as these --layer ... are omxplayer options and a process is shown with them, I assume omxplayer is still being called; I expect that any other program will just bail out with some message as "unknown option". Are these multiple instances of omxplayer just hanging around? I don't know. Hit the F5 key to see how these processes are related to each other.

[slappymcphee]

will check and get back to you.

[jehutting]

Hi @fnkngrv

I'm a little bit confused about your EmulationStation. This is what I made of googling for EmulationStation.

Retropie is a retro-gaming machine, and yes, it can play videos using omxplayer. It builds on EmulationStation. The code is in Retropie GIthub.

The RetroPie EmulationStation is a fork of Aloshi/EmulationStation, which is abandoned (no longer being developed). This is the repository where you filed your issue (#685).

So what are you actually using? Images/code from the Aloshi website or from Retropie?

[slappymcphee]

Retropie

[slappymcphee]

So I take it I submitted for the wrong listing of emulationstation?

[jehutting]

Yes, I do think so. The Retropie has a forum, which seems to me very active. Maybe that we can find more info there. I will download an Retropie image -as it seems just like fun- and see if I can get it run with omxplayer. Any info on how you got yours up and running?

[slappymcphee]

well that is a loaded question. The best way to get started would probably be to watch a video entitled How To Install And Set Up RetroPie 4.2 Or Higher Raspberry pi 1 2 3 Or Zero 2017 by the channel ETAPRIME on Youtube.

This will give you the basics to get one up and running. Rpi 4.2 and higher actually has VLC as the default video renderer because it supports overlays and many themes now have overlays in them. In order to force OMXplayer you need to change the es_settings.cfg file to have the string value changed to True.

[jehutting]

OK...after a lot of downloading/updating/upgrading/googling/git cloning/building/blahblahblah...got (latest and greatest github'ed) emulationstation ES with the video preview up and running on an up-to-date RaspberryPi Model 3B.

Looked at the code and found that dbus-daemon --fork --print-address 5 --print-pid 6 --session doesn't appear as ES is calling omxplayer.bin.

Still don't know why the omxplayer.bin as part of the --layer ... commands isn't shown. The code uses execve() to run omxplayer. The cat /proc/PID/cmdline shows (my code modified options to check if htop doesn't cut it off) --layer10010 --loop--no-osd-oboth--win1113,196,1816,667/home/pi/suits-short.mkv. I assume this is a (standard) linux behaviour or ... firmware fault :-)

ES stopped and started omxplayer as a result of the screensaver kicking in several times. I saw no omxplayer processes hanging around...

Just ordered a Pi Zero W, so will check coming week if this makes any difference for ES.

[jehutting]

SO...on a Raspberry Pi Zero W

After several screen saver stopping and manually restarting the video preview all looks still OK (no zombies :).

Well, while writing this down my Zero froze... For about a 20-30-xxx seconds. When the screen saver kicked in, the system got responsive again (htop running again). OMXPlayer just started the new loop of the video (as it shows the frame at 4 seconds mediatime).

...And a second time, it froze for about 3 minutes. Again screen saver kicking in brought the system back running.

Will run without emulationstation to see if I get the same behaviour.

[slappymcphee]

Sorry for the delayed response. Was on business travel. Thank you again for your efforts to try and ascertain what is really going on!

[slappymcphee]

@jehutting have you been able to test further outside of ES on this by chance?

[jehutting]

@fnkngrv I tested it outside the retropie: omxplayer kept looping for two days without an issue.
I also tried my infinity-looper (see # 437) and that script ran for a couple of days too without an issue.

Strange thing is that when I went back testing the retropie videopreview, the freezing thing (as I described in above post) didn't occurred a single time?! Did I had an unlucky moment where the high CPU usage of retropie in combination with the high cpu peek during the seek of omxplayer lead to the freezing?

As in # 552 popcornmix brought raspberrypi/firmware# 824 up. Seems the same behaviour I experienced. But without the freezing occurring again I can't say if the firmware update (fix, which I haven't installed yet) works for me.

I really don't understand why the freezing occurred and why it doesn't occur anymore.

[petershaw23]

bringing this thread back from the dead, as i encountered the same issue on my pi zero. any updates?