What happens when internet lines/access is down?

[Richard Woon]

Hi,

I am thinking of testing out Concerto for a 50 screen pilot digital
signage project and was wondering.
If one of the sites loses internet access connectivity thus not able
to reach the Concerto server, what will be displayed on the screen?

I understand that no updates/changes will be on screen till the line
comes back up, but will the screen still display the previous content?

So far I have tested Xibo, but I find this to be very client resource
intensive plus it needs windows on the client display machines, which
is which is why I have decided to switch to Concerto now that you have
video support.

Rgds,
Richard Woon

[Brian Michalski]

You're understanding seems correct, when the internet lines go down the screen stops updating. The current content just sits on the screen until the connection is restored.  When the connection is back, the screen resumes rotating content as normal.

~Brian

--
You received this message because you are subscribed to the Google Groups "Concerto Digital Signage" group.
To post to this group, send email to concerto-dig...@googlegroups.com.
To unsubscribe from this group, send email to concerto-digital-s...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/concerto-digital-signage?hl=en.

[Andrew Armenia]

There's one additional caveat: some Concerto player configurations reboot periodically to flush Firefox caches etc. If that happens, the screen will show a Firefox "cannot load page" message. If this is a concern, I'd recommend disabling that behavior (i.e. make sure "schedule.pl" is removed from /etc/tasks or suitably modified.) It might also be possible to use a caching proxy like Squid to cache some content on the client side. (Brian - would this work?) It wouldn't even be necessary to run a second box for the proxy - the necessary software could be embedded in the clients themselves.

-Andrew

[Brian Michalski]

Squid could probably provide serve the content while being offline, but I'm not sure how well it would answer the request to figure out what image to serve (i.e getting image_27.jpg is easy, knowing we should fetch #27 is a bit more difficult).  HTML5 may be the best solution for a fully-featured offline Concerto instance but that is probably a few months out at the moment.

~Brian M

[Richard Woon]

Thanks for the feedback guys, I guess for now my best option would be
to remove/modify /etc/tasks/schedule.pl right?
What would be the downside of not flushing Firefox cache?

Would be it possible (using Squid) to call a specific default page
i.e. offline.html page if/when the lines go down?

-Richard W

Brian,
How would HTML5 work for this to happen?

On Dec 14, 1:39 am, Brian Michalski <bmichal...@gmail.com> wrote:
> Squid could probably provide serve the content while being offline, but I'm
> not sure how well it would answer the request to figure out what image to
> serve (i.e getting image_27.jpg is easy, knowing we should fetch #27 is a
> bit more difficult).  HTML5 may be the best solution for a fully-featured
> offline Concerto instance but that is probably a few months out at the
> moment.
>
> ~Brian M
>
> On Mon, Dec 13, 2010 at 12:08 PM, Andrew Armenia <and...@asquaredlabs.com>wrote:
>
>
>
> > There's one additional caveat: some Concerto player configurations reboot
> > periodically to flush Firefox caches etc. If that happens, the screen will
> > show a Firefox "cannot load page" message. If this is a concern, I'd
> > recommend disabling that behavior (i.e. make sure "schedule.pl" is removed
> > from /etc/tasks or suitably modified.) It might also be possible to use a
> > caching proxy like Squid to cache some content on the client side. (Brian -
> > would this work?) It wouldn't even be necessary to run a second box for the
> > proxy - the necessary software could be embedded in the clients themselves.
>
> > -Andrew
>

> > On Mon, Dec 13, 2010 at 11:56 AM, Brian Michalski <bmichal...@gmail.com>wrote:
>
> >> You're understanding seems correct, when the internet lines go down the
> >> screen stops updating. The current content just sits on the screen until the
> >> connection is restored.  When the connection is back, the screen resumes
> >> rotating content as normal.
>
> >> ~Brian
>

