The second screenshot, the layoutId 2 seems to have an empty name? Which shouldn’t be possible as you can’t create/edit layout’s name to be empty, but it would seem that it’s indeed empty - which may very well cause issues, unless of course screenshot was edited to hide the name.
I assume layout id 1 and 3 do work without issues?
There seem to be an issue only with 2.xlf file.
You can also enable debugging and/or advanced logs for your player, if there is something else going on, then there should be some logs about it.
I am pushing Xibo for a Proof of Concept for client.
The second screen shot had the client name in and as this is a Proof of Concept with Xibo competing against other vendors it would be deemed unfair if it was publicly known which Digital Signage applications are being considered.
Nothing is displayed apart from the default Xibo screen.
This is the default template which I deployed and then tried to change. I tried adding txt at the bottom of the screen.
There seem to be an issue with XMR, if I recall correctly, you’re using docker installation, correct?
In which case you should only need to configure xmr public address to be:
tcp://domain.name:9505
or
tcp://cms.ip.address:9505
I assume the player is 1.8.1 as well, correct?
You could try to clear display cache (edit&save it), perhaps issue rekey xmr as well, once you make sure that it has correct public address in CMS settings.
That being said, even incorrectly configured XMR shouldn’t cause issues with the layout playback, it’s also a bit strange that all other files were downloaded correctly and only 2.xlf wasn’t.
Could you check schedule.xml and requiredFiles.xml in the player local library and make sure there is correct data there?
I can have a look at this layout, if you can export it and send it to me via private message (feel free to rename it etc).
Is XMR also configured in the cms settings as I mentioned in my previous post?
Does this layout id2 has some special characters in the name?
Could you also edit&save display profile assigned to this device?
Perhaps clear the schedule for this display and select the default layout (id 1 ) as the default layout for it.
Make sure that it is displaying it correctly, clear display cache, restart display, make sure that schedule.xml does not mention layout id 2 anymore.
Double check that layout id 2 is valid and then schedule it to your display.
Alternatively, uninstall the player, delete player local library and settings in \AppData\Roaming then install player again, clear schedule for this display record in CMS, connect it to the CMS, set layout id 1 as default, if that works then schedule layout id 2.
You could also try to export this layout and then import it with different name - so then it will have different layoutId, I’m not certain what when wrong there.
As I mentioned I can have a look at this layout and try it on one of our devices here in the office, if that would be of interest then please send me your layout.
and here, there seem to be still some XMR issues, could you please send the rekey action to the player (displays page → edit display-> advanced → reconfigure xmr) then restart your player just in case.
It should be enough to have in the CMS settings no need to overwrite it here I suppose.
As my VM environment crashed and I had to get ready for a demo I reinstalled from scratch and I have the same issue. I tried doing the reconfigure XMR and it didn’t make a difference.
When the player first connects it pulls down the layout correctly. When I make changes the issue occurs.
I was facing a similar issue and I’m using Docker on Ubuntu Server. I haven’t done many tests but it looks like that the problem was solved after I change the Windows user on player from standard user to administrator. I had limited the user access to avoid that someone install undesired application on player.
I don’t know if it makes sense, but maybe the issue was being caused by some access restriction.
