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.
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.
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.
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?
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.
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:
LayoutID:
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.
^ 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?
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.
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 …
