SOLVED: The CF causes processor overload UNLESS fixdisk used to optimise hard drive again

Alternatively use the Telnet menu (I don't know whether it's in 3.00, it might be).
What command do you use.
Btw, have been trying to find out differences between my version and ver13 but wiki just took me in circular directions having not found what I needed
 
What command do you use.
Btw, have been trying to find out differences between my version and ver13 but wiki just took me in circular directions having not found what I needed
Type menu If you have disabled it being displayed by default.
 
Like the problem in this thread of mine?
Like the problem in this thread of mine?

I have two HDR-Fox T2. One experiences blocking on HD recordings at times. This seems to be to do with CPU processing/temperature (stab in the dark: are the tuners getting too hot?) Running the fan at Max reduces the occurances of blocking. Setting unencrypt and processing to "not whilst recording" also helps. Another option is to have the machine powered up for a couple of hours before recording commences. My newer machine doesn't experience similar issues although I have only owned it for a few months. The much more knowledgeable people on this forum will able to help identify hardware revisions. My older machine has the aerial connections next to each other. The newer one has them one above the other.
 
The much more knowledgeable people on this forum will able to help identify hardware revisions. My older machine has the aerial connections next to each other. The newer one has them one above the other.
What more do you need? The latter is the revised "RE" hardware using just one dual tuning can instead of two individuals.

This seems to be to do with CPU processing/temperature (stab in the dark: are the tuners getting too hot?) Running the fan at Max reduces the occurances of blocking.
Never heard of this before, but how long has it been gathering internal dust? See https://hummy.tv/forum/threads/hdr-fox-hardware-commissioning-disassembly-repair.5728/
 
So, i was able to watch a recent recording together with cpu graph, and virtually every peak corresponded with pic blocking .

Waiting for reboot after the current recording for safe mode
 
So, i was able to watch a recent recording together with cpu graph, and virtually every peak corresponded with pic blocking .

Waiting for reboot after the current recording for safe mode
Have you tried turning off auto processing during recording from the settings menu to see if that reduces/eliminates the problem without needing safe mode?
 
And yet the spikes occur
Have you tried safe mode? I appreciate you could not then monitor the processor load (except maybe on the command line), but at least that would give you a hint whether the CF was responsible for the loading. My hunch is that your excess load is actually due to disk thrashing.
 
Have you tried safe mode? I appreciate you could not then monitor the processor load (except maybe on the command line), but at least that would give you a hint whether the CF was responsible for the loading. My hunch is that your excess load is actually due to disk thrashing.

I thought I did give it the "safe" command and it was waiting for rebooting. But i discover this morning that the webif is still there. as luck would have it, i recorded a SD prog last night and where the cpu spikes are, there is no pic breakup.
 
hmm, when I went and gave it "safe" again it said sthing like safe mode will be disabled on reboot. So I was on safe mode since last night. so how come my webif and sysmon and everything was still there this morning?
 
hmm, when I went and gave it "safe" again it said sthing like safe mode will be disabled on reboot. So I was on safe mode since last night. so how come my webif and sysmon and everything was still there this morning?
Did you reboot after selecting safe mode, it isn't automatic

Based on a link I posted earlier in this thread I created a small routine that logs the top 10 cpu consuming processes every 10 secs and can be run in both normal and safe mode to help identify what is actually causing any spikes.

create and make executable /mod/bin/cpulog
Code:
#!/mod/bin/bash
echo "log top 10 processes to /mod/tmp/cpulog.log"
while true; do (echo "%CPU %MEM  PID  ARGS ----- $(date)" && ps -e -o pcpu,pmem,pid,args --sort=pcpu | tail) >> /mod/tmp/cpulog.log; sleep 5; done
Type cpulog on tlenet command line
You can monitor the output of this or any other log file in real time with the tail -F logfile command
eg
Code:
humax /mnt/hd2/mod # tail -F /mod/tmp/cpulog.log
0.2  0.0    15 [pdflush]
0.3  0.0  1175 [kjournald]
1.2  0.3  2021 /bin/sh /mod/sbin/scanmounts
1.3  0.2 27631 tee -i /mod/tmp/Countdown_20200217_1409-dec.ts
2.0  7.0 27630 /mod/bin/jimsh /mod/bin/chaseget /mod/tmp/Countdown_20200217_1409-inp.ts 0
2.6  1.3 18369 /mod/sbin/smbd -D
5.3  0.7 27635 /mod/webif/plugin/detectads/silence 0 -70 0.2 5 60 65 3
8.5  1.5  1947 /mod/bin/epg -f /mnt/hd1/dvbepg/epg.dat sqlitedumpd /mnt/hd1/epg.db
24.4  7.0 27634 ffmpeg -nostats -loglevel fatal -i pipe:0 -vn -sn -ac 2 -f au pipe:1
29.3 31.6   367 /usr/bin/humaxtv
%CPU %MEM  PID  ARGS ----- Mon Feb 17 14:43:35 GMT 2020
0.2  0.0    15 [pdflush]
0.3  0.0  1175 [kjournald]
1.2  0.3  2021 /bin/sh /mod/sbin/scanmounts
1.3  0.2 27631 tee -i /mod/tmp/Countdown_20200217_1409-dec.ts
2.0  7.0 27630 /mod/bin/jimsh /mod/bin/chaseget /mod/tmp/Countdown_20200217_1409-inp.ts 0
2.6  1.3 18369 /mod/sbin/smbd -D
5.2  0.7 27635 /mod/webif/plugin/detectads/silence 0 -70 0.2 5 60 65 3
8.5  1.5  1947 /mod/bin/epg -f /mnt/hd1/dvbepg/epg.dat sqlitedumpd /mnt/hd1/epg.db
24.3  7.0 27634 ffmpeg -nostats -loglevel fatal -i pipe:0 -vn -sn -ac 2 -f au pipe:1
29.4 31.6   367 /usr/bin/humaxtv

Note if you have altered the encryption keys on your humax that any recordings made in safe mode will be made using the standard encryption and won't be, automatically, viewable when you return to normal mode.
 
Last edited:
Back
Top