MontysEvilTwin
Well-Known Member
By default my units are set up for accurate recording, but I use the Multimode package to pad recordings on selected channels. I also use Detectads for chaserun processing of non-BBC TV channels. This works fine for both AR and padded channels when the recordings are set up from the TV guide. However, while manual timer recordings work, they are only processed by Detectads if they are on a channel with AR recording (default setting), if the channel is flagged for padding in Multimode, it is not processed by Detectads: the recording is not even checked by Detectads for channel exclusion.
The problem may be be deeper than Detectads: it might be caused by an interaction between Multimode and the system autoprocessing. If the unit is brought out of standby during the recording, at the end of the recording, rather than being decrypted immediately as the result of an autotrigger process, it is not processed until the next scheduled scan.
I tested this earlier by setting a manual timer recording to run from 10:56 AM until noon (CBS Action - a channel I set for padding). The system booted at 10:53:41 (according to activity.log), the recording started at 10:56:01 and finished at 11:59:59 (according to redring.log: I could not find the event logged anywhere else). It was not processed by Detectads and was decrypted when the next autoscan ran at 12:05. Oddly the filename was 'CBS Action_20160418_1054' (recording actually started at 10:56). I also noticed while the recording was running that the start time was set in the hmt file as 10:54 and the end time was 12:02 (68 minutes rather than the actual duration of 64 minutes). When the recording finished at noon (as scheduled in the manual timer), the end time in the hmt file was amended to 11:58 (incorrect) with a duration of 64 minutes (correct). It seems that while the recording happened correctly as defined by the timer, some of the system settings were as if padding had also been applied to the manual timer. This behaviour is incorrect, but I don't know if it is responsible for the failure of Detectads to process the recording.
The problem may be be deeper than Detectads: it might be caused by an interaction between Multimode and the system autoprocessing. If the unit is brought out of standby during the recording, at the end of the recording, rather than being decrypted immediately as the result of an autotrigger process, it is not processed until the next scheduled scan.
I tested this earlier by setting a manual timer recording to run from 10:56 AM until noon (CBS Action - a channel I set for padding). The system booted at 10:53:41 (according to activity.log), the recording started at 10:56:01 and finished at 11:59:59 (according to redring.log: I could not find the event logged anywhere else). It was not processed by Detectads and was decrypted when the next autoscan ran at 12:05. Oddly the filename was 'CBS Action_20160418_1054' (recording actually started at 10:56). I also noticed while the recording was running that the start time was set in the hmt file as 10:54 and the end time was 12:02 (68 minutes rather than the actual duration of 64 minutes). When the recording finished at noon (as scheduled in the manual timer), the end time in the hmt file was amended to 11:58 (incorrect) with a duration of 64 minutes (correct). It seems that while the recording happened correctly as defined by the timer, some of the system settings were as if padding had also been applied to the manual timer. This behaviour is incorrect, but I don't know if it is responsible for the failure of Detectads to process the recording.