Category Archives: MythTV

Link: Some hints for getting free-to-air satellite channels into the Electronic Program Guide in Kodi (or another frontend)

If you are running a satellite backend system such as TVHeadEnd or MediaPortal (or MythTV, if you are one of the lucky few that can actually get it to work), and you use Kodi or the MythTV frontend, then it is possible to populate the schedule grid with listings from many sources. Note I did not say that it is easy, just that it is possible. The key is to use an external program … These are commonly referred to as “schedule grabbers”, or just “grabber” programs.

The real trick is figuring out how to use one of those programs. …..

Some hints for getting free-to-air satellite channels into the Electronic Program Guide in Kodi (or another frontend) (Free-To-Air America)

If you tried upgrading XBMC under OS X, run a MythTV backend, and get the error “No PVR Client has been started yet”, see this thread

This thread contains information on the buggy XBMC version 12.3 for OS X, and a couple of suggestions for reverting back to XBMC 12.2, which will fix the problem for now.  This issue does NOT appear to be present in Linux versions of XBMC 12.3.

Link: MythWeb ssh tunnel howto [for MythTV users]

I am going to briefly describe how to connect to mythweb that is behind a firewall in a router. I will assume you have mythweb running. If you need help with that please see the mythweb documentation: http://www.mythtv.org/docs/ I will also assume that you know how to forward ports on your router. …..

Full article here:
MythWeb ssh tunnel howto (MythTV wiki)

Is it possible to create a do-it-yourself substitute for Aereo?

 

Disclosure
Disclosure: There are a few links to Amazon in this article. Those are affiliate links, and we might make a few bucks if you click on them and buy anything.

 

Important
Note: This article should be considered somewhat dynamic, because we may update it from time to time as we discover additional information on this topic.

By now you’ve probably heard of a new service called Aereo, which is described by Wikipedia as follows:

Aereo is a technology company based in New York City that allows subscribers to view live as well as time-shiftedstreams of over-the-air television on Internet-connected devices.[1]

…..

Aereo provides this service by leasing to each user an individual remote antenna. [4][9][10] This distinguishes Aereo from purely internet-based streaming services.[11]

You can find a full review of Aereo here. Unfortunately, there are several problems with Aereo. The #1 issue is that they only serve certain specific areas of the country, and due to conflicting court rulings, it may be a very long time before they are able to enter certain markets, particularly on the west coast of the United States.

But also, you are for the most part limited to receiving only the channels you would be able to receive if you had a very good outdoor antenna system mounted on your home (in fact, you might get more channels than Aereo provides with such an antenna, depending on your location). Hate your local broadcasters? Too bad, because Aereo won’t let you subscribe to out-of-area signals. In fact, the Aereo Terms of Use includes this section (under “MEMBERSHIP, USE AND BILLING”):

1. You may only register for an Aereo Membership if you live within a market in which Aereo is available (the “Aereo Market”) and you must register for the Aereo Membership using your residential address. A Member may only use the Site and the Equipment to receive television signals that are available in your Home Market. A Member may not use or attempt to use the Site and/or Equipment to access signals that are not available in your Home Market or register for a Membership if you reside outside of the Aereo Market, including, without limitation, by providing a false home address, using a business address, by using another person’s login and password or by any other method that misrepresents or conceals your residential address. Aereo reserves the right to verify your residential home address using your Internet Protocol address, your billing information, geo-location and any other information that you, your ISP, or computer system provide to Aereo, as well as any publicly available information. To the extent offered by Aereo, temporary promotional access will only be available to users physically located within one of the markets in which Aereo is available, and we reserve the right to verify your location through geo-location and exclude you from using Aereo if the geo-location check fails.

So if you were thinking of trying to use a VPN, and/or some other method to conceal your actual location from Aereo, be aware that as far as Aereo is concerned you are persona non grata. We are not so naive as to think that no one will figure out a way to do it anyway. But since Aereo charges a monthly fee for their service, we wondered if there isn’t a better way to go.

How well do you get along with your family and friends?

We are going to discuss an alternative that, quite frankly, won’t work for everyone. Actually, there are two methods. One is for if you are in reception range of your local TV signals, and those are the signals you want to receive. The other is for everyone else, but it builds on the first one. However, the second method only works if you have a close family member or good friend living in a strong reception area, and both they and you have high speed broadband and generous (or no) bandwidth caps. It might also work if you own or rent space that you control in such an area. So, if you are a business owner and one of your business locations is in a strong reception area, you will be able to use the second method.

How do you know what’s a strong reception area? Go to the site TVfool.com and where it says “If you’d like to check your location, then…
>> Click HERE <<“, click on that link. Fill in the requested information for your location and it will give you a graphic that contains information about the TV signals available in your area. Let’s say, for example, that you live in Niagara Falls, New York. You might get a chart that looks something like this:

Sample TVFool chart for unspecified location in Niagara Falls, New York

Sample TVFool chart for unspecified location in Niagara Falls, New York

When you look at this chart, the channel list is color coded, with the strongest signals at the top. Now, TVFool tends to be a bit optimistic about reception conditions. Assuming that you will only tolerate a perfect signal, with no or only very rare breakups and glitches, you should probably interpret the chart this way:

Green: An indoor “set-top” antenna might be sufficient to pick up these channels, but you would be better off with an attic or outdoor antenna unless you can actually see the transmitter towers from your home.
Yellow: If you want a reliable signal on these, don’t even think of trying to get by with anything less than a good outdoor antenna, or at the very least, an attic antenna that is preferably located in a window facing the transmitters.
Red: Fuggeddaboutit! Despite what the site may say, it’s very unlikely that even a good outdoor antenna will get you those stations reliably. Of course, if your tolerance for breakups and interruptions, and total blackouts during bad weather is high, and you want to spend a LOT of money on a tall tower and excellent antenna, you might get a few of these.
Grey: The transmitter may as well be in Antarctica as far as you are concerned. On RARE occasions you might receive these channels, but don’t ever count on it.

If all of the channels you really want to receive are in the green, then you may want to try method #1, which you will need to read about in any case because it also forms the basis of method #2.

Method #1: Your own antenna at your home.

Why pay Aereo if you can pick up all the signals (and maybe more) at your own home location? We chose Niagara Falls as an example for a couple of reasons: Most people have some general idea where it is, and Aereo doesn’t yet offer service there, and even if they did it’s unlikely they would offer the Canadian channels as part of their package (we will see when they come to Detroit, supposedly later this year, which is also in a market with a Canadian channel or two.  EDIT March 2014: Aereo does not carry any Canadian stations in Detroit).

 

Important
EDIT March 2014: In the text below, there are several references to the “HDHomeRun Dual”, but this device is being superseded by two newer devices:  The HDHomeRun DUAL – Generation 4 (Amazon Link), which is said to have a better tuner and other improvements over the previous model, and the HDHomeRun PLUS (Amazon Link), which in addition to the other improvements also “Converts video to H.264 AVC for more efficient streaming and better playback support on portable devices.” This latter feature, available on the HDHomeRun PLUS model only, could be important if you are sending the video to another location over the Internet, as will be discussed in the next section.
The basis of an alternative to Aereo involves a hardware device, and a software package. The hardware device is the HDHomeRun Dual (Amazon link). It is basically a network-connected tuner that can tune up to two signals at a time from an antenna. You can use more than one on the same network, so if you wanted the ability to tune up to four channels simultaneously, you could buy two HDHomeRun Duals. Note that each HDHomeRun Dual can connect to a separate antenna, or to the same antenna through a splitter. So if, as often happens, you have a clusters of stations in two (or more) different directions, you could use one HDHomeRun and antenna to receive the channels in one direction, and another HDHomeRun and antenna to receive the channels in another. In the case of our hypothetical Niagara Falls viewer, they might point one antenna to the southeast to pick up the Buffalo stations, and another to the northwest to pick up the Toronto stations. For that matter, they could add a third HDHomeRun and antenna to pick up the stations from Hamilton, Ontario, or they could try aiming an antenna halfway between Toronto and Hamilton and connect that to a single HDHomeRun, and hope for the best.

