TechNazgul RSS

Friday, January 28, 2011

Customized XBMC Transparency Skin for MythBox

I’ve been a long-time XBMC user and recently started using MythTV as well after dumping my satellite subscription.  The MythBox integration with XBMC is awesome, but one thing I felt was lacking was an XBMC skin with an easy front-page option to click directly into MythBox.


Most XBMC skins offer the ability to customize submenus one or more levels deep in their menu system, but if you’re trying to convince your wife or kids that MythBox is the best thing since sliced bread, you don’t want to frustrate them by asking them to remember a complicated set of button clicks to get into live TV (MythBox).  The way around that is to customize a skin to allow the MythBox script to be called from the home screen. (note that the Transparency skin does the option to add custom buttons to the front screen, but only if they call up a favorites.xml file, it does not allow a script to be called from the custom button, at least not currently)


Since a picture is worth a thousand words, below is what the customized Transparency skin looks like.  As it turns out, making this work only requires changes to one file and the addition of the mythtv background file. 


Download the required files here if you’d like to make these changes yourself.


You’ll need to unzip the files and copy them into your xbmc userdata folder.  Navigate to: userdata –> addons –> skin.transparency and then mimic the file structure in the zip file.  The file Includes_home.xml goes into the 720p folder and the mythtv.jpg file goes into the backgrounds folder. 


To enable the view from within Transparency, you need to have the following enabled: 

Settings –> Skin Settings –> Menu –> TV


“TV” in this case has been replaced by MythTV and will be called “Live TV” in the Menu.  If you want to name that something different, navigate to line 2037 in the Includes_Home.xml file and change “LIVE TV” to whatever you want it to be.





Technorati Tags: ,,

HDTV OTA Antennas: Terk HDTVa vs. Antennas Direct DB2

I’ve recently decided to cancel our $85 / month DirecTV subscription and will instead be utilizing a combination of MythTV (open-source DVR software ) for managing over the air (OTA) broadcasts and online streaming (Netflix, Hulu, etc.) as a replacement f or movies/TV series.  (which will undoubtedly be a topic in future posts).


During the process of setting this up, I had to choose an antenna for my attic to allow me to receive the OTA broadcasts in our area.  I purchased the two top-selling HDTV antennas from Amazon and compared the two. 


When dealing with antennas, I realize that everyone's situation is unique, but below is my experience.  I live in Austin, TX about 12 miles north of most of the main towers. The antenna is in my 2nd story attic. 


Most of the stations in my area broadcast on UHF, but one continues broadcasting in VHF so I initially thought I needed an antenna that did both UHF/VHF. For that reason, I picked up this Terk HDTVa (which does both UHF/VHF) first and was disappointed with its results, both on UHF & VHF. The signal was decent, but definitely not flawless.


In addition, I found two things about this design sub-par. First, with the VHF antennae extended, the unit takes up a lot of space, even in an attic. It's also very unstable when fully extended. Secondly, the stated need for it to be plugged in regardless of whether you are using the amplification or not makes for a slightly inconvenient installation. Finally, I noticed that the power adapter when plugged in was exceedingly hot, so hot that it was uncomfortable to hold in my hand. Long-term, that just does not seem safe to me.

To make a long story short, I tried the antenna for a day and then ordered the Antennas Direct DB2 Multi Directional HDTV Antenna to replace it. It immediately improved my reception on UHF and surprisingly, on the one VHF station as well. The antenna was placed in the exact same spot as the HDTVa.  Below are the signal comparison results for each antenna.


Terk HDTVa antenna
Channel -> Signal Strength / Signal Quality
54.1 -> 61/83
42.1 -> 65/91
24.1 -> 80/100
18.1 -> 72/94
36.1 -> 78/95
7.1 -> 54/75 [VHF]








db2Antennas Direct DB2 antenna
Channel -> Signal Strength / Signal Quality
54.1 -> 91/100
42.1 -> 84/100
24.1 -> 94/100
18.1 -> 95/90
36.1 -> 96/95
7.1 -> 91/100 [VHF]

Conclusion: The DB2 was 15-30% better on every channel and also does not require power for amplification like the HDTVa does. A hands-down winner in my situation.



Configuring DD-WRT VPN client with HideIP VPN

