We just managed to install a test environment with Xibo 1.8.0. Everything seems to work so we try to test new features.
Scheduling a layout on ‘Always’ does not seem to work:
It does not show up on my schedule. Weird thing is that I do show up on my Agenda:
Who is also experiencing this problem and what can be the solution?
The Agenda view shows the output being sent to the Player, so I’m pretty sure your schedule is being sent.
What does the Player status screen show?
Also check that “Test Videos 2” layout is valid. See in the status column, it’s showing as needed to be built, which suggests to me it’s just been edited.
If it’s invalid, it won’t be sent to the Player at all.
The status of both Test Video-layouts is correct:
At this moment the Agenda is showing two scheduled Always-tasks:
These have been scheduled about half an hour ago. So far my client only shows the ‘Welcome to Xibo’ default layout. It has not made any attempt to download files. Client has been rebooted.
The schedule is not showing anything at all:
So it does not seem to be working. Scheduling the regular way (with start and end date) seems to working fine so far for the same layouts.
What does the Player status screen show please?
With the schedule screen, you’re sure you have the Player selected at the top? Your screenshot doesn’t show it.
The schedule screen:
The player status shows the following information:
And
So it has downloaded the media files (37, 38 and 41) and the scheduled layouts (9 and 10) as you can see. It just does not show anything… The only scheduled layout is LayoutId 1 which of course is the default layout.
Status in CMS:
This is with a Docker based install?
What web browser are you using? Does clearing your browser cache make any difference?
Do the scheduled events still show on the Agenda view?
I did not use client version 1.8.0… Apologies. Now I do but it does not make any difference. XMR is not required for scheduling to work, is it?
‘Xibo will function without XMR running, but will not run any player actions. Scheduling and Layouts will function as normal.’ (source: http://xibo.org.uk/manual-tempel/en/xmr.html)
The installation is not Docker based since we only use a web server at this moment. We performed the manual install which seems to work properly (just like the previous versions) except for these settings.
XMR isn’t required for scheduling to work, but it will make the Player react more quickly.
If it’s not a Docker install, then it could be many things. Amongst the many reasons we’ve chosen to move to Docker is to ensure these kinds of “works on one machine, doesn’t on another” aren’t an issue any longer.
If you want support from the project moving forward, then it’s not always going to be possible for us to help you if you’re running a custom install.
That said, we can get an idea of what’s going on in your scenario by looking in the schedule table of your database.
Can you get a list out of the events in there please:
select * from schedule;
Will get what we need.
Hello Alex. Thanks for your help so far!
-- phpMyAdmin SQL Dump
-- version 4.6.5.2
-- https://www.phpmyadmin.net/
--
-- Host: 127.0.0.1
-- Generation Time: Mar 23, 2017 at 04:24 PM
-- Server version: 10.1.21-MariaDB
-- PHP Version: 5.6.30
SET SQL_MODE = "NO_AUTO_VALUE_ON_ZERO";
SET time_zone = "+00:00";
/*!40101 SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT */;
/*!40101 SET @OLD_CHARACTER_SET_RESULTS=@@CHARACTER_SET_RESULTS */;
/*!40101 SET @OLD_COLLATION_CONNECTION=@@COLLATION_CONNECTION */;
/*!40101 SET NAMES utf8mb4 */;
--
-- Database: `test-1.8.0`
--
-- --------------------------------------------------------
--
-- Table structure for table `schedule`
--
CREATE TABLE `schedule` (
`eventID` int(11) NOT NULL,
`eventTypeId` tinyint(4) NOT NULL,
`CampaignID` int(11) DEFAULT NULL,
`commandId` int(11) DEFAULT NULL,
`recurrence_type` enum('Minute','Hour','Day','Week','Month','Year') DEFAULT NULL,
`recurrence_detail` varchar(100) DEFAULT NULL,
`userID` int(11) NOT NULL,
`is_priority` tinyint(4) NOT NULL,
`FromDT` bigint(20) DEFAULT NULL,
`ToDT` bigint(20) DEFAULT NULL,
`recurrence_range` bigint(20) DEFAULT NULL,
`DisplayOrder` int(11) NOT NULL DEFAULT '0',
`dayPartId` int(11) NOT NULL DEFAULT '0',
`recurrenceRepeatsOn` varchar(14) DEFAULT NULL,
`lastRecurrenceWatermark` bigint(20) DEFAULT NULL,
`syncTimezone` tinyint(4) NOT NULL DEFAULT '0'
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='High level schedule information';
--
-- Dumping data for table `schedule`
--
INSERT INTO `schedule` (`eventID`, `eventTypeId`, `CampaignID`, `commandId`, `recurrence_type`, `recurrence_detail`, `userID`, `is_priority`, `FromDT`, `ToDT`, `recurrence_range`, `DisplayOrder`, `dayPartId`, `recurrenceRepeatsOn`, `lastRecurrenceWatermark`, `syncTimezone`) VALUES
(5, 1, 6, NULL, NULL, NULL, 1, 0, 0, 2556057600, NULL, 0, 1, NULL, NULL, 0),
(6, 1, 6, NULL, NULL, NULL, 1, 0, 1490223600, 1490310000, NULL, 0, 0, NULL, NULL, 0),
(7, 1, 7, NULL, NULL, NULL, 1, 0, 1490223600, 1490310000, NULL, 0, 0, NULL, NULL, 0),
(13, 1, 10, NULL, NULL, NULL, 1, 0, 0, 2556057600, NULL, 0, 1, NULL, NULL, 0),
(14, 1, 9, NULL, NULL, NULL, 1, 0, 0, 2556057600, NULL, 0, 1, NULL, NULL, 0),
(17, 1, 6, NULL, NULL, NULL, 1, 0, 0, 2556057600, NULL, 0, 1, NULL, NULL, 0),
(19, 1, 6, NULL, NULL, NULL, 1, 0, 1490277600, 1499209200, NULL, 0, 0, NULL, NULL, 0);
--
-- Indexes for dumped tables
--
--
-- Indexes for table `schedule`
--
ALTER TABLE `schedule`
ADD PRIMARY KEY (`eventID`),
ADD KEY `layoutID` (`CampaignID`);
--
-- AUTO_INCREMENT for dumped tables
--
--
-- AUTO_INCREMENT for table `schedule`
--
ALTER TABLE `schedule`
MODIFY `eventID` int(11) NOT NULL AUTO_INCREMENT, AUTO_INCREMENT=20;
--
-- Constraints for dumped tables
--
--
-- Constraints for table `schedule`
--
ALTER TABLE `schedule`
ADD CONSTRAINT `schedule_ibfk_1` FOREIGN KEY (`CampaignID`) REFERENCES `campaign` (`CampaignID`);
/*!40101 SET CHARACTER_SET_CLIENT=@OLD_CHARACTER_SET_CLIENT */;
/*!40101 SET CHARACTER_SET_RESULTS=@OLD_CHARACTER_SET_RESULTS */;
/*!40101 SET COLLATION_CONNECTION=@OLD_COLLATION_CONNECTION */;
Well, the records are in that table as expected, which does make sense are they are shown in the agenda. The from and to dates are 0 and 2556057600 respectively, to represent a schedule that runs from 1970 to 2050 - i.e. always.
Why these are not returning in the calendar is confusing.
Can you put your CMS into “Test” mode on the settings page, and then run through the Fault page making sure you have the schedule ready for your display on the previous month. Truncate the logs, run the fault wizard in another tab, and then go to the current month in the schedule.
This should generate the exact SQL it is using to populate the events on the calendar.
Export the logs and pop them on dropbox so we can get to them.
Well… I found something confusing… The values ‘0’ and ‘2556057600’ seem to be correct:
But for some reason it matches 2556057600 to the 24th of November of 1914…
The complete log:
2556057600 is definitely right.
It’s equivalent to 31st December 2050 which is what we use for “infinite” under the hood.
I suspect there’s an issue with the way integers are handled either in the version of PHP or MySQL that you’re using, which means they are being converted to a negative number (it’s what happens when you overflow a 32 bit integer).
I know the number is right. We will try to find out why it isn’t converted to the right date. Will get back at you when we know what causes this problem
I think the MySQL version is probably OK, as those numbers are recorded in a BIGINT column.
Its more likely to be the “2038” problem, where PHP on 32bit systems and windows has a maximum timestamp value of INT32
Whats your environment?
You could try this:
edit /lib/Entity/Schedule.php on Line 41, changing:
public static $DATE_MAX = 2556057600;
to
public static $DATE_MAX = 2147483647;
and then run this SQL:
UPDATE `schedule` SET toDt = 2147483647 WHERE toDt = 2556057600;
If this works for you, we will add it as a bug fix
Oh my god… I cannot believe we did not think of this before 
It makes so much sense.
We are testing 1.8.0 in a Windows Server 2012 R2 environment. Not what we usually use, but it was the easiest way to test the new CMS version on short notice.
Changing the maximum date from December 31th 2050 to February 19th 2038 solved the problem! The ‘Always’ function is working properly right now.
Thanks again!
Fab, ill write that into an upgrade step/patch for 1.8.1 