Hi!
With Alex help I started CMS v.1.8.2 Docker install under Linux. After the initial fiddling with the CMS firewall, the v.1.8.2 players under Win10 Home 64bit started playing images and video. A couple of additions which I suggest to the hints in Xibo CMS Post-Installation Setup Guide - 1.7 Series :
Windows Media Player should be installed and activated for XIBO player to work normally under Win OS.
Under Win10 the library folder may need permission settings, I allowed Full control to Everyone, not all hosts need manual intervention.
Scheduling seems to me not precise and I checked Docker time - it is different from time on host, 3 hours difference:
docker ps -a
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
6eee150fe459 xibosignage/xibo-cms:release_1.8.2 “/entrypoint.sh” 4 days ago Up 3 days 0.0.0.0:8081->80/tcp xibo_cms-web_1
34bbc9c8afbc xibosignage/xibo-xmr:release_1.8.2 “/entrypoint.sh” 4 days ago Up 3 days 0.0.0.0:9505->9505/tcp, 50001/tcp xibo_cms-xmr_1
docker exec -ti xibo_cms-web_1 bash
/# date Wed Sep 13 12:46:29 UTC 2017 - docker is 3 hours behind
root@6eee150fe459:/# exit exit
date Wed Sep 13 15:46:57 EEST 2017 - tost time 15:46 is the correct one
CMS ADMINISTRATION - Settings: Regional tab:
Timezone (GMT+3:00 Europe, Sofia
Date Format Y-m-d H:i
*** with this setting probably the CMS time is corrected relative to Docker time. How can I check CMS time?
WIN10 regional settings (where player 1.8.2 is installed):
short date: d.N.yyyy ‘г.’ (BG format) short time: H:mm
*** Is there a problem if date&time format in CMS are different from regional settings on CMS host and/or player host? Or I shall change CMS format according to http://xibo.org.uk/manual/en/advanced_dateFormat.html documentation? I do not mind working with CMS default format.
When XIBO player is running and I press “i” there is the following text:
LayoutID:33. Runs from 1.1.1970 г. 3:00:00
XMR Status: Disconnected, waiting to reconnect, last activity: 1.1.0001 г. 0:00:00
Is this pointing to some timing problem? In BG “г.” is the abbreviation for “year”. Year 1970 3:00:00 and especially 01 January 0001 0:00:00 is puzzling.
Thanks for your comments. I’ve addressed each below:
Windows Media Player is listed in the system requirements already
The default location should not require any modifications. If you choose to put the Xibo library elsewhere, and have a limited user account, then certainly you may need to adjust permissions. Granting “Everyone” access though probably isn’t the best thing to do.
The container always runs at UTC, as should any sensibly configured server. You adjust the timezone you want the CMS to run in in the CMS settings as you have shown. Once the timezone is set correctly, then the CMS scheduling will work as expected.
Changing the timezone after adding schedules will cause those to skew by the amount you have adjusted, so you should set the correct timezone before adding schedules.
I’d suggest the issues you’re seeing are related to your Player side date format and not related to the CMS. Please use an English date format, and that should resolve your issue.
“I’d suggest the issues you’re seeing are related to your Player side date format and not related to the CMS. Please use an English date format, and that should resolve your issue.”
Thanks for the suggestion. I will test it, but it is impossible to implement it in real life as players are installed on workstations where the digital display (wide screen TV) is connected as monotor2. On monitor1 the operator is performing other tasks and absolutely needs local format for date, time etc. On the Linux server side I am free to use whatever format I choose.
“If the mountain does not come to Mohamed, Mohammed goes to the mountain ”: don’t You suggest to change date/time settings on the server side to match all workstations format and thus avoid inconsistency between player & host? Is the player tied internally to English format (in WMP there is no format option)? Do these strange dates shown by player point to a real problem?
I’m pretty certain changing the format in the CMS won’t affect the dates sent down to the Player as they are expressed in a fixed format (I believe YYYY-mm-dd - ie ISO standard format). The date format only affects what is shown in the web interface. @dan would be able to tell you for certain.
The Player application is assumed to have complete control of the computer. I’m pretty sure you’ll hit issues if you try and have other people using the machine. From memory, Xibo will constantly steal focus from whatever the user is trying to use. I may be wrong on that. You would need to test.
Yes I think they do. It implies the Player is misinterpreting the dates it’s receiving.
In practice CPU sharing is working perfectly for me on 10 localions for >2 years. A price efficient config with i3 processor and integrated HD video outputs on motherboard, 4GB DDR3, small SSD for OS and a HDD for data experiences no visible delay performing other jobs beside XIBO.
Contrary to that, an Android smart TV box which I tested is much weaker and though XIBO licence is cheaper than Win, hardware cost makes Android solution obsolete in places where a Win workstation is a must and it needs just a bit more productivity to run both jobs.
If scheduling does not go right, I have a workaround: to cycle a layout/campaign to the grouped displays manually till time comes right for the next event, a few days usually.
If it works for you then that’s great to hear. We’ve heard from others that that setup causes issues for them. All I’m doing is relaying that to you. The issue is not with speed or delays. Simply that when the Player changes from one layout to another, focus switches to the Xibo Player. So if you were typing in a box for example at the time, you’d suddenly stop typing in to one application, and instead start typing in to another. If you’re not seeing that issue, then clearly there’s no need to worry about it.
