Scheduling with problems in Developer 1.8.3

Scheduling with problems in Developer 1.8.3

The Schedule of 1.8.2 had some problems, so I followed each evolution of code in the development of 1.8.3. Several issues have been resolved, congratulations to the developer team.

There are still two problem items:

When editing a schedule, the daypart field (always, personalized or daypart) is not loading the option defined in the schedule, it is loading the combobox incorrectly. EX: Create a schedule with Allways, click edit and you will see that the schedule type will not be loaded like allways

Schedules with repeat feature, optional scheduling is not working. Test, create a custom schedule from 00:00 to 01:00, set the replay every hour until the end of the day. The scheduling does not work, the android player status screen is listed as * layout, as layout not scheduled. Apparently it’s putting it as a second default layout.

NOTE: I took the liberty of testing something in development because it is the most important function of the system, as it has not yet released version 1.8.3, I hope you have time to correct these two items for this release.

Thank you :champagne:

I can’t recreate this unfortunately - i create a schedule with “always”, save it, edit it and it is set to always as expected. The same is true with custom and any other day part that has been predefined.

When I do that I see this:

which looks correct

I then call Schedule on XMDS and I get this:

<?xml version="1.0" encoding="UTF-8"?>
<schedule generated="2017-10-19 18:22:24" fitlerFrom="2017-10-19 00:00:00" fitlerTo="2017-10-21 00:00:00">
   <layout file="1" fromdt="2017-10-19 00:00:00" todt="2017-10-19 01:00:00" scheduleid="30" priority="0" />
   <layout file="1" fromdt="2017-10-19 01:00:00" todt="2017-10-19 02:00:00" scheduleid="30" priority="0" />
   <layout file="1" fromdt="2017-10-19 02:00:00" todt="2017-10-19 03:00:00" scheduleid="30" priority="0" />
   <layout file="1" fromdt="2017-10-19 03:00:00" todt="2017-10-19 04:00:00" scheduleid="30" priority="0" />
   <layout file="1" fromdt="2017-10-19 04:00:00" todt="2017-10-19 05:00:00" scheduleid="30" priority="0" />
   <layout file="1" fromdt="2017-10-19 05:00:00" todt="2017-10-19 06:00:00" scheduleid="30" priority="0" />
   <layout file="1" fromdt="2017-10-19 06:00:00" todt="2017-10-19 07:00:00" scheduleid="30" priority="0" />
   <layout file="1" fromdt="2017-10-19 07:00:00" todt="2017-10-19 08:00:00" scheduleid="30" priority="0" />
   <layout file="1" fromdt="2017-10-19 08:00:00" todt="2017-10-19 09:00:00" scheduleid="30" priority="0" />
   <layout file="1" fromdt="2017-10-19 09:00:00" todt="2017-10-19 10:00:00" scheduleid="30" priority="0" />
   <layout file="1" fromdt="2017-10-19 10:00:00" todt="2017-10-19 11:00:00" scheduleid="30" priority="0" />
   <layout file="1" fromdt="2017-10-19 11:00:00" todt="2017-10-19 12:00:00" scheduleid="30" priority="0" />
   <layout file="1" fromdt="2017-10-19 12:00:00" todt="2017-10-19 13:00:00" scheduleid="30" priority="0" />
   <layout file="1" fromdt="2017-10-19 13:00:00" todt="2017-10-19 14:00:00" scheduleid="30" priority="0" />
   <layout file="1" fromdt="2017-10-19 14:00:00" todt="2017-10-19 15:00:00" scheduleid="30" priority="0" />
   <layout file="1" fromdt="2017-10-19 15:00:00" todt="2017-10-19 16:00:00" scheduleid="30" priority="0" />
   <layout file="1" fromdt="2017-10-19 16:00:00" todt="2017-10-19 17:00:00" scheduleid="30" priority="0" />
   <layout file="1" fromdt="2017-10-19 17:00:00" todt="2017-10-19 18:00:00" scheduleid="30" priority="0" />
   <layout file="1" fromdt="2017-10-19 18:00:00" todt="2017-10-19 19:00:00" scheduleid="30" priority="0" />
   <layout file="1" fromdt="2017-10-19 19:00:00" todt="2017-10-19 20:00:00" scheduleid="30" priority="0" />
   <layout file="1" fromdt="2017-10-19 20:00:00" todt="2017-10-19 21:00:00" scheduleid="30" priority="0" />
   <layout file="1" fromdt="2017-10-19 21:00:00" todt="2017-10-19 22:00:00" scheduleid="30" priority="0" />
   <layout file="1" fromdt="2017-10-19 22:00:00" todt="2017-10-19 23:00:00" scheduleid="30" priority="0" />
   <layout file="1" fromdt="2017-10-19 23:00:00" todt="2017-10-20 00:00:00" scheduleid="30" priority="0" />
   <default file="1" />

