Month: December 2012

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, or you can see if you can find a suitable ready-made .iso file at Matt Gadient’s site.

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

If the bootup delay (about 30 seconds on the Apple logo) bothers you, see Reducing the 30 second delay when starting 64-bit Ubuntu in BIOS mode on the old 32-bit EFI Macs.

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

Asterisk/FreePBX: How to get the DID of a SIP trunk when the provider doesn’t send it (and why some incoming SIP calls fail)

The symptom: On a SIP trunk, you can’t get an inbound route to work – it just doesn’t seem to recognize the number. You might be able to get the call to come in on your any DID/any CID route, or maybe the call doesn’t get answered at all. When you type sip debug from the CLI, you can see (when you scroll back to the point where the call came in) that a sip INVITE packet arrived, and perhaps it contained the DID number in the sip To: header (in the form To: <sip:NUMBER@IP ADDRESS>), but you also see that the FROM_DID was set to s. In other words, you see a line that looks like this:

  -- Executing Set("SIP/9995552368-09876543", "FROM_DID=s") in new stack

EDIT: The most common reasons this happens are one or both of two things. Either you are not specifying the number of your DID in the format your provider is sending it (for example, they are sending 11 digits including a leading “1”, but you are only using ten digits in your inbound route), or they are sending the number in the SIP “To:” header. In the latter case, FreePBX has a much easier way to deal with this now. Before you do anything else, try changing the trunk context from from-trunk or from-pstn to from-pstn-toheader. This works for both SIP and PJSIP trunks, but only if the provider really is sending the number in the SIP “To:” header.

Only continue with this article if you have tried the above and it doesn’t work, as much of what is below simply shows an older and less intuitive way of doing the same thing. If the above did not work, don’t forget to change your trunk context back to whatever it was previously. (End of edit.)

Before you attempt anything else, you may want to try this suggestion by Dan Swartz: Check the registration string (in the trunk settings for the provider), and if it’s not already there, try putting the DID at the end of the registration string, prefixed by a ‘/’. It may (or may not) require a leading ‘1’ too. e.g. ‘/18005551212’ (or your country code if you are not in the U.S./Canada, etc.). So, your registration string would take this format:

accountid:password@your.provider/yourDIDnumber

Remember to try your DID both with and without the country code prefix. If this doesn’t work, it’s time to try a workaround (however, you may want to read the addendum at the bottom of this article first!). Perhaps you can see the DID number in the sip INVITE packet’s To: header, but the CLI reveals that Asterisk isn’t picking it up, and therefore it goes to your default inbound route.

(Oh, and for anyone who’s still trying to figure out how to turn off sip debugging, the CLI command is sip no debug)

Fortunately this isn’t a hard thing to work around, as long as the DID number really is in the sip To: header.

NOTE: In the following examples, we now use the s extension rather than _. – this is considered better practice (and safer) but the disadvantage is that the context will fail if the provider is sending any type of DID, even if it’s incorrect or incomplete. If the code doesn’t seem to work, try replacing the s extension with _X! (the extension is to the right of the => and space characters).

First, create a context in extensions_custom.conf that looks like this:

EDIT: Really, don’t do this next part, unless you are running an old version of FreePBX! Just change your trunk context to from-pstn-toheader and be done with it! (End of edit.)

[custom-get-did-from-sip]
exten => s,1,Noop(Fixing DID using information from SIP TO header)
exten => s,n,Set(pseudodid=${SIP_HEADER(To)})
exten => s,n,Set(pseudodid=${CUT(pseudodid,@,1)})
exten => s,n,Set(pseudodid=${CUT(pseudodid,:,2)})
exten => s,n,Goto(from-trunk,${pseudodid},1)

Or, thanks to naftali5, you can cut the above down to one line of code that does the same thing, but is a bit less obvious to the casual reader:

[custom-get-did-from-sip]
exten => s,1,Goto(from-trunk,${CUT(CUT(SIP_HEADER(To),@,1),:,2)},1)

(And speaking of naftali5, if you are using his Dialplan Injection module – which may not work with the most recent versions of FreePBX, so don’t run out and get it if you aren’t already using it unless you are sure it has been updated to work with the version of FreePBX that you are using – and want to put the above line in the Destination section, then you will need to use a slightly different syntax, changing the commas to bar characters, so it looks like this:

* Custom App: from-trunk,${CUT(CUT(SIP_HEADER(To)|@|1)|:|2)},1

The part after Custom App: is what you paste into the text box. This ONLY applies to Dialplan Injection users)

