Feature Request - Autotimers

[ccs]

Extending the end time of a timer created by autotimer works fine until autotimer runs again and changes it back.

One solution is to disable the autotimer in question, but you need to remember to re-enable it later.:)

Would it be possible in some way to prevent autotimer from changing the new end time?

Maybe change the timer type to a one-off timer? (This would probably result in another auto timer being created.)

Or flag the timer as "changed by user", so assume it's ok.

[Tkr001]

Or simply allow a new auto timer field to add n minutes at the end of this auto timer only would work for me. Particularly useful for live sports events that are prone to overrun.

[birdman]

Extending the end time of a timer created by autotimer works fine until autotimer runs again and changes it back.That's configurable ("Modify exisiting timers"), but you probably want to leave it on in general.


One solution is to disable the autotimer in question, but you need to remember to re-enable it later.:)Another is to edit the specific autotimer setting the timer and set a "Custom offset" with a relevant end "after recording" offset. This will affect all timers set by it, but would probably be preferably to disabling the autotimer and then forgetting to re-enable it.


Would it be possible in some way to prevent autotimer from changing the new end time?The issue with this is determining when you don't want it to change....


Or flag the timer as "changed by user", so assume it's ok....and then the start time changes as well.

[abu baniaz]

I think there is an underlying issue that needs investigation and resolution.

During overruns, the now-next EPG shows the current/active/overrunning event. Recording the event results in a name of the scheduled event. Surely now-next EPG should be taken into account at the highest priority. I believe there is a mix up with now next and EIT. I may be wrong.





Incidentally, the AutoTimer plugin OE-A teams use is many commits behind the one PLI uses. Picking them in is beyond my ability as they took different paths several years ago owing to be un/able to deal with tasks . IIRC one of the recent commits was to recognise Series number.

[birdman]

During overruns, the now-next EPG shows the current/active/overrunning event. Recording the event results in a name of the scheduled event. Surely now-next EPG should be taken into account at the highest priority. I believe there is a mix up with now next and EIT. I may be wrong.Given that there is a difference between what the EPG shows and what pops up with the "OK" button (the InfoBar?) in such instances I think you are correct.


Incidentally, the AutoTimer plugin OE-A teams use is many commits behind the one PLI uses. Picking them in is beyond my ability as they took different paths several years ago owing to be un/able to deal with tasks . IIRC one of the recent commits was to recognise Series number.Are they in the same git?
I actually have my own mods to the AutoTimer code (it allows you to set time periods when checking for similar descriptions...a requirement when EFL football highlights were on Channel5, 5+1, and Spike and I might be running out of tuners - the need went away with Channel5 HD) so might have a look.

[ccs]

Thanks for the replies.

One thing I noticed during the World Cup, an autotimer rescheduled from Tuesday to Wednesday was added ok, but the original wasn't deleted, even though there were 2 or 3 days notice to work it out.

[birdman]

Thanks for the replies.

One thing I noticed during the World Cup, an autotimer rescheduled from Tuesday to Wednesday was added ok, but the original wasn't deleted, even though there were 2 or 3 days notice to work it out.That would be because the AutoTimer code only adds and adjust timers (if one it would set overlaps with an existing timer).
To delete them it would need to keep a list at the start of its run of those set by AT code, remove each one as it finds it (again) and then delete any timers remaining in that list. But it doesn't...
It also doesn't happen all that often...

[ccs]

That would be because the AutoTimer code only adds and adjust timers (if one it would set overlaps with an existing timer).
To delete them it would need to keep a list at the start of its run of those set by AT code, remove each one as it finds it (again) and then delete any timers remaining in that list. But it doesn't...
It also doesn't happen all that often...

…. Timer List/Info tells you when a timer has been created by autotimer, so it's already known, and a list won't be needed??

It's no big deal, unless I happen to run out of tuners :), I thought it used to work once upon a time, but could be wrong.

[birdman]

…. Timer List/Info tells you when a timer has been created by autotimer, so it's already known, and a list won't be needed??Yes it will. You need to keep a list of those that are auto-timer-set and remove all that are "still-creatable" from it as you go. Anything left in the list at the end can be deleted.
Mind you, this fails if you happen to have an EPG failure which incorrectly wipes out an autotimer-set timer just before it is about to record.

[ccs]

Enabling "Custom Offset/After Recording" on the autotimer looks like a good compromise, it changes timers currently recording as well as future timers.

So I can make a change when I know there's an overrun, and it's not the end of the world if I forget to change it back.

Something like the Tour de France (next year), say, can have a permanent additional hour for all recordings without any hassle.