#CMS Version
3.3.4
Apache2 / Php 7.4 on Ubuntu server 22.04 LTS
Issue
XMR Status : inactive with errors on https wrong protocol
somme other errors on log agent :
"Exception in Run : Le client a trouvé ‘text/plain;charset=UTF-8’ comme type de contenu de la réponse, alors qu’il attendait ‘text/xml’
There has been an unknown error with XMDS, it has been logged. Please contact your administrator.
Player & state registered on cms : check
.json config with xmr : check
firewall : check
apache2 redirects and other features : check
player config on server : check
default page : check and there is only that page on screen, all other layouts created on CMS seems not working, get an error “text/plain… bla bla text/xml”
very frustrating to get stucked with online clients and not be able to solve this. nothing appears in logs in player or server…
I have a lot of players to deploy on this version (250+) and I’m worried about what I will find next…
Someone have an idea to solve this error ?
any up plz ?
actually using V3.3 of CMS on Apache server and still stuck when want to add new players with same error.
I have totally wiped my server & reinstalled it, redeployed CMS and player and still can’t register new players at all.
Hi Jywebbs. Please excuse such a large delay receiving a response to your issue.
The first thing I noted about this is that you are using Windows IoT as your operating system. Have you tried testing a Xibo for Windows player on a full Windows release? If not, I would recommend starting there in case that is your issue. I’ve not tested the Xibo player on an IoT build, so I cannot confirm that it has all of the relevant drivers/functionality for running the Xibo player without issue.
If you find the same issue occurs when you are using a full/desktop Windows build, please can you update the post.
On a side note, the latest version of the Xibo for Windows player is now R310 (at the time of writing this message). Could you also try R310 so we can also see is this is a version specific issue?
So I downloaded the latest build (3R310) on a full win10x64 pro build and understood one thing during deploy process.
We have to delete the files in the "documents\library" and the XML in “%appdata%\roaming” folders just after uninstalling de .msi package and restart the player before full clean reinstall, otherwise the error message remains and it’s impossible to activate the player on the server.
I think the files remaining on the folders are in conflict with the new process of licence query and creates some freak brehavior with the hardware serial key that do not corresponds with the new one provided by the server.
I will ensure the behavior is the same for some cluster of players and feedback results.
After a while, it seems the error respawns with manual update the CMS to v3.38 (I had to do cause the bug of automated playlists that didn’t work).
After that, none of new player could connect to CMS and receive new plans anymore.
It’s very frustrating, how could it be possible, I investigated and receive the same message “xml text plain html”… XMDS error…
All players are upgraded to 3R309… so fully compatible with this version of CMS
I noticed some widgets don’t respond correctly even I done the verification after the phar migration.
I’m stuck at this point, plz help me solve this issue I think I’m going to be mad
Hi Jywebbs, thank you for updating this post. Is your CMS accessible across the internet? If yes, could you provide me with the CMS URL and key in a private message?
Hi Jywebbs, or any other community users who are receiving this error. If you find yourself in this same situation, could you go to the Settings page in your CMS, then the Troubleshoot tab. Set the Elevate log date to one in the future, with enough time to gather logs for this issue. Click save to confirm and refresh the page. Can you try connecting your player again and let me know if the issue persists? If it does, can you create troubleshoot logs, recording the issue occurring and provide them to me in a private message?
Thanks for assistance I will try to investigate via logs and send U some soon.
I took time to review all custom deployment methods via Apache and I confirm that everything was carried out according to standards so it’s full OK in this way.