Installing MythTV on Debian

Here is my method for setting up MythTV on Debian 7 (Wheezy). I chose Debian as I found it the most stable Linux distribution and also allowed for a very minimal installation. This is a backend only setup as I use XBMC as the frontend on another PC.

Note: The commands below are run as the root user unless specified.

  1. Install Debian. I used the network install ISO, set up on a USB stick. During installation I did not choose to install any packages other than SSH.
  2. Login via SSH. I use PuTTY on my Windows machine. In order to get mythtv-setup to work, you will need to install an X Windows server. I use Xming.
  3. In PuTTY, enable X11 forwarding. Enter localhost:0 for the X display location. Make sure Xming is running before connecting.
  4. Update /etc/apt/sources.list. We need to add the repository at, so MythTV can be installed.
    deb wheezy main non-free
    deb wheezy-backports main
  5. Add non-free to the existing sources as well. This was required to download the firmware for the Sony PlayTV tuner I’m using.
  6. Run the following to install the deb-multimedia package source.
    apt-get update
    apt-get install deb-multimedia-keyring
    apt-get update
  7. Here I’m installing the firmware for the tuner, as well as ntp client and the X Windows Server.
    apt-get install firmware-linux-nonfree xorg ntp
  8. Install MythTV. We need to install from the Wheezy-Backports repository as the stable one does not have the latest version.
    apt-get -t wheezy-backports install mythtv mythweb
  9. I open access to Apache for access to MythWeb on the local subnet. Edit /etc/mythtv/mythweb.conf.
    Allow from <Subnet>/24

    Where is your LAN IPv4 network address.

  10. Restart the Apache server for the above change to take effect.
    /etc/init.d/apache2 restart
  11. Create MythTV storage directories. I have a drive mounted to /mnt/storage, and create a directory here called mythtv. Under this I create two directories, one for recorded TV, the other for the live TV buffer. I then give the mythtv user read and write permission on the directories.
    cd /mnt/storage
    mkdir mythtv
    mkdir mythtv/recordedtv
    mkdir mythtv/livetv
    chown mythtv:mythtv recordedtv/
    chown mythtv:mythtv livetv/
    chmod 755 recordedtv/
    chmod 755 livetv/
  12. Run mythtv-setup as your non-root user. Refer to the MythTV Wiki for setup help.
  13. Make sure mythtv-backend is running. You can start the backend like so.
    /etc/init.d/mythtv-backend start
  14. The MythTV backend should now be ready.

Rebooting this blog

After a few years without touching this blog I’ve decided to actually use it. I will be posting anything I feel would be worth sharing.

Restoring SBS 2008 Backup To Hyper-V

As a test I thought I would see how the SBS 2008 backup handles restoring to a Hyper-V virtual machine. The P2V was successfull but of course there are some issues to deal with.

This is how I did it on a Windows Server 2008 R2 standard machine.

1. Attach the USB backup disk to the Hyper-V host.

2. Open Computer Management -> Disk Management and take the backup disk offline. This allows Hyper-V to attach the usb disk as an internal IDE disk.

3. Open Hyper-V manager.

4. Edit the properties of your SBS 2008 VM. Set the usb disk as the secondary device on the primary IDE channel.

5. Boot the VM using your SBS 2008 DVD or ISO.

6. Restore the system using Windows Complete PC restore.

7. When the restore is complete the VM will reboot. If everything is OK you should eventually see the login prompt.

8. You will need to rerun the connect to internet wizard to fix the network. I also noticed you’ll need to reimport your SSL certificate, so make sure you have a backup of that handy!

That was as far as I got in testing but from what I could see there shouldn’t be a major problem doing a P2V of SBS 2008 to Hyper-V.

Black Screen On SBS 2008 Startup

After having our SBS 2008 server in operation for 9 months I noticed that restarts were taking much longer than normal, around 40 minutes. On an unrelated issue I went to open Device Manager and it took some time (probably around a minute) to display the list. Viewing hidden devices (with the environment variable DEVMGR_SHOW_NONPRESENT_DEVICES enabled) is where I found the problem.

Under the section “Volume Shadow Copies” were thousands of “generic volume shadow copy” entries, most of them disabled (not present). My guess is these had been created by windows server backup and the swapping of external usb backup disks. The thousands of shadow copy devices had made the system registry hive huge, causing the delay opening device manager and the black screen at startup.

Here is my solution. Please do this at your own risk!

1. Obtain the Microsoft devcon utility from the Windows Driver Kit. This TechNet Wiki page explains how.

2. Get Rob van der Woude’s RmHidDev.bat script here.

3. Modify lines 53-56 to this:

FOR /F "tokens=1 delims=: " %%A IN ('DEVCON FindAll @STORAGE\VolumeSnapshot\HarddiskVolumeSnapshot* ^| FIND /I /V "matching device(s)"') DO (
	TYPE "%Temp%\DevconFind.txt" | FIND "%%~A" >NUL
	IF ERRORLEVEL 1 %Debug% DEVCON Remove "@%%~A"

4. Start an elevated command prompt.

5. Run RmHidDev.bat /Y /D >> output.txt to pipe the output to a log file. This will give a list of all devices the script will remove. Do this to double check it will only remove the disabled generic volume shadow copy devices.

6. Run RmHidDev.bat without switches to remove the devices.

After doing this Device Manager and restarts were much quicker. I noticed no issues with the backups but again do this at your own risk!

Thanks to this post as the basis of this solution.

Mysterious V6 Slowdown 2

Just like my previous post, a customer showed me how slow it was to open quotes in V6 on their new Windows 7 machine.

I fired up Process Monitor and looked at the output while loading a quote. I noticed many requests to read\write to the file V6. ini. This file resides in C:\Windows (only in V6 2.1 and older). Since Windows Vista any attempt by an application (without a manifest) to write to C:\Windows will virtualise the file to a location in the user’s profile. This is completely transparent to the application.

For some reason the virtualisation of V6.ini was causing major slowdown in V6. To stop the virtualisation I assigned the write permission to the copy in C:\Windows. This resolved the problem.

Mysterious V6 Slowdown

A few weeks ago I came across a very strange slowdown problem with V6. The customer informed me that it was taking at least five minutes to open quotes, big or small. I logged into the computer and checked the installation. It was a brand new Windows 7 machine and V6 had just been installed so everything was set up correctly.

So I started my usual checks. First was event viewer. I noticed some warnings in there regarding dynamically loaded dll’s. I hadn’t seen that event before and looked into it.

Using the fantastic Process Monitor from Microsoft’s SysInternals, I noticed in the stack of the V6 executable a dll that looked out of place. Checking the properties of this dll showed that it belonged to the anti-virus software installed on the machine.

I hoped that disabling the anti-virus would unload the dll. I was wrong. To dig deeper I loaded up Autoruns (also from Microsoft’s SysInternals) and noticed that the dll was listed in the AppInit section. Disabling this entry and restarting the system solved the problem!

I looked into what AppInit is. It’s a deprecated “feature” (if you could call it that) where dlls are loaded when user32.dll is loaded at startup. This knowledge base article and Microsoft’s Raymond Chen explain why this “feature” should not be used.