Then, in the trunk associated with the provider, change the trunk context statement (which should read context=from-trunk) to:

context=custom-get-did-from-sip

(Or for Dialplan Injection users, just use

context=injection-n

but replace n with the actual injection number, which will appear next to the injection name in the right-hand column menu of injections.)

And note that with such providers, you may have to move that context statement from the USER details to the PEER details section. This is why calls from some SIP providers sometimes fail to come in at all – they effectively never "see" the User context and details, therefore they don’t see the context statement there and have nowhere to go. It’s also why you sometimes see instructions for sip providers that leave the User context and User details sections totally blank, but include a context statement in the peer details – in most such cases it’s because the provider is treating the customer as an end user (like someone using a softphone or a VoiP adapter) rather than as a peer, and they aren’t sending DID information.

The above instructions may also solve the problem where you have two (or more) trunks from the same provider, but Asterisk always treats it as if all calls are coming in on one of the two trunks, therefore again not allowing you to set up separate inbound routes for each trunk. As long as the provider sends the number in the sip To header, the above code should set the DID properly.

If the first part of the To: statement is something other than a DID number (a user name, for example), then you may have to add a line just before the final Goto statement. For example, let’s say the provider is sending To: <sip:Fred@IP ADDRESS> and your DID number (or at least, the number you want to use to denote your inbound route) is really 5551212. You’d then use code similar to this:

[custom-get-did-from-sip]
exten => s,1,Noop(Fixing DID using information from SIP TO header)
exten => s,n,Set(pseudodid=${CUT(CUT(SIP_HEADER(To),@,1),:,2)})
exten => s,n,Set(pseudodid=${IF($["${pseudodid}"="Fred"]?5551212:${pseudodid})})
exten => s,n,Goto(from-trunk,${pseudodid},1)

Or, as long as you only have ONE trunk from that provider, you could always just cheat a little and hardcode the desired DID in a separate custom context, like this:

[custom-stupid-provider]
exten => s,1,Noop(Fixing DID to 5551212)
exten => s,n,Goto(from-trunk,5551212,1)

And use the name of this context in the trunk settings. I hear you asking, why not just do it this way on all trunks with this issue? Well, because if you add a second trunk from the same provider, this won’t work correctly for both trunks, and if you ever change your number and then forget what you’ve done and just try to set your inbound route to the new number, it won’t work. And besides all that, if you have more than one SIP provider that doesn’t send proper DID, you’d have to create a separate custom context for each of them, instead of having one custom context that works for all of them.

One final note for Free World Dialup users, you may find that sip calls will still not come in until you put the following statement in sip.conf:

insecure=invite

I have no idea why that works, but it seems to make a difference.

What if the provider doesn’t send the number in the sip To: header?

There is at least one provider that actually sends a s character instead of a number in the sip To: header. What can you do with a provider like that? Well, all may not be lost. If you only have a single trunk from that provider, you can just use the "cheat" shown above, since it doesn’t rely on the contents of the sip headers. If, however, you have TWO or more trunks from the same provider, you can do a sip debug from the CLI and watch as calls come in on each trunk and note whether there are any consistent differences.

For example, if you have two lines on the same account, the provider will often assume that you are using a VoIP adapter (such as a Sipura or Linksys) and will use port 5060 for line 1, and port 5061 for line 2. That difference might show up in the headers of the sip INVITE packet, for example:

Via: SIP/2.0/UDP 111.222.333.444:5060;branch=z9hQ4bK67sc0a8e;rport

In this case, you see that there is a colon (:) before the port number and a semicolon following, and that there are actually TWO colons on the line before the port number, so maybe this would work:

[custom-really-stupid-provider]
exten => s,1,Noop(Fixing DID using port from SIP VIA header)
exten => s,n,Set(pseudodid=${CUT(CUT(SIP_HEADER(Via),;,1),:,3)})
exten => s,n,Set(pseudodid=${IF($["${pseudodid}"="5060"]?5551111:${pseudodid})})
exten => s,n,Set(pseudodid=${IF($["${pseudodid}"="5061"]?5552222:${pseudodid})})
exten => s,n,Goto(from-trunk,${pseudodid},1)

Or, if you only have two trunks from this provider, you probably could just condense the two test lines into one, by testing for one port number and assuming the other if the conditional test fails, like this:

exten => s,n,Set(pseudodid=${IF($["${pseudodid}"="5060"]?5551111:5552222)})

