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

Black Hole

May contain traces of nut
#1
Update: This problem is now cured by a new firmware release. See HERE (click).

As you may know I am using the standard built-in DLNA server to stream to an HD-FOX. A couple of times I have experienced cut-offs before the end of a HiDef streamed play-back - of course one of the key values of the HD-FOX is its ability to stream HiDef direct from the HDR-FOX without any of our interventions.

I have not rigorously tested it, but the pattern that is emerging is there is a 4GB limit on the accessibility of the data. Would this be a limitation of the DLNA protocol, and if not is it an implementation bug in the server or the client?

I'm not expecting anybody to be able to answer these off the cuff, it is the aim of this topic to "seek the truth".
 
OP
OP
Black Hole

Black Hole

May contain traces of nut
#5
Right, a little more flesh on the bones:

I've only got one StDef recording that exceeds 4GB - 164 minutes worth of a film on 5 recorded with padding. It measures 4.04GB, so if the hypothesis is correct I expect it to clip off within the last couple of minutes. Sure enough, it does (and it plays right to the end locally). I'm recording 3 hours of BBC News as a test file at the moment, and I shall try streaming to PC/XBMC but as there are no transport controls it will take a long time to test.

The HiDef Strictly recording which clipped when streaming is 65 minutes / 4.64GB, so the crunch should be at 56m - and it is. The evidence is stacking up, but not concluded which end the problem is yet.

Jumping the gun a bit, but if it proves to be the HDR's DLNA server this could be a reason to switch to Mediatomb - except that requires decrypted files and therefore Decrypt-In-Place. But if Decrypt-In-Place is in place I might as well be mounting as a network share. Sigh.

Wait a minute - what about you people using the server for downloading decrypted files or running Decrypt-In-Place? Are you hitting a 4GB file limit?? If not, that implies the problem is in the HD-FOX.

Update: 3 hours of News only clocked up 3.9GB! Dammit!!
 

Brian

Administrator
Staff member
#6
Jumping the gun a bit, but if it proves to be the HDR's DLNA server this could be a reason to switch to Mediatomb - except that requires decrypted files and therefore Decrypt-In-Place. But if Decrypt-In-Place is in place I might as well be mounting as a network share. Sigh.

Wait a minute - what about you people using the server for downloading decrypted files or running Decrypt-In-Place? Are you hitting a 4GB file limit?? If not, that implies the problem is in the HD-FOX.
If you do switch to Mediatomb and Decrypt-In-Place, don't forget to transfer the discussion Back to the Customised Firmware forum.;)
 

xyz321

Well-Known Member
#8
I successfully transferred a 4.5GB file using wget from the DLNA port. This would seem to suggest that the problem is with your client and not the HDR DLNA server.
 
OP
OP
Black Hole

Black Hole

May contain traces of nut
#9
I agree. I should be able to confirm when I have a file I can stream to PC and HD-FOX to compare. I have a DLNA-capable NAS knocking about somewhere, see if I can get the HD-FOX to stream from that, and whether the same limit shows up. Perhaps the HD-FOX will lose its crown as the best client!
 
OP
OP
Black Hole

Black Hole

May contain traces of nut
#10
Update: successful playback right to the end of a 4.04GB StDef recording by PC/XBMC (1 test out of 1). Doesn't look good for the HD-FOX!
 
OP
OP
Black Hole

Black Hole

May contain traces of nut
#12
Probably the same root cause, but a completely different mechanism. The FAT32 limit is about the number of bits allocated to file size in the disk structure - but of course the HD-FOX does not use FAT32 internally. If the suspicions are correct, there is some other variable in the workings of the DLNA client within the HD-FOX (and possibly replicated in the HDR-FOX) that has not been allocated enough bits to count in - and 4GB is the most you can count with a 32-bit variable.

It can't be endemic to the HD-FOX's OS implementation, otherwise it would not be able to address locally-stored files in excess of 4GB. Anybody making a recording to external drive longer than an hour's worth of HiDef would be complaining by now.
 
OP
OP
Black Hole

Black Hole

May contain traces of nut
#13
More data: using a 4 hour StDef test file (4.97GB), XBMC played it to the end but the HD-FOX made it to 3h 19m and then dropped it. I even had them running simultaneously! I calculate it should have been more like 3h 12m, what I will have to do is split the file at the point the HD dies and then read the file size.

Anybody using the HDR-FOX as a DLNA client? Does it suffer the same thing??
 
#14
More data: using a 4 hour StDef test file (4.97GB), XBMC played it to the end but the HD-FOX made it to 3h 19m and then dropped it. I even had them running simultaneously! I calculate it should have been more like 3h 12m, what I will have to do is split the file at the point the HD dies and then read the file size.

Anybody using the HDR-FOX as a DLNA client? Does it suffer the same thing??
does the same thing happen on the HD if the file is decypted first ?

if it fails try moving the file to the pc, play the same file on the HD, does it fail again
 
OP
OP
Black Hole

Black Hole

May contain traces of nut
#15
does the same thing happen on the HD if the file is decypted first ?
I can try that, but it's hard to see any justification for it being different. The server is decrypting on the fly for the HD-FOX and XBMC regardless, and the clients both receive decrypted streams.

if it fails try moving the file to the pc, play the same file on the HD, does it fail again
I can probably try that, but you are moving out of my comfort zone. If I make it that far I shall probably dig out my Iomega DLNA-enabled NAS, transfer a decrypted version of the test file to it, and try streaming it to the HD- and HDR-FOX.

There is something in the back of my mind from way back - somebody has mentioned this problem before. I shall have to go digging, possibly on 'the other place'.
 

oijonesey

Hummy.tv SEO Guru
#17
Anybody using the HDR-FOX as a DLNA client? Does it suffer the same thing??
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! ;)).
 
OP
OP
Black Hole

Black Hole

May contain traces of nut
#18
you need to find out whats causing the files to fail
this should tell you if its something to do with DLNA, or more to do with the HD
To find out for definite will involve logging the network traffic and enough understanding of the DLNA protocols to see which end stops doing what it is supposed to first. However, the fact that I can stream perfectly well to PC/XMBC using exactly the same mechanism at the server (HDR-FOX) end surely is a very strong hint that it's the HD-FOX client that's at fault?

I am trying to find the boundaries of the problem, looking for somebody else to confirm the problem isn't a one-off, and to test whether the code is common to the HDR-FOX client and suffers the same problem (apparently negative by oijonesey's report).
 
Top