Smart Home Automation Part III - Media Systems

Incorporating the TV and the HiFi

The most visible part in any home environment is the media system. Ever since real fireplaces fell out of fashion, the TV or stereo system has become the focal point of most living rooms. They are also the devices with which we spend the most time interacting. It is therefore essential you understand the possibilities of these devices.

As with all consumer electronics, the feature sets and prices change on a daily basis. Therefore, I’ll concentrate primarily on the necessary features and inner workings of the machines without detailing specific makes and models, since by the time you read this, other machines will already be available.

The Data Chain

The simple act of “playing an album” changes significantly in the home automation field. Not only is the location of the media itself unconstrained, but it’s also the place where you can listen to it. This has been exemplified recently with iTunes allowing you to play music on several different computers and with Spotify providing a music-streaming service allowing access to various music tracks from your home PC or mobile.1 If your interest in music is casual, or chart-based, then these services are often enough. But for many people, they have albums in their collection that are either rare or obscure enough to not appear on any commercial-led web site. Or they might prefer to have their music data stored on their own computers, lest the company go out of business, change the terms of service, or lose connectivity in some other fashion. When this is the case, we need to provide a way of getting the music from a hard disk to the human ear. This is the data chain.

There are four steps in this chain. The first step is the data itself. This is the directory structure of WAVs, MP3s, or OGGs that represent the music (or other media) in your collection. This data is then read by a server (which is the second step) before being distributed (the third step) to one or more speakers in the house. The fourth and final step is when the human gets to hear (or see) the media. This model still applies when playing music on a portable music player or desktop PC, although for a desktop PC all the logical units are held within one physical box.

Extracting the Data

Often known as ripping, this is the process where the media, usually stored on DVD or CD, is converted into a computer-friendly data format, ready for playback. Many pieces of software are available, so I’ll cover these with an example only.

Compact Disc

A CD is the easiest and quickest format by far, because most of the constituent parts are available within Linux. A tool, such as abcde, can automatically do the following:

• Extract the audio as a WAV file
• Convert it to OGG Vorbis
• Determine the artist and album
• Download and apply the tags automatically
• Name the files accordingly

All that is then necessary is to copy the files to your filesystem. I personally always extract my CDs to a separate (local) folder for reasons of speed—it’s faster to write locally and then copy en masse since it means my server isn’t dealing with lots of small write requests when I might be wanting to stream something else. This also gives me an opportunity to manually change the files in case there’s a problem, as sometimes happens when the album is longer than the standard 74 minutes.2 For mass ripping, you can write a short script that saves time by automatically opening and closing the CD drawer. It might not sound a lot, but the initial hurdle in extracting your music collection is psychological; the thought of swapping many hundreds of CDs and renaming and tagging each file is daunting. Since the audio is ripped at the speed of your CD or DVD drive (and not the duration of the album), you can extract a whole disc in about 5 to 10 minutes. And with the online track listings database (CDDB, which combines the start time and duration of each track into an ID for the disc as a whole), the tagging process is also automatic. Sometimes there are duplicate IDs, which requires manual intervention, but most of the discs can be processed automatically using the -N flag, as shown in the following script. The abcde script also supports arguments that allow you to specify the format of the filenames, if this is important to you, along with layout information for handling albums with multiple artists.

1. #!/bin/bash
2. while :
3. do
4. echo Insert next disc...
5. read x
6. cdcd close
7. abcde -N
8. cdcd eject
9. done

DVD

With the more complex format of DVDs and the industry’s perpetual insistence that encryption isnecessary, the ripping of DVDs has an extra requirement,3 namely, libdvdcss2. This is a library that circumvents the copy protection on encrypted discs, which most commercial movies use. Its legality is uncertain, so the major Linux distributions have erred on the side of caution by not including the package. Instead, the library must be downloaded separately, either from an alternative repository or from compiled source. Naturally, I must take the same “safe” approach and can only tell you how you might install it, if you find the files on a web site somewhere.

On Debian, for example, an extra repository is added by placing a single line in the /etc/apt/sources.list file:

deb http://www.debian-multimedia.org lenny main

This is followed by the following traditional process:

apt-get update

apt-get install libdvdcss2

Sometimes you have to download and install the package manually. That command line invocation would be as follows:

dpkg -i libdvdcss2_1.2.10-1_i386.deb

Alternatively, the source installation would be as per the INSTALL file, probably something like the trinity of this:

./configure

make

make install # as root

