Original title: Accessing Media Only Through the USB Menu
This thread has evolved from its original intention into a complete reference on sharing content between HDR-FOXes and HD-FOXes over a home network, so that recordings made and stored on one unit can be viewed and manipulated on another: the methods available, advantages and disadvantages of each method, how to do it, and work-arounds.
I have left the original post intact for reference; to skip the preamble and go straight to the details see Post 3 (click).
Accessing Media Only Through the USB Menu
Having three HDRs and an HD all networked and able to play each other's recordings via decryption* and network-shares-automount, I use the Media >> Storage >> HDD (default) menu to access local recordings and the Media >> Storage >> USB menu to access remote recordings (I don't want the attendant risk of merging remote file systems into the local file system).
Instead of mounting virtual USB drives (ie the network shares) into My Video, there would be no attendant risk if the local My Video was set up as a virtual USB in the USB menu, where I could then access all recordings everywhere from the same storage mode.
So, I set up another share on my HDR-FOX1 pointing to My Video (in [ModSettings]: "folder=My Video", or for HD-FOX "folder=Video") from its own SMB server (best not share Media, because the shares are under Media so you end up with infinite recursion**). The result is that, provided I select Media >> Storage >> USB after a reboot***, pressing Media gets me a menu to drill down into any of my 'Foxes, not just the remote ones.
Here's the same thing on my HD-FOX (there's a reason I don't have HDRFOX2 or HDFOX1 & 2 on my list - they're not on my home network!):
The significant benefit, apart from personal convenience, is that the technically challenged members of the household**** will no longer have switch between HDD and USB to play local or remote recordings, or even local HDD and USB recordings (this is a purpose for which people with no network devices to share from could also make use of network-shares-automount). If the storage can be made to default to USB, that will be even better***.
The next step is to use a different folder than My Video as the target for each share. I already use symlinks as short-cuts to specific folders, so within (say) media/Shortcuts I could have symlinks to My Video and [Flatview].
It strikes me that virtual-disk / virtual-disk2 might be used to mount My Video, but I don't think that can be done at the moment and would require a package mod. In the mean time, this network-shares-automount method works.
* Key sharing would work equally well if a user didn't want to decrypt for some obscure reason... but of course the back catalogue would need decrypting anyway before changing the key! Key sharing is particularly useful for HD-FOX recordings, because there is no fast way to decrypt.
** IIRC NFS sharing (instead of SMB) defaults to not sharing shares, so this infinite recursion should not happen if you choose NFS rather than SMB. However, as I have Windows in the mix, SMB suits me better. To access any real USB devices connected to a remote 'Fox, set up another share specifically for it eg "HDRFOX1_USB1".
*** It would be very nice if Media >> Storage >> USB could be made part of BootSettings. A possible alternative is to run that as an ir package macro.
**** I don't have any of those, but I know others of us do!
The next step is to use a different folder than My Video as the target for each share. I already use symlinks as short-cuts to specific folders, so within (say) media/Shortcuts I could have symlinks to My Video and [Flatview].
I have succeeded in this and will write up the details in the first post, but there is something I don't understand:
In the initialisation script I created links /media/Shortcuts/My Video, ../[Unclassified], etc, but found that didn't work unless first I created /media/Shortcuts. OK, fine.
Having created /media/Shortcuts then various links underneath that, and adjusted [ModSettings] for mount "HDRFOX1" to target Shortcuts instead on My Video, Media >> USB lists HDRFOX1 and inside that the shortcuts. Excellent.
But, in the USB list there is also an entry "Shortcuts", which is empty. It seems that the existence of a folder in /media is enough to get it treated as a mounted device for the Media menu... or is that something to do with virtual_disk2?
Is there something I can do to make Shortcuts invisible (eg a property), or maybe locate it somewhre other than /media (but where I can still target it with [ModSettings}?
* HD-FOX is not excluded, but has limitations and requires other measures - see "HD-FOX" below.
Let's suppose you have two HDR-FOXes, one downstairs and the other upstairs (for the sake of argument - later these will be named "Downstairs" and "Upstairs"). You want to watch the recordings from either, on either. You can do that without any mods at all, using Humax's native DLNA mechanism (but the alternative is much better, see later):
Sharing Recordings by Native DLNA
Connect both HDR-FOXes to your home network, by whatever means. Ethernet cables to your router are preferred (and most stable), but that is not always possible and USB WiFi dongles, power line networking (HomePlugs), or Ethernet-connected WiFi adapters, are alternatives. Configure their networking from Menu >> Settings >> System >> Internet Setting.
On both HDR-FOXes, set Menu >> Settings >> System >> Internet Setting >> Content Share = On. This turns on the DLNA server, so that a DLNA client elsewhere on your home network can discover the server and play content from it.
To view a recording from the other HDR-FOX: Media >> Storage (blue) >> Network. This enables the DLNA client, which then lists the servers it can find on the network (the first time a server has been enabled, the discovery can take a long time so be patient - leave it a day if necessary). Navigating "HDR-FOX T2" will allow you to browse the recordings on the remote unit, but not necessarily in the same listing order as you are used to locally, and play them.
There are a number of drawbacks with this:
Recordings made are not immediately accessible via DLNA, they have to be "indexed", which typically takes place shortly (but an indeterminate time) after the recording completes. Neither are they available for "chase play" (when playback starts before the recording has ended), like they would be locally.
The DLNA index displays only the recording filename, not the media list title displayed locally.
The DLNA index does not have options to select the listing order, eg alphabetically or by date.
Playback by DLNA has limited options for transport control (only skip back, skip forward, cursor left, cursor right - no FF/RW or slo-mo, no jump-to-bookmark or set/delete bookmark, no resume playback). Neither can you delete/rename/move recordings.
Note that recordings are encrypted on the HDR-FOX HDD. The DLNA server circumvents this by decrypting the data (not the file itself) in transit to the client.
If you have more than two servers on your network, it will not be obvious which is which in Media >> Storage (blue) >> Network. Installing custom firmware provides a mechanism to give each unit an individual name (eg "Downstairs", "Upstairs", "Study"): WebIF >> Settings >> General Settings >> Hostname. For readers unfamiliar with Custom Firmware, see Quick Guide to Custom Firmware (click).
Alternatives to DLNA
The options described below use Custom Firmware to avoid all those drawbacks, and make recordings on the remote HDR-FOX (or even HD-FOX) behave as if they are local, with all the facilities. The process looks complicated when written out in detail, but actually it is very straightforward - especially if you are already a custom firmware user.
The key point to keep in mind is that HDR-FOXes (and HD-FOXes) encrypt everything they record, and only the unit that made the recording can play an encrypted recording. Sharing a recording by DLNA bypasses this problem, because DLNA sharing is (effectively) playing it from the original unit. Every other mechanism for sharing recordings must use a work-around:
Use Custom Firmware facilities to give all the units the same encryption key; or
Use Custom Firmware facilities to decrypt recordings to be shared.
Changing the encryption key for a unit means making any existing recordings unplayable unless they have been decrypted, and the encryption key will revert if the CF is not running for some reason (making recent recordings unplayable). Therefore, in practice, even if the units will have matching encryption keys, it is usual to set up full decryption as well. Nonetheless, matching keys are useful, particularly if a unit is never used to record and therefore has no recordings, or for HD-FOX (which has no fast decryption).
As it is difficult to anticipate which recordings will be required for sharing, it is usual to decrypt everything.
(not complete)
Sharing Recordings by Foxlink
NB: I do not use Foxlink myself, so I would be obliged for any corrections to the below.
If all you want to do is play recordings from one HDR-FOX on another (and not the other way around), the simple solution is the foxlink package. This is particularly suitable for a HDR-FOX + HD-FOX combination, where the HD-FOX is not used to make recordings (even on an external drive), and doesn't even need an aerial*, but provides access to HDR-FOX recordings from another room. If your requirements are more sophisticated than that, such as two-way sharing or more than two units inter-sharing, see "Sharing Recordings by SMB Server".
* Except for running the Setup Wizard after a Restore Factory Defaults operation.
The following describes the simplest possible setup, using a HD-FOX as the client, when the HD-FOX is never used to record locally. If the HD-FOX is used to record to its external USB drive, the following will make existing (not future) recordings unplayable, but this can be resolved later (see below).
(not complete)
Sharing Recordings by SMB** Server
Without using the DLNA server (and its limitations), other arrangements have to be made to circumvent the encryption. This can be done by ensuring all recorded content is decrypted.
What we are going to do is: (1) decrypt all existing recordings so they can be shared, and set things up so that future recordings are decrypted automatically; (2) set up an SMB** server on each HDR-FOX; (3) set up software on each 'FOX to look for specific servers and automatically make them available on the Media >> Storage (blue) >> USB menu.
** SMB is a network protocol used for implementing networked drives, and is supported by Windows. If you wish, or if you need to, you could use NFS as an alternative to (or as well as) SMB, which is supported by Linux and Mac.
For this to work, (unlike DLNA) it is essential your 'FOXes have fixed IP addresses on your home network. For advice about this see Configuring IP Address (click).
Ensure the DLNA server is turned on (this is necessary for hardware-accelerated decryption): Menu >> Settings >> System >> Internet Setting >> Content Share = On.
In case you haven't already, it is necessary to install CF (see above). As a minimum, install packages:
auto-unprotect
virtual-disk2
network-shares-automount
samba (for SMB).
Note that nfs-utils (for NFS) is already installed as a consequence of installing network_shares-automount.
Set all existing and future recordings to decrypt automatically by configuring the WebIF as follows: WebIF >> Browse Media Files, click "media" on the file path shown at the top, then on the "OPT+" button menu next to "My Video" select "Recursive Auto-Decrypt". The auto-unprotect package (installed above) is so that HiDef recordings will be treated the same as StDef recordings, otherwise HiDef recordings would not decrypt.
Installing the samba package has already created an SMB server available to the network. Now we configure network-shares-automount to pick up the server running on the other HDR-FOX:
Using WebIF media browser or the on-screen menus, navigate to folder "My Video/[ModSettings]/smb" (this folder was installed by network-shares-automount).
Within folder smb, on the downstairs HDR-FOX create a folder "Upstairs", and on the upstairs HDR-FOX create a folder "Downstairs". Wait a few moments, and network-shares-automountwill detect these new folders and populate them with some sub-folders, the names of which are used as settings for creating a network share. The default sub-folder names are:
domain=Domain or Workgroup
folder=ShareFolder
host=10_0_1_XX
mac=ABABABABABAB (only needed for wakeUp)
password=Password
shareFolder=off
user=User
wakeConstantly?
wakeNow?
If you want more information about the workings of network-shares-automount, see the relevant forum topic listed in "References".
The only settings which need editing are "folder=..." and "host=...". Remember that we are talking about the remote machine, so on the downstairs HDR-FOX, in "My Video/[ModSettings]/smb/Upstairs", rename "folder=ShareFolder" to "folder=My Video" and rename "host=10_0_1_XX" to "host=<IP address>" (replace <IP address> with the actual IP address of the upstairs HDR-FOX, substituting underscores for dots, eg "192_168_1_13"). On the upstairs HDR-FOX, in "My Video/[ModSettings]/smb/Downstairs", rename "folder=ShareFolder" to "folder=My Video" and rename "host=10_0_1_XX" to "host=<IP address>" (replace <IP address> with the actual IP address of the dowstairs HDR-FOX - which is of course different from the IP address of the upstairs HDR-FOX).
Reboot.
Now, what you should have, is the other HDR-FOX appearing as a pseudo-USB drive in each HDR-FOX's Media >> Storage (blue) >> USB menu, called either "Upstairs" or "Downstairs". Selecting it then brings up the contents of My Video, just as if it were on the actual machine, with all the usual management and playback options.
The main limitation is that, if a recording has not been decrypted, when you try to play it from a remote HDR-FOX you will get the "unsupported or scrambled" message.
The network-shares-automount package sets up SMB and NFS clients (by also loading the cifs and nfs-utils packages automatically). It then polls the network for active servers at IP addresses specified in the SMB or NFS sections of [ModSettings], and mounts them into the local file system as pseudo-USB drives if found. However, the Humax standard firmware doesn't make any USB device available on the USB menu unless it has detected a physical USB drive is present, so virtual-disk2 kids it that it has.
The auto-unprotect package removes the automatic protection applied to HiDef recordings, intended to prevent copying of high-definition content but it also prevents hardware-accelerated decryption. Once "unprotected", a HiDef recording can be treated exactly the same as a StDef recording.
The samba package provides an SMB server, whereas an NFS server is already included in nfs-utils (automatically loaded by network-shares-automount for its NFS client).
As mentioned in the main text, network-shares-automount has its own discussion thread (link at the bottom of this post). However, just to note: I do not recommend using shareFolder=on. This adds a special [Shares] folder in My Video (or Video on HD-FOX), linking to the remote shares mounted by network-shares-automount, but the standard Humax firmware doesn't know the storage inside that folder isn't local, so recordings in it are counted by the DLNA indexer and included in the free space calculations (neither of which are good ideas). Also, some users have had accidents and deleted that folder by mistake (or lack of knowledge, perhaps by another member of the household), resulting in all content being systematically deleted on the remote servers in the process (deleting a folder involves the contents of that folder being deleted, and then the folder itself) - that is why the name of the folder was made "[Shares] Do not delete!".
HD-FOX
The major difference with the HD-FOX is that it doesn't have a DLNA server, therefore cannot be the server in a DLNA-based pairing - but can be a client, and works in exactly the same way (as a client) as a HDR-FOX.
Ditto acting as a client for SMB: with custom firmware installed, install the network-shares-automount package (no need for samba, virtual-disk2*, or auto-unprotect) and set it up in exactly the same way as a HDR-FOX... except the [ModSettings] folder will be found in media/drive1 (or whatever your USB drive is called).
The HD-FOX can provide a SMB server by installing samba (or the NFS server available through nfs-utils), but (as with HDR-FOX) the content to be served needs to be decrypted, and without a DLNA server there is no hardware acceleration available to aid decryption. All is not lost: the HD-FOX can be made to decrypt in software, so by installing auto-unprotect and setting recursive auto-decrypt on media/drive1/Video (as per the HDR-FOX), recordings will be routinely decrypted just the same (except more slowly). Alternatively, select just the recordings you wish to access from elsewhere and set them to decrypt individually.
Encryption/Decryption Key Sharing
The alternative to decrypting everything you want to share (or just sticking with sharing by DLNA), is to have all the 'FOXes use the same key for encryption (and decryption). This means that when an encrypted recording is shared, the client 'FOX is able to decrypt the recording and play it, just the same as it would for its own recordings.
The CF is able to modify the encryption key the 'FOX uses: WebIF >> Settings >> Advanced Settings >> Encryption Key, which should be 32 hex digits long (including any leading zeros, which must be explicitly stated). If you were starting from a clean slate, with no existing recordings, it would make sense to simply give all your 'FOXes the same encryption key, and then recordings would be completely interchangeable.
There are a couple of "gotchas" though. The first is that, before changing the key on any particular 'FOX you must make sure all existing recordings have been decrypted, otherwise they will be useless without changing the key back again. You can tell when a recording has been decrypted: in the WebIF media browser, it will be marked with a "DEC" icon.
The other "gotcha" is that, if CF isn't running, the key will revert to the original. It is therefore well worth routinely decrypting, even with shared encryption keys.
Shared keys are particularly useful in one scenario: there is a HD-FOX in the mix. Decryption on HD-FOX is by software only, which is significantly slower than the hardware-assisted decryption available on HDR-FOX, so new recordings are not available to share for some time after broadcast. Decryption of the HD-FOX's content can be avoided by giving all the other 'FOXes the same key as the HD-FOX. However, software decryption performance is significantly improved by setting a key with repetition in it, so the recommended process (if your setup includes an HD-FOX) is:
Set all existing recordings for hardware (HDR-FOX) or software (HD-FOX) decryption;
When complete, set the encryption key on all 'FOXes to "00000000000000000000000000000000"* (and continue to routinely decrypt);
* As a bland key is recommended for efficiency, and there is no need for security, there is no point in choosing any other key than the obvious "all zeros". Note, however, that all-zeros is not a null key (no encryption) - it's just encryption using a key which happens to be all-zeros. "33333333333333333333333333333333" has also been suggested, as this could be represented by the standard formula (whereas all zeros is not).
Another advantage of key sharing is "chase play": decryption does not take place until the the recording has completed and the DLNA indexer has found it, so a recording is only available in encrypted form until then. If the client has the sane key as the server, and can therefore play encrypted content from the server, it is able to play recordings which are still in progress (just like it would locally), and this minimises any apparent difference in user experience between local and remote recordings.
The native encryption key is constructed using the serial number of the 'FOX and its MAC address - both of which are shown on the label. Thus it is possible to recover undecrypted recordings from a dead HD- or HDR-FOX by reprogramming the key on another 'FOX, or by software decryption, if you still have those details.
Decryption can occur at the same time as a recording is taking place, using mechanisms for "chase decryption" built into the detectads package.
Software decryption on-the-box tests the current key for decryption, and if that fails tries the 'FOX's native key. Thus, even with a user-specified key, recordings encrypted with the original key (but not a different user-specified key) can be decrypted, but without the usual hardware acceleration.
Short-Cuts to Specific Folders
By following the instructions for SMB sharing above, the link to any particular 'Fox from the USB menu on another 'Fox presents the contents of My Video (as configured using the "folder=" setting in ModSettings.
Excellent (but 24 hours too late ). At least I now know what I have is actually correct.
My installation is single ended, so I (at your suggestion I think) decrypted just one box and then set the keys the same. Decrypting the almost 1TB on the other box would have been horrible. It might be worth covering that explicitly as an option.
One of the other info sources mentioned the _ not dot or other things, and I got carried away and used "My_Video" for the name in the ShareFolder. I got there eventually, but again might be worth making explicit.
A couple of questions.
I installed samba on both boxes. Was that needed for single ended?
The [ModSettings] folder is in the My Video location. Is there any way to hide this? (And why not a config file?)
I could have sworn you originally expressed an interest in mutual sharing, but I haven't checked. samba will be needed for collecting everything together under the USB menu, which is on the "to be continued" agenda.
Bit of a shame that really, though I understand why some people may want it configurable through the SUI if they are not that conversant with going directly into the file system to set it up. To those who are though it's really a 'set and forget' thing to my mind, so having to have it permanently pollute the SUI media file list is regrettable.
To those who are though it's really a 'set and forget' thing to my mind, so having to have it permanently pollute the SUI media file list is regrettable.
Yes, I like that idea. Things have moved on since NSA was created. Maybe NSA2, and leave NSA as it is? Or just have NSA only create and look for [ModSettings] if a config file doesn't exist? (If the latter, then installation could create a dummy config file for editing and renaming.)
It strikes me it would be simpler to run up a tweaked version of NSA as NSA2, that just doesn't do any of those [ModSettings} things and reads a config file instead.
I understand why some people may want it configurable through the SUI if they are not that conversant with going directly into the file system to set it up.
I was thinking/expecting it would be set up via WebIf, since I used that to install the packages. No need to get into the file system and cmd prompts.
But it is what it is for now. As prpr says it would need a bit of work by someone (competent) to change it and that also has potential issues with backward compatibility as BH alludes, so it's not trivial.
I suppose it would be quite easy to support a hidden directory (eg .ModSettings) as an alternative name for the configuration directory, in case it is not desired to make the configuration available via the on-screen UI, certainly a lot easier than adding support for a configuration file.
Again, historical. There wasn't much consensus what to call stuff. Modified/Custom Software/Fimware. You have to have been around at the beginning (those were exciting times, some individuals making break-throughs and then the application of those break-throughs).
Some people wanted to be able to use the CF facilities without a web browser, which is why there are "bundles" that can be downloaded to UPD and installed just by plugging it in.
So the relevant code is in /mod/sbin/scanmounts. The block of code from the comment at l.123 to the end of the if-block ll.125-131 can be replaced as follows:
Code:
# set up links to where we can get at the settings folder (a bit messy due to HDR / HD differences)
# allow for several possible settings folders, separated by |; last is default
modsettings='.ModSettings|\[ModSettings]'
# if the settings folder is mounted but not present, unmount
# (allow for alphanumeric chars and \._- in mount point dir name)
sroot="$(mount | grep -oE "/([._\\[:alnum:]-]+/)+(${modsettings})")"
if [ -n "$sroot" ]; then
# unescape eg '\040' -> ' '
sroot="$(printf "$sroot")"
[ -d "$sroot" ] || umount "$sroot"
fi
# if the settings folder is not mounted, set it up
if ! mount | grep -qE "(${modsettings})"; then
case $(cat /etc/model) in
HDR) # put [ModSettings] here as root isn't accessible
sroot="/media/My Video"
;;
*) # HD put [ModSettings] on root
sroot="/media/drive1"
;;
esac
# strip any regex \ escape from possible modsettings and split at |
for ms in $(IFS="|"; echo ${modsettings} | sed 's@\\@@g' ); do
# if dir exists, or it's the default
if [ -d "${sroot}/${ms}" -o "[ModSettings]" = "${ms}" ]; then
sroot="${sroot}/${ms}"
break
fi
done
# assertion: "$sroot" is a valid directory pathname, either actual or potential
mkdir -p "$sroot" &&
mount /mod/settings "$sroot"
fi
The idea of this is that you use the package to create the settings folder, then stop it /mod/etc/init.d/S90netshares stop, rename it (eg for HDR mv "/mnt/hd2/My Video/[ModSettings]" "/mnt/hd2/My Video/.ModSettings" and start it again /mod/etc/init.d/S90netshares start; after that the package will use the hidden folder instead of the one it created. In fact, it should be possible to switch the directory name back and forth using this procedure, depending on whether you want to use the on-screen UI or not.
...
There are a couple of "gotchas" though. The first is that, before changing the key on any particular 'FOX you must make sure all existing recordings have been decrypted, otherwise they will be useless without changing the key back again. ...
Apparently manual decryption will try to use the original key if the new key doesn't work for a particular recording. That does mean running it on the machine where the recording was made, though.
I've installed [ Foxlink ] on two of my Humax HDR Fox T2 recorders, but not to watch or stream recordings, I've set it up to move recordings on to a third, the main recorder, all three are Humax HDR Fox T2, that have custom firmware, all three have auto-updated firmware and package updates, but...
I've also set up [ sweeper ] rules to move files, which do actually work, but need some polish
(the main recorder is 'A', so we'll call the second recorder 'B')
For example, 'B' is used to record conflicted recordings originally intended to be recorded on 'A' (recordings that were going to be recorded on 'A' but caused a timing conflict), a check is made using [ sweeper ] that the correct lcn, recording title, recording time, 'is' new, 'is' shrunk, it then gets moved to the [ /media/HDR ] which is the [ foxlink ] path to recorder 'A' and gets deleted from the recording's original location, on recorder 'A', a [ sweeper ] rule then moves the recording to [ /media/My Video ] from where it is watched, another [ sweeper ] rule processes it further as it now has a not new flag
The recording on 'B' is recorded to [ /media/My Video ] and copied to a [ moving folder ], in the [ moving folder ], a [ sweeper ] rule moves the recording to [ /media/HDR ] as a result, deletes the recording from the [ moving folder ]
The recording then gets copied again on recorder 'B' to [ /media/HDR ]
I want to keep the recording on 'B'
Ideally, I would like the [ sweeper ] rule(s) to mark the new file as watched when the recording is copied from [ /media/My Video ], so that is doesn't keep getting copied to the [ moving folder ] ( the [ moving folder ] is a stepping stone folder from where it is actually moved to [ /media/HDR ] ), how do I make follow on [ sweeper ] rules work, the rule that starts [ Previous Rule Matched ]
Sorry, this is so long, but having got in to [ sweeper ] from your kind encouragement, but my concentration is not what it once was, I tend to prod and poke by experimentation until I get somewhere or give up, I have tried [ network-shares-automount ], but all those options mean nothing to me, but I have got [ Foxlink ] doing partially what I need, it may not be being used for what it was intended for, but sort of works for me
Many thanks for all the hard work and time helping
I recommend foxlink is only used for simple one-to-one one-way sharing, which is what it was designed for and all it can really be used for. Use network-shares-automount for anything more complicated.
As to the rest, it would be better asked in a sweeper thread and would be inappropriate to discuss here (even if I knew the answer). I believe you already have a thread discussing your sweeper problems.
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.
). At least I now know what I have is actually correct.