If it is docker installation, then you should only need to set the public xmr address in CMS settings
as Alex has said it should be tcp://yourserver.domain.com:9505 or tcp://your.ip.address:9505
Players need to be able to access this ip/domain on this port.
Private address should be tcp://cms-xmr:50001 by default and if it’s not visible in CMS settings then please check docker-compose.yml file there should be cms-xmr:50001 under ‘links’ section. If you haven’t changed it or if you’re not using any custom ports then that I believe it should be set to just that.
I’m sorry, I used brackets and messed up how that showed, our XMR Public address is tcp://ServerName:9505 So instead of name.domain.local, its just name. Our machines can ping based on name alone so is that fine or should I change it?
I’ve always left the docker-compose.yml file in its default state.
I can confirm that under “Services:->cms-web:->links:” I have
cms-db:mysql
cms-xmr:50001
And just to have it here the cms-xmr: entry is:
cms-xmr:
image: xibosignage/xibo-xmr:release_1.8.2
ports:
- "9505:9505"
restart: always
mem_limit: 256m
env_file: config.env
I believe that’s correct then (and indeed the default ports) ie 50001 for private and 9505 for public xmr address.
It’s relatively easy to test it, you can request a screenshot from player that should come back pretty much instantly, especially on local network or send some basic command.
Are the maintenance issues still persisting?
Is anything else not quite working for you?
If it’s a docker install originally, then we hide the private address as you never need to change it.
I’m wondering though if you have an incorrect value in there, causing your slow maintenance run.
You can check by connecting to MySQL, and running the following SQL:
SELECT setting, value from setting where setting like "XMR_%";
That should show you the XMR public and private address. The public address is inconsequential from the point of view of slow running Daily Maintenance task. If it’s wrong, the Players won’t be able to connect to XMR, but that’s not the issue we’re troubleshooting here. The XMR_ADDRESS is the one we’re concerned with. That should be set to
tcp://cms-xmr:50001
If it’s not, we have our culprit, and you can set it correctly by running the following SQL:
UPDATE setting set value="tcp://cms-xmr:50001" where setting="XMR_ADDRESS";
Instructions on connecting to MySQL are here:
If that isn’t the issue, then I think we’re at the stage where I need to see this first hand. I’ll need a copy of your data sent over (if you’re happy to do that) so I can recreate here and see what the issue is. If you want to do that, I can send over details of how to send your data to us.
Peter - Sending a screenshot request works pretty much immediately so we are good there I think.
Yes, the “Daily Maintenance” process still appears to be stuck for all intents and purposes.
To my knowledge, this is the only item sticking out at the moment, other than an issue with Tidy but Alex said that was a known bug you all are working on.
Alex - I ran the MySQL Command and it returned:
setting value
XMR_ADDRESS tcp://cms-xmr:50001
XMR_PUB_ADDRESS tcp://xibo:9505
So I guess we are at the sending data step. I’m fine with it, we don’t display anything particularly confidential.