HideIP VPN is a simple, fast VPN provider that I’ve used in the past to help navigate around poor BGP routing issues that were slowing down my backups to CrashPlan’s online backup service.  Specifically, the goal was to avoid any and all routing through Cogentco’s very slow route to CrashPlan Central (which increased my uploads by 350%).  I’m optimistic that at some point CrashPlan will fix this problem by talking to Cogentco about how it’s affecting their service, but despite it being reported several months ago by many users on their forums, their only response is that they don’t believe it’s their problem (bummer).


However, configuring the VPN on each machine in my network was a pain I didn’t want to go through, so instead I set up a VPN on my DD-WRT router (Asus RT-N16) to direct all CrashPlan Central traffic through the VPN (which is faster than the direct connection BGP chooses for me to CrashPlan’s central servers).


This is all done in DD-WRT version v24-sp2 (mega build).  In the DD-WRT GUI, choose Services –> VPN – PPTP Client –> Enable.


That brings you to this interface:




Now, let’s explain each of the options above.


Server IP or DNS Name: This is the address of the HideIP VPN server you wish to use.  At the time I was doing this, here is how the IP addresses map to locations.  The lines in bold are VPNs that actually do avoid Cogentco’s routing to, so if you’re trying to accomplish the same thing, I’d recommend you use one of those. resolves to: - Houston, TX resolves to: - Los Angeles, CA resolves to: - Dallas, TX resolves to: - NYC resolves to: - Dallas, TX resolves to: - Santa Ana, CA resolves to: - Chicago, IL (the one I’m using above) resolves to: – NYC


Remote Subnet:  This is the range of addresses belonging to  I chose a wide swath of addresses that includes the complete last octet of the IP address. 173.225.132.x, which is what the combination of remote subnet and subnet mask accomplishes above.  Use those same values if you are backing up to  Realistically, this will cause some non-crashplan traffic to go over this VPN as well, but I don’t consider that a big problem.


MPPE Encryption: These options are necessary to connect to HideIPVPN’s service:

mppe required,no40,no56,stateless


MTU/MRU/NAT: leave as default.

Username/Password” as provided by HideIPVPN


Once you’ve configured these options click Save, then Apply Settings.   Then navigate to “Administration –> Reboot Router.”  The router will connect to the VPN upon reboot. Make sure to give it 2-3 minutes to fully reboot and connect, after which you can test success by opening a terminal window and doing a traceroute to  In Windows, the output looks like this.  The key that you are looking for is for the 2nd line to read something like below, an internal IP address on HideIPVPN’s network.  After that, just check the route to make sure that it does not include CogentCo and you’re set.




In my case, going through CogentCo maxes me out at a ~500 Kbps to  When I establish the VPN through HideIP-VPN-NYC, I achieve ~1.8 Mbps (on a 3 Mbps uplink connection), a 350% improvement.


Friday, January 21, 2011

CrashPlan Online Backup: Maximizing Upload Speeds

Note that the problems related to dedupe/compression observed in this post were fixed by CrashPlan in the 3.03 software release in March of 2011.  As of March, 2011, the problems with CogentCo remain problematic (limits of 300-500 Kbps through CogentCo vs. 3 Mbps + through any other route).


The recent comments in a forum thread at CrashPlan re: compression / deduplication and CPU usage prompted me to run a series of tests with different configuration settings to see how/if it impacted upload speeds to CrashPlan Central (their online backup archive).  Below are the details on the tests I performed as well as the results.


Test file:  3GB ISO file of a DVD
Archive location:

Online Archive Size: ~100k files, 2.4TB
Server OS: Windows Server 2008 R2
RAM: 12 GB
CPU: i7-860, 2.8GBz Quad Core with Hyperthreading
System Drive: 64GB SSD
Source File Drives: 10x2TB RAID 6
[Given this configuration, if this server ends up being resource constrained, you can imagine that almost any other machine would be as well given a similarly large backup set]


Between each change of the settings below, I restarted the CrashPlan service using the restart command in the GUI.  Speed results below are taken from observing Windows network monitoring for several minutes of sustained performance, not from the CPU GUI (which sometimes reports different throughput based on compression & de-dupe).  During testing, I was monitoring the WAN interface on my router during all tests to ensure there was no significant consumption of my bandwidth from anything else on my network.


Lastly, this Windows install is brand new as of yesterday with only a handful of applications installed other than CrashPlan, so interference from other software should be minimal.


