This weekend provided me with quite a bit of a surprise challenge. While I was able to solve the problem, eventually, the entire process and the circumstances surrounding it revealed some serious issues with Linux.
In order to protect my client, I’m not going to directly reference their name.
In order to properly understand the situation, we need to go back in time quite a ways. The middle of last year I believe. The client purchased a new Samsung laptop that had come with Windows 8 on it. However they were having this really strange issue where the network stack was arbitrarily having issues loading site content and it wasn’t playing nice with the optical drive. They had an OBF with the optical drive, replaced it and still had the same issue. After fighting with this thing for some time and thinking we had it fixed and then it would just puke again, I finally suggested to them that we install Linux on there to see how it would go. This client had seen me using Linux before and wasn’t ever entirely opposed to the idea of using it rather they never had any serious motivation to do so until now. So they agreed and I installed Ubuntu 13.04 LTS on it.
Because all they really needed was an internet outlet, media outlet and a word processor, this fit the bill perfectly. They didn’t play games or anything like that. The optical drive was working really well and the networking stack wasn’t having the same issues that it was when Windows 8 was installed.
However a new challenge crept up in the form of the demand of “I want to watch Netflix and Amazon VOD”. Great. Two of the worst DRM-based streaming services that don’t play nicely with native Linux at all. Now it’s actually not too inconceivable to have either of these services working on your Linux machine; if you’re willing to hack at it that is. You’ll also have to accept the fact that the streaming isn’t going to be as fluid as it would be on a device that has a Netflix app on it (which is basically everything but a native Linux computer for some unknown reason).
The challenge here is that both Amazon and Netflix use Microsoft Silverlight for streaming. The reason is purely DRM. Silverlight has a nice API that’s cozy to content providers that want/need to lock their content down. There are other tools that do this but Silverlight is the one they went with. Amazon, now, is a little more flexible as I found out because with a little trickery, more specifically using a User Agent Switcher, you can get it to use Flash instead of Silverlight which makes most of the problem go away as Flash has traditionally worked nicely under Linux. The UAS is critical to getting Netflix to work under Linux because if you don’t send the right UA, Netflix will just puke every time.
Linux has several Silverlight alternatives but most of them are very fringe. A project that was popular not too long ago was Moonlight but that doesn’t seem to have had much traction lately. The one that’s getting the most attention right now is Pipelight. This project was originally featured back on WebUpd8 and that article pointed to two PPAs. So I add the PPAs and installed the appropriate software from there along with a UAS extension into Chrome. I tried it myself, got it working and showed them how to do it. Easy as pie.
Time went on and this client had moved out of my immediate consultation area. They contacted me again this past weekend stating that they could no longer watch Netflix or Amazon and that they had reset their router and thought that might have something to do with it. Now unless they really goofed something up with the router, I doubt that would’ve been causing it. It had been some time since I’d messed with Pipelight or anything so I took to doing some research. It turns out that Pipelight had some substantial updates but more importantly, the PPAs that were in use originally had been consolidated into one which was not in use on their system. So the solution here is quite simple: remove the software, remove the PPAs, add the new PPA, install the software again and enable the necessary plugins one at a time testing functionality as you go.
Originally I’d tried to diagnose with the client over email but 60 messages later, it was becoming apparent that this wasn’t working. So she brought up the idea of remote assistance. That’s great but remote assistance doesn’t practically work in Linux like it does in Windows. My preferred method of choice, VNC, is not installed by default on most Linux distributions. Not to mention that the server component would have to be installed on their machine in order for me to connect. Services like Join.Me and LogMeIn are out of the question. She wasn’t at all familiar with what it actually took to establish remote access to her computer so I was really in a bind here. And in a bad way too as almost nothing at my disposal was going to work.
Then I stumbled across the Chrome Remote Desktop extension/plugin for Google Chrome. As it sounds, this provides you the ability to have remote access to a person’s computer who’s also running the CRD. The principal is quite simple: one person generates a code for a remote session, sends that code to the person who wants to connect remotely, and that person joins the session using the code and they’re in. Sounds great, right? Well had it not been for teenie little problem of CRD only keeping a connection for anywhere from thirty seconds to eleven minutes at a time, it wouldn’t have been that bad. I could not get any work done on their computer and had to ask them several times to regenerate a code so I could get VNC server installed. And it wasn’t just me either. A quick search showed that this is a problem across the board and I can’t find a damn thing from Google about what’s going on with this thing.
So after I managed to get VNC installed, I remoted in that way and boy did it feel good to have a solid connection. I was finally able to do what I needed to do to get Pipelight working again.
In total, the problems with the remote access added an additional two hours of work time to what would have taken maybe an hour at worst.