With just a HDHomeRun Dual, you can watch television on any computer or network-connected device in your home, and that includes any TV that’s connected to a computer or compatible home theater PC. But since a TV can already receive signals from an antenna, that may not by itself be too useful. Oh, and by the way, if someone has told you that it is no longer possible to use an antenna to pick up signals now that television has gone digital, there is no polite way to say this: They flat-out LIED to you. And let’s just say that there have been more than a few LIARS among the ranks of cable TV and satellite customer service representatives.

The real magic happen when you pair a HDHomeRun with a software package called MythTV. But before we get into that, let’s first explain a bit about how MythTV works.

There are two components to MythTV, a backend and a one or more frontends. A backend and a frontend can be run on the same computer, but they don’t have to. You can almost think of the backend and frontend as two separate programs that are installed as part of the same package. The frontends depend on having access to a backend. In a way, it’s a little like the relationship between a web page server such as Apache, and a web browser such as Firefox or Chrome. One web page server can serve pages to many web browsers, but a web browser is useless if there are no web servers. In the same way, you can have many MythTV frontends on a local network, but they need to be able to connect to a MythTV backend somewhere on the network.

The backend is what actually receives the signal from any connected tuners, such as the previously-mentioned HDHomeRun Dual. If the signal is being recorded, it is the backend that stores the recorded program to a storage device. It is the backend that actually runs the schedules that record programs. The backend also can receive program guide information, which is then made available to the frontend clients.

The frontend is what runs on your PC (which could be a Home Theater PC), tablet computer, or other device. It lets you view live or recorded TV from the MythTV backend. It also allows you to access the schedule information on the back end, and schedule the recording of future programs.

There is actually a LOT more that both the backend and frontend can do — MythTV is a VERY capable program — but this is simply a high-altitude overview of how the two components relate to each other. It should be noted that certain other home theater programs, notably XBMC, can also act as a MythTV frontend (with somewhat limited capabilities) if it has the correct PVR add-on installed, but that’s beyond the immediate scope of this article.

What many MythTV users might not realize is that the MythTV backend offers a web interface (called MythWeb) that allows you to schedule programs, and do much more, from a web browser on your local network. One thing it offers is the ability to download files of recorded content. So, for example, if you have a recorded TV show that you’d like to watch while you’re riding the bus or train to work, you can simply download it to your phone or tablet before you leave.

This also implies that you don’t necessarily need to run a frontend to get some benefit from the MythTV backend. For example, if all you ever want to do is record shows off the air so you can view them later on your phone or tablet, you can do that by running the backend only, and interacting with it solely via the MythWeb interface.

We have found that the easiest way to get a MythTV installation going is to install Mythbuntu on a dedicated computer, which doesn’t necessarily need to be a high-powered machine. In fact, if you only plan to use it as a backend, the main thing you want to make sure of is that it has a fast network interface – at least 10/100, but if you plan to have more than one HDHomeRun on the network, a gigabit interface would be very desirable. Other than that, as long as the computer isn’t totally ancient, it will probably work. If you also want to use it as a frontend, then the requirements are probably a bit more stringent.

But then again, there are people who run MythTV on a Raspberry Pi (also see this documentdirect PDF link). So maybe the requirements are even lower than what we believe. If it will run reliably on a Raspberry Pi, that implies perhaps that all you would need is a HDHomeRun, a Raspberry Pi, and an external hard drive with plenty of storage (that does not attempt to draw too much power from the Pi’s USB port) and you’d be in business, assuming you’re able to follow the directions.

A few months ago, we mentioned where you could find A complete guide for setting up MythTV from start to finish plus a few other helpful links, and we also told you How to get free TV schedule information for MythTV. So, if you’re in a good reception area, all you have to do is set one or more HDHomeRuns and antennas, and a system running MythTV (particularly the backend) and you’ll be all set. You’ll be able to do pretty much everything you can do with Aereo, with no monthly charge whatsoever!

Method #2: But what if you’re not in a good reception area, or you can’t put up an antenna?

First you need to understand that a lot of people who think they can’t put up an antenna actually can, under FCC regulations. You’re permitted to install a satellite dish or antenna up to 1 meter in diameter on property that is under your direct control. So, for example, if you live in an apartment building with a balcony, and the balcony is under your direct control (that is, it’s for you only, not shared with your neighbors) then in most cases you can put an antenna there, provided it’s relatively small and unobtrusive and you don’t damage the landlord’s property. The FCC says so (disclaimer: We are not lawyers, so if this matters to you, find a lawyer and ask him for advice – don’t take our word on this). But, not all landlords recognize that federal law allows this, so you may need to pick your battles. And, you do not have the right to place an antenna in an area you do not control, such as the roof of your apartment building.  For more information, see YES YOU CAN: Put a dish or antenna on your apartment balcony.

If you own a home but it is in a development that has deed or covenant restrictions that forbid you from erecting an antenna, we first of all will say that you were very dumb to buy into such a development (but, you probably already realize that!). Keep in mind, though, that the neighborhood busybodies can’t give you grief about your antenna if they don’t know it’s there, so you could get creative and hide it so they can’t see it, or can’t recognize it as an antenna. For example, with a little ingenuity it might be possible to hide a flat antenna underneath vinyl siding, though obviously such mounting would make it difficult to point the antenna at the stations you want to receive. Some people have disguised antennas as a piece of deck furniture, or even as an artistic item.

Sometimes you can place a small indoor antenna such as one of the Mohu Leaf or Terk indoor HDTV antennas in a window or on a wall and get adequate reception (some people have found that less expensive models such as those offered by Homeworx will do the job, but read the reviews before purchasing any indoor antenna).

But if that doesn’t work, what can you do? Well, think about what we said earlier about having have a close family member or good friend, or better yet, another property that you own or control, in a strong reception area. If there’s also a broadband connection available at that location, then you could put a MythTV backend, HDHomeRun, and perhaps an antenna (if they don’t already have one you can tap into) there. If it’s a friend or relative’s home, you could offer to set that person up with a MythTV frontend so they can watch and record shows, thereby giving them some incentive to let you place this equipment in their home.

Then when you want to watch a show that’s not available in your area, all you need to do is log into the MythTV web interface at the remote location, and tell it to record that show. After the show is recorded, you could go back into the MythTV web interface and download the show, and then after it’s downloaded you can delete it off the server to make room for more recordings.

There is an issue with that, though. Quite simply, the recordings are HUGE! For example, we recorded a high definition half hour newscast and the resulting file size was 3.47 GB! And while MythTV has a built-in transcoding option, that is more for changing the container format than shrinking the file size. So, you may want to figure out some way to compress the video prior to downloading it (possibly using ffmpeg or HandBrakeCLI, or maybe you know of something even better). And prior to doing that, you’ll probably want to give the recordings filenames that mean something to humans. We suggest you look at a script that’s often distributed with MythTV called mythlink.pl, after which you can use the video compression utility of your choice to shrink the files to something a bit more manageable. Then you can upload or download the compressed files using SFTP, which works over a ssh connection.
 

Important
Note: For HandBrakeCLI users, we found that a line of this form will compress a 720p or 1080p source file significantly, producing a 720p output and only 2-channel stereo sound:

HandBrakeCLI -i ~/path/to/original_file.mpg -o ~/path/to/compressed_file.mp4 -e x264 -q 20.0 -r 29.97 –pfr –crop 0:0:0:0 -l 720 -w 1280

If anyone can figure out how to make HandBrakeCLI output full multi-channel sound, please let us know in a comment (only after you have tested it, though – we tried some settings that we thought should work, but didn’t).

Another option for compressing the video that might be even easier to implement is Mythbrake, a script that “shall be called as MythTV user job. It transcodes the DVB recordings (mpeg files) using Handbrake.” This script requires that you install the command line (CLI) versions of Handbrake and Mediainfo (so, the package names are handbrake-cli and mediainfo), both of which can be found in the online repository and installed using apt-get or Synaptic. If you want to use this script, be sure to read the entire Wiki page because you WILL need to make some changes to the script, especially if you do not live in Germany.
 
