I have a recurring problem with numerous of my Xibo clients which has occurred since upgrading from 1.4.0 to 1.7.4. At random, a display will fail to load the client and display the following error message on-screen:
“There is an error in XML document (0,0)… Path C:\Documents and Settings\Username\Application Data\xiboclient.config.xml”
On inspecting the config file, it is totally blank. I have copies of all my config files so I have to copy it back over to fix the problem. It will then reoccur after a few days or possibly weeks. This appears to affect the majority of my 40 or so displays.
In 1.7 series that file gets rewritten at each collection interval I believe (as the CMS pushes down the Player configuration) so if you got unlucky and just pulled the power to the box as that write was happening that could cause that file to be empty I guess?
The clients run constantly, and just drop to a blank layout overnight rather than turning off. And these are across multiple sites too with no other indication of power issues. Many of them are fitted pretty high up where they couldn’t be manually powered off. So I’m not sure that could be the cause.
Not sure if you meant to do that now and post the results, or wait until one fails? I’d have to enable auditing on all my displays to catch one in a timely manner, which i can do if needs be. I’ve enabled it on a few repeat offenders for now. Currently the results look like this:
I think any request should be OK. It’s actually Dan that asked me to ask you for it. We’re thinking there might be something in there preventing it serialising the response so keep it on until you get a failure, and then see if there’s anything different about the XML from the logs preceeding it going wrong
My hope was that when I ran the XML through a validator it would throw up some errors, which would explain why it failed to serialise correctly when saved.
Can you determine if it is failing at every collection interval, or just some of them? You should be able to look at the contents of that xml file at any time and see its running values.
It must be failing at just some of the collection intervals, as a particular display can go for days or weeks without the fault occurring. I’ll try and catch one failing with auditing enabled.
I’ve had a failure on one of the displays with audit enabled, however there is nothing in the log on the server. Looks like it actually failed on Wednesday, but I was out of the office and by the time I’ve found it the logs appear empty! My max log age setting is 30 days so not sure why. I do have a copy of the local log.txt file from the client if that would help?
I don’t understand why you have 1 massive log file - 1.7.4 splits logs out into separate files when it gets over 25 messages, so that is a bit odd…
Regardless the end of the file is where we would expect any pertinent information, and there isn’t any unfortunately - it dies half way through flushing to the file, which is normal for a crash:
It dies at 14:58:43, which is before the next collection which is due at 14:59:01 (the last one was 14:58:31) - so it dies in between collection intervals.
Even more odd, the config file is only read into memory when the player starts up, not during runtime. So an empty config file might be a symptom rather than a cause.
In your first message you said:
Does that mean the error only presents when you re-open the player after a crash?
Is there anything in the Windows Application Log regarding a crash?
I’m not sure how the logging is meant to work, but sounds like that could be a problem.
The clients just sit and run constantly, so save for power cuts they won’t get a reboot and the client should never close and re-open. I’ve check the windows event log and there is nothing whatsoever around that time, and certainly no evidence of a reboot or crash! To the best of my knowledge there is nothing that would be causing the client to close and open at that time.
Essentially it should create a new file each time the log size reaches 25 entries. These are then sent to the CMS in small chunks rather than sending one big file. Having one big file there certainly won’t be helping as I imagine it is failing to send. Perhaps you can delete that file and see if it starts creating the smaller ones?
This player is definitely a 1.7.4 player and not something older?
Thinking outside the box a little - is the users profile on the local drive? I.e. how likely is it that the users profile and therefore the config file to disappear for a short while?
I’ve deleted it and we’ll see what happens. Just checked another 5 or 6 of my clients at random and all have log.txt files around the 50MB mark currently. Something must be wrong with that mechanism in my environment.
Re the user profiles, they are just standard local users with a local user profile unfortunately. Can the config file not just remain static unless there is actually a change? Or is it to do with the display settings profiles?
The clients are 1.7.4 with your fixed .exe for the PowerPoint download issue. However, this current behaviour existed before that .exe patch.
If so, then it makes perfect sense that it grow in size indefinitely. The player routinely creates and sends log files to the CMS - this is the mechanism I thought you were using - it makes sense that you aren’t!
You’re a gent, thanks! I’ll drop that client onto a good few of my displays and give it a good test for a while.
Re the logs, I have indeed populated that field. Would it be better not to? I guess it’d mean the logs would only exist on the CMS and never permanently on the client. I hadn’t realised this- I thought I was just specifying the temporary location of the log file prior to it uploading to the CMS. It’ll explain some of the disk space issues I’ve been having, that’s for sure!
I put the modified .exe on all my clients, and so far I haven’t had a single instance of the config file being empty. Result! Will I have to stick with the version I have now, or is this something that could be included in future releases?
It will be in the 1.7.6 and 1.8 releases, so you can upgrade normally when the time comes. Its no problem to continue using the EXE I provided in the mean time.
