of course I am. watching the live stream never has pic breakup, whereas as soon as you start recording that very stream fairly shortly the pic breaks.
does an hd recording made during those 70% peaks of yours not have pic breakup?
-
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
of course I am. watching the live stream never has pic breakup, whereas as soon as you start recording that very stream fairly shortly the pic breaks.
does an hd recording made during those 70% peaks of yours not have pic breakup?
Black Hole
May contain traces of nut
No, never - on any of my three HDR-FOXes or one HD-FOX. What you have said does not rule out signal problems. Nor do I believe you have ruled out HDD problems.
Another thought: the cooling system relies on temperature reports from the HDD only. If the CPU is covered in dust, it won't be getting any benefit from the fan and could potentially throttle back if it is overheating.
Confirm I have the right impression: when viewing live with no recording or processing jobs, reception is fine. When recording, live picture breaks up.
Does the recording show the same break up? If so, we really are looking at signal problems as the prime suspect. What sustained figures do you get from Menu >> Settings >> System >> Signal Detection, particularly for muxes you are having problems with?
Are you running ad-detect in chase mode? That will make the situation worse in all respects. However, if your signal is robust and as long as there are no performance-degrading problems with the HDD, we know that the HDR-FOX processor is capable of doing it (and there is no reason to believe your box is any different - assuming the fan works and there isn't a blanket of dust inside).
Have you run fixdisk since updating? A better fixdisk is one of the benefits of the update.
Perhaps not, but the auto-processing permitted times controls are there for a reason (not that I use them, but some find them necessary): WebIF >> Settings >> Auto-Processing Settings.
@af123: any thoughts? Sounds very odd to me, but 3.00 was a long time ago:
why would it overheat at periodic times as the cf is processing?
correct impression except no CF no pic breakup on recordings anymore
the same breakup
52% or more on hd channels with 100%
no ad detect
not run fixdisk because recordings
i had don't run autoproc during recordings not that it helped at all
btw i did open the box, no warranty sticker at all and i had it from new. anyway, was flabbergasted to see almost no dust in there, hoovered what there was and some dust in the external fan which managed to get rid of.
Last edited:
why would it sound odd to you. it either is or it isn't taxing the cpu more. no room for sounding as my pic shows quite clearly
Black Hole
May contain traces of nut
Your experience is not in keeping with my or other experience, so why wouldn't it sound odd?
Black Hole
May contain traces of nut
Yes, but not to the extent of causing a problem.
You seem blind to the idea that your setup has a fault somewhere, and this thread title does not deserve the prefix "solved"! Nothing has been solved, all you have done is point a finger.
I don't think that there is any evidence that it's a bad thing. My boxes all do it too and I never experience picture breakup - and since most of the video processing occurs in hardware, that is not surprising. When the box is busy doing decryption or ad detection, the on-TV menus can be slow but that's the only symptom I've observed on any of my three boxes.
my other question still remains
also, if the maxed out doesn't matter why do my pic breaks occur simultaneously with the thrashing of the cpu?
MymsMan
Ad detector
By running the cpulog execs posted earlier in this thread.
Two regular processes that are not part of the auto process are the epg update and the rs sync process, potentially they could be brought under auto and stopped from running whilst recording is in progress but it would be pity to lose the ability to use RS to schedule programmes whilst a recording was in progress.
As has been repeatedly said high cpu is NOT the cause of picture breakups, what might be the cause is the extra disk activity created by these processes but with a healthy disk this should not cause problems, Your focus needs to be on what is wrong with your disk drive that is allowing pixellation to occur and stop focussing on the red herring of CPU load.
Today I recorded simultaneously two HD programmes and watched one of them in chase play whilst allowing Auto and other processes to run normally without a single flicker of picture break up (even though there was bad weather that can interfere with the signal quality) Cpu load was frequently peaking at 100%
Can you record 2 HD and watch a 3rd while in Safe mode without picture break up?
Last edited:
Black Hole
May contain traces of nut
I've demonstrated something like seven or eight simultaneous HiDef streams in the past - not a problem for a healthy HDD.
hmmm. that just does not sound right at all. why would an hdd on the brink be suddenly behaving itself once the CF is removed? as I said before, I've had no more pic breaks .
i'll have another go at smart once my recordings are done but please give me a sensible answer to the question above
MymsMan
Ad detector
But have you tried anything more than single recordings since you removed the CF?
That was why I asked
If as I suspect the disk is struggling to cope I wonder if it will be able to cope with more than a single recording.
If you believe that your disk is fine how do you explain that cpu levels that many of us routinely experience cause your machines problems but are totally fine for others.
I think at least two others have reported pic break myms,an being one
To add to MM's above, your HDR exhibited a similar problem in two separate cases: one where manually initiating an intensive operation caused recording pixellation, and one where background processing apparently had the same effect. This is not observed by most CF users and developers (who are likely to be most sensitive to problems) woukd not have set up the CF as it is if the problem was commonly observed.
An unusual failure normally involves several interacting issues. You see this especially in highly regulated environments like aviation where a lot of effort has been made to avoid single-mode failures.
If some additional function enabled in CF "un"safe mode stresses the disk more than is the case in safe mode, as I suggested in the earlier thread, a marginal issue with the disk might cause recordings to be pixellated, even if it's not visible when viewed live (eg, not in detectads chase play). Because the disk firmware tries to present a consistent interface to the OS, SMART stats are the best hope of identifying if this is happening; but it's possible that the issues are even under the SMART radar.
It might be interesting to see what's actually running at the peak CPU periods: fortunately you can run the script that MM and I proposed in this thread in either mode. But the electrons in your HDR's (dual core) CPU have no recourse to the Working Time Directive and can be worked as hard as system ventilation allows.
An unusual failure normally involves several interacting issues. You see this especially in highly regulated environments like aviation where a lot of effort has been made to avoid single-mode failures.
If some additional function enabled in CF "un"safe mode stresses the disk more than is the case in safe mode, as I suggested in the earlier thread, a marginal issue with the disk might cause recordings to be pixellated, even if it's not visible when viewed live (eg, not in detectads chase play). Because the disk firmware tries to present a consistent interface to the OS, SMART stats are the best hope of identifying if this is happening; but it's possible that the issues are even under the SMART radar.
It might be interesting to see what's actually running at the peak CPU periods: fortunately you can run the script that MM and I proposed in this thread in either mode. But the electrons in your HDR's (dual core) CPU have no recourse to the Working Time Directive and can be worked as hard as system ventilation allows.