Which also looks correct.

I’ve not watched by android player for the whole time - but it did change to the Layout I was expecting and keep it there for at least an hour.

That is great - its really helpful to do this!! We definitely want to fix issues before we release if we can!

Please watch the video with the demo.

This problem occurs if you have at least one daypart created.

Another problem is that you have created some daypart, even if unused in any schedule, when you create a schedule of type allways and in sequence delete the daypart you created (unused), the system automatically erases all allways schedules.

Using repeat…
Not Working…

I guess all of your problems might be because your “Tarde” daypart has an ID of 1.

-- Auto increment 2 on purpose - 1 is reserved
CREATE TABLE `daypart` (
  `name` VARCHAR(50) NOT NULL,
  `description` VARCHAR(1000),
  `isRetired` TINYINT(4) DEFAULT 0,
  `userid` INT(11) NOT NULL,
  `startTime` VARCHAR(8) DEFAULT '00:00:00',
  `endTime` VARCHAR(8) DEFAULT '00:00:00',
  `exceptions` TEXT NULL,
  PRIMARY KEY (`dayPartId`)

When the daypart table is created it sets AUTO_INCREMENT=2 on purpose, so that 1 is reserved for the Always day part.

Can you check in your database and see if this is the case? It could explain all of the issues you’re seeing.


Hello Dan, the problem was exactly this for the daypart, I deleted the table and created it again. It worked…
It is not good practice to tie the ID, you could have the Allways entered as ID 1 and prevent its deletion.

Still have problem with schedules with repetition, did you see the print of the status of the players that I sent?

Dan, I did a lot of testing.

Allways - OK
Custom Simple - OK
Custom Repeat - OK
Daypart simple - does not play
Daypart Repeat - does not play

If you want to try: PM send with login information

Thanks! we will take a look at your CMS. If you would prefer to set a more secure password on that you can PM it to me.

@Peter - can you please have a look when you get a chance next week

Hi Laercio,

Thank you for the access to your CMS, I had my device connected to it for a bit and did some testing with your dayparts etc.

I believe we’ve found the real issue behind it, the send files in advance option in CMS Settings, you’ve significantly changed it from the default value it is set to 1440s = 24min, which in itself is not quite correct and it also exposed a different issue for us.

The problem is fixed here -

It will be in the 1.8.3 release, you’re of course welcome to apply this patch locally to your CMS.

Alternatively change the files lookahead back to the default value 172800 (or anything over 1 day really).

Hi Peter, good afternoon.

Unfortunately, it is not possible to run the schedule by period (simple and with repetition), even after adjusting the parameter.

Unfortunately the parameter was quite out of the ordinary, I did several tests to try to make the scheduling with daypart work. For this reason the value was so out of the ordinary.

Here’s the test script:

557 - Allways (OK)
485 - Custom - No Repeat (OK)
492 - Custom - With Repeat (OK)

567 - Daypart - With No Repeat (NOT OK)
(Not Show on Player) / (Show on CMS Schedule)

As I did not want to edit your files lookahead from the current value, I had to change your schedule slightly, as it’s around 9 am your time I changed the daypart to something that will be detected by the player with your current settings - as the filter will not work perfectly well with 24min files lookahead.

schedule generated="2017-10-24 08:51:23" fitlerFrom="2017-10-24 08:51:23" fitlerTo="2017-10-24 09:15:23";
  layout file="557" fromdt="1969-12-31 21:00:00" todt="2038-01-19 01:14:07" scheduleid="3" priority="0";
  layout file="485" fromdt="2017-10-23 00:00:00" todt="2017-12-31 00:00:00" scheduleid="1" priority="0";
  layout file="492" fromdt="2017-10-24 00:01:00" todt="2017-10-24 23:59:00" scheduleid="2" priority="0";
  layout file="567" fromdt="2017-10-24 06:00:00" todt="2017-10-24 12:00:00" scheduleid="4" priority="0";

^ that’s from your player when I added a new event with the 6-12 daypart on it (I’ve removed the event as I did it only to test it and get the schedule).

Since that’s schedule.xml from the player, I’d expect it to show all those events at the specified times, if it’s not displaying all of them, then it might be something else rather than schedule as that part seems to be ok now - still that 24min files lookahead is far from perfect.

Hello Peter, I want to put a 24-hour pattern in the lookahead files. I only put 24 min for testing, since the daypart with repeat schedule was not working I started to test the parameters.

I saw that now the scheduling daypart and daypart with repeat are running.
In short was it just the lookahead parameter that generated the problem?

Indeed we believe that’s all it was.

24min or anything lower than a day would have a chance to cause scheduling issues, because it did not get the current time properly instead the player searched from midnight ie in your case it was 00:00:00 to 00:24:00 any event outside of that was not correctly sent to the player.

With the change Dan made, it does get the current time correctly now, which would help even if the lookahead is set to a low number, still I’d recommend to leave it at least at 24h.

Hello Peter and Dan,

With code 1.8.3 I am not able to put layout in groups of layouts, I get the msg that the layout does not exist.
Can you reproduce this problem?

You mean assign layouts to the campaign?

No, I do not have this issue here on 1.8.3.

Could you enable CMS auditing / test mode, recreate the issue and check what errors does this create on Logs page?

Not Found#0 \lib\Entity\Schedule.php(945): Xibo\Factory\DayPartFactory->getById(10) #1 \lib\Entity\Schedule.php(692): Xibo\Entity\Schedule->calculateDayPartTimes(Object(Jenssegers\Date\Date), Object(Jenssegers\Date\Date)) #2 \lib\Entity\Schedule.php(637): Xibo\Entity\Schedule->generateMonth(Object(Jenssegers\Date\Date)) #3 \lib\Service\DisplayNotifyService.php(276): Xibo\Entity\Schedule->getEvents(Object(Jenssegers\Date\Date), Object(Jenssegers\Date\Date)) #4 \lib\Entity\Campaign.php(559): Xibo\Service\DisplayNotifyService->notifyByCampaignId(785) #5 \lib\Entity\Campaign.php(351): Xibo\Entity\Campaign->notify(Array) #6 \lib\Controller\Campaign.php(567): Xibo\Entity\Campaign->save(Array) #7 [internal function]: Xibo\Controller\Campaign->assignLayout(‘785’) #8 \vendor\akrabat\rka-slim-controller\RKA\Slim.php(79): call_user_func_array(Array, Array) #9 [internal function]: RKA\Slim->RKA{closure}(‘785’) #10 \vendor\slim\slim\Slim\Route.php(468): call_user_func_array(Object(Closure), Array) #11 \vendor\slim\slim\Slim\Slim.php(1357): Slim\Route->dispatch() #12 \vendor\slim\slim\Slim\Middleware\Flash.php(85): Slim\Slim->call() #13 \vendor\slim\slim\Slim\Middleware\MethodOverride.php(92): Slim\Middleware\Flash->call() #14 \lib\Middleware\Actions.php(142): Slim\Middleware\MethodOverride->call() #15 \lib\Middleware\Theme.php(35): Xibo\Middleware\Actions->call() #16 \lib\Middleware\WebAuthentication.php(133): Xibo\Middleware\Theme->call() #17 \lib\Middleware\CsrfGuard.php(62): Xibo\Middleware\WebAuthentication->call() #18 \lib\Middleware\State.php(117): Xibo\Middleware\CsrfGuard->call() #19 \lib\Middleware\Storage.php(47): Xibo\Middleware\State->call() #20 \lib\Middleware\Xmr.php(36): Xibo\Middleware\Storage->call() #21 \vendor\slim\slim\Slim\Slim.php(1302): Xibo\Middleware\Xmr->call() #22 \web\index.php(124): Slim\Slim->run() #23 {main}

Hi Peter,

Something specific in this CMS that generated this problem, some untreated situation.
In another CMS with the same code I was able to create, unfortunately I could not trace the reason …