Using stateless windows clients (Web Exception in Run: The remote server returned an error: (404) Not Found.)



I want to use Xibo with stateless windows clients:

My client boots a Windows 7 image with installed Xibo player (200-200) over the network.
This image is fresh on each reboot. On boot, a hardwarekey is generated automatically (SHA1 of the physical MAC-address, so it is always the same) and copied to the default library location (c:\users\xibo\documents\xibo library\). The folder is empty despite the hardwarekey-file.
There is a XiboClient.xml file in %APPDATA% file with the correct server url, server key and default library path.

The display is automatically authorised at first boot.

Most of the time this actually works, but just sometimes the client won’t show any layouts, and only show the splashscreen. Sometimes it will take a few minutes to start showing layouts, sometimes it never will.
The log then shows a lot of

Web Exception in Run: The remote server returned an error: (404) Not Found

The Webserver is reachable, using a browser I can access http://<server>/xmds.php, but when using parameters like http://<server>/xmds.php?file=xyz&displayId=18&type=M&itemId=32 (from requiredFiles.xml), it gives 404.
If it works (as I said, sometimes it just works) the links from requiredFilex.xml work,and I can download files from the Server.

XMR-status on the client is “Connected”, in both scenarios.

The server is a docker 2.0.0 installation, out of the box (Ubuntu). (The problem was exactly the same in 1.8.2).

Any ideas?

Best Regards,


Did you tried to delay a xibo startup?


The player is started specifically after the hardwarekey-file is put in place.

Would delaying it further help?


depend how fast your connection to internet is.
When I was scheduling my clients I set the delay to 30 second, to be sure that wifi is connected.
Because if the first try was occurred before the internet worked it waited 30 minutes till next pull.

So try it out.



Tried it, didn’t change behavior. :thinking:
Being a network problem would not fit the 404 errors, they indicate there is network connectivity.



So i did a lot of reading and trying out.

The xmds documentation says:

The CMS supports downloading files over XMDS directly or over directly over HTTP. If HTTP downloads are enabled the path attribute will contain a fully qualified download path and a new attribute named saveAs will be present showing the intended save path.

HTTP downloads are only valid for one usage and are refreshed with a new path each time RequiredFiles is called.

If I request the files via Postman

<soap:Envelope xmlns:soap="" xmlns:soapenc="" xmlns:tns="urn:xmds" xmlns:types="urn:xmds/encodedTypes" xmlns:xsi="" xmlns:xsd="">
  <soap:Body soap:encodingStyle="">
      <serverKey xsi:type="xsd:string">{{serverKey}}</serverKey>
      <hardwareKey xsi:type="xsd:string">{{hardwarkey}}</hardwareKey>

I receive a list of files with path argument.
I can use this argument once to receive a file, on the second time it gives me a 404.

However, calling requiredFiles again does not give a new path, it is the same again. So using the same link again, produces a 404, bcause the links are only valid once.

So it seems the documentation is not quite accurate about the new generation of links.

Maybe that’s a bug of sorts?



The CMS knows the state of the Player.

When you reconnect, the URLs that the CMS sends down in the RequiredFiles document will all be invalid as they are old, and the CMS knows the Player already has those files (they’re valid for one download session only).

You’d have to clear the CMS side Player cache somehow to send fresh URLs for the Player to obtain new content, or wait for the cache to either expire naturally, or for some content change to trigger the display cache being dropped.

It’s not designed to support that kind of workflow.

You also loose your XMR key on each reboot so XMR won’t work with the CMS as you describe.


Thanks for the clarification. That makes it clear for me where my problems stem from.

I understand that the workflow is not supported.

Having a stateless client is highly desirable for me, as it reduces administration for the clients drastically.

@alex maybe it is a “quick win” for you as well to provide at least a workaround to make this scenario work. :wink:

Therefore, please allow me to ask:

  • How long is the server side player cache expiration timeout?
  • Can it be adjusted (e.g. via settings-custom.php)?
  • Can the cache be cleared (e.g. by an API-Call)?



We use the method we do for two reasons.

Generating RequiredFiles and the nonces inside it is an expensive operation. Doing it every time that the Player requested the document, when it already has those files downloaded is therefore undesirable from our side.

The links work one time only as a security feature. It prevents someone intercepting those URLs and using them to download content from your library after the fact, so loosening that also isn’t desirable for us.

I’m not sure off hand what the cache interval is, but I would guess around a day. It can’t be adjusted no.

You could clear the cache with any API call that would cause the Player to need to download new content (eg scheduling a new layout, adjusting an existing layout etc).

Is there no way you can allow the Player library to persist across reboots, and just have the rest of the OS roll back? Tools I’ve seen in the past (eg Deep Freeze) always supported that kind of operation.


So would it be enough to make a plain file copy of the directory?
A workaround would then be: Copy the files in place before the Xibo Client starts, then make a backup every hour or so.


Yes I think that should work.


Seems to work great.

I now copy the library to a fileserver every hour (in a subdirectory named like the hardware key), and on boot I get the latest copy for the client.


Edit: @alex, see the documentation that I quoted above. The links are not newly generated everytime requiredFiles is called. Maybe you want to update that doc. Cheers!


Thank you. I’ve queued an edit to that doc so it should be updated in the next few hours.