Back in 2008 when I originally was looking at the various solutions for archiving my movies, I weighed the pros and cons of things and decided to rip my movies to VIDEO_TS format. I did that for a few reasons:

• I wanted to keep the fidelity of the original movie. I didn’t want a whole bunch of additional compression artifacts that would detract from the watching experience.
• I wanted to keep the sound. I didn’t want everything downmixed to stereo sound, I wanted the full surround experience you’d normally get with the movie.
• I wanted a backup of the original disc. In the event a disc goes bad, I wanted to be able to re-burn the disc.

Well, six years (!) have passed since I made that decision and a lot has changed, not only with technology, but with my own thoughts on what I want.

• Full DVD rips take a lot of space. That native MPEG-2 compression is really not great. Not to mention the digital files some DVDs come with for “interactive features” and things.
• We don’t use the extra features. After running the media center for this long, our usage pattern with it has become pretty clear – we watch the main movie but we generally don’t make use of the behind-the-scenes featurettes, audio commentary, or other features of the movies.
• The FBI warning, menus, previews, and other “up front stuff” is annoying. We’ve known that all along, but it’s like that five minute tax you just accept for watching a movie. I’m tired of paying that tax.
• Discs don’t go bad as often as you think. Of the literally hundreds of discs I have, I think I’ve had like two go bad. I know I’ve jinxed it now that I’ve said it.
• Disk space isn’t free. It’s cheap, but not free. The real challenge is that if you have a NAS with all full bays and a RAID 5 array, it’s not really that easy or cheap to expand. You have to move all the data off the giant array (to where?), upgrade the disks, and move it all back. (Basically. Yeah, there are other ways to swap one disk out oat a time, etc., but the idea is that it’s painful and not free.)
• Video containers are way better and more compatible now. Originally it was nigh unto impossible to get actual surround sound out of a compressed video in an MKV or MP4 container. I say “nigh unto” because some people had figured out this magic incantation and had it working, but finding the right spells to make it happen was far less straightforward than you might think. I tried for a long time to no avail. Plus, compatibility in general was not great – one device would play MP4 but not MKV; one device wouldn’t play any of them; one device would only play MP4 but only certain bit-rates of audio. It was horrible. Now pretty much everything plays MP4 and DLNA servers stream it nicely.
• Compression is way better. Handbrake has changed a lot since I originally looked and the filters it uses are way better. You don’t notice the difference in a converted movie the way you once did, and it’s way easier to get “the right” settings for things.

What really got me thinking about it was this Slashdot article talking about how a person lost 20TB of data because it’s basically impossible to back all that up at home. I don’t have 20TB of data, but I have 5TB and my NAS is close to 80% full. I don’t have much room to continue just adding movies and, as noted, disk space isn’t free. It got me thinking about looking at video formats again.

I ended up switching to:

• Handbrake’s “High Profile” preset modified with…
• The primary audio channel updated from 160kbps to 256kbps
• The “x264 Preset” set to “Slower”
• Based on the content type, choose an “x264 Tune” of “Film,” “Animation,” or “Grain.”

These settings yield results that are visually comparable to the original DVD source; and include both stereo mixdown (for iPads and mobile devices that don’t support surround) and surround sound passthrough audio (for media servers and players that support surround).

I chose the higher quality sound because my primary use case is still high-fidelity home theater speakers and while I don’t need lossless audio, I wanted really good quality, too. It didn’t seem to affect the file size in any significant way.

I chose the “slower” x264 preset because I could tell in some areas the difference between “medium” (the default) and the slower settings, but from a time-to-encode perspective, “slow” and “slower” yielded about the same amount of time. I tried “very slow” but it nearly doubled the amount of encode time (not feasible for hundreds of discs).

The file size is roughly 25% – 50% of the original source content, so for a 4GB DVD I see about 1.5GB – 2.0GB compressed movies; for an 8GB DVD I see 2.0 – 3.5GB compressed movies. This is great from a space perspective because it means I can put off expanding my RAID array for a while longer.

On my current (not great) computers, I can encode a two hour movie in about 8 – 10 hours. Thank goodness for the queue feature in Handbrake, I can just queue up a ton of movies and let it run around the clock. I have a couple of computers going all the time now. Of course, with the number of discs I have to go through, it’s still going to be a couple of months.

This has opened a lot of new doors from a compatibility standpoint at home. My Synology NAS comes with a DLNA server that streams these perfectly to any device at home, so I can watch from my phone or tablet. The XBMC media center plays them beautifully and gets the full surround sound. I can put these on the iPad and take them traveling with us. I don’t have the full backup anymore… but for the cost/benefit on that, I may as well just re-purchase discs that go bad if I have to.

Some documents that helped me determine this new format:

The Handbrake Guide, particularly

• The discussion on video container options
• The x264 preset/tune/profile page
• The guide to surround sound

This amazingly well done “best settings” guide for Handbrake 0.9.9

A comparison of the x264 “RF” settings in Handbrake

If you’re interested in the rest of my media center solution, check out the main article.

