Duplicate Autotimer recordings.

[Mork]

I am occasionally seeing some Autotimers creating two identical recordings.

Not a big problem, but somewhat annoying. Anecdotally it only seems to happen when recording 10HD,but that could be coincidence.

I have seen this on both my V2, and now on my U4 after applying the latest update. Was not apparent on the older U4 firmware.

EDIT: I found a few similar posts in the T2/T3/T4/U4 Threads. They all seem to indicate the issue started in Firmware build v19.3, and may be related to situations where the broadcaster changes the EPG Event ID or details when the machine is tuned to the same channel just prior to the timer firing. - I have set the uniqueness test in the AutoTimer to "On Same Service" and "Title and Description" and see if that stops it. But other threads are unclear if that worked.

[Mork]

Screenshot of duplicate recording off a single Autotimer. Note different durations..

[Barboots]

Are your autotimers set to only respond to matches in your Favourites bouquet? Prior to learning of the need to do this I was getting numerous duplicate recordings.

Cheers, Steve

[Grumpy_Geoff]

Screenshot of duplicate recording off a single Autotimer. Note different durations..

The nuffies at Network TEN must've originally incorrectly published The Project for 18:30-21:45, then later published it with a new EPG event ID (EIT) and for 18:30-19:30, and the AutoTimer plugin has reacted and created a new timer.
Even enabling setting "Guess existing timer based on begin/end" wouldn't have helped in this case as the duration percentage match between the new event and the original unpadded timer's duration was not at least 80%.
[assuming I understand the "timeSimilarityPercent" code in the plugin]

[Jan]

Yes, I occasionally get this issue as well, and usually on Ch10. I have all options set correctly as advised in all the other posts about this issue, but still it happens sometimes. I have decided not to waste any more energy on it, and just delete the extra timer/recording!

[Mork]

Today, both my U4 and my V2 independently created duplicate recordings on 10HD ("The Project" on the U4 and "Bold an the Beautiful" on the V2).

It could be something to do with the 10HD EPG Stream that impacts V19.4 Firmware versions.

The Uniqueness flag made no difference here.

BTW - It is not me that watches "The Bold an the Beautiful"

[Gully]

Today, both my U4 and my V2 independently created duplicate recordings on 10HD ("The Project" on the U4 and "Bold an the Beautiful" on the V2).

It could be something to do with the 10HD EPG Stream that impacts V19.4 Firmware versions.

The Uniqueness flag made no difference here.

BTW - It is not me that watches "The Bold an the Beautiful"

Are you sure you don't watch it? You must be the only one with v19.4 firmware!

[martbd]

Try setting the recording to repeat Monday-Friday or weekly, it worked for me.

[Grumpy_Geoff]

Today, both my U4 and my V2 independently created duplicate recordings on 10HD ("The Project" on the U4 and "Bold an the Beautiful" on the V2).

Not enough info to offer a suggestion.
Attach a copy of the /etc/enigma2/timers.xml file.

[Mork]

@Grumpy_Geoff.

Sorry I missed your request. I have attached timer files for both devices.

The duplication only appears in the timerlist a couple of days out from the recording start.

The issue only seems to happen on Ch10, and is seen on both my U4 and V2 recorders.

The U4 file shows the duplication for 10HD News, but the V2 file does not show the same for Mondays "Bold and the Beautiful", but it probably will on Sunday night

IMPORTANT - I want it abundantly clear that it is not me that watches "Bold and the Beautiful"

[Grumpy_Geoff]

The U4 file shows the duplication for 10HD News, but the V2 file does not show the same for Mondays "Bold and the Beautiful", but it probably will on Sunday night

Here's the two timers for "LIVE: 10 News First" for today -

Code: Select all