> >> On Mon, Dec 13, 2010 at 3:47 AM, Richard Woon <richw...@gmail.com> wrote:
>
> >>> Hi,
>
> >>> I am thinking of testing out Concerto for a 50 screen pilot digital
> >>> signage project and was wondering.
> >>> If one of the sites loses internet access connectivity thus not able
> >>> to reach the Concerto server, what will be displayed on the screen?
>
> >>> I understand that no updates/changes will be on screen till the line
> >>> comes back up, but will the screen still display the previous content?
>
> >>> So far I have tested Xibo, but I find this to be very client resource
> >>> intensive plus it needs windows on the client display machines, which
> >>> is which is why I have decided to switch to Concerto now that you have
> >>> video support.
>
> >>> Rgds,
> >>> Richard Woon
>
> >>> --
> >>> You received this message because you are subscribed to the Google Groups
> >>> "Concerto Digital Signage" group.
> >>> To post to this group, send email to
> >>> concerto-dig...@googlegroups.com.
> >>> To unsubscribe from this group, send email to

> >>> concerto-digital-s...@googlegroups.com<concerto-digital-sign age%2Bunsu...@googlegroups.com>
> >>> .

> >>> For more options, visit this group at
> >>>http://groups.google.com/group/concerto-digital-signage?hl=en.
>
> >>  --
> >> You received this message because you are subscribed to the Google Groups
> >> "Concerto Digital Signage" group.
> >> To post to this group, send email to
> >> concerto-dig...@googlegroups.com.
> >> To unsubscribe from this group, send email to

> >> concerto-digital-s...@googlegroups.com<concerto-digital-sign age%2Bunsu...@googlegroups.com>
> >> .

> >> For more options, visit this group at
> >>http://groups.google.com/group/concerto-digital-signage?hl=en.
>
> >  --
> > You received this message because you are subscribed to the Google Groups
> > "Concerto Digital Signage" group.
> > To post to this group, send email to
> > concerto-dig...@googlegroups.com.
> > To unsubscribe from this group, send email to

> > concerto-digital-s...@googlegroups.com<concerto-digital-sign age%2Bunsu...@googlegroups.com>
> > .

[Brian Michalski]

The downside of not clearing the Firefox cache as often is that your system may start to hang or lag after a while, Firefox isn't exactly known for being efficient in it's memory usage.

I haven't though enough about the specifics of Squid or HTML 5 to present any great implementation ideas, but it's on the list of things to think about when I get a chance.

~Brian M

To unsubscribe from this group, send email to concerto-digital-s...@googlegroups.com.

[Vincent V.]

Hi Brian,

I'm also evaluating Concerto for a digital signage solution. I hosted the system on their current hosting provider (which they liked), and they also liked the interface and approval process. 

But my client is also concerned that when the network goes down, the screen "freezes" (until the flush happens and then there is nothing).

Is some kind of client-side caching or syncing planned soon? 

We are looking to use a Logitech Revue or Apple TV (new version) as the player, but if we have to go to a Linux mini-system (Dual-core atom or such), we would be open to that, too.

Thanks,

Vincent

[Brian Michalski]

Hi Vincent,

You're right, when the network dies Concerto should pause and then resume again when the network comes back online.  This is a known limitation of V1 where we didn't implement much client side caching.  It's on our radar for V2 and I'm confident we'll have a much better way of handling network outages, continuing to rotate some content regardless of the device.

Thanks,

~Brian M

--
You received this message because you are subscribed to the Google Groups "Concerto Digital Signage" group.

To view this discussion on the web visit https://groups.google.com/d/msg/concerto-digital-signage/-/t59Kd1p9UqYJ.

[Vincent Vermeulen]

Excellent. Looking forward to seeing that. Any idea on a timeframe (3 mo, 6 mo, 1 yr ?). I may be able to stall my clients with a promise of a "future" functionality.

[Jeff Hollingsworth]

Another option is to get one more of the Foxcomm boxes (recommended for
the clients) and make that the server at the customers's site. If they
have one physical location that can work well. If the Internet
connection is down, the signs will still update. Also, depending on
what you put on the signs and their internet connection it can reduce
bandwidth needs. I assume this customer doesn't use VOIP business phone
lines, in that case you could make the argument that an Internet outage
is already a major event.

Jeff

