Playlists attr: qeue or schedule

[jmrunge]

There should be an attribute on the playlists that tells mosto if the playlist should be qeued (no matter its start time) or scheduled for a specific time. If qeued, Mosto will look at the time of the playlist just to be aware of the order. If scheduled, Mosto will schedule a job to start playing this playlist no matter what is it playing at the time of schedule.

[Lacrymology]

I'm not sure I understand the difference.

Let's say I've got a playlist running from 3 to 5.

I receive a playlist that says it needs to start at 4.
I understand that if it's scheduled, it'll start at 4:00 regardless.
If it's queued, Will it actually go off at 5?

[jmrunge]

Thats the idea. First, Caspa should warn the operator that he is queuing
an overlaped playlist. And Mosto should warn too. But 'queued' or
'scheduled' are mandatory over the time the playlist's time. We thought on
some kind of automatation (if current playlist ends at 5 and next ends at
5.01, queue it) but finally got to the idea that it was better to be more
explicit about it. We always have to preserve the idea that screen cant go
black. And 'scheduled' will be used more for forcing a playlist to replace
other without having to modify it.

2013/3/28 Tomas Neme [email protected]

I'm not sure I understand the difference.

Let's say I've got a playlist running from 3 to 5.

I receive a playlist that says it needs to start at 4.
I understand that if it's scheduled, it'll start at 4:00 regardless.
If it's queued, Will it actually go off at 5?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/7#issuecomment-15614540
.

[Lacrymology]

why not have the frontend handle this by sending a 'delete' (or a move) command on the replaced playlist and just putting the newly replaced playlist in the required place?

In any case, this would go in the not-yet-implemented "player" interface.

[jmrunge]

Its an option, but for initial release, we also have to handle the case that something will go on air from outside Mosto (live or DVD ie). Thtats another reason for schedule a playlist and not qeue it. And we also should validate everything that comes from Caspa (just in case, defensive progrmming sayed Niv).

Enviado desde mi BlackBerry

-----Original Message-----
From: Tomas Neme [email protected]
Date: Fri, 29 Mar 2013 10:37:54
To: inaes-tic/[email protected]
Reply-To: inaes-tic/mbc-mosto [email protected]
Cc: Juan Martin [email protected]
Subject: Re: [mbc-mosto] Playlists attr: qeue or schedule (#7)

why not have the frontend handle this by sending a 'delete' (or a move) command on the replaced playlist and just putting the newly replaced playlist in the required place?

In any case, this would go in the not-yet-implemented "player" interface.

---

Reply to this email directly or view it on GitHub:
#7 (comment)

[xaiki]

There are 2 different things here.

Its an option, but for initial release, we also have to handle the case
that something will go on air from outside Mosto (live or DVD ie). Thtats
another reason for schedule a playlist and not qeue it. And we also should
validate everything that comes from Caspa (just in case, defensive
progrmming sayed Niv).

I agree with tom: we should handle that state in caspa.
that said, what jm is exposing is elegant too, what i'm concerned about is
how this drags on in history, we started to talk about it in the last
reunion, but I'm not sure how it was settled.

anyway, the 2 points:

1. the common code should check validity, and pull off a flag (in the
   message bus, as not to violate the object belongness) in case of an invalid
   schedule, THAT SHOULD BE RESOLVED by caspa.
   if we do get to an invalid state (invalid is not the right word, maybe
   out-of-common-ops), we need to deal with it (like jm said).
2. for now, we can have holes in the programation. (next we'll have special
   playlists), if we want to put up a DVD we'll have to do it from outside.
   mbc-playout.

anyway, in that case, the playout should still be playing a default loop,

so that if we come back to our stream, no black frames goes on air.

Niv Sardi

[jmrunge]

Agree! I should fill an issue so we dont forgot about the loop... Next meeting we should try to define the "schedule" and "qeue" attrs finally...

[jmrunge]

What happened with this finally? @fabriciocosta, @Lacrymology?

[Lacrymology]

Right now all playlists are set up with the queue method, I think.There's no way in the frontend to handle this right now

[xaiki]

now there is.
we share a common conf.
make it a conf value an #WIN

On 18 April 2013 13:05, Tomas Neme [email protected] wrote:

Right now all playlists are set up with the queue method, I think.There's
no way in the frontend to handle this right now

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/7#issuecomment-16585914
.

Niv Sardi

[jmrunge]

@Lacrymology ? :)

[Lacrymology]

setting a default is not "handling" it. "handling" it would be having a way of creating playlists with different settings on this!

I mean, all playlists right now are ensured to be non-overlapping by the frontend (and will be double-checked by our validation API when we finally have one), and there's no way of generating a playlist that cuts onto another one.

[Lacrymology]

Also, what's the difference between this and the values discussed in #71 ?

[xaiki]

#71 is about cilps in playlists,
this is about playlists between each other.