Runaway processes

I've had several occasions in the last couple of weeks where an attempt to convert a recording to MPG went wrong: 100% CPU usage with no output. Response to webif commands or remote control became glacial or even stopped altogether. The only solution I could think of was to use my file manager to copy the file to the hard disk then delete it on the Humax; copying was extremely slow because of the CPU usage. The Queue showed it as still running, even after deletion and two reboots. It did eventually report it as failed.

On a previous occasion, I copied the original TS file back to the Humax and tried again. It did convert it, but very slowly and with high CPU usage. Today, I just used one of several converters I have on the PC which handled it with no problem.

My question is whether there's a more elegant way to halt a runaway process than by deleting the file it was supposedly working on. Also, any ideas why this problem has cropped up after two years of converting to MPG without difficulty.
 
I don't think it will resolve the problem but, if your signature is correct, you are using CF ver 3.11. This was withdrawn and ver 3.12 was released.
 
I don't think it will resolve the problem but, if your signature is correct, you are using CF ver 3.11. This was withdrawn and ver 3.12 was released.

I am on 3.12 but had forgotten to update the signature. I think I'll do it manually from now on to avoid confusion:

Web interface version: 1.4.1-4
Custom firmware version: 3.12 (build 3965)
Humax Version: 1.03.12 (kernel HDR_CFW_3.12)
Loader Version: a7.34

Windows 7 x64.
 
You could just kill the process that is hogging the CPU by telnetting into the Humax.
It is probably ffmpeg, but use the top command to see what is running, then you can kill the offender with pkill ffmpeg
(humaxtv usually also shows highish cpu but don't kill that!)
Delete the queue entry for the recording to stop it being restarted.

What version of ffmpeg are you using - 2.8 is in the beta test repository at the moment, it could be the cause or cure.
 
You could just kill the process that is hogging the CPU by telnetting into the Humax.
It is probably ffmpeg, but use the top command to see what is running, then you can kill the offender with pkill ffmpeg
(humaxtv usually also shows highish cpu but don't kill that!)
Delete the queue entry for the recording to stop it being restarted.

What version of ffmpeg are you using - 2.8 is in the beta test repository at the moment, it could be the cause or cure.

I'm using 2.8-1.

I'll your telnet suggestion when the machine is idle. Does it matter what directory I'm in when issuing the top and pkill commands?
 
As a quick test I picked a suitable file for MPEG conversion (MPEG video, MP2 audio); the recording was three hours and twenty five minutes long. I first used ffmpeg 2.8.1 to convert the file (Webif function), then I uninstalled ffmpeg, installed the old version (0.10) and repeated the process. Each run took about 15 minutes to complete (see below).
MPEG.jpg
The first run started at 9:50m, the second at 10:13 am. Both versions were similarly process hungry, typically using 70-85% of the CPU at any given time (according to top). With other hungry processes running, the unit could easily become sluggish or even lock up. Due to the similar behaviour of each version, the upgrade does seem an unlikely cause of the problems encountered by JoeBloggs911, but I cannot explain why it worked correctly for him before the upgrade.
Regarding ffmpeg 2.8 and 2.8.1, the latter has just had a small patch applied to fix a bug encountered when stream copying DVB subtitles. So unless you are copying subtitles, they behave identically.
 
As a quick test I picked a suitable file for MPEG conversion (MPEG video, MP2 audio); the recording was three hours and twenty five minutes long. I first used ffmpeg 2.8.1 to convert the file (Webif function), then I uninstalled ffmpeg, installed the old version (0.10) and repeated the process. Each run took about 15 minutes to complete (see below).
View attachment 2872
The first run started at 9:50m, the second at 10:13 am. Both versions were similarly process hungry, typically using 70-85% of the CPU at any given time (according to top). With other hungry processes running, the unit could easily become sluggish or even lock up. Due to the similar behaviour of each version, the upgrade does seem an unlikely cause of the problems encountered by JoeBloggs911, but I cannot explain why it worked correctly for him before the upgrade.
Regarding ffmpeg 2.8 and 2.8.1, the latter has just had a small patch applied to fix a bug encountered when stream copying DVB subtitles. So unless you are copying subtitles, they behave identically.

I too ran some tests today before seeing this. I manually, via Opt+ command, converted two episodes of Decline and Fall (about 1 hour each). I didn't time them, but both seemed to progress at normal speed. I later queued two episodes of Galapagos for conversion. Both failed with high CPU and no sign of an MPG file. I killed each ffmpeg process as advised in an earlier post. Later, I tried a manual conversion via Opt+ and both completed normally. This very limited test does seem to point to using queuing as the source of the problem. However, I have to say that queuing worked normally on other recent occasions, so it looks like one of those pesky intermittent issues which are so hard to nail down.

BTW, how would I go about downgrading ffmpeg to test further?
 
I too ran some tests today before seeing this. I manually, via Opt+ command, converted two episodes of Decline and Fall (about 1 hour each). I didn't time them, but both seemed to progress at normal speed. I later queued two episodes of Galapagos for conversion. Both failed with high CPU and no sign of an MPG file. I killed each ffmpeg process as advised in an earlier post. Later, I tried a manual conversion via Opt+ and both completed normally. This very limited test does seem to point to using queuing as the source of the problem. However, I have to say that queuing worked normally on other recent occasions, so it looks like one of those pesky intermittent issues which are so hard to nail down.

BTW, how would I go about downgrading ffmpeg to test further?
I didn't try queuing, I just ran directly from webif.
You can download ffmpeg 0.1 from here. Copy the file to the HDR-FOX (I save to '/mnt/hd3') and input the following commands from telnet:
Code:
opkg remove ffmpeg --force-depends

opkg install /mnt/hd3/ffmpeg_0.10_mipsel.opk
 
I didn't try queuing, I just ran directly from webif.
You can download ffmpeg 0.1 from here. Copy the file to the HDR-FOX (I save to '/mnt/hd3') and input the following commands from telnet:
Code:
opkg remove ffmpeg --force-depends

opkg install /mnt/hd3/ffmpeg_0.10_mipsel.opk

Thanks. I did that on my second machine and queued a recording for extraction to MPG. It failed as before, with constant high CPU and no MPG file. I killed the processes and deleted the queue entry, reinstalled ffmpeg 2.8-1 and tried a manual conversion from the Opt+ menu. As before, it worked fine, so it looks as if ffmpeg isn't the cause and that it's more likely related to starting from the queue.
 
Back
Top