Once you can use VLC to play DVDs, you know the library is successfully installed and is consequently available to all the main media player applications, such as mplayer, totem, xine, and so on.

When ripping DVDs, you have to consider the amount of hard disk space you want to devote to your collection, whether you want (or need) the DVD menus, and on what devices they are being played. Ultimately, there are two choices.

Rip As ISO

This makes a raw copy of the entire disc and stores it as a file. This is the easiest process to initiate, because you simply invoke the following:

dd if=/dev/dvd of=TheOffice-series1.iso bs=1024

This will generally require between 4GB and 8GB of space and includes all the DVD menus, titles, chapters, and subtitles. Movie players like VLC will be able to handle interactive components such as menus, but others won’t. This is especially true of units that don’t support the DVD logo since they won’t have the CSS code and of smaller low-power devices such as MediaMVP. In the case of the latter, you can partially solve the problem by using VLC to remotely transcode the movies, but it still won’t be able to handle the processing of the DVD menus.

As will all disk images, Linux is able to mount them to a directory so they can be read and so their files can be queried normally. This can be done with the following or automatically through the desktop:

mount -t udf –o loop TheOffice-series1.iso dvdimage

Note that you cannot mount the image to your usual DVD location (such as /dev/dvd) since that is a block device, and you can only mount images to a directory.

Rip As Movie Files

This method occupies the bulk of “DVD ripping” software, with many available versions for both the command line and the GUI. Although the GUI versions provide screenshots of the titles and chapters and an array of configurable options, they are (almost without exception) merely front ends to a set of standard back-end tools, such as mencoder. You can remove the resources and time utilized by this middle man by going straight to the metal.