Important
EDIT: As mentioned earlier, simce this article was originally written SiliconDust has released the new HDHomeRun PLUS (Amazon Link), which has the ability to compress the video stream within the hardware itself. However, we do not know if MythTV can handle the compressed stream at this time.  If MythTV has the ability to work with the compressed stream, that might mean that the files sizes would already be reduced and there may not be a need to run additional compression software, and it also introduces the possibility that the compressed stream could be sent to another location in real time.
We don’t know how much Aereo compresses their files, but would suggest that unless you have a very generous bandwidth cap, you don’t plan on watching an entire day’s schedule of soap operas and game shows using this method! If you do, you will probably blow through your bandwidth cap pretty quickly, and we suspect that’s also true for actual Aereo users. You can only compress video just so much before it starts to look like crap. But for that occasional prime time program you just can’t miss, this at least gives you a way to receive it.

Now you are probably wondering, wouldn’t I need to open one or more ports in my friend or relative’s router to be able to access the MythTV backend, and wouldn’t that be a security risk for them? The answer is yes, you do need to open one port only for ssh, and no, it won’t be a security risk if you know what you are doing and pay attention to what we are about to tell you.

When you set up the MythTV backend, we suggest that you don’t simply open port 22 (the standard ssh port) in the router and forward it to the backend machine, unless you are also knowledgable enough to set up a firewall that limits outside access to you and you alone. What we instead suggest is that you forward a different port, such as a higher, more obscure port to port 22 on your backend (alternately you could change the ssh port on the backend if you know how to do that, and then open that port in the router). The idea is that, as far as anyone outside the local network is concerned, you don’t want the common ssh port 22 to be open. That will at least slow down some of the bad guys.

But in addition to doing that, and especially if you don’t do that, be sure you set up ssh public/private key authentication and then disable the use of passwords for ssh logins. That way, a would-be intruder simply cannot ever succeed in cracking your password, because you don’t use one! To do that, on a Ubuntu or Mythbuntu machine (and in many other variants of Linux) open the file /etc/ssh/sshd_config with a text editor (you will need to be root or use sudo) and make sure all the values are set as shown below (add any that aren’t there, and if they are already there, make sure they aren’t commented out):

PubkeyAuthentication yes
ChallengeResponseAuthentication no
PasswordAuthentication no
UsePAM no

Then either reboot the system or run /etc/init.d/sshd reload from a command prompt. Don’t do this until you have public/private key authentication working, and make sure all those settings are correct (especially PubkeyAuthentication yes), otherwise you will lock yourself out of the system!

Do NOT open port 80 so you can get to the MythWeb page. You should only open the (obscured) ssh port as described above.

Here is how you get to the MythTV backend from a remote location. First, to get to the MythWeb page, open a ssh session using the following syntax:

ssh -C -L <local port>:localhost:<remote port> user@remotedomain:<remote ssh port>

Now that may seem a bit confusing, so let’s break it down. Let’s say that your remote MythTV box is hanging off of a router at internet address 1.2.3.4, and in the router you are forwarding incoming TCP port 12345 to port 22. On the MythTV backend your user name is superadmin, and the MythWeb page is on the standard http port 80 (the default), and you want to be able to access remotely it in your browser by going to http://localhost:8080/mythweb/  —  in that case, you’d use this:

ssh -C -L 8080:localhost:80 superadmin@1.2.3.4:12345

Then, once you have executed that (effectively opening an ssh tunnel from your machine to the other), you can access the MythWeb page by going to http://localhost:8080/mythweb/

Please don’t use 12345 as your actual port number for incoming ssh traffic — make it something a bit more obscure! For more information, see the MythWeb ssh tunnel howto. When you use this method of access, all your traffic between the backend and your web browser travels through a secure and encrypted tunnel, and because you didn’t open any http ports in the router for MythWeb, nobody else outside the local network can get to it. By the way, if your MythTV backend is not at a fixed IP address, you may need to set up an account with a dynamic DNS service such as FreeDNS, so you can find your backend on the Internet. In that case you’d use the dynamic IP address in place of 1.2.3.4 in the above example.

But, what if you need to do some configuration on the MythTV backend? Well, there is a way to do that too, without installing any other software or opening any more ports. First, open the file /etc/ssh/sshd_config on the MythTV backend and make sure the following value is set:

X11Forwarding yes

Assuming that it is, on your local machine open an X terminal program. For example, on a Mac you will want to go to the Utilities folder (in the Applications menu), open Utilities and then run either X11 or (if you have it installed) XQuartz. Under Linux you can probably use a normal terminal window, since Linux supports X windows. Under Windows, the method will depend upon the terminal program you’re using (if you’re using PuTTY, the article Setting up X11 tunneling in PuTTY may be helpful). When that terminal window opens, enter a command in the following format:

ssh -C -X -l username address -p port

For example, again assuming the same specifications we used earlier:

ssh -C -X -l superadmin 1.2.3.4 -p 12345

Note that the syntax varies somewhat from that used to invoke some other types of ssh sessions — we have no idea why.

Once a ssh connection is made to the distant machine, you can then enter:

mythtv-setup

To run the MythTV backend setup program. Note that windows will appear as if they were running on your local machine. For example, on a Mac, the opening window will look like this:

Prompt from MythTV backend on remote server appearing in X window

Prompt from MythTV backend on remote server appearing in X window

The tipoff that this is actually running on a remote server is an X icon in the title bar. Other windows will appear and disappear as you navigate around the program. When you are ready to exit the setup program, navigate to the main menu and press the Esc key. This should close the program, although it may first pop up a window asking if you want to run mythfilldatabase. In most cases you should answer “No” unless you have a specific reason for doing so (be sure to click “No” if you are using the method described in How to get free TV schedule information for MythTV to get your schedule information), and then you can type exit at the X terminal prompt to close the ssh session. When you do it this way, you’re not using the overhead of a remote desktop program (which you don’t have to install), and you don’t need to open any additional ports, plus your entire session is encrypted and compressed.

(Pro tip for Mac users: If you are in an X window and you need to paste text from your local clipboard, click the middle mouse button or wheel.)

By the way, if ever you ever try to run other software using this method, be aware that some programs should be run using sudo and some should not. mythtv-setup should NOT be run using sudo, but something like update-manager should:

sudo update-manager

Although since you are at a command prompt from the remote system anyway, you could just do

sudo apt-get update && sudo apt-get upgrade

to update your software packages.

Obviously there is a lot more that could be said about the procedure for setting up MythTV, but our purpose here is to give you a general idea of how setting up your own substitute for Aereo might be accomplished. And, of course, there are probably other ways to achieve the same result. Some people prefer a program called TVHeadEnd to MythTV, but we don’t because we found it very difficult to configure. Some people prefer to use another type of TV tuner instead of a HDHomeRun, but we like the HDHomeRun Dual because it is small enough that you can put relative close to the antenna (thereby minimizing signal loss) rather than needing to run coaxial cable to the machine running the MythTV backend.

And we know that some of you may be thinking, my friend or relative has cable, couldn’t I… hey, we are not even going there. That opens up another whole can of worms, the main one being that most cable signals are digital nowadays and the HDHomeRun DUAL cannot receive them. There is another model of HDHomeRun, the HDHomeRun Prime (Amazon Link), that uses a CableCard and can receive digital signals, but we have read several articles that indicate that if the cable companies have anything to say about it, the CableCard technology is going away soon. And beyond all that, we suspect that most cable companies would take a very dim view of one of their subscribers slurping up cable signals and then sending them over the Internet to a friend or relative. As we noted earlier, we are not lawyers, so we won’t opine about the legality of it, but we suspect that cable company lawyers might have some strong feelings about it.

EDIT (March, 2014): Is there any other way to get free TV if I live in a poor reception area?

That depends on where you live and whether you have a clear view of the southern sky. If you live in a rural area, or an area where the local code enforcement officials and neighborhood busybodies are not too persnickety, you may be able to install a large C-band satellite dish (sometimes also known as a BUD, which is an acronym for “Big Ugly Dish”, although the newer mesh models aren’t as ugly as the older dishes). We are not talking about one of the smaller dishes here; while a small dish can be used to receive certain signals (notably PBS), most of the network TV signals and feeds to be found will be on C-band.

