Disable checking in encoding profile

[v0tti]

It should be possible to disable checking for certain encoding profiles. On many events the "subformats" are released without checking.

[saerdnaer]

When implementing this issue, I would opt for a generic way to disable different states configurable in the encoding profile – c.f. cloud encoding.

[jjeising]

There is already an unmerged (private) pull request that needs some minor work. Will merge soon.

[jjeising]

Working on this in #162.

[a-tze]

Counter-proposal: make checking an automatable state.

Advantages:

• changes to data model are very small, no structural changes AFAICS
• some automated checking (minimum: proper decoding, check of duration) is better than no checking at all and maybe even better than human checking, as is demonstrated by this issue

Disadvantages:

• Checking worker will usually need to have a ticket filter to not work on master tickets. Forgetting this filter will be a likely trapdoor

[MaZderMind]

@a-tze can't a checker-worker filter on the encoding-profile-properties? In the early days we had room .filter as part of the API – i don't know if that part of the API is still there.

[a-tze]

@MaZderMind Yes, having a filter in the worker is a valid counter-measure, but I did not want that to be a mandatory part of the concept ;)

That part of the API is still there, because there is no other way for the recording worker to filter out recording tickets by their time properties on the server-side, e.g. not getting all of them, inspect the property and then reset them. But IMO the worker-side filter is something with a mixed track record, and I would rather tend to drop it when it's in the way. It just makes things intransparent.

[MaZderMind]

@a-tze From a bare logic standpoint it would be okay to have a "Automatic Checker Worker" which only checks Encoding-Tickets who's Encoding-Profiles have an "eligible-for-automatic-checking=yes" property.

I can't see the intransparency in this.

[a-tze]

Hmm. True. This will correlate 99.9% with the master property but an additional property on encoding profiles is not expensive and improves this thing.

[MaZderMind]

@a-tze most importantly it is explicit and does inherently document what it does and who uses it.

[pegro]

Properties on encoding profiles get propagated to all projects assigning them. So you can't have automatic-checking disabled in a project, while having it enabled in another!?

I would propose introducing a corresponding flag on the project-profile-assignment, as a database column, disabled as default. Saves us from joining even more tables?!

I also think generally properties which are inherently important for the application (excluding crs-scripts), should be stored as columns instead of properties.

[MaZderMind]

@pegro We could have a second Property, like we currently have with Publishing.YouTube.Enable=yes (on the Project) and Publishing.YouTube.EnableProfile=yes (on the Profile)