Note that the code in this section is untested, it’s just to give you some ideas about how to possibly handle the really oddball situation were you have two (or more) lines from the same provider, and cannot find any other way to differentiate them. And, don’t automatically assume you have a bigger problem than you actually have – for example, it may well be that having different port numbers on the different trunks would allow Asterisk to distinguish them enough that the simple "cheat" method would work (you’d have to make one for each trunk, of course).

Again, if a particular piece of code doesn’t seem to work at all, try replacing
exten => s, . . . . .
with
exten => _X!, . . . . .
in all lines of the context (just in case the provider is sending some unknown number). But if that works, you should consider using whatever the provider is actually sending as the DID for your Inbound Route, which would eliminate the need for this extra code altogether.

Addendum

There are a few other reasons that incoming calls may fail that have nothing to do with the main topic of this How-To, but are common enough that they should be mentioned anyway. The first is that in every trunk configuration, there must be a statement that reads:
context=from-trunk
Some providers will tell you to set the context statement to something else – don’t do it (unless you have a valid reason, such as following the instructions above). Providers are generally more familiar with Asterisk than FreePBX, and often don’t realize that you can’t just use any context name you like in FreePBX unless you also create that context somewhere (usually extensions_custom.conf).

Also the placement of that context= statement can be important. If a provider is treating you as an extension (which would likely be the case if most of their customers use VoIP adapters and/or you are a “Bring Your Own Device” customer) then in most cases you will not need to have a USER context or USER details at all in your trunk, but you still need to have a context=from-trunk statement (or another context= statement if you are following instructions elsewhere on this page) and in this case it will need to be in your PEER details, not your user details. So, if incoming calls aren’t working, try putting context=from-trunk in your trunk PEER details, and if that works, then totally remove the USER context and USER settings from your trunk configuration, since they aren’t doing any good anyway.

To further complicate matters, I have noted that with a couple of providers, nothing seems to work until you do the following. The symptom typically is that you have no problem connecting with other providers, and (if you have tried this) you have no problem connecting with the provider in question if you are using an external hardware device (such as an ATA), but no matter what you do you can’t receive calls from the provider. I hate recommending this because I don’t know exactly why it works, but it’s a trick I’ve used for a couple years now to resolve issues with a couple of specific providers. Don’t try this until you’ve first tried adding the DID at the end of the registration string, prefixed by a ‘/’, as shown near the top of this page.

Open the file /etc/asterisk/sip_general_custom.conf in any text editor and check to see if the following lines are in there:

bindport = 5060 ; Port to bind to (SIP is 5060)
bindaddr = 0.0.0.0 ; Address to bind to (all addresses on machine)
insecure=invite
tos=0x68
srvlookup=no

If any of the above lines are missing, add them to the file. In my experience these lines will not cause problems with other providers but they do magically get things working with a select few providers that are more used to serving customers using an ATA than through a trunk into an Asterisk box. If this gets things working you can try removing lines one at a time to find out which are actually doing the trick, or you can just leave them all in place – as I say, in my experience they don’t seem to cause problems with other providers, although obviously your experience might be different.

Yet another issue that you may encounter, especially if you are upgrading from an earlier version of FreePBX, is that if you have disallow= and allow= statements in your trunk configuration (to specify the use of particular codecs), starting with Asterisk 1.4 the disallow= statement(s) (particularly if it’s disallow=all) must be placed above the allow= statements. This is one of many cases where Asterisk upgrades have broken existing functionality for no good reason whatsoever, other than that the Asterisk developers could not be bothered to ensure backward compatibility.

One other note: There is an obscure bug in Asterisk that can cause incoming calls to fail. If Asterisk ever receives a Caller ID NAME that contains only one quotation mark (usually a name with a quotation mark at the start of the string but not at the end) it will not handle the call properly, and may ignore the incoming call completely.

Additional Reference:

Asterisk SIP channels

Notes on using HDHomeRun recorder under Ubuntu for lowest CPU usage when recording from HDHomeRun device

 

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.

Sometimes I write articles for others, but sometimes I use this blog just to post a collection of notes on something I had a need to do.  This is one of the latter type.  You are welcome to look, and if it helps anyone else, great, but it’s not a full, step-by-step, “here’s how to do it” article, and I definitely do not advise you to just blindly emulate what I did, since there are probably more elegant ways to do this. This was one of those “I just want to get the thing working” type projects, and I must say that it works very well, at least for me.