Looking at the list of media center posts I’ve got and the updates/changes over time just to the main article, I’m thinking I may need to switch to storing this in a wiki. The world of media center stuff changes too frequently to keep the articles all updated. It’s just getting confusing.

Over the last six months, give or take, I’ve noticed that my Netflix streaming performance over my Comcast internet has taken a dive.

If I stream a show during the day, I can get a full 1080P HD signal. Watching through my PS3, I get Super HD. It’s awesome.

However, watching that same show once it hits “prime time” – between, say, 7:30p and 10:30p – I get a maximum of 480SD.

I saw this article that went around about a fellow who caught Verizon supposedly doing some traffic shaping around Amazon Web Services and it got me wondering if Comcast was doing the same thing.

I called Comcast support and got the expected runaround. The internet people sent me to the TV people (because you watch Netflix on your TV?!); the TV people sent me to the home network support people (because no way is it a Comcast issue), then the home network people said they would transfer me to their dedicated Netflix support team…

…which transferred me to actual Netflix support. No affiliation with Comcast at all.

Netflix support ran me through the usual network troubleshooting steps, which I’d already done and basically amounts to “reboot everything and use a wired connection,” all of which I’d already done, and then we ended up with “call your ISP.” That’s how I got here in the first place. Sigh.

I reached out this time to @comcastcares on Twitter and had a much better result. I got in touch with a very helpful person, @comcastcamille, who did a few diagnostics on their end and then got me in touch with their “executive support” department.

The executive support department sent a tech to my house who replaced my aging cable modem. That actually improved my speed tests – I used to only occasionally make it to ~25Mbps down, but with the new modem I consistently get between 25Mbps and 30Mbps. Unfortunately, that didn’t fix the Netflix issue, so I called back.

This time I got ahold of a network tech named Miguel who not only spoke very clearly but also knew what he was talking about. A rare find in tech support.

First we did a speed test on two different sites. My results:

• speedtest.comcast.net: 10ms ping, 28.52Mbps down, 5.95Mbps up
• www.speedtest.net: 0ms ping, 28.67Mbps down, 5.90Mbps up

Looking good. On that same computer, I then tried streaming Netflix. 480SD. Lame.

Then he mentioned something I didn’t consider: Amazon Prime is also backed by AWS. Same computer, streamed an Amazon Prime video… full HD in less than three seconds buffering.

For giggles, we tried streaming Netflix and running the speed test at the same time and got similar results as the first speed test. I also ran the Net Neutrality speed test and got great results.

Of course, as mentioned on the Net Neutrality test site, much of the Netflix traffic doesn’t actually flow from AWS, but through Open Connect peering agreements. Ars Technica has a nice article about how several providers are having trouble keeping up with Netflix and it may not necessarily be intentional traffic shaping so much as sheer volume.

In the end, Miguel convinced me that it may not be entirely a Comcast problem. He also mentioned that he, himself, switched from Netflix to Amazon Prime because the quality is so much better. Something to consider.

Of course, Google Fiber is now looking at Portland, so that may be a good alternative.

For the record, I’ve never really had any problems with Comcast the way many people have. I admit I am possibly an exception. Other than the phone runaround, which you often get with any type of service provider, Comcast service has been reliable and good for me. Netflix aside, the TV works, the phone works, the internet is getting good speed and is always up… I can’t complain. (Well, the prices do continue to go up, which sucks, but that’s only peripherally related to the service quality discussion.) We tried Frontier, the primary local competitor, and I had the experiences with Frontier that other people seem to report with Comcast. Frontier (when I was with them) had outages constantly, pretty much refused to help… and actually did things that required me to reset my router periodically and fully reconfigure the network.

But, you know, Google Fiber…

Let me say up front, I’m no TFS guru. I’m sure there’s something simple I’m probably overlooking. I just feel like this was far more complicated than it had to be so I can’t get over the idea I’m missing a simple switch flip here.

Anyway.

We have a bunch of TFS 2012 build agents. They all have VS 2012 installed and they build VS 2012 solutions really well. But we’d like to start working in VS 2013, using VS 2013 tools, so I undertook the adventure of figuring this out.

I thought just installing Visual Studio 2013 on the build agent would be enough, but… not so.

I’m guessing most folks haven’t run into trouble with this, or maybe they have the option of upgrading to TFS 2013 and they bypass the issue entirely. The first sign of trouble I ran into was our custom FxCop rules: they were built against VS 2012 (FxCop 11.0) assemblies, so if you run the build in VS 2012 it works great, but in VS 2013 there are assembly binding problems when it loads up the custom rules. It went downhill from there.

I’ll skip to the end so you don’t have to follow me on this journey. Suffice to say, it was a long day.

Here’s what I had to do to get a TFS 2012 build agent running with a full VS 2013 stack – no falling back to VS 2012 tools:

On the build agent…

1. Install Visual Studio 2013.
2. Update the build agent configuration to have a tag “vs2013” – you need a tag so you can target your build configurations to agents that support the new requirements.

In your project/solution…

