Frontend uses 100% CPU when paused

[anonymous]

Trunk r20736, xv-blit renderer, viewing basic SD content that barely loads the CPU. When I pause playback, mythfrontend CPU utilization jumps to 100% (single-core machine) and stays there until I unpause.

I first noticed this after pausing a video on my laptop, running an errand, then returning to find a burning smell coming from the laptop (apparently Lenovo hasn't figured out thermal management).

[Shane Shrybman]

Heh, MythBBQ :))

Can you post a mythfrontend log with -v playback verbose option?

Does this problem occur on every pause or just some?

What was the last known working version of trunk?

[anonymous]

mythfrontend -v playback

[anonymous]

Can you post a mythfrontend log with -v playback verbose option?

I've added the log to the ticket.

Does this problem occur on every pause or just some?

Every pause... It doesn't always hit 100% CPU, but certainly much higher than during playback. E.g. mythfrontend using 40% during playback, 80% during pause.

What was the last known working version of trunk?

Hard for me to say, because I somewhat recently jumped to trunk. It was fine on 0.21-fixes, but the problem has been there since I started running trunk at r20511.

[Shane Shrybman]

Ok, thanks for the log but no signs of activity between the DoPause?() and DoPlay?(). It's doubtful we'll see anything but try again with -v all this time.

Is it perhaps Xorg that is consuming the cpu and not mythfrontend?

According to that log, mythfrontend thinks your display is interlaced. Can you check your Xorg log and see if that is really the case?

Hmm, maybe cpufreq is active and when paused the cpu is running at slower speed and hence mythfrontend appears to consume more cpu?

[anonymous]

Thanks for checking. I tried again with -v all, and there's tons of logs, but as you suspected, everything stops during the pause.

But... I went looking at the code and found this:

NuppelVideoPlayer?.cpp: 3695: if (paused) ... 3732: printf("startplaying waiting for unpause\n"); 3733: usleep(500);

Things improve if I set it to usleep(1000) - i.e. 1ms. Is there a reason this sleep interval is so short?

[Shane Shrybman]

Replying to anonymous:

Thanks for checking. I tried again with -v all, and there's tons of logs, but as you suspected, everything stops during the pause.

But... I went looking at the code and found this:

NuppelVideoPlayer?.cpp: 3695: if (paused) ... 3732: printf("startplaying waiting for unpause\n"); 3733: usleep(500);

Things improve if I set it to usleep(1000) - i.e. 1ms. Is there a reason this sleep interval is so short?

Not that I'm aware of and it does seem to be a very short sleep for being paused. I wonder why more people aren't seeing high cpu usage when paused.

Change sets touching that area are ancient so I imagine it might just be some bitrot.

It looks like a power wasting, BBQ feature and we ain't gettin' no steaks out of it! Your frontend should be using zero cpu when paused, IMHO. How large do you have to make that sleep to achieve that? (5 or 10ms perhaps?)

Good find, and thanks for digging into it!

[Shane Shrybman]

Ok, smarter minds than mine have chimed in and are saying that it is most likely that your cpu is getting clocked down when the frontend is paused and mythfrontend appears to take more cpu.

Also, the OSD is getting redrawn while paused if there is a clock in it. Coupled with the fact that your unit consumes 40% cpu with SD content suggests some non myth efficiency issues. So that could be the issue.

[anonymous]

Well, the problem system is an old AGP-based P4 on a somewhat old distro, with ATI drivers, so I guess there's plenty of potential for efficiency problems. I appreciate the pointer to cpufreq - I'll have to read up on that.

Looks like I have some chasing to do, but no sense in doing it on the commit list. :) In the meantime, I'll probably increase the sleep interval as a local fix.

Thanks for the help!

[Shane Shrybman]

Replying to anonymous:

Well, the problem system is an old AGP-based P4 on a somewhat old distro, with ATI drivers, so I guess there's plenty of potential for efficiency problems. I appreciate the pointer to cpufreq - I'll have to read up on that.

Sorry, I meant to mention it in the message. You can check the current frequency with:

$ cat /proc/cpuinfo |grep MHz cpu MHz : 1596.000 cpu MHz : 1596.000

Checking before, during and after pausing will tell you if it's changing.

[Shane Shrybman]

Ugh, just this part is the command: cat /proc/cpuinfo |grep MHz