Receiving C-band (large dish) and Ku-band (smaller dish) is something of a hobby, but the reward is that you can receive several network and non-network stations for free, although the signals do tend to come and go. Stations or signals that are here today may not be available tomorrow, but new ones may appear. If you want to learn more about this, there is a discussion forum at Ricks Satellite. You can also search for information on “Free To Air” satellite receivers and equipment, but be aware that the phrase “Free To Air” has a different meaning in North America than in some other parts of the world (particularly Europe).

Be careful, however, particularly if you live in the U.S. or Canada, because there are some sellers (particularly on eBay) that sell illegal equipment, that can be used to “pirate” scrambled pay TV signals. The problem with this equipment, besides the fact that you are engaging in piracy, is that any television receiving equipment also radiates RF energy for a short distance and therefore it IS possible to tell if you are using this equipment from within a vehicle driving by on the street. But the bigger issue is that very often the sellers of such equipment are caught, and their customer list is confiscated by the FBI or some other federal agency, and then the feds go after the purchasers of such equipment, and you can get a huge fine and even potentially a prison sentence for knowingly using such equipment. The general rule is that if a signal is unscrambled on a satellite it is okay for you to watch it, even if it is a pay TV service, or even if they transmit some ominous sounding warning that it is a feed intended only for a network’s affiliates. But, the moment they scramble the signal it is off limits for those that aren’t paying to receive the signal and using approved equipment (Disclaimer: We are not lawyers, so if this matters to you, you may want to consult with an attorney to get correct, up-to-date information).

The forum mentioned above prohibits the discussion of signal piracy, so you are pretty safe in using any equipment recommended on that site. We will also add that some sites may leave you with the impression that there is nothing available on C-band anymore. While it is true that the days when hundreds of unscrambled signals were available are long gone, if you are in a poor reception area the ability to get a good signal from even one or two stations might make a big difference, and there are a lot more than one or two unscrambled signals available as this is being written. BUT, if you own a home that is in a development that has deed or covenant restrictions that forbid you from erecting a satellite dish, you will not be able to put up a C-band dish, and that’s also true in many cities, and even in some of the more hoity–toity townships.

If you speak any languages other than English, then you have an added incentive to look into Free to Air satellite TV, because many of the stations available (particularly on Ku-band, which can be received using a smaller dish) are in languages other than English. The same is true if you are a news junkie, because often breaking news feeds will be available on satellite. For example, during Hurricane Katrina and the rescue efforts that followed, local TV station coverage from New Orleans was available for viewing on satellite.

A few final thoughts…

You may be thinking, as we often do, that there is no reason people should have to go through all this nonsense to watch TV. It is inevitable that the model for the delivery of video content must change, just as the model for the delivery of music has changed. The only thing that holds it back are the broadcast industry and the networks, who can’t let go of the distribution methods that they have used since the birth of commercial television. The idea that if you live in a certain geographic area, you can only get major network content from a particular group of local broadcasters is an idea that is well past its shelf life. Besides, a lot of people hate their local broadcasters and to a lesser degree the networks, for a number of reasons — for example, the need to plaster their own gaudy graphics over the top of the program you want to watch, and the fact that if they say a program will start at a certain time, it doesn’t always do that. Some people do still like to watch local news, but many stations are now consolidating their news departments so that you are now more likely that ever to get the same news on most or all local channels, just read by different talking heads. And most younger people get their news online (the closest they will come to watching televised news is The Daily Show).

So at some point, Aereo needs to realize that their real value will be in offering people access to channels that they cannot currently get in their local area. We understand why they are not doing that now — they need to fight one legal battle at a time — but only offering customers stations that they can already get off the air with a good antenna is not going to be a sustainable business model forever, particularly as the program producers start to realize that they can bypass the networks and local stations altogether. The change will take time, but the question is when it will take place, not if it will take place. There is a whole generation coming up that hardly watches network television; does anyone really think that when they are old enough to be elected to office or appointed to leadership positions that they will be the slightest bit interested in keeping the major networks/local affiliates model on life support? Or that they will think that geographic restrictions on which stations you can watch are anything other than totally ridiculous?

Why is it that we can tune in an AM or FM radio station from another part of the country, or even another part of the world, and listen all we want, but we can’t even watch an online stream from our local network affiliates — except, perhaps, when they are airing locally originated programming? What makes video so special? In a sane world, a service like Aereo, as it currently exists, shouldn’t even be necessary. The networks, or at very least, the local stations should be streaming their content themselves! The fact that Aereo exists, and is apparently thriving in the places where it offers service, is a testament to how far the established broadcast industry has their heads up their collective posteriors.

Using irrecord to allow LIRC to recognize extra buttons, as from an unused remote and/or a Harmony remote

A few days ago we published an article on Using the Raspberry Pi to control AC electric power. We ended that article by showing how you could control the Raspberry Pi’s GPIO pins using a standard remote associated with a Home Theater PC on the same local network. Actually, come to think of it, there’s nothing to prevent someone from sending such commands across the Internet to a distant system, if one has an application that requires it. But I digress…

One problem that some users might encounter is that there are simply no free buttons on the remote control that can be used for other functions. Or maybe there are extra buttons, but they don’t seem to do anything. Or maybe you have a Logitech Harmony Remote or some other type of universal remote, and you downloaded a configuration for it to match your existing remote and infrared receiver but it added some additional buttons that appear to do nothing. Or, failing all that, maybe you have a spare infrared remote from a no longer utilized or broken device, that you’d like to use to control some additional functions (such as the GPIO pins on the Raspberry Pi, as in the aforementioned article). The question is, can you get your Home Theater PC (the one to which you have the infrared receiver attached) to recognize those additional button presses?

In our experience, the answer is that there’s a high probability, but it seems to depend on whether your infrared receiver can properly receive and decode the additional button presses. Which it just might be able to, even if it’s not doing that now. So, how can you tell what it’s now recognizing, and whether it can be made to recognize additional button presses?

First of all your system must be using the LIRC software for this to work. Most Linux-based home theater software does, so if you have a Home Theater PC and it’s not running some variant of Windows, it probably already has LIRC installed. Note that LIRC is actually a small collection of programs, none of which are actually named lirc, so just doing “which lirc” from a command prompt probably won’t tell you if it’s installed. Instead, you can check for one of the included programs — for example, try “which lircd” (lircd is the lirc background process) and see if it shows a path to that program.

Before you go any further, from a terminal prompt enter this:

irrecord --list-namespace

You may want to copy the output of that command to a text file that you can keep open in another window while you proceed, or just open another terminal window so you can refer back to this one. You could even print out that list if you think it would help. You are probably only going to be concerned with the entries that start with the characters KEY_ (and NOT those that start with BTN_, which may seem counter-intuitive, but that’s just how it is, at least with “MCE” compatible remotes — MCE = Windows “Media Center Edition”, in case you were wondering).

Next you will want to find out which buttons are already recognized. You should do this from a terminal prompt, with none of the software that normally responds to remote control commands running (so kill any instances of XBMC or similar software before doing this). Enter the command “irw” (without the quotes) and then start pressing buttons on the remote. For each button that LIRC recognizes, you will see one or more lines of text appear. Note any buttons that irw doesn’t print out anything for. If you are wanting to add a second remote to get additional usable buttons, see if irw responds to any of those buttons (it’s very unlikely that it will). The buttons that irw does not recognize are the ones we will try to add in the following steps.