<timer begin="1599893820" end="1599898800" serviceref="1:0:19:634:603:1014:EEEE0000:0:0:0:" repeated="0" rename_repeat="1" name="LIVE: 10 News First" description="Comprehensive coverage of local, national and international news. Plus, all the latest sport and weather." afterevent="auto" eit="13431" tags="" disabled="0" justplay="0" always_zap="0" descramble="1" record_ecm="0" isAutoTimer="1">
<log code="500" time="1599274772">[AutoTimer] Try to add new timer based on AutoTimer LIVE: 10 News First.</log>
<log code="509" time="1599274772">[AutoTimer] Timer start on: Sat Sep 12 16:57:00 2020</log>
</timer>
<timer begin="1599893821" end="1599898801" serviceref="1:0:19:634:603:1014:EEEE0000:0:0:0:" repeated="0" rename_repeat="1" name="LIVE: 10 News First" description="Comprehensive coverage of local, national and international news. Plus, all the latest sport and weather." afterevent="auto" eit="13728" tags="" disabled="0" justplay="0" always_zap="0" descramble="1" record_ecm="0" isAutoTimer="1">
<log code="500" time="1599812234">[AutoTimer] Try to add new timer based on AutoTimer LIVE: 10 News First.</log>
<log code="509" time="1599812234">[AutoTimer] Timer start on: Sat Sep 12 16:57:01 2020</log>
</timer>

They have different program event IDs (EIT), thus they're are considered different program events -
eit="13431"
eit="13728"
The start times differ by one second. The timer for eit 13431 was generated Sat Sep-5 12:59:32, whilst the timer for eit 13728 was generated yesterday 18:17:14.
The TEN Network pulled the original event and replaced it, rather than simply updating the original event's time.

Here's the duplicate "The Bold & The Beautiful" from Thursday. Again with different EITs (13061 c.f. 13664). Start times differ by 32 seconds and program duration by 33 seconds -

Code: Select all

<timer begin="1599719280" end="1599722400" serviceref="1:0:19:634:603:1014:EEEE0000:0:0:0:" repeated="0" rename_repeat="1" name="The Bold &amp; The Beautiful" description="Liam is stunned to learn that Hope did not keep her commitment. Steffy?s desperation begins to show when Finn declines her urgent request." afterevent="auto" eit="13061" tags="" disabled="0" justplay="0" always_zap="0" descramble="1" record_ecm="0" isAutoTimer="1">
<log code="500" time="1599104677">[AutoTimer] Try to add new timer based on AutoTimer The Bold &amp; The Beautiful.</log>
<log code="509" time="1599104677">[AutoTimer] Timer start on: Thu Sep 10 16:28:00 2020</log>
<log code="5" time="1599719260">activating state 1</log>
<log code="0" time="1599719260">Found enough free space to record</log>
<log code="0" time="1599719260">Filename calculated as: &apos;/media/hdd/movie/20200910 1628 - 10 HD - The Bold &amp; The Beautiful&apos;</log>
<log code="6" time="1599719260">prepare ok, waiting for begin</log>
<log code="5" time="1599719280">activating state 2</log>
<log code="11" time="1599719280">start recording from: Tuner A</log>
<log code="5" time="1599722400">activating state 3</log>
<log code="12" time="1599722400">stop recording from: Tuner A</log>
</timer>
<timer begin="1599719248" end="1599722401" serviceref="1:0:19:634:603:1014:EEEE0000:0:0:0:" repeated="0" rename_repeat="1" name="The Bold &amp; The Beautiful" description="Liam is stunned to learn that Hope did not keep her commitment. Steffy?s desperation begins to show when Finn declines her urgent request." afterevent="auto" eit="13664" tags="" disabled="0" justplay="0" always_zap="0" descramble="1" record_ecm="0" isAutoTimer="1">
<log code="500" time="1599644665">[AutoTimer] Try to add new timer based on AutoTimer The Bold &amp; The Beautiful.</log>
<log code="509" time="1599644665">[AutoTimer] Timer start on: Thu Sep 10 16:27:28 2020</log>
<log code="5" time="1599719228">activating state 1</log>
<log code="0" time="1599719228">Found enough free space to record</log>
<log code="0" time="1599719228">Filename calculated as: &apos;/media/hdd/movie/20200910 1627 - 10 HD - The Bold &amp; The Beautiful&apos;</log>
<log code="6" time="1599719228">prepare ok, waiting for begin</log>
<log code="5" time="1599719248">activating state 2</log>
<log code="11" time="1599719248">start recording from: Tuner A</log>
<log code="15" time="1599720262">record time changed, start prepare is now: Thu Sep 10 16:27:11 2020</log>
<log code="15" time="1599722062">record time changed, start prepare is now: Thu Sep 10 16:27:08 2020</log>
<log code="5" time="1599722401">activating state 3</log>
<log code="12" time="1599722401">stop recording from: Tuner A</log>
</timer>

