Disabled timers created by Autotimer sometimes are added again

[Alexwilmac]

In the past I used to disable autotimers' created timers (may I call it "autotimered" to avoid the difference from a normal timer and an automated created one? ;) ) in case I did not want to record something, without deleting the autotimer itself.
This is useful particularly for series when you have already recorded an episode or "autotimered" which are set for channels where you can't record from.
Usually, disabling an autotimered does the trick. But lately it's frequently happening that a new timer is created for the same time and channel for whom you already have a disabled autotimered.
It should be useful and comfy to avoid such a behaviour: what do you think?

[Grumpy-Geoff]

Perhaps the EIT of the EPG event has changed, thus the plugin is generating a second timer as the original timer's EIT does not now match the EPG event's EIT.
Look in /etc/enigma2/timers.xml and compare the EITs in the two timers.
I don't think the status of the timer is relevant.

[Alexwilmac]

Yes, I had thought something like this. Only, it would be useful if there was a way to perform such an action.
The basic thing is that the Autotimer is an incredibly useful plugin. Its only weak side is in cases like I described and it would get near the perfection if there was a way to avoid repeated recordings, even by a manual intervention from the user.
Obviously the field which controls the option about how many times you want to record is not good for series, for instance, nor to avoid to record from scrambled channels.

[Grumpy-Geoff]

Yes, I had thought something like this. Only, it would be useful if there was a way to perform such an action.

You can use File Commander to view the file.

The basic thing is that the Autotimer is an incredibly useful plugin. Its only weak side is in cases like I described and it would get near the perfection if there was a way to avoid repeated recordings, even by a manual intervention from the user.

Enabling the setting "Guess existing timer based on begin/end" should help in this case, as long as the duration percentage match when comparing the new event and the original unpadded timer is at least 80%.

[Alexwilmac]

Thanks: I'm doubting the cause is the EIT file: only, knowing it doesn't help to avoid the problem. Instead, for your suggestion! I'll surely try it, hoping it won't interfere in other cases, like EPG errors (it often happens that the XMLTV fonts rewrite an existing EPG with little differences or you have that because of channels which have their own EPG "built-in" system.
But, I'm immediately try your setting! Thanks.

[Grumpy-Geoff]

Did you view the timers.xml file and compare the EIT values in the two timers?

I've never had a new timer generated by an AutoTimer definition for an EPG event where an exiting timer exists within the 80% timer overlap match, but I've run with "Guess existing timer based on begin/end" enabled setting since Adam was a boy.
The enabled/disabled state of the existing timer is not relevant.

[wedebe]

I've had similar happen a while ago (Astra 28*), not sure if it's still happening as I'm in dev mode and adjusting settings and code regularly.

Could it be related to having, for example, FreeSat and Virgin EPGs enabled simultaneously in enigma2 settings (therefore having different EIT)?

[Grumpy-Geoff]

Could it be related to having, for example, FreeSat and Virgin EPGs enabled simultaneously in enigma2 settings (therefore having different EIT)?

Could be.

If EITs match; then 
    update existing timer
else
    if "Guess existing timer based on begin/end" is enabled; then
        if event c.f. timer overlap >= 80%; then
            update existing timer
        else
            create new timer
        eif
    else
        create new timer
    eif
eif