With all that said... the results are:


Test 1: (Control case)
Data de-dupe: Minimal
Compression: Off
Results:  2.1 Mbps upload
CPU usage: ~4% average across 8 threads


Test 2: (test 1 with compression to ON)
Data de-dupe: Minimal
Compression: *On*
Results:   1.95 Mbps upload (essentially the same as test 1)
CPU usage: ~4% average across 8 threads


Test 3: (test 1 with compression to auto)
Data de-dupe: Minimal
Compression: *Auto*
Results:    2.1 Mbps Upload
CPU usage: ~5% average across 8 threads


Test 4: (test 1 with de-dupe to Full)
Data de-dupe: *Full*
Compression: Off
**Results:   530 Kbps Upload**
CPU usage: ~15% average across 8 threads (or effectively 100% of one thread)


Test 5: (test 1 with de-dupe to Auto)
Data de-dupe: *Auto*
Compression: Off
***Results:    550 Kbps Upload***
CPU usage: ~15% average across 8 threads (or effectively 100% of one thread)


Conclusion: De-dupe set to anything but minimal is an absolute throughput killer when backing up large compressed files and/or when backing up from a large backup set.  This could be due to the size of my backup set (100k files and 2.4 TB, which is a lot to de-dupe), but it appeared to be limited by the ability of the de-dupe process to use only 1 CPU (other than this, I observed low network usage, low overall CPU usage, low memory usage, no disk queues, etc.). 


Also, this was a head-slap moment for me as I've been struggling to figure out why my throughput to CrashPlan was so poor for some time now and was actually reimaging this server just for the purpose of starting fresh with CrashPlan and getting my speed issues fixed once and for all.  Duh...


Takeaway for me:  I'm turning compression to Auto and De-dupe to Minimal.  I can't tell you how happy I am to have finally figured out what was causing the performance bottleneck on this backup set...  This might not work for everyone, but if you're in  similar scenario to mine, I'd encourage you to try these settings.


I’ll close by saying I love CrashPlan.  It is the best backup software I’ve found out there and I’ve tried several.  Now that I have this figured out, it’s even better.  :-)  Hopefully this knowledge helps others out as well.


Finally, I’ll close by mentioning one other well-known issue affecting upload speeds to CrashPlan Central.  It involves routing through the cogentco network and is discussed here and here (and probably elsewhere) on CrashPlan’s forum.  I wrote up a related post discussing how this bottleneck can be avoided through use of a VPN to avoid the CogentCo network.


Advanced network configuration using vmware Player

Vmware-netcfgIn the past, the advanced network configuration utility for vmware was installed automatically with vmware player, but at some point they started making it more difficult to find.  As it turns out, vmnetcfg.exe is still included with the installer, but you have to manually extract and move it to your install directory.

The steps to extract it are fairly simple.  Download the standard vmware player installer and then do the following:


  • Open a command prompt in the same directory as the vmware installer.
  • Issue the command, VMware-player-3.<version>.exe /e .\netcfg
  • Navigate to the netcfg folder in the same directory, which now contains the extracted installer files
  • Open ‘’ with Winrar (or something similar) and you will see the vmnetcfg.exe file.
  • Copy that file to your install directory… Something like C:\Program Files\VMWare\VMWare Player\
  • Once copied, you can double-click the utility from that folder and begin the advanced configuration of your vmware network adapters.


If you’ve not used this utility before, it allows you to specify which virtual network adapters fulfill which function, define which subnets you want each virtual adapter to use, etc.  For example, if you have two network connections on your computer and want to bind different vmware network adapters to different physical network connections (and related VLANs), you can do so using this utility.


Thanks to The Advisers Group for the original tip.


Technorati Tags: ,,

Thursday, January 20, 2011

Enable Windows Snipping Tool in Server 2008 R2

64px-Snipping_Tool_Vista_IconStrangely, attempts to Google this solution led to many convoluted results that involved copying files from a Vista install to the Server 2008 directory or hacking the registry to make this work. As it turns out, in Server 2008 R2, it is simple as:


Server Manager > Features > Add Features > Desktop Experience.


This does include some other ‘junk’ that you might not want on your server like WMP, Desktop Themes, etc., but it will get you the Windows Snipping Tool as well.


Technorati Tags: