We have been using Xibo for a couple of year and it’s been working great.
After updating to Version 1.7 we have problems with the client goes to black.
We are know using version 1.7.3 and still have the same problem. It’s installed on Windows 7 embedded.
Any ideas?
Have you worked through this first:
Checked this, and everything looks fine. I have a screen dump of the logfile, if you want to see.
The client is working fine for a couple of days, then suddenly it goes black. If I do a restart of the client software, everything works fine again.
We have had the same layout with xibo 1.5 and 1.6 and never had this problem before.
Yes some idea of what’s on the layout, what durations are configured, the machine spec, and any logs would be a good starting point. Note we’ve never supported Embedded versions of Windows as they don’t get the full .net framework load from Microsoft. I only mention it as that could be the root of the issue.
Also can you try keeping Task Manager open on top of the Player for a while to see if the black screen coincides with any particular system metric (ie high CPU loading, running out of RAM etc)
Intel Core i3-4100 2,4GHz
4 GB ram
64 bits Windows Embedded Standard
I’m sorry, but I’m not aloud to attach any image of logfile to this thread.
If you like to see, I have teamviewer installed on the client.
You can post up images, but you need to read a few other threads here first to gain “trust” to do so. It’s that way to prevent spammers uploading junk!
Also as I said, full details of the layout too
So the errors suggest the Player can’t connect to the CMS. You need to investigate why that might be. Prime candidates are missing .net framework updates (and they may not be available to you on Win 7 Embedded), poor network connection (eg wifi connection) and/or faulty cabling/hardware.
By the details of the layout, I mean a text description. So for example, two regions, the first with 2 images, durations 10 and 5 seconds and the second region with a webpage hosted on a local server, duration 90 seconds, in Open Natively mode.
Alex
This error I got on one of our client today. (It’s been working fine since last Friday)
The layout is quite simple. It’s only one region displaying different pictures on the whole screen. The duration is 15 or 20 seconds.
All the clients located on different firestations are connected to the network with cable.
They’re much the same errors as before. The first ones “remote name could not be resolved” are where there’s no connection between the player and your DNS servers. So we’re asking to resolve “server.com” and getting no response. So that’s a simple networking issue you need to investigate. The last lines suggest that then the Player could connect for a period but perhaps some packets were lost or there was some timeout. None of those should prevent a layout with some images on from continuing to play back.
Can’t find any problems with the network. It’s 4 different firestations with over 20 displays, and it’s the same problem on all locations. As said earlier, this was not a problem with Xibo 1.5 and 1.6 on same network.
Could you try 1.7.4 please?
There was an issue found in 1.7.x before that where it could lock on a black screen when using webpage media types so perhaps that’s what’s occuring?
Updated to 1.7.4 today. So I will test it for a few days
After updating to 1.7.4 this morning, I have discovered a new problem. Xibo halts on one of my layout that show a html page.
If I restart xibo client, it runs normally until the specific layout. This has never been a issue before.
Is it just with that one specific HTML page or all HTML pages?
I have one url layout scheduled that worked fine before update. It’s a page with ongoing rescue missions. The page is live, and it’s updating every 15 sec. So the problem is that the xibo player is not loading next layout scheduled , but only repeat the same url layout
Can you export your layout please so we can test it here?
If you like, I could give you access to a player with Teamviewer, because the url is a internal ip.
We’d need to be able to recreate it locally as it would need to be run on a development machine where we can see what’s happening.
Can you test with a different URL and see if the issue persists - my suspicion is it won’t as it hasn’t been a problem in testing here.
If so we’ll need to isolate what it is about that particular website that’s causing a problem in a way that gives us a test case we can reproduce here.
Different url tested, and works fine. Downgraded player to 1.7.3 , now my internal url works again.