HDHomeRun recorder is a simple Python script that will record specific channels based on a pre-established schedule.  It is less CPU intensive (and in my opinion, much easier to set up) than some of the other ways to do this, such as Myth TV.  But it is more limited — in particular the current script will only record from a single tuner, and there’s no GUI at all.  Everything is done in script and configuration files.

Here’s what I did:

Using  apt-get or Synaptic, install the following:  hdhomerun-config-gui, hdhomerun-config, libhdhomerun1, python-pip:
sudo apt-get install hdhomerun-config-gui hdhomerun-config libhdhomerun1 python-pip

Install apscheduler:
sudo pip install apscheduler

EDIT (for newer version mentioned by Fred C. in the comments): Then go to this page and click the ZIP button to download a ZIP file containing HDHomeRun recorder.  Unzip it into a subdirectory off of your user directory (I named the subdirectory HDHomeRun_Recorder on my system) — you should get several files and a scripts directory, which contains a couple more files. At this point you might want to check the ownership and permissions of the files — in particular make sure the .py files are executable. Do NOT follow the instructions in the README file; they are for an older version of the software. You may want to read the file, particularly if you have a WDTV Live media player, but the INSTALL section needs updating.

You then need to modify a couple of the files.  This is a bit tricky because what might seem the obvious way to do it won’t work (unless you apply my fix mentioned below).  So here is what you need to do:

(Read through this before actually doing anything, it may save you some effort!)

First, modify config-file.  There are three things you need to change here.  First you need to change this line as shown:

hdhomerun_config = /usr/bin/hdhomerun_config

This assumes the hdhomerun_config program is in /usr/bin, which it will be if you installed it using apt-get or Synaptic.  Next, you need to modify the tuners line to show the correct tuner IDs for your HDHomeRun — you can discover these using the HDHomeRun Configuration utility, if you don’t already know them.  And, you need to replace the entries in the channelmap section with your local channels.  You can run the hdhomerun_setup.py program (run it with no arguments and it will tell you what arguments it needs) and it will show you a list of channels (note it takes a few minutes to run, so be patient), and it appears as if it produces an entire config-file for you, but it doesn’t (keep reading before you do anything, there’s a fix for this below that you might want to try).  So look at the list of channels it outputs and then change each line to match the format you see in the included config-file.  For example, let’s say you see:

35.1   = 11   3   WGVU-11
35.2   = 11   4   WGVU-11
35.3   = 11   5   WGVU-11
35.4   = 11   6   WGVU-11
0 = 11 9 (control)
0 = 11 10 (control)

What that needs to be changed to in config-file is:

35.1 = 8vsb:11, 3       ; WGVU-11
35.2 = 8vsb:11, 4       ; WGVU-11
35.3 = 8vsb:11, 5       ; WGVU-11
35.4 = 8vsb:11, 6       ; WGVU-11

I have no clue why the hdhomerun_setup.py program doesn’t produce the correct output, it just doesn’t. I tried fixing it to produce the correct output (despite the fact that Python is a very incoherent language to me), and think I have it, so if you want to try my fix to hdhomerun_setup.py, the code is at the end of this article.

Second, you need to modify schedule-file. This is an example schedule file, and you just modify the entries with programs you like to record.

When you run the python script, I found that you need to actually be in its directory, and also that when you run it, it will seem like nothing is happening. And the command prompt won’t come back either, so you may want to initially run it using screen:

screen ./hdhomerun_recorder.py

You can use Control-A followed by D to detach from the process. To check that it started and everything is working okay, check logfile (in the same directory as the hdhomerun_recorder.py program). I found that the following could be used to kill the process:

pkill -f “python ./hdhomerun_recorder.py”

I made a bash shell script that looks like this:

#!/bin/bash
export USER=yourusername
pkill -f “python ./hdhomerun_recorder.py”
cd HDHomeRun_Recorder
./hdhomerun_recorder.py &

I can run this script to restart the Python script (in case I make a change to the schedule) and I can also add it to my startup items to start the script after a reboot (the pkill is ignored in that case).

Note: If you need a way to determine the channels in your area and don’t want to run hdhomerun_setup.py, see hdhomeruntoolbox, but note that the .strm files it produces are not in the correct format for XBMC (in case you are using XBMC, and if you are and you know anything about Java, maybe you want to grab a Java Decompiler and see if you can fix the output). However, after it runs, the information you will need for each channel in HDHomeRun recorder will be in a file named scan_tuner1.txt in the (hidden) .hdhomerun directory. When you look in that file, you will see sections for each working channel that contain information such as this:

