Here’s a script that I’ve been working on for the past few days.
I wrote it to make it easier to pull info for a large number of AD users, and then export the data into CSV or a datagrid.
I’ll probably be adding on to this script as time goes on.
A few weeks ago, I picked up a Rosewill RNG-407-Dualv2 for my home server. It’s a dual gigabit NIC, that Amazon had for less than $40. Thanks to Hyper-V and an Ubiquiti managed switch, I was able to quickly set up port channel, which gave me some extra speed on network operation, as well as separating my VI network traffic from my management traffic.
Since they were so affordable, I decided to pick one up for my desktop as well. My desktop runs Windows 10 Pro, with Hyper-V. I figured I’d set it up the opposite way from server, with the desktop getting the port channel 2 gbps connection, and my VM’s getting my existing onboard 1 gbps connection. Little did I know that this was going to be a bit more of a hassle.
As any decent IT guy would do, I tossed aside the provided driver CD, and jumped online to grab the latest drivers. And then the fun started.
Rosewill’s drivers installed as expected and I suddenly had two LAN interfaces as expected. However, Microsoft does not support teaming in Windows 10 natively. That was probably something I should have investigated before buying this, but what’s a home tech project that doesn’t have a few surprises?
I did some checking on Rosewill’s site, however, it was sparse on details and instructions. There was a diagnostic driver that had a folder called teaming, however attempting to install it was blocked by Windows due to incompatibilities.
At this point, I was starting to get concerned, so I decided to check with the chipset manufacturer and see what generic drivers they had. Fortunately, the network chip is a Realtek product, so they had several driver options on their website.
I download the latest Windows 10 drivers, and install. They are more recent than the Rosewill ones, so I had high initial hopes for them. Alas, there was still no way to configure teaming from the driver side.
Realtek had a diagnostic driver, so I attempted an install of that. Everything seemed great. Network cards showed up in network devices with Realtek Teaming driver, and no alerts anywhere. So, I fire up the Realtek Diagnostic Tool, and it fails with a protocol error. I do some Googling, and turn up an old driver on AsRock’s site of all places that claims teaming abilities.
Deciding that I have nothing left to lose, I download and install the driver pack. I try to load the teaming utility, and it comes right up. I am then able to set up network teaming through the rather archaic looking utility. After a quick port channel config on the switch, I’m able to get connected.
As a test, I start copying some large files to two separate systems to maximize speed. Right away, I hit 1.5gbps, which is exactly what I want to see.
For now, I’m satisfied, however, I suspect I’ll be trying the Realtek Diagnostic drivers again, since I’m not sure why those wouldn’t work, but an older AsRock driver for Realtek would.
I run a PC-based DVR with some SiliconDust HDHomeRun Prime tuners. Historically, I’ve used Windows Media Center, as it was painless to use, and had a robust 10 FT interface as well as an excellent TV guide. However, when Microsoft announced that it was going to be a paid addon for Windows 8, I saw the writing on the wall, and started researching other alternatives.
I ended up with NVPR, after testing a lot of the other Windows based solutions, such as MediaPortal and ForTheRecord (which I believe is now Argus). NPVR seemed to have the easiest guide setup and the most stable recording out of those three. The only issue that I’ve had with NPVR, and it’s the same as all non-MCE options, is that it doesn’t support DRM recordings. So, depending on your cable provider, this may not be that useful. However, for cablecard copy-freely channels as well as clearqam/antenna channels, it’s a great choice.
NPVR is free, supports some scripting to handle guide and recording handling, and is rock solid stable. Let’s go through what features it offers.
We’ll start with the guide functionality, since that is where a DVR program lives and dies. Fortunately, NPVR supports both MC2XML as well as SchedulesDirect. I decided to pay the $25 a month to get SchedulesDirect. It’s easy to setup and update, and quite accurate. When you open the guide, it shows a (configurable) timespan and all the shows that are airing.
Recording options are quite robust, with the basic “Record Once”, “Record All New” and “Record All”, as well as more advanced options like “Record all at this time slot” or “Record on these days”. Files are saved as TS files with an XML sidecar for metadata. While some may prefer a compressed file to save space, having the raw TS files gives a lot of options, particularly if you want to strip commercials or re-encode to your standard format. There are script hooks in the scripts directory that let you run postprocessing scripts to move files, or reencode, or whatever else you’d like.
Live TV and playback work well, although it’s not on par with MCE, or even the more recent releases of the SiliconDust TV App that support DRM channels. At this point, I either use the SiliconDust TV app on my computer, or the cable provider box for live TV.
Beyond that, it also has a strong web interface that supports much larger channel displays, as well as a robust search and record function. Definitely helpful for those days that I’m out of town and want to quick double check whether or not I’ve got my shows recording.
It also has a good community, and regular updates, as well as some plugin support. One plugin that I highly recommend is GuidePlus [site link]. It will automatically update the guide listings for shows that you have set to record with season/episode details, as well as renaming the files with the same info. It makes it quite easy to see whether or not you’ve seen an episode or not.
All in all, NPVR is the best DVR product on PC that I’ve tested. At some point, I’ll do a comparison with PLEX and SiliconDust’s beta DVR product.
I use SiliconDust’s HDHomerun Primes for my DVR needs at home. The prime model lets you connect a cablecard from your cable provider, and access the full range of channels, and not just the few local channels that come through ClearQAM (assuming you have one of the few providers that even offer those anymore).
As with most cable providers, on top of the cablecard, my provider toss in a tuning adapter that is required to access the full range of channels. That takes what used to be just a single network device in the case of a simple ClearQAM tuner, to a 3 device setup, wherein any failure will cause random channels to fail to complete loss of recording abilities. Tuning adapters in particular are quite fail-happy. I tend to need to restart mine about once or twice a month.
After a particularly bad string of recording/tuning failures, I decided that something needed to be done. I use PRTG’s free license to monitor my home network, so I started looking at that first to see what was needed to write a plugin. Fortunately for me, PRTG plugins can be Powershell, and just need to return a simple XML value in order to handle logging and alerting.
Unfortunately, the HDHomerun devices do not use an accessible API, so I had to go back to the drawing board. I ended up using curl to grab and parse the network page for the site for the details that I wanted to track. Since the pages are simple HTML, results are pulled almost instantly, and I’ve not seen any negative impact from pulling reports every minute.
For starters, I wanted to validate that the tuner was actually responding and serving the page. Why not start with the basics? On the off-chance the page doesn’t respond, it’ll throw an error, and depending on how you have your PRTG set up, you can get an email for that.
Then, working my way down the failure points, I wrote the needed code to track the cablecard status. If the cablecard shows anything but working, it’ll kick back an error. While this is an issue that I’ve only see happen once, it wouldn’t be a complete monitoring solution if I disregarded the risk potential. Unfortunately, this wasn’t one that I wanted to test, since the last time I removed a card, I had to sit on the phone with support so that they could re-pair it with the tuner. That being said, it should work as expected.
The final (and most expected) failure point is the tuning resolver. These boxes have a tendency to just randomly crash or stop responding, causing random channels to not show up or not be found. Frustratingly, in most cases, there aren’t even any LED changes to show that they have failed. Thankfully, the HDHomerun is able to tell when they go down, and the pages will update with failures if it loses contact with them. If the script detects anything wrong, it’ll bounce back a failure, and (if configured), you’ll get an email with failure details.
Deciding to err on the side of overkill, I also added some statistics reporting as well. So the script will monitor the signal strength/quality of each tuner individually, as well the cablecard signal quality/strength. It makes it easier to verify any sort of quality issues, as well as just being an interesting thing to track.
Installation of the script is just a matter of adding it to your plugins directory, and adding a custom/exe sensor in PRTG. It takes three parameters:
Enter the IP address of the tuner you’re tracking here.
Put a 0 if this is a plain tuner, and a 1 if it is a Prime/CableCard tuner
Put the number of tuners that you have. 2 generally for plain, and 3 for Prime
The script for monitoring the cablecard and tuning resolver statuses is separate from the main script, so make sure you include that one as well.
That script only has the parameter of -IPAddress.
You can download these scripts from Github here.
After a very, very long break, I’m bringing Furytech back. In the coming days, you’ll be able to find reviews of products, thoughts on technology, random scifi opinions and more!
More to come!