Countdown Final (weird Expire behaviour)

[Black Hole]

I think the hmt utility should extract what is in the .hmt file without modification.

FWIW, I agree that's the best policy.

Lack of "obvious error" checking.

I know you're not knocking anyone, but just as a general comment for readers: that is the nub of engineering. It is only possible to counter error situations that are anticipated, and the art is to have the imagination to anticipate them.

It seems to me the end recording time is a better measure of the age of a recording than the start time, but it needs a sanity check (or the result of any calculation based on it should be sanity-checked).

The problem with BH's box is probably caused by being multi-region tuned and the Scheduled end data is not as expected.

How so? The Recording End value is valid now, and if it is not valid until the recording has completed but utilities are using a proxy value because they don't realise the recording has not completed and it is a proxy value, there is a systemic problem. It just happens that the problem has shown up on a multi-region box.

It's not clear to me what there is in the .hmt to declare whether a recording is in progress or finished. If it can be determined, then perhaps there should be an additional property output by the hmt utility.

 

[prpr]

I know you're not knocking anyone, but just as a general comment for readers: that is the nub of engineering. It is only possible to counter error situations that are anticipated, and the art is to have the imagination to anticipate them.

Absolutely.

How so?

Speculation based on observed effects, but without the actual evidence to back it up.

It's not clear to me what there is in the .hmt to declare whether a recording is in progress or finished.

There isn't. Techniques include checking for the .ts file growing and/or the file being open for write by the humaxtv process.

 

[prpr]

An update to prevent this problem from recurring is in the latest webif and sweeper beta packages.