Chromecast - This is why we can't have nice things

Thu 11 September 2014 by Fred Clift

There was a recent chromecast firmware update from google. This wasn't the long awaited new functionality promised at IO. It ostensibly has better tab-casting performance and some bug fixes (e.g. change in some apis related to subtitles, among others).

There has been some speculation that the reason for the update, without the promised "Summer 2014" new functionality was to address a recent announcement by some smart guys on XDA about a new method of rooting the device - the so-called HubCap Root Release.

One other unmentioned change, which affects me, was the change to how Chrome Remote Debugging works on the device.

It used to be that the remote developer port was open 24x7 on devices in development mode. Now, it appears that the ONLY time a device has the developer port available and open is when running a dev app that you have registered in the developer console. When the app ends, the connection is closed. I presume that there is some firewall-rule magic going on - that the port is only opened after your dev app has successfully launched.

This makes my Display Whatever You Want trick useless. Yes, it still works, but ONLY when you have already launched some app you have control of. I feel like going off on a long rant about the folks at Google breaking my toys and restating the title of this post. But... I want to try to give them the benefit of the doubt.

I'm pretty sure that they didn't rush out a new firmware update just to spite me. They must have had this change in the works for quite a while now.

My current operating theory is that having the remote-debugging stuff available all the time was a security issue for them. Specifically, they have content providers (think "big media streaming companies"), that use DRM - I would guess that having debug access to the receiver app would make it much easier to reverse-engineer and circumvent content protections. DRM is probably a necessary evil, placating content providers, while only keeping honest people honest.

I had a simple automatically starting slideshow program that no longer works. But, I can work around it.

Using my native-api POC from last post, I have been able to launch my app, which only needed slight tweaks to be considered a "real" receiver app.

Here is simplified html similar to what I did before the remote-debugging port was restricted.

<html> <head> <title>castphotosaver</title>
        <script>
            function new_img() {
                var i = document.getElementById('slide');
                i.src='/img?'+Math.random();
            }
        </script> </head>
<style type="text/css">
img { display: block; margin-left: auto; margin-right: auto; max-width: 100%; max-height: 100%; }
</style>

<body>
<img id='slide' src="/img">
</body></html>

I feed it images from a little webservice - each hit on /img gives the next photo. I add the query parameter as a (lame) way of keeping the browser from caching and not reloading the image.

The bare minimum to turn this into a receiver that the cast device will like is this:

<html> <head> <title>castphotosaver</title>
        <script type="text/javascript"
                src="//www.gstatic.com/cast/sdk/libs/receiver/2.0.0/cast_receiver.js">
        </script>
        <script>
            function new_img() {
                var i = document.getElementById('slide');
                i.src='/img?'+Math.random();
            }
        </script> </head>
<style type="text/css">
img { display: block; margin-left: auto; margin-right: auto; max-width: 100%; max-height: 100%; }
</style>
<body>
<img id='slide' src="/img">
<script type="text/javascript">
  window.onload = function() {
    window.castReceiverManager = cast.receiver.CastReceiverManager.getInstance();
    //castReceiverManager.start({maxInactivity: 60});
    castReceiverManager.start();
    setInterval('new_img();',3000);
  };
</script>
</body></html>

All you have to add is code to load the receiver library and instantiate and start a 'CastReceiverManager'. As a side note you can control the PING/PONG frequency for connected senders with that commented out maxInactivity parameter...

The sender code to launch this is left as an exercise to the reader. In reality I never wrote a sender. I used my python-native-api proof-of-concept to load the app.

I fully expect a new update to break this in the future.

In retrospect, I think that perhaps it would have been better if Google had NOT restricted when the debugger port was available on debug devices, but rather restricted the debug device to only run your own registered apps. At least it would make my life easier.

This is why we can't have nice things.

Chromecast - steps closer to a python native api

Fri 05 September 2014 by Fred Clift

So, after seeing this: https://gist.github.com/TheCrazyT/11263599 I got more interested in being able to speak the native chromecast api from python.

That lead me to this presentation by Sebastian Mauer: http://www.slideshare.net/mauimauer/chrome-cast-and-android-tv-add14 especially slide 20, which lead to a bit more google ...

Chromecast - Displaying arbitrary URLs using pychromecast

Mon 25 August 2014 by Fred Clift

Continuing on with my Chromecast experiments... I have been playing with a python library on github by Paulus Schoutsen called pychromecast. At various points in it's life it has been able to interact with Chromecast devices to do a variety of things. With the official SDK release and firmware ...

Chromecast - both cool and frustrating

Thu 21 August 2014 by Fred Clift

I recently purchased a Chromecast device. For the price it's a great media streamer. You can control it from your Android or IOS smartphone from many different apps. For chrome browser, you need to install a browser plugin. There are many websites that, when viewed in Chrome browser give ...