The solution is to enable AutoTimer setting "Guess existing timer based on begin/end".
I've banged on about it enough on this forum.

[Mork]

Thanks Mr Grumpy.

It took me a while to find that setting, but will see it it fixes it.

[Grumpy_Geoff]

It took me a while to find that setting, but will see it it fixes it.

It will.

[kj3931]

"The solution is to enable AutoTimer setting "Guess existing timer based on begin/end".
I've banged on about it enough on this forum."

"It took me a while to find that setting, but will see it it fixes it."

Perhaps it's only a man's look, but I can't find the setting, can someone please give me a hint?
I am getting some duplicate recordings on The Project - Channel 10 again.
Perhaps someone could educate them to edit existing EIT's rather than deleting the previous ones and creating new ones?
(Spoken out of total ignorance how this process works / is supposed to work)

[prl]

"The solution is to enable AutoTimer setting "Guess existing timer based on begin/end".
I've banged on about it enough on this forum."

"It took me a while to find that setting, but will see it it fixes it."

Perhaps it's only a man's look, but I can't find the setting, can someone please give me a hint?

From live TV, MENU>AutoTimers, MENU>Settings>Guess existing timer based on begin/end.

It's on the second page of settings.

The settings in that page refer to all AutoTimers.

MENU>AutoTimers, MENU>Edit new timer defaults allows you to set up defaults for all new AutoTimers when they are created.

Perhaps someone could educate them to edit existing EIT's rather than deleting the previous ones and creating new ones?
(Spoken out of total ignorance how this process works / is supposed to work)

The FreeTV Operational Practice OP 58 Implementation Guide for DVB EIT Schedule Information just says:

2.6 Unique Identification of an Event

Every event in the event loop of an Event Information Section is assigned a unique identifier known as the event_id. This unique identifier is used to link the event information in the two EIT tables, EIT_schedule_actual and EIT_p/f_actual. The event_id broadcast in the EIT_schedule_actual for an event shall be the same event_id that is broadcast in the EIT_p/f_actual for that particular event.

But since broadcasters routinely ignore other parts of that document (section 2.5, for example), even if there was a useful rule, there's no guarantee that they'd bother to follow it.

[kj3931]

Thanks, I hadn't realised that there was a MENU for affecting ALL Autotimers before getting to the MENU for the individual Autotimers. You never stop learning!
As for ignoring the rules for EITs, I'm not surprised. No doubt there were numerous serious efforts combined with many team meetings involved in setting up the rules, only to be overridden by individual work practices and "Chinese whisper"-type training. So the issue perpetuates ....

[sonicblue]

I've noticed this issue as well. For me it was on network 10 with recordings of MotoGP. I will try Grumpy Geoff's solution and report back if it works.

I thought AutoTimer checks the event description for uniqueness, and since they have the same description it should not add the duplicate anyway.

[Grumpy_Geoff]

I thought AutoTimer checks the event description for uniqueness, and since they have the same description it should not add the duplicate anyway.

Enabling AutoTimer setting "Guess existing timer based on begin/end" just allows an existing timer on the same service to be modified to match the new EPG times, if the original event has been replaced by the broadcaster (different EIT) and the time similarity is greater than 80%, rather than creating a new timer. You can tell when this "guess" has occurred, as the timer's log entries will have an additional entry -
"[AutoTimer] Warning, AutoTimer {x} messed with a timer which might not belong to it: {y} ."

