• The forum software that supports hummy.tv has been upgraded to XenForo 2.3!

    Please bear with us as we continue to tweak things, and feel free to post any questions, issues or suggestions in the upgrade thread.

System Flush Finally Fixes Developing Problems While Trialling CF

Newcoppiceman said:
I wouldn't mind betting it's a cap that's the problem.
Click to expand...
Perhaps, but how do you explain the freezes only happening with some services (so far as I can see, services known to be "iffy")?

Newcoppiceman said:
The 680n mains dropper capacitor (not an electrolytic) had failed - I've had similar caps fail in a smoke alarm and underfloor heating controller.
Click to expand...
Capacitors under serious stress, acting as a cheapo substitute for a proper PSU!
 
Newcoppiceman said:
Beginning to get some quality data on this fault now as it seems to be "hardening". I'll try the RMA process and system flush before fully exonerating the CF (and closing this thread).

If watching one of a number of services (eg London Live, Talking Pictures TV, Sky News...) the picture freezes somewhere between 45s and 70s after picture first appears; sound continues for a few seconds then system auto-reboots and cycle repeats. I'll try to make a list of affected and unaffected services (the latter includes BBC News and BBC Parliament and, I think, all the HD services). The occasional auto-rebooting at initial startup is likely related to this behaviour.

A two-PVR method of investigating further might be required, but before that I'll try a few simple things like swapping the power board and running with the lid off and applying freezer. It might even be worth undertaking bulk replacement of all the electrolytic caps. I wouldn't mind betting it's a cap that's the problem. As an aside, last week I repaired our Neff oven which had been resetting its clock to zero when the timer alarm sounded. The 680n mains dropper capacitor (not an electrolytic) had failed - I've had similar caps fail in a smoke alarm and underfloor heating controller.
Click to expand...
As a data point, both my HDRs have the occasionally lock up/crashes roughly once a month. Symptoms are very similar to yours.
When they lockup the picture freezes while audio continues. It won't respond to the remote and I'll have to use the rear power switch to power cycle.
When they crash/reboot it's like yours. It freezes (as above) but reboots by itself. It's not temperature related as it's happened a few minutes after start up as well as when it's been left on for over a day. On restart it'll be fine even if left on the same channel. I used one of them to perform the tests on #28. (Also I adjust the fan to ensure the HDD doesn't exceed 40c throughout the year.)

Edit 1: forgot to mention the frozen video hang or frozen video reboot seems to happen while the HDR is idle just viewing live TV.
 