SCANNING: 201000000 (us-bcast:11)
LOCK: 8vsb (ss=100 snq=91 seq=100)
TSID: 0x05E7
PROGRAM 3: 35.1 WGVU-11
PROGRAM 4: 35.2 WGVU-11
PROGRAM 5: 35.3 WGVU-11
PROGRAM 6: 35.4 WGVU-11
PROGRAM 9: 0 (control)
PROGRAM 10: 0 (control)

In config-file, the above would translate to something like this:

35.1 = 8vsb:11, 3 ; WGVU-11
35.2 = 8vsb:11, 4 ; WGVU-11
35.3 = 8vsb:11, 5 ; WGVU-11
35.4 = 8vsb:11, 6 ; WGVU-11

Note that stations will not always have the real channel numbers after the callsign, so the real channel number actually comes from the (us-bcast:11) in this case.

Setting up config-file is probably the hardest (not actually hard, but maybe tedious) part, if you can’t get my modifications to the hdhomerun_setup.py script (below) to work, but remember that you only need to add the channels from which you might want to record programming, not every channel available. Remember to restart the Python script if you change the schedule, but of course you DON’T want to do that while it’s recording programming!

I should add that since HDHomeRun recorder is a Python script, it’s probably possible to make it run under operating systems other than Ubuntu, but I just haven’t attempted to do that.

Here are my changes for hdhomerun_setup.py, that should cause it to print out usable lines that replace the existing lines in config-file (you will have to copy and paste them; it does NOT overwrite config-file). Note that there will only be one tuner shown on the tuners line, so you should add your additional tuners if you want to use them For example, if you have a HDHomeRun Dual, and this script prints out tuners = 10ABCDEF:0 you should add the second tuner so that the line is tuners = 10ABCDEF:0, 10ABCDEF:1 (with comma and space separating the two).

#!/usr/bin/env python

def channel_iter(file):
    for line in file:
        if line.startswith("SCANNING: "):
            channel = line.split()[2].strip('()')
            channel = channel.split(':')[1]
        elif line.startswith("LOCK: "):
            modulation = line.split()[1]
        elif line.startswith("PROGRAM "):
            (PROGRAM, subchannel, vchannel, name) = line.split(None, 3)
            subchannel = subchannel.rstrip(':')
            name = name.strip()     # remove new line
            name = name.replace(' ', '-')
            yield (vchannel, modulation, channel, subchannel, name)

def channel_info(hdhomerun_config, device_id, tuner):
    import subprocess
    import tempfile

    f = tempfile.TemporaryFile()
    cmd = [hdhomerun_config, device_id, "scan", "/tuner%d" % tuner]
    p = subprocess.Popen(cmd, stdout=f)
    p.wait()
    f.seek(0)
    return list(channel_iter(f))

def main():
    import sys, os, os.path

    usage = ("usagde: %s path-to-hdhomerun-config device-id tuner-number"
             % sys.argv[0])
    if len(sys.argv) != 4:
        sys.exit(usage)
    hdhomerun_config = sys.argv[1]
    device_id = sys.argv[2]
    tuner = int(sys.argv[3])
    if not os.path.exists(hdhomerun_config):
        sys.exit("%s doesn't exist, aborting!")
    if not os.path.isfile(hdhomerun_config):
        sys.exit("%s is not a regular file, aborting!")
    if not os.access(hdhomerun_config, os.X_OK):
        sys.exit("%s doesn't have execute permission set, aborting!")

    chan_info = channel_info(hdhomerun_config, device_id, tuner)
    if not len(chan_info):
        sys.exit("couldn't find any channels, quitting!")

    print("[global]")
    print("logfile = logfile")
    print("media_dir = media")
    print("schedule_file = schedule-file")
    print("hdhomerun_config = %s" % hdhomerun_config)
    print("tuners = %s:%s" % (device_id, tuner))
    print("[channelmap]")
    print("# virtual-channel = physical-channel program-number name-of-program")
    for (vchannel, modulation, channel, subchannel, name) in chan_info:
        line = "%s = %s:%s, %s t; %s" % (vchannel, modulation, channel, subchannel, name)
        if vchannel != '0':
            print(line)

if __name__ == '__main__':
    main()

Featured Article:

Recent Posts

Recent Comments

Archives

Categories

Meta

GiottoPress by Enrique Chavez

%d bloggers like this: