Rounding problems with total-time

[egli]

Apparently once a year there is a rounding problem with total-time. This then causes a problem in the validation. Ask Beat for more details.

[egli]

The problem appears to be that in rare cases the sum of the play times of all included audio files in a book is not exactly the same as the total-time specified in the ncc file. If that is the case the validator complains and hence mdr2 refuses to touch the production.

If that happens the operator needs to go in and manually fix the total-time in the ncc file. Usually all it takes is to increase the time (hh:mm:ss) by one second.

[egli]

We use the configurable validator from the pipeline1 to check if a dtb is valid. In theory you can pass a time-tolerance which would solve our problem to the implementation but this parameter is not exposed in the script.

The daisy202-validator of the Pipeline2 also has this parameter only this time it is exposed in the API.

So the choice is to either

1. modify the source of Pipeline1 to support Time Tolerance
2. or migrate to Pipeline2 for dtb validation

The second option is certainly more appealing, since we will eventually have to migrate to Pipeline2 anyway. There is however the risk that the Pipeline2 dtb validator behaves slightly differently than the validator from the Pipeline1.

What is the verdict?

[egli]

Currently Madras is still using pipeline1 for this due to a bug in Pipeline2 (daisy/pipeline#653). However this has been fixed in the mean time and we could in theory explore this idea again