dan you saved my life!
I was evaluating Xibo: I’ve set up a Linux box as server, two Windows players (one on W7, the other on W8.1), and couldn’t figure out why sometimes it worked, and sometimes not, why I could play videos on the W7 player but not on the W8.1 one, why even a simple web page wasn’t able to be displayed, etc.
Your “patch” works like a charm!
Thank you again,
Georges
Where can I set the download window. i.e. 00:00 to 23:59? I hope this will fix my issue as well.
In the display profile in the CMS. If you haven’t already you’d need to create a default profile for your Windows clients first
I’m pretty sure the bug will only effect people that have created a default - but it would be interesting to know for sure!
Found it and made the change. It is working now. Many thanks…
I installed the patch that you suggested - $value = ($value == ‘00:00’) ? “0” : DateManager::getTimestampFromTimeString($value) * 1000;
setting the time from: 00:10 to 23:50 result to:
outside download windows
setting the time from: 00:00 to 00:00 result to:
inside download windows
Interesting you have a 1 hour discrepancy between your CMS time and client times as shown in the client. It would suggest something CMS side is wrong with regard to timezone and hence why all your other date/time values are out by 1 day too.
Server:
Client Time:
I think the CMS is saving your date in your local time zone, but the players are expecting GMT.
Can you try changing the patch to:
$value = ($value == '00:00') ? '0' : DateManager::getTimestampFromTimeString($value . ' GMT') * 1000;
And then setting the 00:10 to 23:50 setting you had before?
save as:
after save and new edit, the values are no longer correct:
I suppose they wouldn’t be, as they are getting formatted for UTC on output too… I think the below change has limited consequences:
Line 77 lib/app/datemanager.class.php
return gmdate($format, $timestamp);
should I try now?
if so, then what exactly ?
1 or 2
3 : Line 77 is {
$value = ($value == ‘00:00’) ? “0” : DateManager::getTimestampFromTimeString($value) * 1000;
$value = ($value == ‘00:00’) ? ‘0’ : DateManager::getTimestampFromTimeString($value . ’ GMT’) * 1000;
Line 77 lib/app/datemanager.class.php
return gmdate($format, $timestamp);
76 public static function getMidnightSystemDate($timestamp = NULL, $format = NULL)
77 {
78 if ($timestamp == NULL)
79 $timestamp = time();
80
81 // Get the timestamp and Trim the hours off it.
82 $dateTime = new DateTime();
83 $dateTime->setTimestamp($timestamp);
84 $dateTime->setTime(0, 0, 0);
85
86 return self::getSystemDate($dateTime->getTimestamp(), $format);
87 }
Both the changes I mentioned should be applied.
The one in the displayprofile code is adjusting the input to be in GMT always. The one in datemanager is adjusting the output to be in GMT always.
I will be testing this in more detail tomorrow - it should be far easier to recreate as we are in BST.
I believe the changes in this GitHub issue should resolve the problem completely. The times are saved and returned in UTC and the player loads them in UTC, takes the hours and minutes components and puts them in a local date.
Are these changes included in 1.7.3? Because no matter what I try I’m having the same issue - cannot change the default layout. I get errors in the log on each display.
Yes they are included in 1.7.3.
If you have errors logged, the best thing you can do is post a new thread with the errors you have rather than opening up old threads that have already been logged as bugs.
Could you please help me to solve the same problem? In the player on Win7 I cannot see the layout, but preview works well from CMS.
The log says this:
“ScheduleManagerThread|2016.04.05. 18:10:27|Error|ScheduleManager - LoadNewSchedule|Layout invalid: 0
UI Thread|2016.04.05. 18:10:27|Error|MainForm - ChangeToNextLayout|Prepare Layout Failed. Exception raised was: Default layout”
-> But actually I’m using another layout with a different id as well.
Anyway it is not working with the ‘default layout’ in the other hand. Try to reinstall the CMS and the player?