Synchronised crashes

geoffd

Member
I have been investigating Humax crashes that have been occuring every few days, once twice in a day, some minutes after switching on the TV in our back room. We keep the Humax on all the time so the only change is the TV. The picture freezes, the sound continues then the Humax re-boots. My first thought was that it was something connected to the HDMI being activated so I changed HDMI cable and HDMI socket on the TV. Second thought was a problem with the Humax itself so I bought another off ebay and put a new 1TB Seagate Pipeline disk in it but still the same problem.

I understand that the symptoms are the result of a software crash but other than the TV, a 2 year old LG, everything else has been replaced. I do run Custom Firmware and I was going to say that I run an identical set of packages on a Humax in the front room without any problem until I looked at the crash log on the front room Humax and found that it had been crashing too. Since the beginning of the year, both have crashed over 40 times and, other than on 3 occasions, on the same day. Moreover, on 13 occasions the time logged for the crash is less than 20 seconds different between the front and the back. On 5 occasions the back was first, on 4 occasions the front first and on 4 occasions the times were the same. We have been away a number of times during the period and there has never been a crash while we have been away. The front Humax, unlike the back, has never crashed while we have been watching it but we only use it in an evening. The latest there has ever been a crash is 18:49 and the earliest 08:01, times when we would usually be using the back Humax and TV.

So could Custom Firmware be involved? I run auto-unprotect, betaftpd, cifs, disable-ota, network-shares-automount, rs, samba, sidecar, virtual-disk2 and of course webif. Of these the most obvious contender, which provides a link between the front and back, is network-shares-automount. I have it configured on each Humax to provide access to files on the other Humax. I have now added the crashdiag package so hopefully it will provide more info next time a crash occurs.

Any thoughts would be appreciated as I have run out of ideas.
 
Any thoughts would be appreciated as I have run out of ideas.
Do you have all the custom firmware packages up to date? (We have seen a number of cases recently where users with problems had been running very old versions of the custom firmware).
 
Do you have the dlna-filter package installed? Media servers running on other devices in your network can cause the humax to crash.
 
Do you have all the custom firmware packages up to date?

I have checked the packages and there was only an update to webif.
This screams dlna-filter to me.

I don't have dlna-filter installed but it sounds a very good suggestion as I guess if it can crash one Humax then why not two. The only DLNA server, other than the Humaxes themselves, I am aware of is on a Synology NAS box. I will get it installed immediately. Thanks.
 
Moreover, on 13 occasions the time logged for the crash is less than 20 seconds different between the front and the back. On 5 occasions the back was first, on 4 occasions the front first and on 4 occasions the times were the same. We have been away a number of times during the period and there has never been a crash while we have been away.
Having observed the time on my Humax screen saver against the time on my PC, I wouldn't be surprised to find the Humax times to be +/- 20 seconds from each other, I can see greater than that from one Humax against my PC. On this basis I would suggest that these crashes happened at the same time.

Any thoughts would be appreciated as I have run out of ideas.

On the basis that they didn't crash while you were away is there anything that you may be turning off or on that could cause a spike on the mains that could upset the humaxes? I would be looking at something with a high power draw, especially if it has a reasonably hefty motor in it. You would only get a conclusive diagnosis of this with a power disturbance monitor.
 
I have checked the packages and there was only an update to webif.
Use of auto-update is generally a good idea. As is making sure you're on the latest CF - currently 3.13
Having observed the time on my Humax screen saver against the time on my PC, I wouldn't be surprised to find the Humax times to be +/- 20 seconds from each other
Might I suggest use of the ntpclient package.
is there anything that you may be turning off or on that could cause a spike on the mains that could upset the humaxes?
I think you're in the realms of fantasy.
 
is there anything that you may be turning off or on that could cause a spike on the mains that could upset the humaxes?
In the instances where we have seen the crash (most often when we switch the TV on for BBC Breakfast) there is nothing we are turning on or off.
 
I think you're in the realms of fantasy.

No, I have seen spikes from the compressor motor in a fridge cause computer problems including lockups. Took a bit of diagnosing as the fridge was on the same power circuit, but was in the room on the other side of the wall.

One of my previous existences was as a computer engineer dealing with all sorts of things from PCs through small and medium business computers to mainframe attach peripherals.
 
The only DLNA server, other than the Humaxes themselves, I am aware of is on a Synology NAS box
Yep, that could do it!
I've created a new package to filter out DLNA server traffic before it reaches the Humax software. It's based on work by @rowanmoor (see http://hummy.tv/forum/threads/humax-twonky.4788/page-4#post-72495 )

This should prevent the crashes that occur in the presence of certain other media servers on the network, such as Twonky v7.

I wouldn't be surprised to find the Humax times to be +/- 20 seconds from each other
Yes, perfectly normal. I did a lot of work on this in the early days, the Humax firmware only resyncs the internal RTC to EPG time if it drifts to +/- 60s (IIRC). There are also multiple independent time-keepers within the system: the screen-saver clock, for example, is independent.

It only really matters if you're making manual timer recordings, except perhaps for getting an accurate time-stamp in a log entry. AR recordings are triggered by external events, and padding recordings should have enough margin built in.
 
No crashes yet so dlna-filter is looking good. About to go away for a week so on past form they are unlikely to crash while we are away in any case.
 
If the apparent causative agent isn't switched on while you're away, the HDR won't crash with or without dlna-filter running. On the other hand, if it never crashes at all I would be very surprised.
 
No crashes yet so dlna-filter is looking good. About to go away for a week so on past form they are unlikely to crash while we are away in any case.
Random hangs and crashes are unfortunately common on the Humax and so I, and ohers, put the Humax on a simple timeswitch so that it is rebooted every day while away to limit any possible loss of recordings.
 
It's over a month now since a Humax last crashed so I think we can safely say that dlna-filter solved the problem. Thanks to MymsMan and prpr for the advice as it is not something I would ever have thought of. And I now have a spare Humax!
 
Thanks for the feedback. If only the Humax code wasn't so crappy (or they'd open sourced it)...
 
Back
Top