Page 2 of 2
Re: Priority value and screen appearance
Posted: 12 Dec 2014 20:47
by radio42
I do not know yet...I need to double-check this here, if I can reproduce it...
Re: Priority value and screen appearance
Posted: 12 Dec 2014 20:59
by radio42
But did you get any issues when enabling the 'Combine Parallel Overlay' option?!
Note, that the other scenario isn't even fully supported; as the 'Prio.' flag was ONLY added for combining parallel overlays and only in that case you might give 2 overlays the exact same start time.
Re: Priority value and screen appearance
Posted: 12 Dec 2014 23:04
by radio42
Not necessary, I found the reason, but your logs are telling the story a bit differently.
Anyhow, as said, it 'was' an unsupported configuration, but it was quite simple to correct that.
The reason, the program/playlist was shortly resumed was due to the 'Allow Start Early' option. That was now corrected.
As such the 2nd waiting overlay wasn't started 'early' anymore, but was now waiting until it's effective time - so that's now corrected (that an uncombined, waiting 2nd overlay can now also start early again). That's why the playlist was resumed and after some time stopped again.
But you said, that the 2nd overlay played OVER the playlist. This I can definitely not reproduce. The log file you send me also clearly shows, that the playlist (current track) was stopped!
So this is unclear - may be you thought it was playing over the playlist, but it wasn't really?
Re: Priority value and screen appearance
Posted: 13 Dec 2014 09:07
by hdradio
But you said, that the 2nd overlay played OVER the playlist. This I can definitely not reproduce. The log file you send me also clearly shows, that the playlist (current track) was stopped!
So this is unclear - may be you thought it was playing over the playlist, but it wasn't really?
The debug log I 've sent you is not for the first time it happened. That time the debug log was not enabled. The second time I enabled it and the result was what I describe
later.
The first time the 2nd overlay played OVER the the next song.
I am absolutely sure because that overlay was a commercial with 1 minute duration and it was playing in parallel with the song.
Re: Priority value and screen appearance
Posted: 13 Dec 2014 11:33
by hdradio
I don't know what 'Suppress" option you mean. The only option I see is 'Suspend program' which was checked.
If you mean ApplySuppressFilter it was unchecked. (in fact I don't even know what this filter is).
Re: Priority value and screen appearance
Posted: 13 Dec 2014 15:49
by radio42
No sorry I mean the Suspend Program option.
But as said without a log it will be impossible to know what happened.
And as said I already found the other issue.
Regarding the 'ApplySuppressFilter' please see here:
viewtopic.php?f=9&t=1264&p=5523#p5523
Re: Priority value and screen appearance
Posted: 13 Dec 2014 20:27
by radio42
Then may be the 'Supress' option was not enabled. I can not tell without the logs.
Re: Priority value and screen appearance
Posted: 13 Dec 2014 22:04
by radio42
Fixed in v3.0.14.28:
- the Upcoming Overlay now also sorts by Priority
- the Upcoming Overlay should now display the Duration correctly
Re: Priority value and screen appearance
Posted: 15 Dec 2014 08:44
by hdradio
- the Upcoming Overlay now also sorts by Priority
Can you do that also on Overlay Scheduler ?
Re: Priority value and screen appearance
Posted: 15 Dec 2014 21:13
by radio42
No. The Scheduler control doesn't allow sorting the displayed items. It is a closed control which sorts the entries internally (by the UI lib vendor) and I have no influence/control over that sorting.