Open egli opened 2 years ago
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.
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
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?
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
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.