1. Update all of your .csproj and MSBuild scripts to specify ToolsVersion="12.0" at the top in the <Project> element. In VS 2012 this used to be ToolsVersion="4.0" so you might be able to search for that.
2. Update any path references in your scripts, project files, custom FxCop ruleset definitions, etc., to point to the VS 2013 install location. That is, switch from C:\Program Files (x86)\Microsoft Visual Studio 11.0\... to C:\Program Files (x86)\Microsoft Visual Studio 12.0\...; or from VS110COMNTOOLS to VS120COMNTOOLS.
3. If you’re using NuGet and have package restore enabled, make sure you have the latest NuGet.targets file. You can get that by setting up a new project really quickly and just enabling package restore on that, then stealing the NuGet.targets. You may need to tweak the ToolsVersion at the top.
4. Update your project’s TFS build configuration so…
   • It requires a build agent with the “vs2013” flag.
   • In the “MSBuild Arguments” setting, pass /p:VisualStudioVersion=12.0 so it knows to use the latest tools.

Once you’ve done all that, the build should run with all VS 2013 tools. You can verify it by turning logging up to diagnostic levels, then opening the final MSBuild log and searching for “11.0” – if you find that there are any paths or anything set to the VS 2012 install location, you’ll know you missed a reference. You will still probably see the VS110COMNTOOLS environment variable, but it won’t be getting used anywhere.

Yesterday we moved Autofac over to GitHub.

I’m cool with that. There’s a lot of momentum behind Git and GitHub in the source control community and I understand that. Nick Blumhardt’s post on the Autofac forum and the linked Eric Raymond post in the Emacs developer list hit close to home for me – I wish Mercurial had “won,” but Git’s fine, too. I don’t feel super strongly about it.*

In moving, we got a lot of really nice and supportive tweets and posts and it’s been a nice welcoming party. That’s cool.

Then there have been some puzzling ones, though, and here’s where I switch out of my “Autofac project coordinator person” hat and into my “I’m just a dev” hat:

Again, I’m not picking on these folks personally, because I respect them and their skills. I’ve seen a few of these and I know (hope?) they won’t take it personally that I grabbed theirs out of the bunch. What I want to address is more my puzzlement around the sentiment I see here:

Why is source control, or a particular source control system, such a barrier?

In a world where the polyglot programmer is becoming more the norm than the exception; where it’s pretty common that a single developer can work in more than one environment, on more than one OS, and/or in more than one language… I have a difficult time understanding why version control systems don’t also fit into that bucket.

I get that folks might have a personal preference. I’m a Sublime Text guy, not Notepad++. I’m a CodeRush guy, not ReSharper. That’s not to say I can’t use those other tools, just that I have a preference and I’m more productive when using my preference.

When I see something like “It’s been fun to get in the codebase and look around,” though, and the [implied] reason that was somehow possible now when it wasn’t before is because of a switch from Mercurial/Google Code to Git/GitHub?

That doesn’t make sense to me.

When I see a project that sparks my interest and makes me think I could make use of it, I don’t really care what version control system they use.** There’s a bit of a “when in Rome” for me there. I mean, honestly, once I pull the NuGet package (or gem, or whatever) down and start using it, and I go to their site to learn more… I don’t really lose interest if they’re hosting their source in some source control system or with a host I don’t prefer. I don’t know of an open source site that doesn’t let you browse the source through a web interface anymore, so even if I wanted to dig into the code a little, it’s not like I have to install any new tools. The “issues” systems on most open source hosting sites are roughly the same, too, so there’s no trouble if I want to file a defect or enhancement request.

Sure, there are some things about GitHub that make certain aspects of open source easier, but it’s primarily around contribution. I concede that pull requests are nice – I’ve made a few, and I’ve taken a few.*** That said, there are some well established conventions around things like patch files (remember those, kids?) that have worked for a long time.

Having a different mechanism of contribution has also never really stopped me. Have you let it stop you? Why?

I guess I look at these other systems more as an opportunity to learn than as a barrier. Just like I have to learn about your coding conventions in your project, your project’s style, the right way to fix the issue I found (or add the enhancement) before I can contribute, the version control may be one of those things, too. It’s not really that big of a deal, especially considering there’s really only Mercurial, Git, and Subversion out there in the open source world and you’ve covered the 99% case.

Don’t get me wrong. I think removing friction is great. Making easy jobs easy and hard jobs possible is awesome. GitHub has been great at that, and I applaud them for it. I just don’t think folks should let source control be a barrier. Add the skills to your portfolio. Sharpen the saw. Have a preference, but don’t let it shackle you.

---

* All that said, I can’t remember a time when I had more trouble with trivial crap like line endings with any source control system other than Git. And until fairly recently, setting up a decent, working Git environment in Windows (where I spend most of my time) wasn’t as straightforward as all that. Obviously my experiences may differ from yours.

** Except TFS version control. Anything beyond even the simplest operations is a ridiculous pain. “Workspaces?” Really? Still? It’s VSS with “big boy” pants.

*** And, as we all know, pull requests aren’t Git, they’re GitHub (or the host) because they’re workflow items, not source control specific. BitBucket has pull requests for Mercurial.