On 4/10/2012 8:52 PM, Vincent Vermeulen wrote:
> Excellent. Looking forward to seeing that. Any idea on a timeframe (3
> mo, 6 mo, 1 yr ?). I may be able to stall my clients with a promise of a
> "future" functionality.
>
> On Tue, Apr 10, 2012 at 8:18 PM, Brian Michalski <bmich...@gmail.com
> <mailto:bmich...@gmail.com>> wrote:
>
> Hi Vincent,
> You're right, when the network dies Concerto should pause and then
> resume again when the network comes back online. This is a known
> limitation of V1 where we didn't implement much client side caching.
> It's on our radar for V2 and I'm confident we'll have a much
> better way of handling network outages, continuing to rotate some
> content regardless of the device.
>
> Thanks,
> ~Brian M
>
> On Apr 10, 2012, at 8:00 AM, "Vincent V." <sw1tc...@gmail.com

> <mailto:sw1tc...@gmail.com>> wrote:
>
>> Hi Brian,
>>
>> I'm also evaluating Concerto for a digital signage solution. I
>> hosted the system on their current hosting provider (which they
>> liked), and they also liked the interface and approval process.
>> But my client is also concerned that when the network goes down,
>> the screen "freezes" (until the flush happens and then there is
>> nothing).
>>
>> Is some kind of client-side caching or syncing planned soon?
>>
>> We are looking to use a Logitech Revue or Apple TV (new version)
>> as the player, but if we have to go to a Linux mini-system
>> (Dual-core atom or such), we would be open to that, too.
>>
>> Thanks,
>> Vincent
>>
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Concerto Digital Signage" group.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msg/concerto-digital-signage/-/t59Kd1p9UqYJ.
>> To post to this group, send email to
>> concerto-dig...@googlegroups.com

>> <mailto:concerto-dig...@googlegroups.com>.

>> To unsubscribe from this group, send email to
>> concerto-digital-s...@googlegroups.com

>> <mailto:concerto-digital-s...@googlegroups.com>.

>> For more options, visit this group at
>> http://groups.google.com/group/concerto-digital-signage?hl=en.
>
> --
> You received this message because you are subscribed to the Google
> Groups "Concerto Digital Signage" group.
> To post to this group, send email to
> concerto-dig...@googlegroups.com

> <mailto:concerto-dig...@googlegroups.com>.

> To unsubscribe from this group, send email to
> concerto-digital-s...@googlegroups.com

> <mailto:concerto-digital-signage%2Bunsu...@googlegroups.com>.

[Brian Michalski]

Piggy backing on Jeff's idea, we've actually towed with letting thick
clients (Linux boxes opposed to Android / iOS devices) run the server
software as well; essentially creating a mesh digital signage network.
It's a fairly complicated idea (we haven't pursued it too much) but
in theory you could use MySQL replication paired with rsync to mirror
a read-only Concerto installation on a client which would then show
it's screen via http://localhost instead of http://remote-server. I'm
no expert in distributed MySQL or rsync, but if completely
disconnected support is required it might not be too hard to setup.
It's unlikely you'll see this mesh signage network in V2.

As for the timeline for the other features, my short answer is yes. 3
months sounds too soon, 6 months sounds far off, and I've been saying
within the year for a long time now. We've been making substantial
progress (some blog updates to come soon) but there's still more work
to be done.

~Brian M

[Vincent Vermeulen]

That would be a nice alternative. If I was able the sync the database, would I lose the ability to monitor the stations?

Or could they check in to the main station while still pulling content locally?

Does the monitoring piece look at the screen accessing the database or web server, or is there a separate task that does that?

[Brian Michalski]

You're right, the screen status updates would be problematic.

I think it would depend a bit on the distributed MySQL setup.  Using replication, you'd only be reading from the local MySQL instance; all writes (i.e. status updates) would be performed on the central concerto server / MySQL master.  Concerto would show screens as "offline" even though they may still be reading content locally.  The writes would fail, reads would work.

