• The forum software that supports hummy.tv will be upgraded to XenForo 2.3 on Wednesday the 20th of November 2024 starting at 7pm

    There will be some periods where the forum is unavailable, please bear with us. More details can be found in the upgrade thread.

Runaway processes

J

JoeBloggs911

Member
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.
 
peterworks said:
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.
Click to expand...

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.
 
MymsMan said:
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.
Click to expand...

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.
 
MontysEvilTwin said:
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.
Click to expand...

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?
 
JoeBloggs911 said:
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?
Click to expand...
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
 
MontysEvilTwin said:
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
Click to expand...

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.
 
You must log in or register to reply here.
Back
Top