Xibo client loose his connection to the webserver

Asked by Alexandre

Hi there,

First thanks for this wonderful piece of soft,

I found an issue on many xibo clients I had set up on the same xibo database.

It appears that some of the xibo clients are loosing their connection really often, the xibo database shows that the xibo client is updated regardless the layout but not connected,

If I try to change the layout, the xibo client would not upodate it as not connected.

Because it's Windows system based, I had set up logmein, and I can see these units connected, so it's not a internet connection issue.

All the xibo client are in static IP adresse corresponding with the router, (dns included).

The public adress of the client (place where the xibo client is running) is eihter fix of not, the same issue appears.

I am running the 1.2.2 server // 1.2.2 client windows based.

Can you please help out with this situation

Question information

Language:
English Edit question
Status:
Answered
For:
Xibo Edit question
Assignee:
No assignee Edit question
Last query:
Last reply:
Revision history for this message
Alex Harrington (alexharrington) said :
#1

There's no persistent connection between client and server. The clients connect to the server, collect what they need and then disconnect until next time.

If you've set your collection interval on the server higher than I think 10 minutes, the server will show the clients as offline at times, but it's nothing to worry about.

The public IP, NAT etc of the client end doesn't make any difference - all that needs to happen is the client be allowed to access the server.

If you're updating content on the server and it's not being displayed on the client then check the following:

* On the client, open the options and click Register. If it says "Display is active and ready to start" then that's correct.
* Check the layouts you're sending to the client don't have media items with long durations. If you send a layout with a 5000 second duration on an image for example then the client will show that layout for a minimum of just over 1 1/2 hours regardless of any change or scheduling change you make on the server. This is by far the most common issue.

Alex

Revision history for this message
Greebo (greeboss) said :
#2

Hi Guys!

to be honest, I have a similliar problem, but I have checked every connection interval and that is not the problem...

It goes like this:

1. let's say that there was a short connection problem (cable from server unplugged or some ISP problems) - the client goes down (red), but after few minutes (ISP problem over) everything goes back to normal - clients go green and update and everything..

2. If the connection problem is longer (hour or so) or the connection was not broken but interrupted (for example to low bandwith or something that stops the net but the IP of server is visible, but something like unreachable) the connection with client breaks and cannot get back to work if the client is not restarted - i don't know, some blacklist or cache in the client?. Can't really tell what it is, but it happens. For example today I had some ISP problem, I could reach some www, but sometimes it was like timeout and stuff, and the xibo server (it is on the same IP) was not recieving anything from clients. They will be restarted tomorrow and I am pretty sure then they will connect to the server. It happend a few times before.

Don't know the answer, maybe You guys do? Still restarting all clients (taskschd restart)

Cheers and thanks!

Revision history for this message
Alex Harrington (alexharrington) said :
#3

Piotr

This sounds like a different issue to me.

I'm 99% sure the first issue is to do with media duration lengths.

You don't say what versions you're running or on what OS etc so it's impossible to have any firm suggestions for you.

Alex

Revision history for this message
Greebo (greeboss) said :
#4

Dear Alex,

I have been trying to resolve my problem for weeks, I have been asking questions here at launchpad, but unfortunately nobody has a solution.

Xibo Server ubuntu 1.2.2 10.04 LTS, Win 7 x64 xibo 1.2.2 client.

Cheers

Piotr

Revision history for this message
kobus44 (kobus44) said :
#5

The problem is your fixed ip environment. On many occassions/locations, I have witnessed that when networks are set with fixed ip addresses, network connections are somehow disrupted. Disruptions last for a couple of seconds to a couple of tenth of seconds. What causes this, I have no idea, but my guess is this is hardware related (i.e. router/switch): I think that most router/switches are most comfortable serving ip addresses based on DHCP, for whatever reason.

Let me first say, wearing my IT-hat, I am always against using fixed ip's. It is both more efficient and elegant to either work with pre-assigned IP-ranges for certain machines, or to just use DHCP and properly name all your hardware, so you move away from identification based on ip-address, and you move towards identification based on, say, each computer's name.

I agree, that in theory a fixed ip environment should work as good as a DHCP environment, as long as you be in control of the ip-addresses. As soon as you erroneously enter two identical ip-addresses on two different machines, you will run into network troubles. My first suggestion: look that this is not the case for you.

My second suggestion is a partial extension of Alex' comment. Xibo only connects to the network/server when necessary. It does not, when it detects no network connection. It does not detect a network connection, when said connection is lost. Furthermore, a well know behavioral bug in many versions of Windows is that whenever an application, dependent upon the network or internet, is being cut off from this network while running, this may cause problems in the sense, that the disconnect of the network is triggered in the program (i.e. the program is told to not further download network information), but not reestablished when the network is re-connected, UNLESS the program is closed, and restarted. Note that this has oftentimes also to do with the programming of the applications themselves, and is not necessarily a Windows-related problem. You could try to mitigate this, by writing a small batch script that executes the following command:

@echo off
ipconfig /renew
exit

You can then plan this batch script to run every 15 minutes (for instance) through the Windows Task Scheduler, or a program like EventGhost.This latter program I would certainly recommend, as I believe it even has a built-in script to re-connect to networks. Might be worth checking out.

Revision history for this message
Greebo (greeboss) said :
#6

Damn :) quite an essay :)

Dear kobus44 You're the man! How come I haven't come up with such an easy solution for the problem.

I supposed it was "triggered in" the software for some unknow reason, but Your script may help a lot.

Thank You! And thank You guys for every support!

Stay cool!

Piotr

Revision history for this message
kobus44 (kobus44) said :
#7

No problem, but be aware that this solution might also CAUSE you problems. Say, Xibo is in the middle of downloading content, or you are showing a layout with dynamic content downloaded directly from an internetpage, and the script suddenly kicks in. It will briefly drop and then reconnect, possibly causing a glitch on the screen (might be something you do not want); or, forcing Xibo to re-download content (something I would not worry about, unless you have very low bandwidth and/or are uploading sizable content, like HD movies). Therefore, I would suggest still looking into the hardware of your network, as this sounds, and most often is traceable to faulty or uncooperative hardware, or wrong settings for these hardware.

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

1.3.3 windows client (not yet released) might give an improvement in this area as it manages the connection to XMDS (Xibo server) a little better.

There were some problems with it correctly disposing resources.

Can you help with this problem?

Provide an answer of your own, or ask Alexandre for more information if necessary.

To post a message you must log in.