State or ticket for recording independent work

[jjeising]

Some work is independent of the recording (and encoding) and can be done, as soon as the full metadata is available. An example can be found in voc/voctopublish#73.

[jjeising]

Hmm. This could be a use case for staging/staged ;) The staging state is nowadays more annyoing to the user than when it was invented, I fear.

@a-tze My issue with that approach would be, that the action is not easily repeatable with the current terms. You currently shouldn't reset a meta ticket to staged if metadata changed for example.

[a-tze]

You would reset it to staging.. and yes, the terms don't match and it's a huge change in concept. However, we're talking about things to be done on METAdata, and before recording starts - so from a certain point of view this looks like a match that should at least be considered.

[jjeising]

and before recording starts

I think changes from the Fahrplan like missing or additional speaker already occurred during recording or even after the encoding was done – one of the reasons postencoding exists.

[derpeter]

regarding the meta data we may need a "meta data changed at" field. So if the "pre-recording" worker has already done its job (e.g. render a prerole) can be triggered again if the e.g. the speaker name changed after the intro has been rendered.

For me as an API consumer this sounds like this should be an operation with the meta ticket, even i'm aware that clients should not alter meta tickets for good reasons. I could imagen two solutions:

1. allow clients to properties to a meta ticket and allow it only to alter these properties
2. have another ticket type like "meta-worker-ticket"

[a-tze]

The "metadata changed" problem should be solved by using some hash. There is similar logic in the Auphonic worker. The hash can be stored as a regular property and later be rechecked by a worker script.

Of course a "modification timestamp" field is nice, but the hash solution could be more specific about which metadata attributes it includes. For example it is not relevant for the prerole if the Room or Starttime changed.

[derpeter]

Just for clarification: The worker would build the prerole, calculate a hash over the properties it uses and store that hash in new propertie?

If thats the case i don't see how we would dedect a change without recalculating the hash. As the client chooses which properties are part of the hash, this means that it has to be done by the same client as the tracker don't know whats part of the hash. As a conclusion we would need to do this again and again until the project is archived. right?

[jjeising]

For me as an API consumer this sounds like this should be an operation with the meta ticket, even i'm aware that clients should not alter meta tickets for good reasons.

I'm not sure I understand this yet: what would a worker change on the meta ticket?

As a conclusion we would need to do this again and again until the project is archived. right?

I think we could introduce a property If-modified-since, so a worker would only get the ticket if meta property changed. The worker could then recalculate its hash and return the ticket if nothing changed. As the metadata is only changed by the Tracker on import, it always knows when changes occurred.

I think we should separate detection of changes and how they are handled (and their state) in the this discussion.

[derpeter]

For me as an API consumer this sounds like this should be an operation with the meta ticket, even i'm aware that clients should not alter meta tickets for good reasons.

I'm not sure I understand this yet: what would a worker change on the meta ticket?

It needs to store somewhere that the job is done. This maybe also could be expressed as a state, than we need to allow the worker to change the state of the meta ticket. Or as propertie.

As a conclusion we would need to do this again and again until the project is archived. right?

I think we could introduce a property If-modified-since, so a worker would only get the ticket if meta property changed. The worker could then recalculate its hash and return the ticket if nothing changed. As the metadata is only changed by the Tracker on import, it always knows when changes occurred.

This sounds good to me. Does this also include changed done by the user via the webinterace ? E.g. fixing a typo in the metadata ?

I think we should separate detection of changes and how they are handled (and their state) in the this discussion.

ack

[saerdnaer]

FYI: I prototyped the issue with additional tickets of type encoding. To get information like a Voctoweb.EventId from this additional encoding master ticket to the main master encoding ticket I had to write it to the parent ticket, which then yield following dialog when trying to import a new revision of the schedule.xml:

[jjeising]

which then yield following dialog when trying to import a new revision of the schedule.xml:

My concerns regarding the use of the meta ticket weren't unfounded… flagging imported properties would be kind of a solution, but this might introduce other issues.

[saerdnaer]

[Disclaimer: I has only skim read the previous discussion and was not aware that you already addressed concerns] other possible solutions:

• only update properties which start with Fahrplan.
• merge properties of the 'independent work' ticket type into encoding tickets, like it is already done with recording tickets.

[jjeising]

I would still suggest introducing a new ticket type that handles other video independent tasks like media publishing.

[derpeter]

I would still suggest introducing a new ticket type that handles other video independent tasks like media publishing.

I would also prefer to follow this path as it more intutive and we don't need to discuss everthing again