Cloud down, so sign down (Updated)

error403

Bryan Mongeau, the Vice President of Technology at BroadSign, and a guy who pays a lot of attention to emerging tech, sent along this photo he strayed across online of an ad campaign running on a Times Square LED ad board:

Says Bryan:

This error is coming from the Azure cloud service, which means someone thought it was a good idea to serve up this sign’s content live from the cloud.  Cloud down = sign down.

HTML5 apps are nice and snazzy, but in signage, you must never, never, never (repeat: never) load assets directly from the network. You must always load them from disk and periodically synchronize what you have on disk with what you can fetch over the network.  This is intro to signage 101 basic stuff.

Which is why I’m amazed at the shortsightedness of Google’s recent ChromeOS push and other entry-level pure browser solutions that consider a web browser as sufficient to be a digital signage player.  There are just so many things that in order to do right, you need to escape the browser’s security model.  For example, for direct access to the local filesystem. ChromeOS does not have proper filesystem access.

HTML5 is a type of dynamic content, not the player itself.

Chris Lydle, from Google’s U.S. digital signage team, counters:

Unfortunately, Mr. Mongeau’s comments are inaccurate and the article should be updated to reflect that.

ChromeOS is not dependent on network connectivity and it does provide offline access to the host file system (as well as USB, Bluetooth and attached human interface devices).

There are a number of CMS solutions that provide this functionality and there are more on the way. For example, Stratos Media (stratosmedia.com) provides a free trial for any who want to see this functionality first-hand.

Dave Haynes

Dave Haynes

Editor/Founder at Sixteen:Nine
Dave Haynes is the founder and editor of Sixteen:Nine, an online publication that has followed the digital signage industry for more than a decade. Dave does strategic advisory consulting work for many end-users and vendors, and also writes for many of them. He's based near Toronto.
Dave Haynes

@sixteennine

Decade-old blog about digital signage and related tech, written by industry consultant and shit-disturber Dave Haynes.
Australian Digital OOH Medical Network Rolls Up Competitors https://t.co/w3bF77LFa5 https://t.co/g0QJ2cQDmu - 10 hours ago
Dave Haynes

9 Comments

  • Jeremy Gavin says:

    Downloading content to the drive for playback SHOULD be Digital Signage 101 but sadly as it relates to HTML as a content type, the digital signage software community as a whole has not implemented download-and-cache. As content providers using HTML we’d love to hear from software providers who have delivered a great solution on this… more importantly our customers would love to hear from you!

  • Chris Lydle says:

    Unfortunately, Mr. Mongeau’s comments are inaccurate and the article should be updated to reflect that.

    ChromeOS is not dependent on network connectivity and it does provide offline access to the host file system (as well as USB, Bluetooth and attached human interface devices).

    There are a number of CMS solutions that provide this functionality and there are more on the way. For example, Stratos Media (stratosmedia.com) provides a free trial for any who want to see this functionality first hand.

    • Dave Haynes says:

      That’s the great thing about comments. It enables points and counterpoints. My suspicion is this not an entirely simple, yes or no thing.

  • Jim Nista says:

    One thing I commonly ask when people ask the question “what happens when the internet goes down?” is what type of systems they are running to prevent and accommodate power failures. My point being, why do we only target this one failure point? Are we over-worrying about a generally rare problem and in the process limiting the capabilities of signage to locally stored slide shows and videos.

    Some data wants to be live, and for that there are some risks. The better CMS systems load locally stored backup content in the case of network failure and some use deep caching of HTML.

    Instead of saying “never” because of something that may happen very rarely… we should look at ways of improving the networking and HTML caching.

    This allows developers and creatives to build advanced solutions that directly communicate with the cloud providing live content.

  • Chris is correct and Bryan is wrong. So wrong in fact I wonder if he’s even actually looked at the Chrome solution.

    Offline is fully supported and anyone who would like to try can sign up for a trial at http://chrome.signagelive.com/

    • Dave Haynes says:

      Bryan would have to answer that, but his background note to me suggested he and his team have drilled down pretty deep on the technical issues around caching and web-based environments.

      dh

  • Chris Pelzar says:

    The 403 error was returned from the Content Server Provider as the content that was supposed to be played was from a URL hosted on the server and obviously the server was down feeding the system.

    If you cached, at some point your cache would show the same 403 error graphic from the Content Providers server.

    If the internet is down, the system can point to alternative local content and some systems can detect if the internet connection is not functioning and make the switch, but in this instance even with the internet up and working, if the source feeding it is not working, you would see the 403 error, so the internet connection is not your problem.

    That being said, the infrastructure in Times Square is a challenge but this error was not a result of that.

    The best practice is to have your data enabled graphics content locally stored and have a data stream that feeds it and makes things update and change. If for any reason there is no update, the screen just stays where it was until the updates from the Content Server begin to come through again. No one would notice..

Comments are closed.