UnDVD (http://sourceforge.net/projects/undvd/) is a Perl script that provides a simple

command-line method to rip DVDs into their component titles, taking whichever language or subtitles you want at the same time. A typical invocation to rip the first three tracks, with English audio, might be as follows:

undvd -t 1,2,3 -a en

The number of tracks available can be determined with the associated tool, scandvd. Since most households will speak a common language, the necessity for the full ISO is reduced, making this a consistent process. The following script provides a full rip of the disc into its own subdirectory. It could even be triggered from a link on the household web page, for example.

1. #!/usr/bin/perl
2. my $language = "en";
3. my $subtitles = "off";
4. my $output = `lsdvd`;
5. $output =~ /Disc Title\:\s+(.*?)\n/s;
6. my $title = lc $1;
7. $title =~ s/\b(\w)/\U$1/g;
8. $title =~ s/_(\w)/ \U$1/g;
9. my $cmd = "undvd -t 1";
10. my $count = $output=~s/\nTitle\://g;
11. foreach(2..$count) {
12. $cmd .= ",$_";
13. }
14. mkdir($title);
15. chdir($title);
16. $cmd .= " -a $language -s $subtitles -e 2";
17. system($cmd);
18. chdir("..");

Issues with Movies

With so many codecs and players available, it’s inevitable that you will occasionally find one that has a problem, such as being unable to play the movie, crashing partway through, losing synchronization between video and audio, unable to fast-forward, and so on. Even the commercial offerings have these problems, so they’re not unique to the open source community. In fact, since we work primarily with software-based solutions, we have a better deal, since the problems can be fixed fairly quickly. Here are some tips:

• Sometimes you can solve sync problems by pausing and unpausing the video.
• Movies that won’t fast-forward often don’t have an chunk index, which can be built when starting the movie with mplayer -idx.
• Other problems will usually need to be reencoded (or transcoded). This can be handled from the larger tools, such as VLC.

Cassette Tapes and Vinyl

Yes, really! There are many people with these beloved relics of technology who want to keep them alive electronically. These are the slowest form of media to rip since they must be done in real time.4 The obvious way to do this is to connect the phono outputs from your deck (be it tape or record) into the line-in inputs of your sound card. You should have as few components in the signal chain as possible, so if your turntable has a preamplifier, so much the better. Otherwise, consider the relative merits of your sound card and deck, and let the higher-quality unit perform the preamp stage. Vinyl particularly requires a preamp stage with RIAA equalization to avoid the sound sounding tinny. 

Once you have the deck connected, find the loudest section of music, and monitor the levels in an audio-recording program, such as Audacity. It should be as loud as possible, without clipping.

This ensures you get the most out of the 16-bit resolution, ensuring the maximum possible dynamic range. This volume, however, should come from the preamp if possible, since a power amplifier will introduce noise.

To ensure maximum quality during recording, you need to take care of external hardware elements, too. So, don’t use the microwave while recording because this can introduce electrical noise that might affect the recordings, don’t fiddle with the connectors, and so on. It is also a good idea to plug the deck into a high-quality UPS or power smoother to limit the amount of wow and flutter caused by fluctuations in mains voltage.

The same approach also works for cassettes, although most tape players have a built-in preamp, so you have no choice here.

There are currently some all-in-one units on the market that combine a tape or record deck with all the necessary amplifiers and converters necessary to provide you with a digital input over a USB cable.

These are ideal for casual users, but since they are made to a price point, and not for quality, you won’t get as good results as you will from a manual setup.

Once you have the recording digitized, it is then a matter of extracting the individual tracks from the file called side_1.wav and encoding them accordingly. There are some tools to do this automatically.

Audacity has its own Silence Finder function (in the Analyze menu), which looks for suitably long gaps in the recording and places markers by them. You can then adjust these markers if necessary and select Export Multiple to save the data between these markers as individual files.

You can then encode them as appropriate. Here’s an example:

#!/bin/bash
LIST="$(ls *.wav)"
for FILE in "$LIST"; do
flac $FILE
done
or with the following:
oggenc $FILE

According to the music and your personal opinions of high-fidelity audio, you may choose to keep this music in one or more formats. The most direct is to keep only the OGG files, because they are suitable for casual around-the-house listening and some fairly involved critical listening. For more discerning audiophiles, Free Lossless Audio Codec (FLAC) provides the same quality as WAV but in a smaller footprint. Some people will keep the FLAC versions stored away on a separate (offline) hard drive while using the OGG files for everyday use. This allows the high-quality recordings to be reencoded at a later date when better-quality codecs become available, without needing to rerip the data.

True audiophiles would never be happy with a computer sound card and should never rip the music in the first place!

Storage

All data must be stored somewhere. In desktop computing that’s an internal hard drive. In home automation, we want that drive to be accessible everywhere else. This generally means it must be on a network and controlled by a network service like Samba.

Stand-Alone NAS Systems

Network addressable storage (NAS), to all intents and purposes, is a hard drive that connects to the outside world through a network cable and IP address instead of an IDE, SCSI, or SATA cable. There are two main advantages with this approach. This first is that by being naturally network aware, you can use the files anywhere in the world with little to no additional configuration. This includes your office, your partner’s office, the bedroom, or even a laptop in the garden or on the train, connected wirelessly. The second is that by being separate from the main computer, you can declutter your main work area by hiding the NAS drive in a cupboard or in the loft/attic. This has a security benefit whereby any burglar stealing your computer hasn’t stolen your data also.

Naturally, without a computer to control the hard drive, there has to be a driver somewhere in the data chain determining the disc format, capacity, and network connectivity. This can either exist in the NAS unit itself or from the server machine wanting to read the drive. Many different versions are available.

Hard Drive Considerations

The main selling factor of any NAS is its storage capability. Currently, anything less than 1TB is rare, which is fortunate since many older IDE drives had a limit of 137.4GB because of the 28-bit addressing mode of Logical Block Addressing (LBA). Avoid anything smaller than 137.4GB in case the manufacturer is using old hardware under the hood, even if it supports an external USB drive, since that will invariably be governed by the same limitation.

Alongside the argument for disk space is the concept of disk format. This is usually given as FAT, FAT32, NTFS, or ext2 and limits the maximum file size possible (as shown in Table 3-1). The format also governs your likelihood of being able to recover it if you need to mount the drive in another machine.

So clearly, if you’re wanting a NAS to store DVD images, you will need a filesystem that can support 4.7GB files. This usually means FAT-based systems are inadequate or that you will have to remove the DVD menus and reencode the movies into an alternative (and smaller) format.

The recover question is slightly more involved. If you ever have to remove the hard disk from its NAS mounting and place it in a standard PC to recover the data, you will need a PC that is able to read whatever filesystem is used by the NAS.

NTFS fairs slightly better in the Linux compatibility stakes, but not much. Although it’s possible to read NTFS partitions under Linux, writing back to them is considered dangerous, although there are two open source drivers (Captive NTFS and NTFS-3G) that do support it. Additionally, there is a commercial driver (NTFS for Linux, from Paragon) that solves the same problem. For basic recovery, a read-only disc is fine, although you won’t be able to repair the disk without reformatting it for the most part.

The natural solution is to use ext2 for any and all NAS drives, because this has the widest support in the Linux world. Many NAS devices now support this, so it can be worth spending a little more to get one because it ticks all the boxes. If your main desktop machine at home is Windows, then there are even ext2 recovery tools for Windows such as Linux Recovery from DiskInternals.

The type of data you’re storing will determine the type of backup plan you need. When this is personal data, such as letters or photographs, then consider a NAS featuring built-in RAID functionality.

These often autoconfigure themselves when a second drive is plugged in, so be warned if you insert a used drive thinking you’ll gain extra space! Several types of RAID configuration are available, but the most common in this case is RAID-1, which uses a second drive to make identical copies of anything written to the first. It does this automatically and transparently from the user, so should either drive fail, the other can be used to recover the data. You should always remember, however, that RAID isn’t a backup! It just makes it a bit less likely that you’ll lose data to disk failure. It won’t protect against corruption from controller failures, fire, flood, or theft.

Note 

Using hardware RAID solutions is a double-edged sword for some system administrators. They work seamlessly and take no effort to set up and maintain. However, if the RAID system has a problem and uses a custom disk format, then it might be impossible to recover the data on the disk. You can solve this by buying two pieces of hardware and verifying that you can swap the disks without a problem before they are put into active service. Alternatively, you can check with the manufacturer that the disk format used either is known or comes with suitable software recovery tools.

Backing up data, such as DVD or music rips, doesn’t (and shouldn’t) require RAID—although having one does no harm. Since this type of data changes less frequently, you can make do with an external USB hard drive plugged into your desktop machine. You can then run the backup software of your choice (see Chapter 6 for some possibilities here) to copy only those files that have changed and then unplug and store the drive. This prolongs the life of the drive and is worthy of the extra effort.

As with all backups, they are useless unless tested regularly, so make sure that you do test them. Some people will test them by copying their backups to a new drive every 6 to 12 months. The cost is negligible, compared to the many hours spent ripping and organizing the data. Furthermore, the price per gigabyte comes down every year, allowing you store more data in a smaller form factor. If you are desperate for extra space, you can then reuse the older drive elsewhere in your system. Although tape backup systems are a favorite of most businesses, the cost and convenience of USB hard drives render them unnecessary for the home market.

Note 

Hard drives either fail in the first few weeks or the day before you remember to back up. Therefore, when buying disks, always buy from different manufacturers and at different times, so if you get one disk from a bad batch (IBM Death Star, hang your head!), you minimize your chances of getting two.

Networking Considerations

For the most part, the network setup of a NAS is straightforward. Usually, it will acquire its own IP through DHCP and provide access to the disk through the services of CIFS/Samba. Sometimes you will need a Microsoft Windows machine to run the setup software, but this is becoming less common as configuration is done through a web page running on the NAS. The main warning here is to look out for machines that don’t have a Samba service and instead rely on something like ZFS.

ZFS is a filesystem that originated at Sun Microsystems and features on NAS systems like the Netgear SC-101. But despite the ZFS specification and its use in larger commercial systems, it does not yet have a suitable kernel driver (because of license incompatibilities). It is currently only possible to run it in conjunction with the Filesystem in Userspace (FUSE) project or the supplied closed Windows drivers. Consequently, if only a ZFS service is provided (like the aforementioned SC-101), it is necessary to install specific drivers on every device that wants to read data from the NAS. This makes it annoying for PC users and impossible for other hardware like the Squeezebox.

Controlling a NAS through Windows Vista can be problematic since some NAS systems use alternate authentication systems. This can be fixed with a registry hack here:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa

by setting this:

LmCompatibilityLevel = 1

Extra Functionality

With many NAS drives being little more than embedded Linux machines, adding extra software is trivial...for the manufacturer. Typical applications include the following:

• Printer server 
• BitTorrent client
• Backup support
• iTunes server

If you want to add your own software, then you are usually out of luck, unless you have one of the variants that has been already hacked, such as the NSLU2, or have a lot of time on your hands to discover the hack yourself! When planning a much larger home installation, then you will probably only need a very basic NAS drive, because it’s likely you’ll soon upgrade to a custom Linux server that will support all the extra functionality you can possibly throw at it, with the NAS service being  available for free.

When buying your first NAS, worry not about the extra functionality but of the storage space it supports because you might not have enough free space left to warrant running a BitTorrent client on it, for example. So many NAS machines are available, at fairly cheap prices, that you don’t need to worry about having everything in a single box. It is not uncommon to have one NAS with several terabytes of space for the primary media storage area for DVD and CD rips and another used as a secondary store and a function server. This second NAS then acts as a daily backup for your desktop PC and printer server. These roles allow you to power down one NAS (through X10, perhaps) for the times when it isn’t needed.

NAS with Media Playback

To some, this is simply a NAS with a TV-out socket on the back. To others it constitutes a paradigm shift, because it allows you to treat the unit as if it were a portable VCR and video library rolled into one. As with everything, its value is governed by how you intend to use it.

One of the big selling points of these devices is that they can be moved from room to room, and even from house to house, without requiring a network. This makes it much easier to show your photographs and home videos to the ungeeked members of your family and friends because you can simply plug a media-enabled NAS device into any TV, and it will work. It is also a way of introducing (a small level) of control over what the kids are able to watch, because they’ll be limited to the contents of the hardware.

Note 

There are many applications that block content for kid-safe viewing. But as parenting books tell you (or, as any parent knows), you can’t solve these problems entirely by technology because it is not really a technological problem.

If you want to expand your media beyond a single room, you will need a version that supports Ethernet, such as Freecom’s MediaPlayer II or cineDISK NAS. These are combined NAS drives, supporting file sharing through Samba, and media streamers that play back files to a TV or HiFi. They have the benefit of being able to stream from a local disk, thereby eliminating any network latency and limiting the cost of separate media units such as the MediaMVP. Furthermore, by distributing your media between several of these devices, you won’t lose everything if an (unbacked up) hard drive fails.

With minimal effort you can distribute the files to those machines that are more likely to play them, such as films in the living room, TV series in the bedroom, MP3s in the den, and cartoons in the kids’ room. If you are separating media in this way, be mindful of potential storage upgrades. Some devices provide a USB port for an external hard drive or memory stick (although some cheaper machines intend this for memory sticks only and do not support large disk sizes), so place these machines in rooms that are likely to increase their disk footprint the most. From personal experience, the disks holding TV shows have filled the quickest by an order of magnitude.

The problem with these type of devices, like all embedded hardware, comes from their upgrade path, and not all companies will add or release new firmware with the latest codecs or fixes to old ones— and many of the devices are too new to have a hacker community to help. Also, unlike the MVPMC, there is not usually a way to use an external transcoder in this situation.

Also, check the specification of each device carefully, because despite the name “NAS” appearing on the box, not all provide a network socket. Some manufacturers will claim it’s “HD-ready” when what they mean is that it will decode the files...but is only capable of viewing it in standard definition. Also, many are supplied without a hard drive but will require one, even if you only intend to stream media through the network, such as with the Emprex Multimedia Player.

However, it is always worth keeping an eye on the market for these devices, and they will often provide new ideas that can be implemented in software, such as the “watch YouTube on your TV” feature.

Configuring a Linux Box

By far the most flexible NAS server is the one you build for yourself. Any machine is suitable, since the processing power need not be great, so it can be an old laptop, Mini-ITX box, or NSLU2. The only requirement is that it has network compatibility. The optional features include USB ports (for additional drives) and a modern BIOS with 48-bit LBA so that it supports disks larger than 137.4GB. This does not just apply to internal disks, but it’s also necessary if you are using external USB hardware since they usually rely on the machine to control the disk.

As ever, it is not necessary to store all your media on the one machine nor is the one machine suitable only as a file server. If you are distributing your media across different physical disks, then it is preferable to store those that necessitate higher bit rates (such as movies) on internal drives and low bit rate media (such as cartoons or music) on external drives or on slower servers.

Each machine needs to be set up as you saw in Chapter 1, but you need to take care with your naming convention if there are multiple servers or you’re likely to move the units.

Preparing a Machine

Being Linux-based, each machine will already have its own filesystem in place (including commercial devices that are based around it), so your only task here is to provide a place for your files.

For internal hard drives, always create a separate ext3 partition for your media. A separate partition is used so it can mounted separately (which makes for easier recovery in case of a crash or power outage), and ext3 provides a journaling filesystem. Also, since the media partition is likely to be the first one filled, your Linux machine will not run into problems if finds there’s no more disk space left. Then provide a mount point by adding a file to /etc/fstab:

/dev/sda7 /mnt/mediadisk auto user,noauto 0 0

And create hard links from somewhere more convenient; in my case, I use a root folder on the server called /media:

ln /mnt/mediadisk/media/tv /media/tv

Note that I have not stored files in the root of the sda7 partition but inside the media/tv folder. This conventional directory structure will benefit me later, should the disk’s purpose be extended to include extra functionality such as backups.

External USB hard drives work in the same way but with a different line in /etc/fstab:

/dev/sdb1 /mnt/usbdisk0 auto user,noauto 0 0

In both cases, the disks are not mounted automatically. This is a personal preference, since it requires—and requires me—to check the disks after a major power failure or crash, a step others might ignore or skip, to the detriment of the filesystem.

The other change for external USB devices is that since the directories are on different physical disks, you are required to use a symlink instead:

ln -s /mnt/usbdisk0/media/tv /media/tv

One addition for these drives is to note which physical hard disk is used to store the content. This is for when a drive breaks, or is about to, and you need to remove the correct one. It is also helpful in those cases where two USB drives have been mounted in the reverse order.

To do this, I simply change to the root directory of the drive in question and type the following:

touch THIS_IS_THE_SILVER_LACIE_500G_DRIVE

touch THIS_SHOULD_BE_MOUNTED_UNDER_SDB1

This demonstrates another reason for not polluting the root. If you’ve followed the tip about buying hard drives from different manufacturers, these names are easy to pick.

Preparing a Filesystem

Once the machines are ready, the media filesystem must be considered; you must think of it in global terms across every server and across the whole house. There are three elements to the storage chain to consider:

• The machine name
• The machine’s physical location
• The shared folder names for the media stored on that machine

Taking these in order, the machine name will often be provided by the manufacturer, such as cineDISK. If you have the ability, rename it to cineDISK1, and add a sticky label to the back of the device indicating this. Always add an incrementing number to the devices if possible, because this will make scanning, backup, and maintenance scripts easier to write since each name is logically created, without arbitrary caveats.

You might want to name the device without any reference to the manufacturer, as in media_nas1. This is also fine, but it’s recommended that you note to which device this refers. I use a single page on my home’s internal wiki containing all the devices, model numbers, MAC addresses, firmware versions, web forums, and so on, of each piece of hardware connected to my network. I also use this to note the physical location of each machine.

The shared folder names should all follow a convention such as media_movies, media_tv, and so on. If you have kids and are providing them with access to the network, then providing separate folders such as media_kids might be an idea. The reason for splitting all the media into separate shared folders is that each can have distinct Samba access rights (each with or without passwords) and be unmounted on its own without affecting the rest of the system. It would be much harder work to control a directory of media/movies if only the root media folder was shared.

Preparing a Master Server

So far we have a number of servers, with lots of technical information and metadata. These names are all for the purpose of maintenance. No user would want, or should need, to know that the cartoons are on media_nas2 in the spare bedroom, under media_children. Nor should a family member be interested that you’ve split the movies folder across two separate disks5 because there were too many for the old drive.

To this end, you should designate a master server. It can be one of the media servers or an entirely different machine. It is recommended that this master server be running the most prominent and important services in the house, one that also stays on 24/7. This allows it to be used as Node0, which you’ll learn about later, in Chapter 4.

This Node0 machine then mounts each shared folder, from each server, into its own directory structure. And it is this directory structure that is shared so that each media-streaming device can access the media.

Note 

On first glance it appears wasteful for NAS1 to connect to Node0, only to be connected back to NAS1, but to scale up effectively, provide all media in a unified environment, and support dynamic changes in the media architecture, this is the best way to do it.

The directory structure I use pulls together all the Samba shares like this:

/net/homenet/slug1/media_tv

and local disks like this:

/net/homenet/mediapc1/usb2/media/movies

into a hierarchy underneath /net/homenet as a number of links or Samba mounts. This is becomes a self-documenting report for the media server layout of home. I then create a series of links under the /net/media directory to hide the structure:

ln -s /net/homenet/mediapc1/usb1/media/tv /net/media/tv
ln -s /net/homenet/mediapc1/usb2/media/movies /net/media/movies
ln -s /net/homenet/itx1/usb1/media/mp3 /net/media/music
ln -s /net/homenet/slug1/usb1/media/videos /net/media/videos

It’s then a simple matter of adding Samba shares for each directory:

[media_tv]
    comment = Media (TV)
    path = /net/media/tv
    browseable = yes
    public = yes
    writable = no
    read only = yes
    guest ok = yes

As in Chapter 1, I create basic Samba shares that are read-only for the family and create separate ones for me that are password-protected and read-write.

Note also that I have used my home’s subdomain (homenet) as a delimiter from the rest of the directory, instead of placing everything in /net. It allows me, as a software developer, to create my own subnet that isn’t part of the general home automation network in case I need to do something risky or experimental!

Share this post