Last edited:
IMO the behaviour where the broadcast channel picture freezes while the sound continues is down to a bad video file (DLNA indexing can touch one that you've forgotten) or bad disk area. It's not normally seen with a clean system.
 
/df said:
...is down to a bad video file (DLNA indexing can touch one that you've forgotten) or bad disk area. It's not normally seen with a clean system.
Click to expand...
Thing is, this problem occurs with live TV only - the PVR is behaving normally when playing back pre-recorded programmes. I would think that in this case, the transport stream delivered by the RF, demodulation and error-correction stages goes direct to the MPeg decoder. (Not sure if this is a software process or handled by hardware.)
 
Don't forget it is also going to disk for the TSR buffer. It would be instructive to disable TSR (run diagnostic disable-tsr).
 
The decoding is all in the SoC which comprises 2 CPUs and an AV processor (not directly accessible from the Linux world). It's very reminiscent of the sort of thing we used to use for image processing in the 80s, but in one chip instead of 2x19" rack units. A selected channel is extracted and written as MPEG-TS to the TSR buffer and/or a recording file. A channel that is being played in real-time is (also) routed to the AV processor's MPEG decoder and the decoded AV eventually appears on the HDMI output.

As well as TSR there is a possibility of DLNA indexing (or whatever) where a pathological AV file may crash (or hang) the settop process.

I wonder if the explanation for the static video vs continuing audio in this failure mode is that the hung or crashed settop process is failing to handle some callback required to keep the video decoder running, say related to en/decryption or HDMI "security".
 
/df said:
written as MPEG-TS to the TSR buffer and/or a recording file
Click to expand...
Definitely "or" not "and". If a service is being recorded it is not also available in the TSR.

/df said:
As well as TSR there is a possibility of DLNA indexing (or whatever) where a pathological AV file may crash (or hang) the settop process.
Click to expand...
But that should happen regardless of current live service. I might be making too much of this, but I have definitely had bursts of reboots every few seconds specifically while tuned to TPTV, resolved as soon as I selected a mainstream service (quickly, before it rebooted again!). I can't say for sure that's what the OP is experiencing, nor does it seem to be every time I try TPTV.
 
Black Hole said:
But that should happen regardless of current live service. I might be making too much of this, but I have definitely had bursts of reboots every few seconds specifically while tuned to TPTV, resolved as soon as I selected a mainstream service (quickly, before it rebooted again!). I can't say for sure that's what the OP is experiencing, nor does it seem to be every time I try TPTV.
Click to expand...
This might be totally off-the-wall, but could this be connected with the "Encore" service via the red button? At various times each of my Humaxes has had problems with a "press red" service. Recordings usually okay, but live TV dodgy. Never had continuous reboots though.
I did have a reboot problem with my 5000T very recently. Turned out the disk had gone read-only and when it tried to write the live buffer it crashed. Had to pull the aerial to regain control. Poxy software!
 
Our PVR is now sitting on a little table outside its usual cabinet, so it's easy to swap-out with one of our spares if needed. The lid has been removed and - should it come to it - I could quite easily undertake a bulk replacement of all the electrolytics on a one-per-day basis. I've found that disconnecting the HDD's power and data connectors makes no difference - still repeated reboots, roughly once a minute, on the "troublesome" services.

I'll continue to investigate but have noted that changing to a "mainstream" channel won't prevent the next freeze/reboot (if previously on a troublesome service) but thereafter the regular rebooting stops.

Just a reminder, currently our HDR-Fox T2 has no network connection and is running Humax's 1.03.12 (not CF) with an RMA process and system flush in prospect.
 
Black Hole said:
Capacitors under serious stress, acting as a cheapo substitute for a proper PSU!
Click to expand...
A cost-effective solution for a low-power, non-isolated PSU but, yes, the caps do lead a hard life. To be fair, the failed Iskra-brand component lasted almost 15 years (had reduced from 680n to 180n).
 
Black Hole said:
That's peculiar.
Click to expand...
Tried again and confirmed. I changed service 30s after first pictures and will experiment with other periods. Will also try one or more of our spare units today. This problem has evolved and affected channels are now unwatchable due to the constant reboots, which was definitely not the case a few weeks ago. This makes me suspect an ageing component is the cause.
 
/df said:
A channel that is being played in real-time is (also) routed to the AV processor's MPEG decoder and the decoded AV eventually appears on the HDMI output.
Click to expand...

Am I right to draw a distinction between a hardware MPeg decoder and one that is a software process? If the SoC's AV processor is a hardware implementation it would make sense to start changing caps around this block. I recall seeing a block schematic of a similar chip (and a pin-out?) somewhere but can't remember where.
 
Newcoppiceman said:
If the SoC's AV processor is a hardware implementation
Click to expand...
Definitely is, it would be far too compute-intensive to be performed without at least hardware acceleration. The SoC is targetted specifically at PVRs and embeds hardware implementation for all the data pipelines. The hardware information section in the wiki links to the technical data. That said, when we say "hardware" we actually mean a dedicated processing unit which is hardware co-ordinated by hard-programmed microcode.

I suppose it's possible that putting the decoder under extra strain due to malformed data results in current spikes and voltage droops if the decoupling isn't adequate, and I don't want to discourage you from looking, but it seems a bit of a stretch.
 
Last edited:
Newcoppiceman said:
As an aside, last week I repaired our Neff oven which had been resetting its clock to zero when the timer alarm sounded. The 680n mains dropper capacitor (not an electrolytic) had failed - I've had similar caps fail in a smoke alarm and underfloor heating controller.
Click to expand...
You're the capacitor tsar or czar. delete as you like
 
To progress investigation of this issue, we’re now using a spare HDR-Fox T2 (same one that helped out when investigating Start Up Fails When HDD Connected | hummy.tv) between 18:00 and 22:00 (my wife being the principal user) and the faulty one outside of these hours (when it’s my turn). The spare PVR is working ok on the troublesome channels, is running 1.03.12 and has never had CF installed. I’ll let this arrangement bed-in for a few days, then (because it’s easy to do) I’ll try swapping the power boards.

In the absence of any other inspiration, I’m thinking of starting by replacing all the electrolytics which are impossible/difficult to access with the HDD in situ; shouldn’t be necessary to remove the main board to change any electrolytic, as far as I can see (I did have to when replacing the optical audio out socket at the same time as investigating the start up fails... problem).
 
We've been successfully hopping between the spare HDR-Fox T2 and the faulty PVR for ten days now. The spare is working faultlessly and the faulty one continues its regular picture-freeze-and-auto-reboot on the troublesome services. Both units are running Humax 1.03.12 (ie not CF). I decided not to bother swapping the power boards and go straight for the RMA process on the faulty PVR, so this afternoon I reinstalled CF and checked the problem remained - it did.

I used the web interface diagnostics to set the return-to-manufacturer mode on next restart. As I type this, a restart has not yet been performed and I've been watching Talking Pictures TV (one of the troublesome services) just fine for more than 30 minutes! I've tried Sky News (another one) and that's ok too. What had become a rock-solid, repeatable fault has gone!
 
You must log in or register to reply here.
Back
Top