Streaming from the HDR-FOX - is there a 4GB limit?

If we can get this proven with an alternative DLNA service, and another example than just me, there will be a strong case to put to Humax that it is not fit for purpose and expect a solution.
 
If we can get this proven with an alternative DLNA service, and another example than just me, there will be a strong case to put to Humax that it is not fit for purpose and expect a solution.
Why not just ring up Humax support, present your evidence so far and see what they say.
 
Because I don't want to go around a "try this, try that" loop, then get a replacement, and be no better off. Is this a fault with my HD-FOX in particular (unlikely), or is it a design problem? I know which, but the evidence is still inadequate to prove the case.
 
Because I don't want to go around a "try this, try that" loop, then get a replacement, and be no better off. Is this a fault with my HD-FOX in particular (unlikely), or is it a design problem?
But you might get the response "we know about that problem" in which case you need do no more. If they offer solutions you don't like, then you politely decline them.
 
Hi BH - I have films stored on my NAS (with DLNA) and can stream them OK back onto the Hummy without any issues at all - HD and SD. Some I've recorded and archived onto the NAS, and some I put there as backups of DVD's (that I legitimately own of course! ;)).
In the interests of proven facts I have just double checked my NAS and can confirm I have a 4.6gb file of a backup of a Shrek3 DVD and it definitely plays OK to the end- so not a >4gb HD file but more than 4gb nevertheless. The films I thought I'd streamed weren't HD after all - but when I have time for the copy to finish I'll get an HD movie on the NAS and prove it one way or the other.
 
This is getting serious now. I have fired up my Iomega Home Media NAS, copied the (decrypted) 5GB test file to it (took an hour and a half at 1MB/s!), enabled the DLNA server, and found I could access it from the HDR-FOX (I have yet to try the same on my HD-FOX, but I have every expectation it will be the same).

You've guessed it: the HDR-FOX also ends the stream at the same 3h 19m point (out of 4h). Admittedly I skipped to just before the expected die point, but the results are consistent and no reason to expect them to be any different if I sat through the whole 3h+ to get there without skipping.
 
In the interests of proven facts I have just double checked my NAS and can confirm I have a 4.6gb file of a backup of a Shrek3 DVD and it definitely plays OK to the end- so not a >4gb HD file but more than 4gb nevertheless. The films I thought I'd streamed weren't HD after all - but when I have time for the copy to finish I'll get an HD movie on the NAS and prove it one way or the other.
We crossed posts. My test file was a 5GB .ts - I wonder if this is data sensitive? I can repeat the same with a HiDef .ts, but I don't think I have anything else in my armoury that would be that large.

Were you definitely DLNA streaming and not network mapping?
 
After some more playing last night and this morning, everything I've tried confirms the 4GB barrier. I put a decrypted 5.64GB 80 minute HiDef .ts onto the NAS, the file plays fine from a USB drive on the HDR-FOX but it breaks at 58 minutes when streamed from the NAS - both HDR- and HD-FOX. The 5GB StDef .ts that broke streaming to the HDR-FOX breaks in exactly the same place on the HD-FOX (as it did streaming from the HDR to the HD).

PC/XBMC played the StDef file fine, as I've mentioned before, from NAS or HDR, but it surprised me by having a good stab at playing the decrypted HiDef file on the NAS - but it couldn't keep up with the data rate. I thought this might be down to the NAS (which seems to be pretty slow on the network), but the HD- and HDR-FOX were fine (until the break point).

This all leads to a point of confusion. I'm getting precisely the same problem with the DLNA client on the HD- and the HDR-FOX, demonstrating (but not proving beyond reasonable doubt) the problem is in the client code and it is common to the HD- and the HDR-FOX. The problem occurs whether the DLNA server is the HDR-FOX or the Iomega NAS, ruling out the server. The problem does not occur when I use PC/XBMC as the client, for content which XBMC is able to play.

But then we get oijonesey with his report that a 4.6GB .vob (I presume) streamed from a NAS to his HDR-FOX client no problems. I don't know what to make of it.
 
I have just tried an SD 4.6GB ts file streamed from a server using the HDR client. It failed to play the last 15 minutes or so. The same file played fine when using the cifs client.
 
Yes, sadly I think that's the best option. I'm happy with the custom software adding new facilities, but the standard facilities really should work out of the box.
 
Perhaps this thread should be renamed to "Streaming to the HDR-Fox-T2" - is there a 4GB limit?".
 
Agreed, but I didn't know which way this was going when I started it. The evidence is sufficient (in my opinion) to create pinned topics in the HD- and HDR- sections with specific titles, pointing to this topic for background.

It occurs to me that this flaw is sufficient to take our decryption activities from (in my mind) "somewhat dodgy" to "fully justified", since the only way to make it do what it is supposed to do is to decrypt the file on the HDR and then make it available to the HD across the network by file share - this being a facility we were supposed to have using the HDR's built-in content protection and the HD's ability to stream from it (and now shown to break on files greater than 4GB).
 
It has been shown that the DLNA client in the HDR-FOX (firmware 1.02.20) and HD-FOX (firmware 1.02.20) contains a bug which prevents playback of network streamed media beyond the 4GB point in a file (presuming the file is greater than 4GB). Playback is normal before that point, but when the 4GB point is reached playback stops as if the file end had been reached.

This has been demonstrated streaming content from the HDR-FOX, and also streaming content from a DLNA-capable NAS (network drive). It has also been demonstrated that another DLNA client (XBMC running on a PC) does not have this limit.

It is possible to estimate the time at which playback will break by assuming the video encoding is at a constant bit rate (which it isn't) - so for example a 4 hour recording that is a 5GB file will break at approximately 4/5 x 240 = 192 minutes (3 hours 12 minutes). A HiDef recording will typically break at around 55 minutes.

The only work-around we have is to play the content from a local drive instead of streaming (which, if the content was recorded using the HDR-FOX for streaming to the HD-FOX, means decrypting it), or installing network sharing facilities on the HDR-FOX and the HD-FOX and accessing the file as if it were local (which also means decrypting it first).

We can guess the cause of this bug: when computer code is written the designers have to specify how many bytes of memory are used to store each variable, the common types being 2, 4, or 8 (16, 32, or 64-bit). The maximum number that can be counted in 4 bytes is 4,294,967,295 - in other words 4G-1. Thus we conclude that somebody didn't account for the possibility that the data would exceed 4GB, and let the compiler default this particular variable to 32 bits.
 
It could be worse than that because all the on-box decryption tools (decrypt-in-place and the webif decrypt) rely on the DLNA server anyway.
 
Yes, I have considered that but not got around to investigating all the new-fangled stuff (auto-decrypt etc etc etc) - little bits of time available, if I get longer time more important things to do. Also some of the content that only just exceeds 4GB could be rescued by a top-tail-deadvert edit.

Bugger - have I typed "seperate" somewhere? Seek and destroy!
 
It was a subtle reminder to others as well. (Wiki);)
Well, you can do something about that yourself! The thing about a wiki is that all registered users become editors, so if you sign up you can correct all the little typos to your heart's content. Then one day I'll come along with more time on my hands that I know what to do with and my technical author's hat on, and re-write the whole lot! (as if)

(One reason I like writing up in the Forum rather than the Wiki is because other people can't fiddle with it! Besides which I also have to learn a new load of formatting :( )
 
Back
Top