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 ...

read more

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 ...

read more

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 ...

read more

Notes on chrome remote debugging

Thu 07 August 2014 by Fred Clift

These are mostly notes for me, but you might find them useful also.

On my laptop, I run chrome and usually have many, many tabs open across a few windows. Google searching for me usually ends up with me open-in-new-tabbing the first 5 or 10 links concurrently... It bugs me ...

read more

Managing Lots Of Pregenerated HTML And Other Files With Pelican

Sat 14 June 2014 by Fred Clift

For one of the Pelican-managed websites I maintain, I have a lot of files that I don't really want to manage with Pelican, and in some cases, I can't easily, without lots of gymnastics.

In this case, I have about 30k html files that are a dump of ...

read more

Embedding PHP in Pelican-generated Static pages

Tue 10 June 2014 by Fred Clift

So, I wanted to make a simple website with pelican. But I had a little legacy php code that I still wanted to function.

It sure would be nice, I thought, if I could take my php app and with only small tweaks make it work as PART of pelican ...

read more

Trying out Pelican static site generator.

Tue 10 June 2014 by Fred Clift

TLDR


I'm running a couple of websites with pelican static website generator because it's easy to maintain, and lightweight, and kind of futurer-proof.

History


So I've tried a bunch of tools over the years to make personal web pages. I hand-rolled html (for a class) in the ...

read more