Using a MySQL cluster setup (multi-master) would make this easier I think, with each client acting as it's own cluster node but I'd be concerned about the bandwidth requirements for this setup.  I'm also unsure how well cluster nodes deal with network trouble.

~Brian M

[tuure]

Hi !

I have a question connected to "offline" version of web client. I
don't know the communication protocol (concerto client <-> server) so
I thought it is better to ask first. Is it possible to imitate server
(answer to the post messages as server doing it in prescribed order )
so that even without Internet access the images will change ?

Łukasz

On 12 Kwi, 10:41, Brian Michalski <bmichal...@gmail.com> wrote:
> You're right, the screen status updates would be problematic.
>
> I think it would depend a bit on the distributed MySQL setup.  Using
> replication, you'd only be reading from the local MySQL instance; all
> writes (i.e. status updates) would be performed on the central concerto
> server / MySQL master.  Concerto would show screens as "offline" even
> though they may still be reading content locally.  The writes would fail,
> reads would work.
>
> Using a MySQL cluster setup (multi-master) would make this easier I think,
> with each client acting as it's own cluster node but I'd be concerned about
> the bandwidth requirements for this setup.  I'm also unsure how well
> cluster nodes deal with network trouble.
>
> ~Brian M
>
> On Wed, Apr 11, 2012 at 10:52 PM, Vincent Vermeulen

> <sw1tch8l...@gmail.com>wrote:

>
>
>
>
>
>
>
> > That would be a nice alternative. If I was able the sync the database,
> > would I lose the ability to monitor the stations?
> > Or could they check in to the main station while still pulling content
> > locally?
> > Does the monitoring piece look at the screen accessing the database or web
> > server, or is there a separate task that does that?
>

> > On Tue, Apr 10, 2012 at 11:50 PM, Brian Michalski <bmichal...@gmail.com>wrote:
>
> >> Piggy backing on Jeff's idea, we've actually towed with letting thick
> >> clients (Linux boxes opposed to Android / iOS devices) run the server
> >> software as well; essentially creating a mesh digital signage network.
> >>  It's a fairly complicated idea (we haven't pursued it too much) but
> >> in theory you could use MySQL replication paired with rsync to mirror
> >> a read-only Concerto installation on a client which would then show

> >> it's screen viahttp://localhostinstead ofhttp://remote-server.  I'm

> >> no expert in distributed MySQL or rsync, but if completely
> >> disconnected support is required it might not be too hard to setup.
> >> It's unlikely you'll see this mesh signage network in V2.
>
> >> As for the timeline for the other features, my short answer is yes.  3
> >> months sounds too soon, 6 months sounds far off, and I've been saying
> >> within the year for a long time now.  We've been making substantial
> >> progress (some blog updates to come soon) but there's still more work
> >> to be done.
>
> >> ~Brian M
>

> >> On 4/10/12, Jeff Hollingsworth <jeffrey.k.hollingswo...@gmail.com> wrote:
>
> >> > Another option is to get one more of the Foxcomm boxes (recommended for
> >> > the clients) and make that the server at the customers's site.  If they
> >> > have one physical location that can work well.  If the Internet
> >> > connection is down, the signs will still update.  Also, depending on
> >> > what you put on the signs and their internet connection it can reduce
> >> > bandwidth needs. I assume this customer doesn't use VOIP business phone
> >> > lines, in that case you could make the argument that an Internet outage
> >> > is already a major event.
>
> >> > Jeff
>
> >> > On 4/10/2012 8:52 PM, Vincent Vermeulen wrote:
> >> >> Excellent. Looking forward to seeing that. Any idea on a timeframe (3
> >> >> mo, 6 mo, 1 yr ?). I may be able to stall my clients with a promise of
> >> a
> >> >> "future" functionality.
>

> >> >> On Tue, Apr 10, 2012 at 8:18 PM, Brian Michalski <bmichal...@gmail.com
> >> >> <mailto:bmichal...@gmail.com>> wrote:
>
> >> >>     Hi Vincent,
> >> >>     You're right, when the network dies Concerto should pause and then
> >> >>     resume again when the network comes back online.  This is a known
> >> >>     limitation of V1 where we didn't implement much client side
> >> caching.
> >> >>       It's on our radar for V2 and I'm confident we'll have a much
> >> >>     better way of handling network outages, continuing to rotate some
> >> >>     content regardless of the device.
>
> >> >>     Thanks,
> >> >>     ~Brian M
>

> >> >>     On Apr 10, 2012, at 8:00 AM, "Vincent V." <sw1tch8l...@gmail.com

[Brian Michalski]

Hi Łukasz,

Right now there is no "offline" version of the web client.  We use HTTP to transfer everything and render if via web browsers, so you'd need to run a full HTTP server to imitate the main server in an offline environment.

Thanks,

~Brian M

[Wojciech Kulesza]

Hi Brian,
thanks for the reply.
What we're currently looking at is to minimize the required transfer between server and client (if they're located on different servers). Our clients (webbrowsers displaying screens) are installed on mini pc's that are connected to internet using UMTS(3G) connection with transfer monthly cap. This connection's cap is mostely for other users and not our screens. We've noticed that there's roughly 300bytes pulls from server each second, which makes it +700megs per month - way to much. that's why Łukasz was asking for offline functionality.
Is putting concerto servers on each of those 10 screens the only way forward for us for now (at least until this feature gets added - we saw 3-6 months is expected timeline - maybe we can help out speed things up?)

Regards,
Wojciech

~Brian M

> >> >>>     concerto-digital-signage@googlegroups.com
> >> >>>     <mailto:concerto-digital-sig...@googlegroups.com>.

> >> >>>     To unsubscribe from this group, send email to

> >> >>>     concerto-digital-signage+unsub...@googlegroups.com
> >> >>>     <mailto:concerto-digital-signage+unsubscribe@googlegroups.com>.

> >> >>>     For more options, visit this group at
> >> >>>    http://groups.google.com/group/concerto-digital-signage?hl=en.
>
> >> >>     --
> >> >>     You received this message because you are subscribed to the Google
> >> >>     Groups "Concerto Digital Signage" group.
> >> >>     To post to this group, send email to

> >> >>     concerto-digital-signage@googlegroups.com
> >> >>     <mailto:concerto-digital-sig...@googlegroups.com>.

> >> >>     To unsubscribe from this group, send email to

> >> >>     concerto-digital-signage+unsub...@googlegroups.com
> >> >>     <mailto:concerto-digital-signage%2Bunsubscribe@googlegroups.com>.

> >> >>     For more options, visit this group at
> >> >>    http://groups.google.com/group/concerto-digital-signage?hl=en.
>
> >> >> --
> >> >> You received this message because you are subscribed to the Google
> >> >> Groups "Concerto Digital Signage" group.
> >> >> To post to this group, send email to

> >> >> concerto-digital-signage@googlegroups.com.

> >> >> To unsubscribe from this group, send email to

> >> >> concerto-digital-signage+unsub...@googlegroups.com.

> >> >> For more options, visit this group at
> >> >>http://groups.google.com/group/concerto-digital-signage?hl=en.
>
> >> > --
> >> > You received this message because you are subscribed to the Google
> >> Groups
> >> > "Concerto Digital Signage" group.
> >> > To post to this group, send email to

> >> > concerto-digital-signage@googlegroups.com.

> >> > To unsubscribe from this group, send email to

> >> > concerto-digital-signage+unsub...@googlegroups.com.

> >> > For more options, visit this group at
> >> >http://groups.google.com/group/concerto-digital-signage?hl=en.
>
> >> --
> >> You received this message because you are subscribed to the Google Groups
> >> "Concerto Digital Signage" group.
> >> To post to this group, send email to

> >> concerto-digital-signage@googlegroups.com.

> >> To unsubscribe from this group, send email to

> >> concerto-digital-signage+unsub...@googlegroups.com.

> >> For more options, visit this group at
> >>http://groups.google.com/group/concerto-digital-signage?hl=en.
>
> >  --
> > You received this message because you are subscribed to the Google Groups
> > "Concerto Digital Signage" group.
> > To post to this group, send email to

> > concerto-digital-signage@googlegroups.com.

> > To unsubscribe from this group, send email to

> > concerto-digital-signage+unsub...@googlegroups.com.

> > For more options, visit this group at
> >http://groups.google.com/group/concerto-digital-signage?hl=en.

--
You received this message because you are subscribed to the Google Groups "Concerto Digital Signage" group.

To post to this group, send email to concerto-digital-signage@googlegroups.com.
To unsubscribe from this group, send email to concerto-digital-signage+unsub...@googlegroups.com.

[Brian Michalski]

Hi Wojciech,

We're currently not very bandwidth sensitive in Concerto, the primary environment we develop in is a high bandwidth LAN space where traffic doesn't matter too much.  We've heard a few users ask WAN questions before, but never 3G networks... I think it's a fairly exciting optimization to work on.

I'm curious, do you have a rough breakdown of what that 700Mb per month is made of?  We've had a few instances where Concerto clients did a poor job caching DNS queries, something that could definitely be contributing to your traffic (and likely some latency as well).  Aside from the lower level things like DNS queries, the bulk of a Concerto client should be small content queries resulting in somewhere around 500 bytes every N seconds (N = average content duration / number of fields on a screen).  After that content "information" is transferred clients might request additional resources, like an image to render.  We'll return a 304 here if the image is cacheable to help minimize the transfer too.  Anything outside of this pattern would be an indicator something strange is going on.  (I honestly have never monitored the bandwidth of a single screen / month before).

I can share some of the plans for V2, but it's still in the works.  We'd to be able to bundle up several of the content "information" messages, describing what content to show instead of sending them individually as it stands today.  I don't think we'll fetch once and use a cache entirely (the ability to quickly unapprove and remove content is a requirement) but we'll cache this information and the related content assets (aka images) so that it would be entirely possible for the client to run disconnected during peak traffic periods or perhaps work more like a sync setup where the screen is only actively talking to the server a few times a day.

I don't know about what browser, client, or server you're using but SPDY might offer some bandwidth savings as well over traditional HTTP.  We don't have any particularly verbose response / request headers to my knowledge, but every bit might count.

Thanks,

~Brian M

To view this discussion on the web visit https://groups.google.com/d/msg/concerto-digital-signage/-/aeEZ0FOBNNEJ.

To post to this group, send email to concerto-dig...@googlegroups.com.
To unsubscribe from this group, send email to concerto-digital-s...@googlegroups.com.

[tuure]

Hi Brian,
I only make some easy calculation. I have two text pickers on webpage.
After 10 minutes I see in firebug (using FireFox as Concerto client)
that the client<->server communication take around 50Kb, when you
multiply it you get around 300MB per month then I multiply it by 2
assuming I will use some graphics also.

I see now in code that your refresh content every second in our case
we don't need to refresh data so often that why we look maybe for some
workaround.
We look forward for functionality that you propose for version V2!

Regards,
Łukasz

> >>> > >> it's screen viahttp://localhostinsteadofhttp://remote-server. I'm

> >>> > >> no expert in distributed MySQL or rsync, but if completely
> >>> > >> disconnected support is required it might not be too hard to setup.
> >>> > >> It's unlikely you'll see this mesh signage network in V2.
>
> >>> > >> As for the timeline for the other features, my short answer is yes.
> >>> 3
> >>> > >> months sounds too soon, 6 months sounds far off, and I've been
> >>> saying
> >>> > >> within the year for a long time now. We've been making substantial
> >>> > >> progress (some blog updates to come soon) but there's still more
> >>> work
> >>> > >> to be done.
>
> >>> > >> ~Brian M
>

> >>> > >> On 4/10/12, Jeff Hollingsworth <jeffrey.k.hollingswo...@**gmail.com>

> >>> > >>https://groups.google.com/d/**msg/concerto-digital-signage/-**
> >>> /t59Kd1p9UqYJ<https://groups.google.com/d/msg/concerto-digital-signage/-/t59Kd1p9UqYJ>
> >>> .
> >>> > >> >>> To post to this...
>
> read more >>