Networking with CIFS, Samba, and NFS

Black Hole

May contain traces of nut
I've had a look round, and although there are custom software packages for networking there seems very little detail on the forum or the Wiki about them (as of this date). Possibly not many people are trying to use them so the discussion hasn't got going.

My purpose here is to provide a focal point for discussion of how to use the packages and problems thereof - there is another topic open already for the auto-mount scripts. At the end of this post I have listed the topics that are currently in the corpus (for previous discussion), but I will start by summarising what I have gleaned over the months - which isn't much, but should satisfy the casually curious.

Anybody not familiar with the terminology should refer to the Glossary (click).

Humax Network File-Share Summary

People make a living out of configuring networks, obviously a simple home network is easier than a complex corporate one, but even so there are all manner of pit-falls for the non-techie. That's why DLNA came into being - it allows home devices to be connected to a network and automatically find each other and share relevant data without the user being involved with setting it all up - other than plugging them in in the first place.

The Humax boxes (we're talking HD-FOX and HDR-FOX here) have DLNA - the HD-FOX has a client (the techies will get annoyed with me calling it a client, but never mind) able to find sources of streamable programme content, and the HDR-FOX has a client and a server (able to supply programme content). A typical media NAS (a hard drive that sits on a network rather than a PC) has DLNA services, as do PC software (able to send and access content), so why would we want to do anything else?

Let's ignore the obvious "because it's there" - such people require no encouragement. The first thing is that DLNA has its limitations. The Humax client implementation is not able to play as many types of file as would be possible if the file was on the Humax disk (or connected USB drive). This may not be Humax's fault, it may be a limitation in the DLNA spec, but never the less accessing the media file as a network share bypasses the limitations and lets the Humax play any media it is capable of.

The next thing is transport control, by which I mean fast forward, rewind, skip etc. DLNA should be able to do that, but it is not well supported and frequently you are left with play and pause - not much help for suspending a programme and picking it up another time, or skipping the adverts. The Humax client does OK in this respect when accessing the Humax server (ie when using the HD-FOX to stream from the HDR-FOX), but in general it's a pain.

The last thing on my list for wanting to bypass the Humax client is the 4GB bug*. A programming error has crippled the client to terminate the playback at the 4GB point in a streamed file - which is not too bad in StDef, several hours worth, but in HiDef we are talking less than an hour. It is rumoured Humax are working on a revision - they have been made aware of the problem and I hear there is a beta firmware release under test.

So much for the advantages of network-sharing rather than DLNA streaming from the client end, what about the Humax server? One thing is to avoid the 4GB bug* when streaming to a Humax client - they go hand in hand, so using a network share at the client end requires a network share at the server end. Also, making the content available as a file-share means it can be accessed by a player client that does not have DLNA support - eg VLC or our current favourite Splash Player Lite. Bear in mind that the HD-FOX doesn't even have a DLNA server, so Mediatomb (an add-on server) or network file sharing are the only options (but see next paragraph re decryption).

Being able to access the Humax file system from a PC as a network drive makes moving stuff about quite straightforward and avoids having to use FTP, handy for backing up, but bypassing the HDR-FOX DLNA server has one very big drawback: all the content will have to be decrypted first. This is not a huge deal on the HDR-FOX, we have the tools to decrypt at will (even automatically in the background), but HD-FOX users must note that the only way to decrypt your recordings is to boot it in HDRmode and use the remote control OPT+ copy operation to decrypt each recording individually (or as a pre-selected batch). With a remote network drive mounted as a file share, it becomes possible to OPT+ copy to the remote drive and decrypt in the process. See Things Every... (click) section 5.

Of course, having everything decrypted as a matter of routine has particular advantages with backing up - if backed up in encrypted form, the only box that can ever make sense of your backups is the box they were originally recorded on, no other. If it breaks and gets replaced, your backups are of no further use to you.

OK, So What Do I Do?

Take my situation. I want to access my HDR-FOX recordings from my HD-FOX without hitting the 4GB limit. As I understand it I need CIFS on the HD-FOX and Samba on the HDR-FOX to provide client and server services respectively.

In addition to that I shall need auto-unprotect running on the HDR to clear the protection flags on the recordings automatically, and unencrypt to decrypt them in the background (once the protection is cleared).

When the auto-mount facilities are debugged I hope to be well away. On the other hand, the (hopefully) imminent 4GB bug fix would be a lot easier.

What about NFS?

I may be wrong here, but from what I gather NFS is required to support file-share networking with Apple Macs. See HERE (click).

Existing Topics:

* The "4GB bug" was fixed in firmware version 1.02.27. Only people still using 1.02.20 will suffer from it.
Last edited: