A quick guide to Beyonwiz T series AutoTimers

[prl]

...
Ok now I'm confused, can I get rid of the ticks on the first page setting up a auto timer or not?

Did you try this? It's also not quite what you want. But if you've tried that and don't like it, you've exhausted the options.

Thanks Peter,
I'm not sure what that link was supposed to show me but I've tried everything and can't get rid of the ticks. It's weird to me to have them ticked by default then say in the guide to untick them. ...

Strange. The usual way of creating links to posts seems to be broken. It intended to be a reference to this earlier post:

If you use EPG, navigate to show, REC, BLUE (instead of EPG, navigate to show, BLUE) I think it should set up an AutoTimer using the defaults set in "Edit new timer defaults". However, it will create the AutoTimer immediately without giving you the opportunity to modify it.

You can still modify it in MENU>AutoTimer.

Using EPG, navigate to show, REC, BLUE will never show the "ticks" screen.

The correct link to the post is this.

[mike007]

...
Ok now I'm confused, can I get rid of the ticks on the first page setting up a auto timer or not?

Did you try this? It's also not quite what you want. But if you've tried that and don't like it, you've exhausted the options.

Thanks Peter,
I'm not sure what that link was supposed to show me but I've tried everything and can't get rid of the ticks. It's weird to me to have them ticked by default then say in the guide to untick them. ...

Strange. The usual way of creating links to posts seems to be broken. It intended to be a reference to this earlier post:

If you use EPG, navigate to show, REC, BLUE (instead of EPG, navigate to show, BLUE) I think it should set up an AutoTimer using the defaults set in "Edit new timer defaults". However, it will create the AutoTimer immediately without giving you the opportunity to modify it.

You can still modify it in MENU>AutoTimer.

Using EPG, navigate to show, REC, BLUE will never show the "ticks" screen.

The correct link to the post is this.

Yeah I tried that and it sets the timer without the time restraint but only on the day set, a way to stop it ticking them in the first place would be great.
Thanks for your help.

[prl]

I'll have a bit of a dig around in the code and see what might be done.

[mike007]

I'll have a bit of a dig around in the code and see what might be done.

Awesome, thanks mate.

[IanSav]

Hi Prl,

I'll have a bit of a dig around in the code and see what might be done.

Perhaps an option can be added to skip the initial tick box screen and just go direct to the main AutoTimer edit screen. This would also better match the AutoTimers to the normal timers UI experience.

Regards,
Ian.

[mike007]

Hi Prl,

I'll have a bit of a dig around in the code and see what might be done.

Perhaps an option can be added to skip the initial tick box screen and just go direct to the main AutoTimer edit screen. This would also better match the AutoTimers to the normal timers UI experience.

Regards,
Ian.

I untick day and time restraints on the first page and do nothing on the second so that would just make even more moves for me. IMO having the option to have whatever you want ticked or not ticked on the first page and being able to skip the second would be better.

[Grumpy_Geoff]

In my opinion, once you've setup AutoTimers using OpenWebif, you'll never go back to the UI way.

[blonk]

Daylight savings has highlighted an issue with my auto timers. Most were an hour out. The Epg was right, but any timer not on 7Flix was firing an hour early for some reason. Only way to get them to update was delete them, and then make a change to one and save, which updated them correctly. My auto timer settings are setup as above, with auto polling on, so I thought they should update automatically. Any thoughts or ideas?

Blonk

[prl]

... Any thoughts or ideas? ...

The traditional semi-annual lottery that is the TV broadcasters' handling of DST time changes?

[netmask]

My cats don't handle DST at all - a chorus of "feed me, feed me now" or we will kill you! The curtains are completely jaded...

[prl]

My cats don't handle DST at all - a chorus of "feed me, feed me now" or we will kill you! The curtains are completely jaded...

Luck you if that only happens around DST changes!

[blonk]

... Any thoughts or ideas? ...

The traditional semi-annual lottery that is the TV broadcasters' handling of DST time changes?

I kind of expected this, but I thought the autotimers automatically updated when refreshed EPG data was generated. Is this not the case? I also ran EPG refresh prior, but this didn't update the existing timers either.

[IanSav]

Hi Blonk,

I kind of expected this, but I thought the autotimers automatically updated when refreshed EPG data was generated. Is this not the case? I also ran EPG refresh prior, but this didn't update the existing timers either.

This is perhaps my greatest disappointment in AutoTimers, once created AutoTimer created timers do not get changed or corrected with updates to the EPG.

Regards,
Ian.

[mike007]

Hi Blonk,

I kind of expected this, but I thought the autotimers automatically updated when refreshed EPG data was generated. Is this not the case? I also ran EPG refresh prior, but this didn't update the existing timers either.

This is perhaps my greatest disappointment in AutoTimers, once created AutoTimer created timers do not get changed or corrected with updates to the EPG.

Regards,
Ian.

My timers have the correct time and so does the EPG, am I to understand that they'll fire an hr early anyway?

[prl]

... My timers have the correct time and so does the EPG, am I to understand that they'll fire an hr early anyway?

Do you have the correct timezone setting (especially, do you have the setting for a timezone that has the right DST rules)? Though I think a wrong timzone setting would have different symptoms.

[mike007]

... My timers have the correct time and so does the EPG, am I to understand that they'll fire an hr early anyway?

Do you have the correct timezone setting (especially, do you have the setting for a timezone that has the right DST rules)? Though I think a wrong timzone setting would have different symptoms.

Yes I'm in Melbourne so +10. When I updated yesterday and set everything up again it was still +10 but it showed DST time, which is of course +11.

Edit- I don't have any symptoms, all my timers are right. Just from previous posts I assumed they were going to fire an hr early anyway.

[prl]

...
Edit- I don't have any symptoms, all my timers are right. Just from previous posts I assumed they were going to fire an hr early anyway.

My misunderstanding, but perhaps those whose timers are out might want to check their timezone settings.

[mike007]

...
Edit- I don't have any symptoms, all my timers are right. Just from previous posts I assumed they were going to fire an hr early anyway.

My misunderstanding, but perhaps those whose timers are out might want to check their timezone settings.

Cool, I'll keep an eye on my first one today just to make sure.

[blonk]

Hi Blonk,

I kind of expected this, but I thought the autotimers automatically updated when refreshed EPG data was generated. Is this not the case? I also ran EPG refresh prior, but this didn't update the existing timers either.

This is perhaps my greatest disappointment in AutoTimers, once created AutoTimer created timers do not get changed or corrected with updates to the EPG.

Regards,
Ian.

So,
Autotimers won't get altered if the EPG times are changed after they are created. I guess it would make sense to only create timers a day in advance to minimise issues. Are there any plans to rectify this issue?

[blonk]

...
Edit- I don't have any symptoms, all my timers are right. Just from previous posts I assumed they were going to fire an hr early anyway.

My misunderstanding, but perhaps those whose timers are out might want to check their timezone settings.

Timezone setttings is GMT + 10, with sync time set at Transponder time. I haven't touched these settings anytime recently.

[mike007]

Hi Blonk,

I kind of expected this, but I thought the autotimers automatically updated when refreshed EPG data was generated. Is this not the case? I also ran EPG refresh prior, but this didn't update the existing timers either.

This is perhaps my greatest disappointment in AutoTimers, once created AutoTimer created timers do not get changed or corrected with updates to the EPG.

Regards,
Ian.

So,
Autotimers won't get altered if the EPG times are changed after they are created. I guess it would make sense to only create timers a day in advance to minimise issues. Are there any plans to rectify this issue?

There's a setting in EPGrefresh to run auto timer after refresh.

[prl]

... Timezone setttings is GMT + 10, with sync time set at Transponder time. I haven't touched these settings anytime recently.

Not really specific enough. There are three GMT+10 settings, for Hobart, Brisbane, and Canberra, Melbourne, Sydney.

They differ on the specifics of their DST settings, so at this time of the year an incorrect setting is likely to make itself known.

IIRC, the Hobart and Canberra, Melbourne, Sydney DST dates are currently the same, but historically Hobart used to have a longer DST period, so different DST dates. The Brisbane setting has no DST change for recent dates, though if you go back far enough DST will apply to some old dates.

[Grumpy_Geoff]

Hi Blonk,

I kind of expected this, but I thought the autotimers automatically updated when refreshed EPG data was generated. Is this not the case? I also ran EPG refresh prior, but this didn't update the existing timers either.

This is perhaps my greatest disappointment in AutoTimers, once created AutoTimer created timers do not get changed or corrected with updates to the EPG.

Regards,
Ian.

So,
Autotimers won't get altered if the EPG times are changed after they are created. I guess it would make sense to only create timers a day in advance to minimise issues. Are there any plans to rectify this issue?

They do get changed, as per setting 'Modify existing timers'. From prl's FAQ:
Modify existing timers controls whether and how timers are updated if their event's time changes in the EPG. "None" disables this feature. "All non-repeating timers" allows the timer to be modified even if its event id is different from the event id in the EPG, and "Only AutoTimers with the same EIT" allows the timer to be changed if the EPG event id is the same as the timer event id. If you want to modify timers using "Guess existing timer on begin/end" (below), you need to set this to "All non-repeating timers". If "Guess existing" is disabled, "All non-repeating timers" and "Only AutoTimers with the same EIT" should have the same effect.

My test - I altered an AutoTimer generated timer from its 17:25 start time to (19:25 and then) 16:25. The AutoTimer plugin came along later and changed it to match the EPG entry (taking into account padding).

[IanSav]

Hi Geoff,

Given your post why do AutoTimer timers for events that are no longer in the EPG get left to run on the wrong program?

Regards,
Ian.

[blonk]

There's a setting in EPGrefresh to run auto timer after refresh.

Thanks, it's already on, and I ran EPG refresh, but timers still didn't update.

[blonk]

... Timezone setttings is GMT + 10, with sync time set at Transponder time. I haven't touched these settings anytime recently.

Not really specific enough. There are three GMT+10 settings, for Hobart, Brisbane, and Canberra, Melbourne, Sydney.

They differ on the specifics of their DST settings, so at this time of the year an incorrect setting is likely to make itself known.

IIRC, the Hobart and Canberra, Melbourne, Sydney DST dates are currently the same, but historically Hobart used to have a longer DST period, so different DST dates. The Brisbane setting has no DST change for recent dates, though if you go back far enough DST will apply to some old dates.

Apologies, GMT +10 Canberra,Melbourne,Sydney. I'm in Sydney.

[mike007]

Hi Geoff,

Given your post why do AutoTimer timers for events that are no longer in the EPG get left to run on the wrong program?

Regards,
Ian.

Yeah we were talking about that a few weeks ago, I was hoping that was fixed in the update, like double recordings supposed to have been. Time will tell I guess.

[blonk]

Hi Blonk,

I kind of expected this, but I thought the autotimers automatically updated when refreshed EPG data was generated. Is this not the case? I also ran EPG refresh prior, but this didn't update the existing timers either.

This is perhaps my greatest disappointment in AutoTimers, once created AutoTimer created timers do not get changed or corrected with updates to the EPG.

Regards,
Ian.

So,
Autotimers won't get altered if the EPG times are changed after they are created. I guess it would make sense to only create timers a day in advance to minimise issues. Are there any plans to rectify this issue?

They do get changed, as per setting 'Modify existing timers'. From prl's FAQ:
Modify existing timers controls whether and how timers are updated if their event's time changes in the EPG. "None" disables this feature. "All non-repeating timers" allows the timer to be modified even if its event id is different from the event id in the EPG, and "Only AutoTimers with the same EIT" allows the timer to be changed if the EPG event id is the same as the timer event id. If you want to modify timers using "Guess existing timer on begin/end" (below), you need to set this to "All non-repeating timers". If "Guess existing" is disabled, "All non-repeating timers" and "Only AutoTimers with the same EIT" should have the same effect.

My test - I altered an AutoTimer generated timer from its 17:25 start time to (19:25 and then) 16:25. The AutoTimer plugin came along later and changed it to match the EPG entry (taking into account padding).

Setting is "All non-repeating timers". If I make a change to an Autotimer it will update fine, it's when the EPG data changes (e.g. program start time is updated by the network), the EPG gets updated, but the Autotimer doesn't.

[Grumpy_Geoff]

Hi Geoff,

Given your post why do AutoTimer timers for events that are no longer in the EPG get left to run on the wrong program?

Regards,
Ian.

AFAIK, the AutoTimer plugin iterates only over the EPG. The plugin does not do a 'reverse run', iterating over AT-generated timers that no longer qualify.


Cheers.
Geoff

[mike007]

Hi Geoff,

Given your post why do AutoTimer timers for events that are no longer in the EPG get left to run on the wrong program?

Regards,
Ian.

AFAIK, the AutoTimer plugin iterates only over the EPG. The plugin does not do a 'reverse run', iterating over AT-generated timers that no longer qualify.


Cheers.
Geoff

Yes, but it should

[mike007]

Another thing that's annoying is if you delete a timer while in progress, it starts recording again. If you delete a recording it should stay deleted

[IanSav]

Hi Geoff,

AFAIK, the AutoTimer plugin iterates only over the EPG. The plugin does not do a 'reverse run', iterating over AT-generated timers that no longer qualify.

Shame. It would be nice if that became an option.

Regards,
Ian.

[Grumpy_Geoff]

...
Setting is "All non-repeating timers". If I make a change to an Autotimer it will update fine, it's when the EPG data changes (e.g. program start time is updated by the network), the EPG gets updated, but the Autotimer doesn't.

Well, I just showed that when the times of an AT-generated timer (taking into consideration either the global padding or the AT definition's custom padding) is not consistent with the relevant EPG entry at the time the EPG is parsed by the AT plugin, the timer is updated.
Note that I didn't alter the AT definition, I simply modified the AT-generated timer.
You don't think my test is valid?

[blonk]

...
Setting is "All non-repeating timers". If I make a change to an Autotimer it will update fine, it's when the EPG data changes (e.g. program start time is updated by the network), the EPG gets updated, but the Autotimer doesn't.

Well, I just showed that when the times of an AT-generated timer (taking into consideration either the global padding or the AT definition's custom padding) is not consistent with the relevant EPG entry at the time the EPG is parsed by the AT plugin, the timer is updated.
Note that I didn't alter the AT definition, I simply modified the AT-generated timer.
You don't think my test is valid?

I don't think it is valid, because you are changing the timer. I've verified that if I do the same, mine gets updated. What you need to do, is update the epg, and see what happens to an existing timer. Unfortunately you can't update the epg. It's like the auto timer is seeing the timer, seeing the epg, but not the time differences, so it gets ignored.

[Grumpy_Geoff]

...
Setting is "All non-repeating timers". If I make a change to an Autotimer it will update fine, it's when the EPG data changes (e.g. program start time is updated by the network), the EPG gets updated, but the Autotimer doesn't.

Well, I just showed that when the times of an AT-generated timer (taking into consideration either the global padding or the AT definition's custom padding) is not consistent with the relevant EPG entry at the time the EPG is parsed by the AT plugin, the timer is updated.
Note that I didn't alter the AT definition, I simply modified the AT-generated timer.
You don't think my test is valid?

I don't think it is valid, because you are changing the timer. I've verified that if I do the same, mine gets updated. What you need to do, is update the epg, and see what happens to an existing timer. Unfortunately you can't update the epg. It's like the auto timer is seeing the timer, seeing the epg, but not the time differences, so it gets ignored.

Here's an example of where the timer was changed 10.5 hours prior to the event start time.
As you can see, the timer was originally generated on 2-Dec. On 9-Dec, its start time was then adjusted to 17:30 (I use IceTV, so the EPG times are on 5-min boundaries, and my pre-padding is 10 minutes).
My guess is that IceTV altered the event start time. That was reflected in the generated timer, as it should,

[mike007]

...
Setting is "All non-repeating timers". If I make a change to an Autotimer it will update fine, it's when the EPG data changes (e.g. program start time is updated by the network), the EPG gets updated, but the Autotimer doesn't.

Well, I just showed that when the times of an AT-generated timer (taking into consideration either the global padding or the AT definition's custom padding) is not consistent with the relevant EPG entry at the time the EPG is parsed by the AT plugin, the timer is updated.
Note that I didn't alter the AT definition, I simply modified the AT-generated timer.
You don't think my test is valid?

I don't think it is valid, because you are changing the timer. I've verified that if I do the same, mine gets updated. What you need to do, is update the epg, and see what happens to an existing timer. Unfortunately you can't update the epg. It's like the auto timer is seeing the timer, seeing the epg, but not the time differences, so it gets ignored.

Mine says "X number of timers modified" after the auto timer runs so I don't know what's happening with yours.

[Gully]

Timezone setttings is GMT + 10, with sync time set at Transponder time. I haven't touched these settings anytime recently.

I don't think anyone picked up on this so far but Transponder time is not reliable generally, much better to use network time sync.

[mike007]

Timezone setttings is GMT + 10, with sync time set at Transponder time. I haven't touched these settings anytime recently.

I don't think anyone picked up on this so far but Transponder time is not reliable generally, much better to use network time sync.

Oh I thought that was the same thing? Do you use the au.pool.ntp.org? I've always used transponder and never had a problem.

[Gully]

Oh I thought that was the same thing? Do you use the au.pool.ntp.org? I've always used transponder and never had a problem.

au.pool.ntp.org is fine.
Transponder means it is coming as part of the TV signal so if they are getting confused, and in the past there have been plenty of examples of that, then you will get your Beyonwiz confused too.

NTP is usually much more reliable.

[mike007]

Oh I thought that was the same thing? Do you use the au.pool.ntp.org? I've always used transponder and never had a problem.

au.pool.ntp.org is fine.
Transponder means it is coming as part of the TV signal so if they are getting confused, and in the past there have been plenty of examples of that, then you will get your Beyonwiz confused too.

NTP is usually much more reliable.

Thanks mate I'll give it a go.

[blonk]

Still getting some timers out by an hour. The only way to update is to delete the timers, and then a new one will be created that matches the EPG. I assume this is a glitch that no-one else is getting, so maybe it's time to bite the bullet and install the latest firmware, and hopefully a new install might resolve it.

[mike007]

Hi guys,
If I set an auto timer on all channels every day with no time restraints it sets the timers but doesn't show up red on the EPG. Alternatively, if I set the auto timer for the program on one channel then try to set it for the same program on another channel the second timer won't set at all. The example is "Supercars: Highlights", it's on One and WINHD on Saturdays and Sundays at different times. Has anyone else noticed this and if so, is it a bug or something I'm doing wrong?
Cheers Mike

[MrQuade]

If I set an auto timer on all channels every day with no time restraints it sets the timers but doesn't show up red on the EPG.

It might be setting the timer on a service that is not in your favourites bouquet. Several channels Like One, are broadcast on multiple LCNs. If you only have the One that appears on LCN 12 in your bouquet, the autotimer may be actually recording from the One that appears on LCN1.

Open the Terrestrial TV LCN bouquet in your EPG and see if the recording appears in that on the alternate One service.

[mike007]

If I set an auto timer on all channels every day with no time restraints it sets the timers but doesn't show up red on the EPG.

It might be setting the timer on a service that is not in your favourites bouquet. Several channels Like One, are broadcast on multiple LCNs. If you only have the One that appears on LCN 12 in your bouquet, the autotimer may be actually recording from the One that appears on LCN1.

Open the Terrestrial TV LCN bouquet in your EPG and see if the recording appears in that on the alternate One service.

Oh yes, that's exactly what's happening. Is there a way to make sure it sets on the one in my favourites list?

Edit- also that doesn't explain why the second timer won't set on a different channel for a program with the same name.

[MrQuade]

Open the Autotimer settings and press BLUE to add services.
Enable the "Enable service restriction" and change "Editing" to "Bouquets"
Then press BLUE to select and add whatever bouquets you want.

Edit- also that doesn't explain why the second timer won't set on a different channel for a program with the same name.

Autotimers will not set recordings for duplicate events if it can help it. Since you were already recording on the One service, the Win one (being a duplicate) would not be set.

[mike007]

Open the Autotimer settings and press BLUE to add services.
Enable the "Enable service restriction" and change "Editing" to "Bouquets"
Then press BLUE to select and add whatever bouquets you want.

Yesssss...it took me a while but I finally got it lol
Thanks heaps MrQuade

[prl]

Yes, filtering and channel selection in AutoTimers aren't exactly user-friendly interfaces.

And when you're using quotes, the Preview button is your friend

[prl]

Also, it may be useful to use MENU>AutoTimer, MENU>Edit new timer defaults to set up your bouquet choice for all future AutoTimer creations

[mike007]

And when you're using quotes, the Preview button is your friend

Umm..... not sure what that means but ok.