Black Hole
May contain traces of nut
Alternatively use the Telnet menu (I don't know whether it's in 3.00, it might be).
-
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.
SOLVED: The CF causes processor overload UNLESS fixdisk used to optimise hard drive again
- Thread starter mihaid
- Start date
MymsMan
Ad detector
Common sense, many hours have been wasted tracking down problems that had been solved years earlier
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
Black Hole
May contain traces of nut
MymsMan
Ad detector
Type menu If you have disabled it being displayed by default.
Black Hole
May contain traces of nut
...or in older versions I think that had to be "tmenu" (both "menu" and "tmenu" work now).
Ezra Pound
Well-Known Member
How about this direct link to the Firmware Release Notes page :-
https://wiki.hummy.tv/wiki/Customised_Firmware_Release_Notes
EDIT
Sorry, post #49 wasn't visible to me when I wrote this post
Last edited:
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.
Black Hole
May contain traces of nut
What more do you need? The latter is the revised "RE" hardware using just one dual tuning can instead of two individuals.
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/
MymsMan
Ad detector
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?
Black Hole
May contain traces of nut
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.
MymsMan
Ad detector
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; donecpulog on tlenet command lineYou can monitor the output of this or any other log file in real time with the
tail -F logfile commandeg
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/humaxtvNote 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: