Xibo

HTML support, what is the underlying architecture?

Asked by blammo

All,

Looking for resources related to describing the underlying architecture of XIBO.

I have a (XP) server running with two Clients, one on the server CPU and one on another XP CPU. Installed very nicely and worked the first time. Very nice software, and already it's inspired a bunch of potential uses.

Most everything is working very nicely, except for when I try to add what I would describe as complicated HTML pages. Specifically I wanted to add something like this page:

http://radar.weather.gov/radar.php?rid=mpx&product=N0R&overlay=11101111&loop=no

or this:

http://forecast.weather.gov/MapClick.php?CityName=Saint+Paul&state=MN&site=MPX&textField1=44.9477&textField2=-93.1037&e=1

as a WebPage (BTW, what's the difference between how a Webpage and Embedded HTML is interpreted?).

Both of those links cause the Client to explode (I can only get things back to working if I reinstall the client) and no matter what I do on the server side. Also, I discovered that after trying to display a complicated page such as this, even switching layouts from the server side won't fix things.

Most of the information I want to display on the digital signage is web based, and in fairly complex page form. We also do quite a bit of Mapping based web sites as well, along with AVL (Automatic Vehicle Location) mapping.

So, my real question is, what is the architecture under the hood? I did notice that when installing the client on the Server CPU that it complained about a IE version that was too old (6), which leads me to believe there is some dependency there. Any thoughts about using something like Firefox instead, or even Chrome? I would like to know what the limits there are to interpreting HTML (web pages and/or Embedded pages) in the Layouts.

Thanks

bobb

Question information

Language:
English Edit question
Status:
Solved
For:
Xibo Edit question
Assignee:
No assignee Edit question
Solved by:
blammo
Solved:
Last query:
Last reply:
Revision history for this message
Dan Garner (dangarner) said : 		#1

The windows client used IE to render both the web page media type and the embedded media type - the linux client uses a chrome based rendering engine for this.

The difference between the "web page" and "embedded" is simply that web page opens up the link you give it directly, whereas embedded opens up a local page containing the embedded HTML you have specified.

When you say "explode", what exactly do you mean? Is there an error message presented? There are some issues displaying certain "complicated" web pages which results from the use of IE (specifically the web browser control in .NET). This control seems to leak memory for certain pages - and there is precious little we can do about it.

There are long term plans to switch to a web kit based rendering engine (to match the linux client) - however these plans are a fair way down the roadmap. We do (under certain circumstances) take sponsorship to develop features immediately (essentially moving them to the top of the roadmap for release with the next version). There are a few companies in the Xibo directory that do this - you could contact one of those if the move away from IE is urgent for you.

If you can provide the error message for the "explode" then I can run those webpages through a debugger here - the known issue tends to take a while to "explode" so this may be something new.

Thanks.

Revision history for this message
blammo (bob-basques) said : 		#2

The "explode" aspect was the best description I could come up with.

The XIBO engine starts up, the defined background, color in this case, is displayed, a few seconds go by, and then a Microsoft error dialog pop up after the the XIBO engine dies (explodes).

I can send the Microsoft error if it will help. It's just painful to reinstall the client every time, I've done it so many time already. Either one of the links in the original posting will cause the explosion of the XIBO display. I've tried in on two different XP CPU's, so I figured it was some systemic problem.

bobb

Revision history for this message
Dan Garner (dangarner) said : 		#3

Hi bobb... I have run an install through the debugger for both of your links - and they seems to display OK (my debugger is on Win 7 though).

What version of the .NET framework do you have and what version of IE do you have?

Revision history for this message
blammo (bob-basques) said : 		#4

IE 8.0.6 on the Server/Client XP box
          .NET Framework - 1.1, 2.0, 3.0

IE 8.0.6 on the client only XP box
          .NET Framework - 2.0 SP2, 3.0 SP2, 3.5 SP1, 4 Client Profile.

BTW, I'll try those links again tomorrow and see what happens. I've been running the server and two displays all of this week with very good stability so far.

bobb

Revision history for this message
Dan Garner (dangarner) said : 		#5

OK, well I have tested those links for a good few hours and they seem to be ok (with a slight memory leak). Certainly no immediate crashes.

If you do test them again and find they still crash - I think the only option will be to wait for the blueprint for replacing IE with a webkit/gecko based rendering engine.

Perhaps there are alternative sites you can use in the meantime?

Revision history for this message
blammo (bob-basques) said : 		#6

Dan,

I tested the same two links out myself again last Friday, and wah-la, they both worked just fine. On two different displays no less.

The only thing I an think of that I did different originally, was to start up the server process, without already having the client up and running already.

In the last tests that I performed, the client was up and running already taking commands from the server, etc. Originally, Iset up the server aspects, and then went the clients and tried starting them, this is when I received the windows error, when trying to start the clients.

I left things running over the weekend, and all is working today, so far.