SOLVED: The CF causes processor overload UNLESS fixdisk used to optimise hard drive again
- Thread starter mihaid
- Start date
Black Hole
May contain traces of nut
Works for me, both via the Diagnostics page and via the command line. Set safe mode and then reboot, access to WebIF gets this:
in which way does that help me?
MymsMan
Ad detector
It shows what the webif should be showing after rebooting into Safe mode
Are you still on a downlevel CF level?
Yes, because 3.13 doesn't have the iplayer anymore
Whether or not iplayer still works doesn't depend on the custom firmware version; it depend on the standard firmware version. Last time I tried with 1.03.12_mod_3.13 iplayer worked.
Black Hole
May contain traces of nut
What are you talking about? Standard firmware lower than 1.03.xx no longer supports iPlayer, so you won't want CF 3.13 for 1.02.20 (for example), but there's no reason you can't install CF 3.13 for 1.03.12.
So that probably explains why you are having problems following our instructions. Stop wasting our time and get your installation up to date.
To reduce the logged ouput, you could tweak it like this:
Code:
#!/bin/sh
# ignore below total CPU threshold in %
CPU_THRESH=65
# polling interval in second
INTERVAL=5
LOGFILE=/mod/tmp/cpulog.log
# number of busy processes
TOP_NUM=5
# extra ps columns
PS_COLS="pmem,pid,ppid,args"
# sort order - busy first, + busy last
UPDN="-"
total() { # sum integers from stdin to stdout
local sum=0
local ii
while read ii; do
sum=$(($sum + ${ii%.*}))
done
printf "%d" "${sum:-0}"
}
echo "log top $TOP_NUM processes to $LOGFILE when CPU usage > $CPU_THRESH"
PS_COLS="pcpu,$PS_COLS"
hdr="$(ps -o $PS_COLS | head -n 1)"
case $UPDN in
'+') crop="tail";;
*) crop="head";;
esac
while true; do
# "ps | total()" is much more efficient than using the system idle percentage from "top -b -n 1"
[ "$(ps -e -o pcpu --no-headers | total )" -ge $CPU_THRESH ] &&
{ echo "${hdr} ----- $(date '+%F %T %Z')" &&
ps -e -o $PS_COLS --sort=${UPDN}pcpu --no-headers |
"$crop" -n ${TOP_NUM}; } >> "$LOGFILE"
sleep $INTERVAL
doneUPDN parameterisation to switch head/tail.As with the original, you need the procps version of ps. The busybox applet doesn't know about CPU usage.
For best results, run this in the background
cpulog & or using an abduco session abduco -n cpulog cpulog.
Last edited:
Yes Sir
awww, it brought back memories of downloading it via the aerial and getting sconcsed when it stopped at such and such a prcentage.
as soon as new firmware was installed, the page in post 62 appeared
Last edited:
I am out of safe mode for now. will go into it later this afternoon.
i think you might have missed my post being edited
Among other possibilities: run a manual backup and compare that file with the automatic backup.
It could be helpful to compare this thread with a previous related thread from the same OP.
Is this the same box?
What is reported for the disk (SMART status), eg from Webif>Diagnostics>Disk Diagnostics?
Is this the same box?
What is reported for the disk (SMART status), eg from Webif>Diagnostics>Disk Diagnostics?
that is the same box but totally different circumstances. that thread was about cropping during recording.
so, in safe mode I watched a hd recording of 30 min, damn those ads, and no pic breakup when I would've expected a couple or at least one.
if you want to record an hd program you want to keep, turn the damn CF off.
In both cases, you're reporting pixellation apparently related to background processing.
As this doesn't seem to affect all, or perhaps even most, users, the question arises whether there's some root cause associated with your, or some subset of, HDR boxes. With consumer electronics it's not likely that you just have a "Friday afternoon" model (like the boiler PCB I had with a connector soldered in backwards). One possible source is a problem with the disk, which is why I asked about the SMART data.
I can confirm from experience that a failing disk does cause picture break-up, though I never went to the length of trying safe mode to overcome it.
As this doesn't seem to affect all, or perhaps even most, users, the question arises whether there's some root cause associated with your, or some subset of, HDR boxes. With consumer electronics it's not likely that you just have a "Friday afternoon" model (like the boiler PCB I had with a connector soldered in backwards). One possible source is a problem with the disk, which is why I asked about the SMART data.
I can confirm from experience that a failing disk does cause picture break-up, though I never went to the length of trying safe mode to overcome it.
there, it was a process I could control: cropping.
here, no control. as I said: quite different.
i'm sure I checked the smart thingy fairly recently and it was just fine. can't do it now, cause safe mode
Just watched a full over 2 hrs show and unless all the pic breaks were during ads the recording was pristine.
think i found the culprit
Black Hole
May contain traces of nut
No, you've just eliminated some of the potential culprits. Saying that the CF (as a whole) is the culprit is tarring everything with the same brush.
hmmm,
let's see: one other guy posted cpu graph which shows a regular 100% peak, just as my cpu NOW on 3.13v peaks at 100%. it stands to reason that the CF overtaxes the tiny processsor
Black Hole
May contain traces of nut
The minor peaks are every 10 mins when the auto-processing scan kicks in, the 100% peaks are when the scan found something to do after a recording was made (I don't know what the 6am one was about!). However, the CF threads are given a much lower priority than the Humax processing threads, so although the processor maxes out the standard tasks should not be inconvenienced.
I think there are many other lines of inquiry: for example, are you sure the extra RF interference created when the box is working hard isn't affecting your UHF reception?