• 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.

A new way of crashing the HDR?

everthewatcher

everthewatcher

Forum Supporter
Last night the HDR was crashing after every 170-180 seconds of uptime.

I seem to have established that it's caused by something it doesn't like - probably a filename - in a shared directory on a Windows 7 PC, connected using network-shares-automount and I'm in the process of finding out what.

It looks like it's a Youtube video downloaded Thursday or Friday that it doesn't like, or one downloaded earlier that it now doesn't like. All recent videos have been downloaded via Youtube.DL using the Youtube.DLG GUI with 'Restrict filenames to ASCII' ticked so that seems to take care of that.

Having stopped the crashing I'm now adding Youtube downloads back into the share to hopefully find the culprit, although another possibility is I've found a limit on the number of files in the share.

Does anyone already know the [likely] cause or have I found something new?
 
Last edited:
Looks like I've found it - there's a file that apparently downloaded OK but which neither VLC or MPC-HC will play properly.

So the it seems there's a process on the HDR that opens files share that it recognises the extensions of (MP4 in this case) and causes it to crash when it doesn't like what it finds - would this be something DLNA-related?

Now I can put everything back as it was - router, disk containing the shared directory and so on.
 
Last edited:
Should add that this coincided with my changing the router to one that had a DNLA server in it (a Netgear DGND3700 found in a bin that soon had the richud.com firmware on it) so that was where the finger got pointed initially, even though the server (ReadyMedia/MiniDLNA) was turned off.
 
Black Hole said:
Probably. This is a known problem if you mount an external network share into the My Video file system (not something I recommend).
Click to expand...
It's worked OK here for well over a year hence my initially looking elsewhere for the problem.

I could understand the HDR not handling a corrupt file more elegantly if it was only expected to play files it had created, but that's not the case.
 
It was never a design expectation that somebody would implant a redirection link from the native file system to a network share. Any of the native processes which scan the file system (eg the DLNA indexer, or just the free space detector) will find themselves crawling a remote file system via a network connection, with associated delays, and the various delays or errors that might be returned were not designed for and certainly not tested for. Any path through the code that was not exercised during software testing is a potential crash.

My preference is to keep external shares on the USB menu only. This limits the exposure to errors, and USB access is designed to be "off box".

The only way the designers could have expected to come across your troublesome file is if you were viewing/importing it via USB or importing it via native FTP (each of which have filters on what you are allowed to do). Never forget the CF gives us multiple opportunities to wildly exceed the design capability of the HDR-FOX, and we should marvel at what it is able to cope with rather than be surprised when we break it. A knowledge of what's going on "under the hood" is instrumental to knowing where the risks are.
 
Last edited:
I think the law of unintended consequences applies here. If you use CF to extend the capabilities of your Humax - you may have to suffer the consequences. Not even just CF. My Humax sometimes crashes if I watch (or rather, stop watching) an mp4 whilst trying to stream* files to the computer (* using that in place of a USB copy to decrypt files). Even more likely if I'm recording at the time. I'm sure it wasn't designed for this purpose. Probably not enough processing power! Sometimes it fails.
 
I think the point is being missed here.

It's accepted that there will be issues when playing files over the network, although that should be fairly robust as the HDR has DNLA capability. I've had HDR crashes while playing from the shared directory that appeared to be linked to intensive disk activity from another process, so now the shared directory is on it's own drive (a 160GB from a dumped Sky box) and so far it's not happened again.

What's happened here is, I'm guessing, is the DNLA indexer has found a file that happens to be corrupt, opened it to read something (headers?) and fallen over, taking everything else with it. VLC and MPC-HC don't complain about this file being corrupt - VLC makes out it's playing but doesn't display anything, MPC-HC displays a black screen with no sound.

I've not tried it but I'd assume the DNLA indexer would have done the same thing had the offending file been on a USB stick.

So it looks like I may indeed have have found another way to crash the HRD HDR with this file.
 
Last edited:
everthewatcher said:
although that should be fairly robust as the HDR has DNLA capability.
Click to expand...
The DLNA part of the Humax software is rather flaky.
I'd assume the DNLA indexer would have done the same thing had the offending file been on a USB stick.
Click to expand...
The DLNA indexer wouldn't, because it doesn't index things on USB sticks.
the HRD
Click to expand...
I think you need a new keyboard, or slower fingers. DLNA, DLNA, DLNA.
 
You must log in or register to reply here.
Back
Top