The creation of a new timer has an issue, depending on if you're doing a uniqueness check on a short description only match or a short and extended description match.
The description matching is actually checking for a greater than 70% similarity.
The extended description matching works okay when comparing EPG events and existing recordings if both have extended descriptions, but it has a flaw I believe, when one of the extended descriptions is missing (e.g. when comparing events and timers because timers do not have an extended description) - see below.
This is why I limit uniqueness checks to short descriptions only.


My pseudo-code summary of the similarity checks -

Code: Select all

# check name & description similarity:
-------------------------------------
default similarity decision -- create a new timer (consider this event a non-duplicate)
if the event/timer names are greater than an 80% match, then 
    # go on to check descriptions
    if "Check for uniqueness in" is "Title and Short description" or "Title and all descriptions"
        if the short descriptions are greater than a 70% match, then
            if "Check for uniqueness in" is "Title and all descriptions", then
                if both extended descriptions are present, then  (*** which can't be true for timers)
                    if the extended descriptions are greater than a 70% match, then
                        decision -- don't create a new timer
                    else 
                        decision -- do create a new timer
                    end-if
                end-if  #### this is the problem if either extended description is not present, no decision made to NOT create (i.e. default "creation" position is left)
            else
                # short desc is similar, but no further checking of extended desc requested
                decision -- don't create a new timer
            end-if
        end-if
    else
        decision -- don't create a new timer
    end-if
end-if

In code terms, it's currently this -

Code: Select all

					foundShort = (0.7 < SequenceMatcher(lambda x: x == " ", shortdesc1, shortdesc2).ratio())
					if foundShort:
						if timer.searchForDuplicateDescription == 2:
							if extdesc1 and extdesc2:
								# Some channels indicate replays in the extended descriptions
								# If the similarity percent is higher then 0.7 it is a very close match
								retValue = (0.7 < SequenceMatcher(lambda x: x == " ", extdesc1, extdesc2).ratio())
						else:
							retValue = True

whereas I think it should be like this -

Code: Select all

					foundShort = (0.7 < SequenceMatcher(lambda x: x == " ", shortdesc1, shortdesc2).ratio())
					if foundShort:
						retValue = True   ### relocate else clause to here ###							
						if timer.searchForDuplicateDescription == 2:
							if extdesc1 and extdesc2:
								# Some channels indicate replays in the extended descriptions
								# If the similarity percent is higher then 0.7 it is a very close match
								retValue = (0.7 < SequenceMatcher(lambda x: x == " ", extdesc1, extdesc2).ratio())

[sonicblue]

Thanks for the info Geoff, that would explain some of the other unusual behaviour I've observed with AutoTimers.

Also, I've observed that sometimes a recording won't have a description, or even a wrong description, eg:



This would cause unexpected recordings when an AutoTimer is set to require uniqueness in "any service/recording" since the recording's description is incorrect.

The strategy I'm currently using to control how sensitive my AutoTimers are to duplicates is:

a. Set my new AutoTimer default to require uniqueness "on any service" and check uniqueness in "title and all descriptions". This seems to bias AutoTimer polls to err on the side of having duplicates rather than failing to record an episode. My reasoning here is that by default I want to cast my net as wide as possible and ensure no episodes are missed (since missing an episode would be highly annoying if you are following a series).

b. If an AutoTimer is regularly recording too many duplicate episodes and I want to shrink the net a bit, I'll set that individual AutoTimer's require uniqueness to "any service/recording".

Given your last post about Timers not having extended descriptions, it appears possible to shrink the net even further by modifying (b) to check uniqueness in "title and short description" as well.

[sonicblue]

Also, I reckon the EPG Refresh plugin interferes with AutoTimer in such a way that creates some very weird and bugged behaviour, and would recommend against using EPG Refresh unless you absolutely need it (even though it's intended to work in conjunction with AutoTimer). Just my experience, may not be true for everyone, just putting it out there.

[MrQuade]

Also, I reckon the EPG Refresh plugin interferes with AutoTimer in such a way that creates some very weird and bugged behaviour, and would recommend against using EPG Refresh unless you absolutely need it (even though it's intended to work in conjunction with AutoTimer). Just my experience, may not be true for everyone, just putting it out there.

What makes you think that? EPGRefresh just visits services periodically. Does it actually interact with Autotimers in any other way (other than having a setting to run an autotimers scan after it runs)?

I could be mistaken, but doesn't EPGRefresh rely on all the same mechanisms that fetch EPG info that occur when you zap to a service?

[Henk]

Also, I reckon the EPG Refresh plugin interferes with AutoTimer in such a way that creates some very weird and bugged behaviour, and would recommend against using EPG Refresh unless you absolutely need it (even though it's intended to work in conjunction with AutoTimer). Just my experience, may not be true for everyone, just putting it out there.

Maybe start using the script in:

Provider visiting - keeping the FTA EPG current

viewtopic.php?f=46&t=12968

for a more frequent update of the EPG.

[sonicblue]

What makes you think that? EPGRefresh just visits services periodically. Does it actually interact with Autotimers in any other way (other than having a setting to run an autotimers scan after it runs)?
I could be mistaken, but doesn't EPGRefresh rely on all the same mechanisms that fetch EPG info that occur when you zap to a service?

I agree there is no apparent logical reason why EPGRefresh should interfere with AutoTimer.

But EPGRefresh does have code which interacts with AutoTimer. And AutoTimer has code that interacts with EPGRefresh too ("skip poll during EPG refresh"). Without looking at the source code I can't say what the extent of the interaction is, whether it might be doing something weird.

Perhaps it might have something to do with the way EPGRefresh's "fake recording" interacts with the EPG cache?

All I know is I was getting all kinds of weird bugged recordings, like these 4 hour recordings that had nothing to do with the AutoTimer it was supposed to be related to. Since deleting EPGRefresh and clearing out all timers and starting from scratch, I've not had any major issues like that.

Maybe start using the script in:
Provider visiting - keeping the FTA EPG current
viewtopic.php?f=46&t=12968
for a more frequent update of the EPG.

Cheers, I'll give that a try.

-------------------------------------

Question for Geoff or anyone knowledgeable in the AutoTimer source code: when AutoTimer is polling and iterating through current timers to check for duplicates, does it only check against active timers, or completed timers as well? I was observing some behaviour which might be explained by not checking against completed timers.

eg. suppose the same event is shown at 19:30 and then again at 22:30. The 19:30 recording finishes, and its timer is now in a "completed" state, and it's not in the EPG either since completed events are no longer in the EPG. At the next AutoTimer poll, AutoTimer finds no duplicate event in the EPG nor in the active timers list (and doesn't check recordings either since by default I'm not checking recordings) and so the 22:30 showing gets added.

[Grumpy_Geoff]

Also, I've observed that sometimes a recording won't have a description, or even a wrong description, eg:

This would cause unexpected recordings when an AutoTimer is set to require uniqueness in "any service/recording" since the recording's description is incorrect.

I think the title and description meta data for a recording is fetched from the EPG at the "prepare" time of the timer, which is 20 seconds before the timer begins recording.
Thus, that MotoGP recording with the MacGyver title/descriptions is unlikely to actually be a MotoGP recording, and Network TEN pulled the MotoGP event some time after the timer was generated and before the broadcast time and replaced it with a MacGyver episode.
This example shouldn't block an "Any service/recording" uniqueness test because the description will be vastly different from a MotoGP event.

[sonicblue]

Thus, that MotoGP recording with the MacGyver title/descriptions is unlikely to actually be a MotoGP recording

I checked it now and it is a MotoGP recording.

This example shouldn't block an "Any service/recording" uniqueness test because the description will be vastly different from a MotoGP event.

But the purpose of setting "any service/recording" is to more rigorously weed out duplicates, and since it's a false positive for uniqueness, it failed its purpose of weeding out the duplicate.

But a false positive for uniqueness is still desirable to me, as it's better than a false negative which would have resulted in a potential miss of that round of MotoGP (well not really, because 10 shows each round multiple times per week).

[Grumpy_Geoff]

Perhaps it might have something to do with the way EPGRefresh's "fake recording" interacts with the EPG cache?

All I know is I was getting all kinds of weird bugged recordings, like these 4 hour recordings that had nothing to do with the AutoTimer it was supposed to be related to. Since deleting EPGRefresh and clearing out all timers and starting from scratch, I've not had any major issues like that.

Coincidence, I'd say.
Fake recording is simply streaming (to no where). No different to zapping, as MrQuade has previously mentioned.

Question for Geoff or anyone knowledgeable in the AutoTimer source code: when AutoTimer is polling and iterating through current timers to check for duplicates, does it only check against active timers, or completed timers as well? I was observing some behaviour which might be explained by not checking against completed timers.

eg. suppose the same event is shown at 19:30 and then again at 22:30. The 19:30 recording finishes, and its timer is now in a "completed" state, and it's not in the EPG either since completed events are no longer in the EPG. At the next AutoTimer poll, AutoTimer finds no duplicate event in the EPG nor in the active timers list (and doesn't check recordings either since by default I'm not checking recordings) and so the 22:30 showing gets added.

Completed timers too. That's why I keep completed timers for 8 days.

[sonicblue]

I'm still unclear why checking for uniqueness in "title and short description" wouldn't solve OP's issue.

If OP had set "title and all descriptions", then sure, I can see an issue where the duplicate EPG event has a long description, but its existing timer only has a short description, in which case EPG's long description != existing timer's None long description, creating a false positive for uniqueness and adding the duplicate.

The fact that network 10 changed the event ID seems to me irrelevant as uniqueness testing looks at title and description, not event ID (or is my understanding wrong here?).

[MrQuade]

("skip poll during EPG refresh")

I don't think that specifically means the "EPG Refresh" plugin, rather simply any time the EPG is being refreshed at any time.

[Grumpy_Geoff]

("skip poll during EPG refresh")

I don't think that specifically means the "EPG Refresh" plugin, rather simply any time the EPG is being refreshed at any time.

It does mean the EPGRefresh plugin, the AutoTimer plugin has code to detect if the EPGRefresh plugin is running.

[MrQuade]

It does mean the EPGRefresh plugin, the AutoTimer plugin has code to detect if the EPGRefresh plugin is running.

Ahh yes, I did see that now in the help text. I stand corrected.

[Grumpy_Geoff]

It does mean the EPGRefresh plugin, the AutoTimer plugin has code to detect if the EPGRefresh plugin is running.

Ahh yes, I did see that now in the help text. I stand corrected.

I think that's 15-all today, your serve

[Grumpy_Geoff]

I'm still unclear why checking for uniqueness in "title and short description" wouldn't solve OP's issue.

If OP had set "title and all descriptions", then sure, I can see an issue where the duplicate EPG event has a long description, but its existing timer only has a short description, in which case EPG's long description != existing timer's None long description, creating a false positive for uniqueness and adding the duplicate.

The fact that network 10 changed the event ID seems to me irrelevant as uniqueness testing looks at title and description, not event ID (or is my understanding wrong here?).

I don't think Mork had a uniqueness test applied. In his edit he states he's (now) applied it to see if it'll make a difference.

In a follow-up post, he had duplicates with 10 News and Bold & the Beautiful. The news program always has the same description, thus a uniqueness test can't be applied. A new timer was created when the original EPG event was replaced with a new one (new EIT). An enabled "guess existing timer" would've let the plugin identify the original timer (> 80% times match) and then update it to reflect the changed times rather than creating a duplicate.

If EITs match, or if "guessing existing timer" and at least 80% time match, then the existing timer is updated. "guessing existing timer" is really the king setting.
Else, the existing timer is left untouched, but is checked for similarity on this service if uniqueness is requested. Remember though, the EPG event may have both descriptions whilst the timer has one only. Thus, the event may not be identified as a duplicate, giving rise to a new timer (below).
Then if a timer for this service was touched, or the event was identified as similar, skip this event.
Otherwise, run through all of the other timers looking for a duplicate - but the time check granularity is to the second, thus unlikely to identify the existing timer, and a new timer is created.

None of the above would matter much if the AutoTimer plugin cleaned up after itself and removed "orphaned" timers that didn't have a matching event (by EIT). There's commented out code to do it.

So, (i) enable "Guess existing timer based on begin/end", (ii) set Check for uniqueness in to "Title and Short description", (iii) use a curated bouquet devoid of simulcasts.
Job done, please thank your mother for the rabbits.

[prl]

I agree there is no apparent logical reason why EPGRefresh should interfere with AutoTimer.

Depends on what you mean by "interfere".

But EPGRefresh does have code which interacts with AutoTimer. And AutoTimer has code that interacts with EPGRefresh too ("skip poll during EPG refresh"). Without looking at the source code I can't say what the extent of the interaction is, whether it might be doing something weird.

EPGRefresh can be configured to use the service list configured in AutoTimers to ensure that the EPG refresh refreshes all services that are used by AutoTimer.

EPGRefresh can be configured to start an AutoTimer scan so that AutoTimers are checked and brought into line with any EPG changes that were made in the run of EPGRefresh that just completed. However, the code that does that looks a bit odd, and could mean that the option doesn't in fact run the AutoTimer update as intended.

Perhaps it might have something to do with the way EPGRefresh's "fake recording" interacts with the EPG cache?

Recordings, fake or real, only read from the EPG cache, mainly to create the recording's .ts.eit file.

[sonicblue]

So,
(i) enable "Guess existing timer based on begin/end"
(ii) set Check for uniqueness in to "Title and Short description"
(iii) use a curated bouquet devoid of simulcasts.

I'm unsure about (ii) because it means recordings will be missed if the event data is something like this:

Static title: Sports Sunday
Static short description: Sports Sunday
Unique long description: Featuring Australia's leading sports personalities, Sports Sunday presents a frank and open debate...

However in the above example, even setting "title and all descriptions" would fail since all episodes of Sports Sunday happen to have a static long description too. In this case the only way to not miss episodes is to set Require description to be unique: None.

I've also seen events like this:

Static title: Event Title
Not necessarily unique short description: Consumer advice: A
Unique long description: The quick brown fox jumped over the lazy dog

In this case any episodes with the same consumer advice would be missed. Although it seems the networks tend to follow this convention for movies only, so it's probably not an issue for series.

Also I would add to the list:

(iv) set Require uniqueness to "any service/recording" if you want a better chance at avoiding duplicates

(v) keep completed Timers for >7 days as they are needed for uniqueness testing (the setting for this is in the main menu Setup > TV > Recording Settings > Remove completed timers after)

(vi) for live sporting events, use partial title matching as the networks don't always give them the same title, eg. some showings of MotoGP are titled "MotoGP 2020", others are "LIVE: MotoGP 2020".

(vii) when you have many AutoTimers, polling can be CPU intensive and make the GUI a bit unresponsive during the poll. To minimise this, poll less frequently eg. every 3 hours. Another potential benefit of polling less frequently is that if the network slightly modifies event data <3hrs before the event airs, it shouldn't confuse AutoTimer into creating duplicates. However a potential downside is when the network changes event data <3hrs before it airs and you actually want your AutoTimer to use that new updated event data.

[sonicblue]

(iii) use a curated bouquet devoid of simulcasts.

But remember the uniqueness test will try and weed out those simulcast events anyway based on their short/long descriptions. It's only if the uniqueness test is failing that bouquet restriction will help.

Hypothetically if I was going to look at improving the AutoTimer source code (which I won't be doing, since I'm burnt out and AutoTimer currently works "good enough") the first thing I would do is to implement long descriptions into the Timer list, so that the AutoTimer uniqueness test will be more accurate.

[sonicblue]

Just spotted this in the EPG

Static title: Top Gear
Static short description: Top Gear
Unique long description: Matt is the first to test the Ford GT in America; presenter Chris and Sabine Schmitz go head to head in a buggy race across the Californian desert.

All episodes of Top Gear currently in the EPG follow this convention, so checking for uniqueness in "title and short description" would fail to record more than 1 episode per week, unless the user manually deletes its completed timer, which should allow the next episode to be added at the next AutoTimer poll, since the completed timer would be the only duplicate causing the uniqueness test to fail.

[prl]

There is no single method that I know of that would make AutoTimers reliably avoid repeats when it uses the FTA EPG, and reliably not mistaking a first run program for a repeat.

The metadata to do it simply doesn't exist in the FTA EPG.

There are lots of inconsistencies when you try using description matching. Regular current affairs shows and related panel shows tend to always have the same description data, though there, repeats can be distinguished by timeslot and/or channel. It's not uncommon for "live reality" documentary shows to have the same the same description over all (or most) episode (e.g. Bondi Vet).

Sometimes the broadcasters have some sort of mark in gthe title or description, e.g. on WIN Canberra, Have You Been Paying Attention? on Mon 28 Sep, and Have You Been Paying Attention? - Encore on Fri 2 Oct, but that's pretty unusual.

[sonicblue]

​Yep, there doesn't seem to be a magic setting that will get it right to a high degree of accuracy.

My main concern is the case where all episodes in a series have the same short and long descriptions, since those would cause missed episodes regardless of the uniqueness testing setting. For those series, uniqueness testing must be disabled altogether.

In light of this, I'm starting to think a preferable strategy might be to simply use a larger HDD, eg. 4tb, and just let it record duplicates.

Another option is to do an EPG search prior to setting up an AutoTimer, to see what convention the network is using for that particular show, and set uniqueness testing accordingly.

For example I can see that all episodes in this particular show have the same short and long description, and I would disable uniqueness testing altogether for this show:



Whereas for this show, the short and long descriptions are unique for each episode, and so either uniqueness testing method should suffice:



I presume IceTV solves the issue as well, but I've never actually used it. Is it reliable?

[Paul_oz53]

I presume IceTV solves the issue as well, but I've never actually used it. Is it reliable?

Within limits, yes. It's greatest weakness is late changes of programming. Sometimes a double episode added without notice will not be recorded. Usually, these are poor rating shows late at night.

I have used it for years and generally find it reliable for prime time shows.

Sometimes I get two copies of a show if it's a repeat of an older series. I just delete the extras.

[prl]

Like Paul, I've used IceTV for years, and I find it generally pretty reliable for what I want to watch. The IceTV UI is also way simpler to use than AutoTimers.

IceTV uses a feed of the ABC and SBS EPG for their channels - there, the reliability is close to the same as the broadcasters'. And it isn't all that much better than for the commercial channels where IceTV has to pretty much create their own EPG.

A good way of gauging the level of errors in IceTV is to follow the IceTV EPG Content section on the IceTV forum where most of the complaints/requests about the EPG content are made by users. Repeat mislabelling is one of the most frequently complained-of aspects of the IceTV guide. However, when you look at the errors, remember that they're across several thousand programs every week.

It is possible to use IceTV in combination with AutoTimers. There, you can use the IceTV feature of being able to add a consistent tag to the title of repeated programs ("[R]" by default), which you can then use a filter on in an AutoTimer to exclude repeats. There are a number of Beyonwiz IceTV users who also use AutoTimers, especially for programs that run daily or on weekdays. IceTV sets timers for these for a week ahead, while AutoTimers set only a timer for the next episode of the program, so using AutoTimers there can reduce the amount of clutter in your timers list.

The Beyonwiz IceTV plugin explicitly prevents IceTV from taking over management of recordings set by AutoTimers.

[sonicblue]

​
Another option is to do an EPG search prior to setting up an AutoTimer, to see what convention the network is using for that particular show, and set uniqueness testing accordingly.

For example I can see that all episodes in this particular show have the same short and long description, and I would disable uniqueness testing altogether for this show...whereas for this show, the short and long descriptions are unique for each episode, and so either uniqueness testing method should suffice.

It occurred to me this could be done automatically, such as by implementing an AutoTimer setting called "automatically choose uniqueness testing" which could search the epg for all episodes and automatically select the appropriate method.

However the payoff is not that big as it doesn't take that long to do the epg search manually, and setting up an AutoTimer is not something that is done so often that significant time or effort is saved. It might still be worth having for new users to improve ease of use.