Also, as you are pressing buttons and watching the output of irw, note the key names that are already used (they will likely be in the next to last column. Here is why. When you add previously unrecognized keys, you have to give them a name that LIRC understands, which can be any name from the output of “irrecord –list-namespace” that is not already used. If you duplicate an existing button name, one of the buttons won’t work. So, take note of the names already used, and also of the buttons that currently don’t do anything. When you have pressed all the buttons on your remote(s), use Control-C to exit irw.

Now before going any further, take a look at the file /etc/lircd/lircd.conf (at this point we are only going to read it, not write to it, so don’t use sudo):

nano /etc/lirc/lircd.conf

Note that file may contain a bunch of comments, and then a line such as this:

include “/usr/share/lirc/remotes/mceusb/lircd.conf.mceusb”

Whatever file is referenced in that “include” is the file we will be working with, which for simplicity’s sake I will henceforth refer to as the lirc remote configuration file. So close lircd.conf and go to that file:

nano /usr/share/lirc/remotes/mceusb/lircd.conf.mceusb (or whatever file was included in lircd.conf)

You should see some preliminary configuration at the top, and then if you scroll down a bit you should see a line that says “begin codes” — below that, the lines that are not commented out will show key codes that LIRC currently recognizes (even if they do not appear on your remote) followed by hexadecimal values. Now this is where it gets a little confusing. When you are naming buttons in the next steps, you do not want to use any button names that already appear in this file. So the general rule for naming buttons in the following steps are:

1. DO use names that appear in the output of “irrecord –list-namespace”. BUT…
2. DO NOT use names that already appear in the lirc remote configuration file.
3. DO NOT use names that appear when you are using irw to find existing buttons (this should be a subset of #2).

Now you are ready to try to add additional buttons to the list that LIRC knows about. The lircd process must NOT be running at this time, so do this:

sudo killall lircd

Now, to see if the additional buttons (or alternate remote) can be used, do this (note this assumes your IR receiver is at /dev/lirc0, which it probably is, but if not you may need to change that reference):

sudo irrecord -d /dev/lirc0 ~/lirctest

The irrecord program will first have you do several things to get some basic information about the remote – this will involve a bit of time and several button presses, so be patient and just follow the on-screen instructions. Then, after it has figured out what it needs to know about your remote, it will ask you to enter a key name — be sure to keep in mind the rules mentioned above! — and after that it will have you press the button on the remote. You can repeat this cycle as often as necessary to get all the buttons you want to add, and at this step you should only add buttons that it doesn’t already know about (ones that did not elicit a response from the irw program). Only do one remote at a time — don’t try to add buttons from different remotes on the same run of irrecord. If, for any reason, you have to quit irrecord before you are finished, delete the file ~/lirctest before you start over.

There may be cases where irrecord simply will not recognize a remote. or does so only with great difficulty. If that is the case, it probably means that either the batteries are dead in that remote, in which case you should restart the irrecord program after changing the batteries, or that the remote is not compatible with your infrared receiver. Different IR devices can operate on different infrared wavelengths, and your IR receiver is probably “tuned” to receive IR commands in a relatively narrow portion of the infrared spectrum. So, don’t be too surprised if some alternate remotes work fine, while others don’t work at all.

After you have run irrecord, the configuration should be in the file ~/lirctest (lirctest in your user directory). What you need to do now is copy the non-comment lines from that file (in other words, the section from begin remote to end remote, including those lines) to the end of the lirc remote configuration file. Before saving the additions, change the name line (right below begin remote) to have a value that is short and meaningful, using all lowercase letters and no spaces (such as name old_vcr if you are adding buttons from an old VCR remote). You may want to save a copy of the original lirc remote configuration file before making any changes, just in case you mess something up. For that matter, I’d also save a copy after you make the additions, since we’re not entirely sure whether the lirc remote configuration file might revert back to the original configuration if an upgrade to lirc comes along. So you may want to keep both a “before” and “after” copy in another directory.

If you want to add buttons from yet another remote, just repeat the process using irrecord. Remember to give the buttons unique names from the list you got when you ran irrecord –list-namespace. Note that the button name you use in irrecord does not need to bear any actual relation to the button name on the remote itself, it just has to be a name that’s not already in use.

Once you have made the additions to the lirc remote configuration file and rebooted the system (to restart lircd and read the new configuration file), run irw again and verify that the new buttons are being recognized. Now you can use those added buttons in your .lircrc file, or in the remote configuration file for a particular piece of software (for example, ~/.mythtv/lircrc for the MythTV frontend, if you are running that).

Readers with Harmony remotes may have noticed that when they looked into the lirc remote configuration file, there was already a lot of buttons defined that do not appear on their remotes, and might have wondered if it is possible to get the Harmony remote to learn those codes. While we have found that getting a Harmony to learn button presses from another remote is relatively easy using the Harmony configuration software — which means it would be easy to add buttons from that old VCR remote, assuming that irrecord was able to recognize it — it’s either difficult or impossible to add raw codes to a Harmony without having another remote that generates them. We tried to figure out if it could be done, but pretty much hit a dead end. If you should figure it out, please feel free to leave a comment explaining the procedure.

Link: MythTV: Use All Buttons of Your Remote Control – Without LIRC

It can be really frustrating to get a remote control to work properly under Linux with LIRC and programs like MythTV, mplayer or XMBC. This article shows how to avoid using LIRC altogether: Treat the remote like any other keyboard, then change the keyboard mapping to use the application’s key shortcuts. Because we do this before the keypresses reach X11, it avoids the dreaded problem of keys with codes >255 not working.

Full article here:
Link: MythTV: Use All Buttons of Your Remote Control – Without LIRC (Richard Atterer)

How to get free TV schedule information for MythTV

 

Important
It appears that in July, 2015 and again in January, 2018 some changes were made to the program (and its associated service) mentioned below.  Zap2it changed the format and operation of their listings service, forcing some changes in the way zap2xml operates.  If you have previously set up zap2xml, you may need to re-download the software and set it up from scratch.  See this article for some additional information, and also the page for the software (as linked below) may provide more up-to-date information.  Also, I’ve removed a reference to a program that used to be free, but for all practical purposes no longer is.

It seems that if you live in the U.S.A., the MythTV people would really like to entice you to pay for a subscription-based TV listings service, but not everyone will do that. So, if you don’t want to pay, how do you populate your TV schedule grid with program information?

The easiest and most unquestionably legal way to do it is to simply grab the listing from the TV transmitters themselves. Almost all digital TV channels transmit schedule information, and to use it you simply need to make sure that on the MythTV backend, under Video Sources, the Listings grabber is set to Transmitted Guide Only (EIT).

The downside of this is that you will only get schedule information for a limited time, typically 1-3 days out from your current date. So, you won’t be able to schedule a program a week in advance. And another thing that might bother some users is that it will cause MythTV to operate your tuners continuously, because MythTV apparently constantly scans the channels for new EIT data (see this discussion in the HDHomeRun forum).

The other way is to use an external program such as zap2xml (Zap2it TV listings to XMLTV or XTVD .xml). In this case you set the MythTV backend Listings grabber setting to “No grabber” and use the zap2xml software to grab the listings and populate the database. The people who profit by selling the TV listings service don’t much like it if you do that, and therefore their proponents try to spread FUD (Fear-Uncertainty-Doubt) about the legality of doing this, but as a practical matter we highly doubt anyone will ever get in trouble for obtaining TV listings this way, and no one has up to this point, to the best of our knowledge. However, if you choose to use this method just be aware that there might be a cloud over the legality of doing so, at least if you believe the supporters of the commercial service. The larger concern is that someday this service will stop working, but that could happen with the pay service also.

Note that people who live outside the U.S.A. have no choice other than to use either the transmitted guide data or a free service, since the pay service only includes U.S. listings.

Generally it is a two step process:  You first run zap2xml to generate the required xmltv.xml file, then run mythfilldatabase (with appropriate options) to import the xmltv.xml file into the MythTV backend.

When you run mythfilldatabase, if you see error messages that include the phrase “Unknown xmltv channel identifier”, this means you need to open the xmltv.xml file in a text viewer or editor and find the channel id for each channel. Then go into the MythTV backend channel editor. For each channel there is an XMLTV ID field. You will need to place the correct channel id from the XML file (the entire string between the quotation marks) into the corresponding XML ID field, then select Next and (on the next screen) Finish, and you will need to do this for each channel. If you do this correctly, the “Unknown xmltv channel identifier” errors should disappear the next time your run mythfilldatabase.

EDIT: After this article was published, we discovered an additional similar program called WebGrab+Plus. It is described as follows: “WebGrab+Plus is a multi-site incremental xmltv epg grabber. It collects tv-program guide data from selected tvguide sites for your favourite channels.” There are some installation hints for WebGrab+Plus here. We have not attempted to install or use WebGrab+Plus, but just wanted to note that this possible alternative exists.

If you know of any other ways to get free TV schedule information for MythTV, please feel free to share in the comments. But if you simply want to debate the legality of the alternatives, please don’t bother – as the title of the blog implies, these are simply technical notes, and not a forum for endless debates over whether something should or should not be done, and we will probably just delete any comments that don’t add to the technical knowledge presented here.

Related Article:
Some hints for getting free-to-air satellite channels into the Electronic Program Guide in Kodi (or another frontend) (Free-To-Air America)

 

Links: A complete guide for setting up MythTV from start to finish

Probably the easiest way to get a MythTV installation up and running quickly is to install Mythbuntu or Mythdora, depending on whether you prefer the Ubuntu or Fedora variant of Linux.  But if you want a bit more hands-on experience, or additional help with configuration, these links might be helpful:

From a Reddit thread:

I’ve been a fan of MythTV for some time, but found that there were very few comprehensive setup guides out there for new users. So, I decided to write one. It’s split into 4 parts (shown below) and covers not just how to set up a MythTV system, but also makes an effort to explain why certain instructions are given along the way.

I hope some of you find it useful, and constructive feedback is of course appreciated. 🙂

Reddit thread with comments
Reddit thread with comments #2

Here is an older MythTV setup guide that we’ve found useful in the past:
Andrew’s MythTV Walkthrough: A Simpler MythTV How-to for Beginners

Don’t forget about the MythTV Wiki. But be aware that if you live in the United States, much of the “official” MythTV documentation will try to push you into paying for a subscription TV schedule service. If you live elsewhere, they are forced to admit there are other alternatives, which there are for U.S. residents as well — yet for some reason they try really hard to push the subscription service to U.S. users.

If you want to get TV listings into MythTV without paying for a subscription service, see How to get free TV schedule information for MythTV.

Installing Ubuntu Linux (or Mythbuntu) in place of OS X on a Mac Mini

 

Important
This is an edited version of a post that originally appeared on a blog called The Michigan Telephone Blog, which was written by a friend before he decided to stop blogging. It is reposted with his permission. Comments dated before the year 2013 were originally posted to his blog.

All computers have their day in the sun, and then something new comes along that makes them less desirable. I have a Mac Mini that I acquired sometime around the time OS X Leopard came out, probably in 2009. As time went by it became slower and slower and I finally replaced it. However, it seemed a bit of a shame to have it just sitting in a closet doing nothing, so I decided to see if I could put Ubuntu Linux 12.04 (the most recent LTS version) on it. I started out by trying to follow the instructions on this page (the Single Boot/MBR option) but ultimately it turned out to be not nearly that complicated. NOTE THAT THIS WILL NOT GIVE YOU A DUAL BOOT SYSTEM; THIS IS REPLACING OS X WITH UBUNTU LINUX, AND ALL YOUR EXISTING DATA ON THE HARD DRIVE WILL BE ERASED!!! YOU HAVE BEEN WARNED!!!

Also: THIS IS FOR EXPERIMENTAL AND INFORMATIONAL PURPOSES ONLY. This is what worked for ME. This MAY or MAY NOT work for you. It may even brick your system (if that should happen, try doing a PRAM reset before you totally panic). It did not do that to me, but your hardware may be a bit different than mine, so I make NO guarantees!!! Here’s all I wound up having to do:

  • Connected a USB keyboard and mouse.
  • Before proceeding I made sure I had the latest firmware upgrade – that is very important since you can’t do it once you have installed Ubuntu, and the rest of this might not work if you have old firmware. Another thing you can’t do is disable the startup chime so if you don’t want that after Linux is installed, find a way to turn it off before proceeding (I wanted and it’s used in the instructions that follow, so I didn’t search for a way to disable it, and I don’t recommend you do either).
  • Inserted my old OS X Leopard installation CD
  • Rebooted while holding down the “C” key
  • Accepted the default language (English) and pressed Enter
  • From the top menu bar, I selected Utilities | Disk Utility
  • In Disk Utility I selected the internal hard drive in the left hand side panel. You have to select the drive itself (it shows the brand name of your drive), not the partition
  • Clicked the Partition tab, selected 1 Partition under the Volume Scheme (instead of Current)
  • Clicked the Options button and selected “Master Boot Record”
  • Clicked the Continue button (this erases the hard drive)
  • When the above finished, I quit Disk Utility, then quit the installer
  • The Mac rebooted — at that point I clicked and held the leftmost mouse button until the CD ejected
  • Inserted the Ubuntu Install CD, then power cycled the Mac Mini
  • At the startup chime I pressed the “C” key to boot from the CD
  • When the Ubuntu CD boots, you are given the option to install Ubuntu directly, or to try Ubuntu (which takes you to the Ubuntu desktop). As it turns out, I could have simply ran the installer. Instead, I did it from the desktop because I was following some instructions that said you have to type in some things during the install, and you need to have access to a terminal window to do that. But when I tried to type those things in, Ubuntu rejected them with errors, so I just let it complete the install (answering the questions it asked during the install). I did NOT select any special partitioning, etc. – I pretty much did a plain vanilla installation, generally accepting the defaults except where they weren’t appropriate or weren’t what I wanted.

 

Important
NOTE: If, when you boot into the Ubuntu installation CD, you are greeted with a screen that asks you to “Select CD Rom boot type” but you cannot select anything because neither the keyboard nor the mouse are functional, then you probably need a special build of Ubuntu built for installation on a Mac. So, go to the Ubuntu CD image menu at http://cdimage.ubuntu.com/releases/ and select the version of Ubuntu you wish to install, then on the next page select “release”, then find a version that is intended to be installed on a Mac. For example:

64-bit Mac (AMD64) desktop image

Choose this to take full advantage of computers based on the AMD64 or EM64T architecture (e.g., Athlon64, Opteron, EM64T Xeon, Core 2). If you have a non-64-bit processor made by AMD, or if you need full support for 32-bit code, use the i386 images instead. This image is adjusted to work properly on Mac systems.

(Emphasis added). If you select one that states that “This image is adjusted to work properly on Mac systems” and burn the ISO to a CD, it should bypass the non-responsive menu and take you right into the Ubuntu setup. Note that there are different versions of Ubuntu Desktop and Ubuntu Server, so pick the correct one to match your hardware.

Note that if you are trying to install Ubuntu 16.04 or later, you may not be able to find a version as described above. In that case you can try the solution offered here, if you can understand the instructions.

When the install was finished (after quite some time), I rebooted. The only unusual thing was that after the reboot, the screen remains white for about 15-20 seconds right at the start of the reboot. Then after that delay, it finally decides it will load Ubuntu. That still happens and while it makes the startup take a bit longer, I’ve seen worse.

Oh, and the sound was muted by default for some reason, and the volume slider set all the way down. After I unmuted it and turned up the volume slider, the sound worked normally.

The wired network connection worked fine. I don’t use WiFi here so I did not test that.

The only real hitch I found was that it won’t boot if you don’t have a video display connected! I have no idea why that is the case but there is a hardware workaround described on this page. Hope you didn’t misplace your Mac Mini’s DVI to VGA adapter! I had a 100 Ω resistor handy and that seems to work fine (it’s probably about 40 or 50 years old but what the heck, carbon resistors don’t change value that much just sitting in a junk box). If you can’t find the DVI to VGA adapter, I have read that at least one user placed a resistor directly into the DVI port between pins C2 and C5; you can use this pinout diagram to find those pins. However, I have not tried this, so I make no guarantees. Either way, the point is that the resistor goes between the analog green signal output and the analog ground return. If you can’t find the adapter, can’t get this to work, or if you just don’t want to mess around with a resistor, you can try a DVI Emulator/Dummy Plug that includes an EDID chip, that may be available from Amazon or eBay. A DVI 1920×1080 or 1920×1200 model should be sufficient; you can find one maker of them here. Such a devices fools the Mac Mini into thinking a display is connected.

After I had this running for a year or two I read that Ubuntu doesn’t control the system fan properly. You can do this in some newer versions of Ubuntu to get fan control to work. First, try using the Ubuntu Software Center to search for and install the macfanctld package (after you check for updates). If that doesn’t work, try this:

sudo apt-get install -y macfanctld

If you are trying to use an older version of Ubuntu, you may need to do this instead (this is NOT necessary in recent Ubuntu versions; the above should be sufficient):

sudo add-apt-repository ppa:mactel-support/ppa
sudo apt-get update
sudo apt-get install -y macfanctld applesmc-dkms

On my system at least, it appeared that this did cause the fan to run a bit faster but not enough that I really noticed it. Once it is installed, you can type man macfanctld at a Linux command prompt to get configuration instructions. Changes to temperature limits and minimum fan speed are made in the file /etc/macfanctl.conf.

Also, although I have not personally done this, I have read on a couple of pages that you can enable automatic reboot after a power interruption by adding one line to /etc/rc.local:

setpci -s 0:1f.0 0xa4.b=0

By the way, I had intended to try Linux Mint but they no longer offer a version that fits on a CD, and I still have about a gazillion blank CDs (plus I already had Ubuntu 12.04 burned to CD) and since the Mac Mini doesn’t have a BIOS in the traditional sense, there is no way to install from a USB stick, so Ubuntu it was. For what I plan to do with this, having Mint would be no advantage, though being able to disable (or decrease the CPU usage of) Unity might be. I hate f—ing Unity and may yet try to find a way to replace it, but that’s not high on my list right now.

Note that nowhere above did I mention a program called rEFIt, nor did I mention BootCamp. I didn’t need either of those.

Had this not worked I could have always reinstalled Leopard, but again, for what I’ll probably be doing with this system (running a MythTV backend, for one thing) Linux was probably a better choice, but I still wanted to be able to use this as a backup regular desktop computer, should the need ever arise. After trying this for a while, I went ahead and installed Mythbuntu over the top of Ubuntu (in effect wiping the first install and starting over), and it’s worked great (and NO Unity!).

Note that if you wind up going with Mythbuntu as I did, you may find that you cannot connect from other machines on the same local network unless you create a rule in the firewall to allow it. I don’t recall explicitly having to do that, but it might be something that I did and then it slipped my mind, and I have read that others have had to it. If you find that you need to do it, simply open a terminal window and enter a command similar to this:

sudo ufw allow from 192.168.0.0/24

replacing 192.168.0.0/24 with a value appropriate for the IP address range used on your local network, if your addresses do not fall into the 192.168.0.x pattern. Note that I am not clear on whether this needs to be done on the Mythbuntu backend itself, or on other machines that are attempting to connect to the backend, or both. Obviously, this is only appropriate for systems that run ufw as the firewall (probably most *buntu distributions).

If you find that your samba log files fill up with complaints such as “Unable to connect to CUPS server localhost:631 – Connection refused”, here is a workaround. In the [global] section of /etc/samba/smb.conf add these lines:

printing = bsd
printcap name = /dev/null

Then from a command prompt restart samba:

sudo service smbd restart

One final note: This is the xorg.conf I used with my “headless” Mythbuntu system. It came from this blog post and I did have to save it as /etc/X11/xorg.conf and not the filename shown in the post:

Section "Monitor"
  Identifier "Monitor0"
  Modeline "1920x1080_60.00"  172.80  1920 2040 2248 2576  1080 1081 1084 1118  -HSync +Vsync
  Modeline "1024x768_60.00"  64.11  1024 1080 1184 1344  768 769 772 795  -HSync +Vsync
EndSection
Section "Screen"
  Identifier "Screen0"
  Device "VGA1"
  Monitor "Monitor0"
  DefaultDepth 24
  SubSection "Display"
    Depth 24
    Modes "1920x1080_60.00" "1024x768_60.00"
  EndSubSection
EndSection

A Perl script to send Caller ID popups from Asterisk to computers running Notify OSD (such as Ubuntu Linux) or any command-line invoked notification system

 

Important
This is an edited version of a post that originally appeared on a blog called The Michigan Telephone Blog, which was written by a friend before he decided to stop blogging. It is reposted with his permission. Comments dated before the year 2013 were originally posted to his blog.

This is basically an update to my article, A Perl script to send Caller ID popups from Asterisk to computers running Growl under OS X on a Mac or Growl for Windows, and you should still use that article if you are sending notifications to a computer on your local network that runs Growl or Growl for Windows as the notification system.

I wanted to find a way to send Caller ID popups to a Ubuntu Linux box, and in the process I discovered a different method of sending such notifications.  There are pros and cons to using the new method, so let me explain those first:

Pros:

  • Can send notifications to any computer that supports command line generated notifications (so it could also be used with Growl, if you can use growlnotify from a command prompt to generate a notification).
  • Can send notifications to any computer that you can SSH into, provided you have it set up to use public/private key authentication rather than password authentication.

Cons:

  • Notifications typically display a couple of seconds later than under the previous method.  I suspect this is due to the SSH authentication taking a second or two.
  • It’s a little bit more complicated to set this up, though not horribly so.
  • Because this uses SSH and requires that Asterisk be granted permission to establish an SSH connection as the super user (by using sudo), there may be unforeseen security risks.

Read that last point again, and please understand that as with all projects on this site, I offer this for experimental purposes only.  I explicitly do not warrant this method as being 100% secure, nor will I tell you that it could not be exploited to do bad things on your system.  I don’t think it can (and feel free to leave a comment if you think I’m wrong), but I just don’t know that for sure.  So, if you decide to use anything in this article, you agree to assume all risks. If you’re the type that likes to sue other people when something goes wrong, then you do not have permission to use this code.  We’re all experimenters here, so no guarantees!

As with the previous method, you must have the Perl language installed on your Asterisk server, and you must have the Asterisk::AGI module installed (I’m going to assume you know how to install a Perl module from the CPAN repository – if you have Webmin installed, it can be done from within Webmin). Chances are you already have Asterisk::AGI installed, unless you built your Asterisk server “from scratch” and never installed it.

There’s one additional thing you must do on the Asterisk server before this will run, and that’s allow Asterisk to run the ssh command as root. So, add this to your /etc/sudoers file (probably at the very end, but in any case it should be obvious where to add this because it will be in a section where Asterisk is granted similar privileges with regard to other programs):

asterisk ALL = NOPASSWD: /usr/bin/ssh

Next you want to copy and paste the following Perl script to the filename /var/lib/asterisk/agi-bin/notifysend.agi on your Asterisk server (to create a non-existent file, you can use the touch command, and after that you can edit it in Midnight Commander or by using the text editor of your choice). If this code looks somewhat familiar, it’s because it’s adapted from some code that originally appeared in a FreePBX How-To, which I have modified.

#!/usr/bin/perl
use strict;
use warnings;
use Asterisk::AGI;
my $agi = new Asterisk::AGI;
my %input = $agi->ReadParse();

# Next two lines fork the process so Asterisk can get on with handling the call
open STDOUT, '>/dev/null';
fork and exit;

my $num = $input{'callerid'};
my $name = $input{'calleridname'};
my $ext = $input{'extension'};
my $user = $ARGV[0];
my $ip = $ARGV[1];

if ( $ip =~ /^([0-9a-f]{2}(:|$)){6}$/i ) {
    $ip = $agi->database_get('growlsend',uc($ip));
}

# OMIT this section if you don't want IP address
# checking (e.g. you want to use foo.bar.com)
unless ( $ip =~ /^(d+).(d+).(d+).(d+)$/ ) {
    exit;
}

if ( $ARGV[2] ne "" ) {
 $ext = $ARGV[2];
}

my @months = (
    "January", "February", "March", "April", "May", "June",
    "July", "August", "September", "October", "November", "December"
);
my @weekdays = (
    "Sunday", "Monday", "Tuesday", "Wednesday",
    "Thursday", "Friday", "Saturday"
);
my (
    $sec,  $min,  $hour, $mday, $mon,
    $year, $wday, $yday, $isdst
) = localtime(time);
my $ampm = "AM";
if ( $hour > 12 ) {
    $ampm = "PM";
    $hour = ( $hour - 12 );
}
elsif ( $hour eq 12 ) { $ampm = "PM"; }
elsif ( $hour eq 0 )  { $hour = "12"; }
if ( $min < 10 ) { $min = "0" . $min; }
$year += 1900;
my $fulldate =
"$hour:$min $ampm on $weekdays[$wday], $months[$mon] $mday, $year";

# Next two lines normalize NANP numbers, probably not wanted outside of U.S.A./Canada/other NANP places
$num =~ s/^([2-9])(d{2})([2-9])(d{2})(d{4})$/$1$2-$3$4-$5/;
$num =~ s/^(1)([2-9])(d{2})([2-9])(d{2})(d{4})$/$1-$2$3-$4$5-$6/;

my $cmd = qq(./remotenotify.sh "$name" "$num calling $ext at $fulldate");
$cmd = "sudo ssh $user@$ip '$cmd'";
exec "$cmd";

Also, if you want to be able to specify computers that you wish to send notifications to using MAC addresses rather than IP addresses (in case computers on your network get their addresses via DHCP, and therefore the IP address of the target computer can change from time to time), then you must in addition install the following Perl script (if you have not already done so when using the previous method). Note that if you have a mix of computers on your network and you are using both the new and old methods, you only need to do this once — it works with both methods (hence the reference to “growlsend” in the database and “gshelper” as the name of this script). Call it /var/lib/asterisk/agi-bin/gshelper.agi and note that there is a line within it that you may need to change to reflect the scope of your local network:

#!/usr/bin/perl
use strict;
use warnings;
my ($prev, @mac, @ip);
# Change the 192.168.0.0/24 in the following line to reflect the scope of your local network, if necessary
my @nmap = `nmap -sP 192.168.0.0/24|grep -B 1 MAC`;
foreach (@nmap) {
    if (index($_, "MAC Address:") >= 0) {
        @mac = split(" ");
        @ip = split(" ",$prev);
        `/usr/sbin/asterisk -rx "database put growlsend $mac[2] $ip[1]"`;
    }
    $prev=$_;
}

Make sure to modify the permissions on both scripts to make them the same as other scripts in that directory (owner and group should be asterisk, and the file should be executable), and if you use the gshelper script, make sure to set up a cron job to run it every so often (I would suggest once per hour, but it’s up to you).

Now go to this page and search for the paragraph starting with, “After you have created that file, check the ownership and permissions” (it’s right under a code block, just a bit more than halfway down the page) and if you are using FreePBX follow the instructions from there on out (if you are not using FreePBX then just read that section of the page so you understand how this works, and in any case ignore the top half of the page, it’s talking about a different notification system entirely). However, note that the syntax used in extensions_custom.conf differs from what is shown there, depending on whether you are specifying an IP address or a MAC address to identify the target computer.

First, if you are specifying the IP address of the target computer, then instead of using this syntax:

exten => ****525,1,AGI(growlsend.agi,192.168.0.123,GrowlPassWord,525)

You will need to use this:

exten => ****525,1,AGI(notifysend.agi,username,192.168.0.123,525)

Note that username is the account name you use when doing an ssh login into the destination system, and it should also be the desktop user on the system (not root!). Let’s say that the system is currently at IP address 192.168.0.123. In order for this to work, you need to be able to ssh into your Ubuntu box from your Asterisk server, using the following command from the Asterisk server’s command line:

ssh username@192.168.0.123

If it asks for a password, then you need to follow the instructions at Stop entering passwords: How to set up ssh public/private key authentication for connections to a remote server, and get it set up so that it will not ask for a password (if you don’t like my article, maybe this one will make it clearer).

It’s probably easiest to configure each computer that is to receive notifications to use a static IP address. But note that if you use the above code and have the gshelper.agi program running as a cron job, then after the first time it has run while the computer to receive the notifications is online you should be able to use a computer’s MAC address instead of the IP address. This only works if you’ve used the modified script on this page, not the one shown in the FreePBX How-To. As an example, instead of

exten => ****525,1,AGI(growlsend.agi,192.168.0.123,GrowlPassWord,525)

as shown in the example there, you could use

exten => ****525,1,AGI(notifysend.agi,username,01:23:45:AB:CD:EF,525)

(the above is all one line) where 01:23:45:AB:CD:EF is the MAC address of the computer you want to send the notification to. Once again, just in case you missed it the first time I said it, this won’t work until the gshelper.agi script has been run at least once while the computer to receive the notifications was online. If for some reason it still doesn’t appear to work, run the nmap command (from gshelper.agi) including everything between the two backticks (`) directly from a Linux command prompt and see if it’s finding the computer (depending on the size of your network, it might be several seconds before you see any output, which is why I don’t try to run this in real time while a call is coming in).

If you are NOT running FreePBX, but instead writing your Asterisk dial plans by hand, then you will have to insert a line similar to one of the above examples into your dial plan, except that you don’t need the four asterisks (****) in front of the extension number, and if it’s not the first line in the context, you’ll probably want to use n rather than 1 for the line designator (and, you won’t be putting the line into extensions_custom.conf because you probably don’t have such a file; instead you’ll just put it right in the appropriate section of your dial plan). In other words, something like this (using extension 525 as an example):

exten => 525,n,AGI(notifysend.agi,username,192.168.0.123,525)

This line should go before the line that actually connects the call through to extension 525. I do not write Asterisk dial plans by hand, so that’s about all the help I can give you. And if you don’t write your dial plans by hand, but you aren’t using FreePBX, then I’m afraid you’ll have to ask for help in whatever forum you use for advice on the particular software that you do use to generate dial plans, because I can’t tell you how to insert the above line (or something like it) into your dial plan.

Now is where it gets just a bit more complicated than in the original method. If you have followed the above instructions, you’ll be able to send the notifications to the remote system using SSH, but there will be nothing there to receive them. So we have to create a small script on the receiving system to do something with the received notifications. That script will vary depending on the receiving system, but it must be named remotenotify.sh and it must be placed in the destination user’s home directory, and don’t forget to make it executable! Here’s one that will work in most Ubuntu installations that have Notify OSD installed:

export DISPLAY=:0
notify-send --urgency="critical" --icon="phone" "$1" "$2"

Those two lines are all you need. On a different type of system (or if you have multiple displays) you may need to or wish to do something different. For example, as I mentioned above, if the destination system is running Growl then your remotenotify.sh script will need to call growlnotify, but beyond that I wouldn’t know what to use there (EDIT: But if the target system is a Mac that is running OS X, a pretty good guess would probably be that you’d only need one line, something like this:

growlnotify -s -p 1 -a Telephone -m "$2" $1

In this case it should make the notification sticky until dismissed by the user, give it a priority of 1 — the default is 0 — and use the application icon from the “Telephone” application if you have it installed. Instead of -a to specify an application’s icon you could use -I followed by a path to an .icns file that contains an icon you want to use.  Type growlnotify –help to see all the growlnotify options.  Oh, and before you can make an SSH connection to a Mac you have to go into System Preferences | Sharing and turn on Remote Login).

The beauty of this approach is that you can make the remotenotify.sh script as simple or as complicated as you need — you could even make it forward a notification to other devices if you wish, but figuring out how to do that is up to you (if you come up with something good, please leave a comment and tell us about it!).

If you’re running Ubuntu on the target system, here’s a few articles you may wish to use to help you get your notifications to look the way you want them to appear:

Tweak The NotifyOSD Notifications In Ubuntu 10.10 Maverick Meerkat [Patched NotifyOSD PPA Updated]
Get Notifications With A Close Button In Ubuntu
Configurable NotifyOSD Bubbles For Ubuntu 11.04: Move, Close On Click, Change Colors And More

If you want to be able to review missed notifications, you may be able to use this (as a side note, why don’t they have something like this for Growl?):

Never Miss A NotifyOSD Notification With “Recent Notifications” GNOME Applet

The idea behind the shell script that runs on the target system was found in a comment on the following article, which may be of special interest to MythTV users:

Send OSD notification messages to all systems on a network

There are links to other original sources throughout the article, so feel free to follow those if you want more in-depth commentary.