[u-u] Electronic signage...

[Colin McGregor]

Just want to note my thanks for this. This filled in a number of
important gaps in my knowledge.

Again thanks.


Colin.


On Wed, Jul 13, 2016 at 11:33 AM, Dan Astoorian <djast at ecf.utoronto.ca> wrote:
> On Wed, 13 Jul 2016 09:37:49 EDT, Colin McGregor writes:
>>
>> The first part of displaying the above is easy enough, a browser the
>> like of Chromium set up in kiosk mode. The code behind the above
>> above, well... Javascript seems to assume a single thread / single
>> task, a problem when you could have all of the above bits of
>> information needing to (seem to) update simultaneously (yes, the
>> events list might only change once a week, sunset time will only
>> change once per day and weather forecast will only change a few times
>> per day, but worst case they will all need to (appear to) change at
>> the same time). AJAX appears to be a possible part of the solution,
>> but... Is there an easier way?
>
> We use Raspberry Pis for our signage.
>
> Some context: we drive the content from the server side.  When the Pis
> boot (and once a day in the early morning, as well as on demand), they
> fetch their HTML layout from a hard-coded URL on the server and save it
> to disk (if the URL is unavailable, it uses the previously-fetched
> copy), and points the browser at file:///home/pi/signage.html.  Storing
> the file locally has two main advantages: it caches it in case the
> server is unavailable when the browser is restarted, and it sidesteps
> certain possible browser security restrictions (e.g., mixed active
> content restrictions, where the browser won't allow a page fetched via
> HTTPS to load a frame via HTTP).
>
> We use frames (via <IFRAME> tags) to break the display into panes.  One
> pane links to a slideshow (for which I was not involved in developing),
> which uses AJAX to try to refresh its content periodically, but not drop
> the slides it's already showing if the server isn't available.  The
> other panes are simply set to refresh every few minutes (and I
> customized the generic webkit "could not load page" layout with a
> friendlier message).  The javascript in each frame is independent, so
> this is a fairly simple solution to your threading question.
>
> For your application, I'd probably set up IFRAMEs with file:/// URLs
> that reload (via META refresh tags or javascript) at appropriate
> intervals, and use cron jobs to fetch the data (or generate it, for the
> values that are calculated).
>
> I haven't tried using Chromium for the web browser.  My original
> implementation used Midori, but it was compiled against Webkit 1.0, so
> it didn't use the GPU's hardware acceleration features, so I switched to
> Epiphany, which uses Webkit 3.  That gave me smoother slide transitions,
> but it crashed an average of a couple of times a day (I used a watchdog
> wrapper script to restart it when it crashed).  I currently use kweb3
> 1.6.9-1 (see https://www.raspberrypi.org/forums/viewtopic.php?t=40860
> for a description of the latest version), which is very lightweight and
> has been extremely reliable--I haven't seen any crashes at all (although
> I preemptively kill and restart the browser daily to make sure it
> doesn't accumulate cruft).
>
> Let me know if you'd like to borrow the javascript I use to shift the
> image around slightly to mitigate burn-in.
>
> If you want to try kweb3, this may save you some time: the invocation I
> use is
>     kweb3 -JKYFr file:///home/pi/signage.html
>
> where -J enables Javascript, -K enables Kiosk Mode, -Y disables video
> and audio (which would be played with an external player), -F enables
> experimental webkit features (I don't remember why I included that
> option), and -r enables reloading via Alt-R (so that the browser can be
> reloaded programmatically via
>     xte 'keydown Alt_L' 'key r' 'keyup Alt_L'
> ).
>
> Regards,
>
> --
> Dan Astoorian, Systems Administrator
> Engineering Computing Facility
> University of Toronto