-
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.
Box crashed
- Thread starter Robti
- Start date
everthewatcher
Forum Supporter
It does seem to be just one of those things, along with the occasional lock-up. The one here crashed last night while doing nothing more demanding than playing a recorded programme. Previous entry in the log was back in November, before that July then November '16. I'll do the monthly fixdisk run tomorrow just in case.
Last edited:
Black Hole
May contain traces of nut
It's network activity that makes them crash/freeze.
Black Hole
May contain traces of nut
Experience and engineering nouse. Yes, okay, it is not possible to rule out other causes entirely and I have even seen an un-networked HD-FOX without a drive freeze, but these events are very rare.
We know network events cause crashes, and therefore that the network interface code isn't as well tested or robust as it could be. Why would that be? Because network abilities were an afterthought, and at the time of market not a significant factor. IIRC DNLA was not included in the original firmware roll-out.
We see plenty of reports of disk faults slowing down HDR-FOXes to a crawl, and I have experienced "RC overload" crashing it, but we don't get reports of disk faults resulting in crashes unless there is also RC activity. Conclusion: the disk interface code is well proven and all the execution paths valid (as you would expect from a mature OS kernel).
If the errant execution of code results in the program counter landing on a random (unplanned) memory location, the result will be unexpected actions, lock-up, or system restart. It is not possible to separate lock-ups from restarts, although restarts could also be triggered deliberately if the system is designed to detect faults and reset in response.
So far I have only talked about mis-execution caused by inadequate programming. This is when an external event or exact combination of events has not been anticipated and accounted for in the code or the testing. Programming cannot overcome mis-execution as a result of hardware failure or disturbance - by which I mean the state of a memory cell or register being altered by a radioactive particle (cosmic rays, ambient radiation, radioactive nuclei in the chip packaging), or the functioning being disturbed by signals (voltage, timing) or power rails being out of specification.
The PSU can become marginal (in which case the whole system will be unreliable), there may be mains-born disturbances (failure will be erratic, and likely other equipment will also be affected), the HDD may go out of spec (failures will be persistent).
On balance, the opportunities for network activity to promote crashes overwhelm all other possibilities unless the crashes are frequent and persist with the network disconnected. The very occasional crash could be triggered by a random event, but that's just noise!
We know network events cause crashes, and therefore that the network interface code isn't as well tested or robust as it could be. Why would that be? Because network abilities were an afterthought, and at the time of market not a significant factor. IIRC DNLA was not included in the original firmware roll-out.
We see plenty of reports of disk faults slowing down HDR-FOXes to a crawl, and I have experienced "RC overload" crashing it, but we don't get reports of disk faults resulting in crashes unless there is also RC activity. Conclusion: the disk interface code is well proven and all the execution paths valid (as you would expect from a mature OS kernel).
If the errant execution of code results in the program counter landing on a random (unplanned) memory location, the result will be unexpected actions, lock-up, or system restart. It is not possible to separate lock-ups from restarts, although restarts could also be triggered deliberately if the system is designed to detect faults and reset in response.
So far I have only talked about mis-execution caused by inadequate programming. This is when an external event or exact combination of events has not been anticipated and accounted for in the code or the testing. Programming cannot overcome mis-execution as a result of hardware failure or disturbance - by which I mean the state of a memory cell or register being altered by a radioactive particle (cosmic rays, ambient radiation, radioactive nuclei in the chip packaging), or the functioning being disturbed by signals (voltage, timing) or power rails being out of specification.
The PSU can become marginal (in which case the whole system will be unreliable), there may be mains-born disturbances (failure will be erratic, and likely other equipment will also be affected), the HDD may go out of spec (failures will be persistent).
On balance, the opportunities for network activity to promote crashes overwhelm all other possibilities unless the crashes are frequent and persist with the network disconnected. The very occasional crash could be triggered by a random event, but that's just noise!
Trev
The Dumb One
Although I agree with all of the above, and thanks for your enlightening deepest analytical thoughts on the subject (no irony intended), I still think that your bald statement "It's network activity that makes them crash/freeze." should have been slightly tempered with the word "often", "frequently" or even "usually".
I think you experience crashes much more frequently than some of us and you may be right that your crashes are network related. I think it is a big jump to say that network activity "overwhelm all other possibilities" for crashes in the general case.
Black Hole
May contain traces of nut
Everyone is free to evaluate what I say and disagree as they wish.
Black Hole
May contain traces of nut
As far as I am concerned, with the noted caveats, the case is sufficiently clear as to be my position on the matter. Disregard a 30-odd year career in electronics engineering design for military applications as you wish.
Mine is a theory which requires disproof, as opposed to a hypothesis in need of further supporting data.
Mine is a theory which requires disproof, as opposed to a hypothesis in need of further supporting data.
You have presented zero evidence to support your conjecture. I have fifty years experience of working with and writing software for computers and thirty years of networking experience but I wouldn't promote something as a theory without some sort of evidence; I would say what you have is a conjecture rather than a theory.
Black Hole
May contain traces of nut
You appear to be blind to the observations - observations and reported events are evidence. Are you offering a comprehensive analysis to counter mine in post 8?
I have evidence that network errors increase the incidence of crashes. Data errors would be reproducible. Dicky PSUs would cause frequent misoperation. Everything else are random events.
Regardless of your experience as a programmer, I'm a hardware engineer. I shall say no more - hopefully time will resolve the issue.
I have evidence that network errors increase the incidence of crashes. Data errors would be reproducible. Dicky PSUs would cause frequent misoperation. Everything else are random events.
Regardless of your experience as a programmer, I'm a hardware engineer. I shall say no more - hopefully time will resolve the issue.
Last edited:
everthewatcher
Forum Supporter
Now then boys, play nicely.
Ezra Pound
Well-Known Member
Do you think the networking problem you talk about in #8 a hardware problem?
I can easily accept that network-related glitches are the primary issue in crashes (iPlayer app, take a bow): presumably it's the Humax blob (/usr/bin/humaxtv, 7MB, needs a good disassembling) at fault rather than network-based CF packages taking the blob or the kernel down.
For an example of a non-network crash, I have observed a consistently repeatable hang/crash when stopping or ending play of an imported mp4 when there is a separate .srt subtitle file, regardless of whether the subtitles are being used, so far with 2 video files from different sources, albeit the same talent.
For an example of a non-network crash, I have observed a consistently repeatable hang/crash when stopping or ending play of an imported mp4 when there is a separate .srt subtitle file, regardless of whether the subtitles are being used, so far with 2 video files from different sources, albeit the same talent.