Autotimer Uniqueness

[scotty]

I'm having some trouble setting up an autotimer with "Require description to be unique".

Having the setting set to No generates 4 timers.
Having the setting set to any combination of On same service, On any service, Any service/recording with uniqueness in Title (expected), Title and Short description, Title and all descriptions, only generates 1 timer on Tuesday.

Code: Select all

<timer name="Mister Maker" match="Mister Maker" enabled="yes" location="/media/hdd/movie/Will/" offset="5" avoidDuplicateDescription="3" searchType="start">

The short and long descriptions are unique for 3 of the 4 episodes:

• Tue 03.07.2018 - Series 2 , Episode 17 - Mister Maker makes springy...
• Wed 04.07.2018 - Series 2 , Episode 18 - Mister Maker transforms...
• Thu 05.07.2018 - Series 2 , Episode 19 - Mister Maker makes a...
• Fri 06.07.2018 - Series 2 , Episode 19 - Mister Maker makes a...

Not sure what I'm missing.

Running build 20180627.
IceTV with repeat marking at end of title "(Rpt)", which all of these episodes are.

Scotty

[Grumpy_Geoff]

Yep, I only got one -

Code: Select all

{21921}< 37826.343> [RecordTimer] [AutoTimer] Try to add new timer based on AutoTimer test - Mr. Maker.
{21921}< 37826.344> [RecordTimer] [AutoTimer] Timer start on: Tue Jul  3 14:55:00 2018
{21921}< 37826.478> [RecordTimer] Record RecordTimerEntry(name=[R] Mister Maker, begin=Tue Jul  3 14:55:00 2018, end=Tue Jul  3 15:55:00 2018, serviceref=1:0:1:2E2:261:3201:EEEE0000:0:0:0:, justplay=0, isAutoTimer=True)

Sometimes, I find the plugin just won't behave.
In those situations, I remove the restriction and set the duplicate timer to disabled (e.g. Friday's "Series 2 Episode 19")

But, ourguide.com.au shows that Friday's episode is S02E20, so not a duplicate of Thursday's S02E19.
http://www.ourguide.com.au/searcher.php ... on=+Search+

The FTA guide on my U4 shows different episodes for Thursday and Friday -
Thu: "Mister Maker makes a sticky picture using kitchen scourers, shows you how to create a fish tank in a minute and demonstrates how to make a stretchy lorry."
Fri: "Mister Maker shows how to scrunch up your picture for a great effect, creates springy creatures that will surprise your friends and demonstrates how to make a hilarious big head mask."

[Grumpy_Geoff]

I did the same test on our T4 which also is using the IceTV EPG as the above T2 test does - it also just generated one timer.
The T2 uses the repeat marking in the title, whilst the T4 uses it in the short description.

I just did the same AutoTimer test on our U4 which is running the FTA EPG, it generated 5 timers for Tue, Wed, Thu, Fri, and Mon.

Perhaps the AutoTimer plugin doesn't like the "," in the IceTV short description and stops there for the uniqueness test.

[scotty]

Thanks for testing and confirming the same result Grumpy_Geoff.

...Perhaps the AutoTimer plugin doesn't like the "," in the IceTV short description and stops there for the uniqueness test.

I was just thinking the same thing.

Scotty

[prl]

Thanks for testing and confirming the same result Grumpy_Geoff.

...Perhaps the AutoTimer plugin doesn't like the "," in the IceTV short description and stops there for the uniqueness test.

I was just thinking the same thing.

It's a bit more complicated than that. The check for similarity is done using the Python library function difflib.SequenceMatcher.ratio(). It considers the two events to be the same if the compared description fields all have a similarity ratio > 0.7 (on a scale 0.0 .. 1.0). I doubt that commas play any special role in that.

[adoxa]

I'm having some trouble setting up an autotimer with "Require description to be unique".

Having the setting set to No generates 4 timers.
Having the setting set to any combination of On same service, On any service, Any service/recording with uniqueness in Title (expected), Title and Short description, Title and all descriptions, only generates 1 timer on Tuesday.

• Tue 03.07.2018 - Series 2 , Episode 17 - Mister Maker makes springy...
• Wed 04.07.2018 - Series 2 , Episode 18 - Mister Maker transforms...
• Thu 05.07.2018 - Series 2 , Episode 19 - Mister Maker makes a...
• Fri 06.07.2018 - Series 2 , Episode 19 - Mister Maker makes a...

The short description is considered the same, so that explains why "Title and Short description" only generates one.

Code: Select all

>>> difflib.SequenceMatcher(lambda x: x==" ", "Series 2, Episode 17", "Series 2, Episode 18").ratio()
0.95

That determines the similarity ratio between the two strings, ignoring space. AutoTimer considers them the same if it's greater than 0.7. Presumably something similar is occurring with the IceTV description. If you'd like to post the exact descriptions, I could test it (unless prl does so).

[Grumpy_Geoff]

...Presumably something similar is occurring with the IceTV description. If you'd like to post the exact descriptions, I could test it (unless prl does so).

Series 2 , Episode 17
Mister Maker makes springy bugs in under a minute, transforms sponges into a work of art and shows how to turn an old plastic bottle into a fantastic firefly.

Series 2 , Episode 18
Mister Maker transforms sticky back plastic and tissue paper into a terrific work of art, makes a jazzy spinner in a minute and shows how to make a brilliant box puppet.

Series 2 , Episode 19
Mister Maker makes a sticky picture using kitchen scourers, shows you how to create a fish tank in a minute and demonstrates how to make a stretchy lorry.

Series 2, Episode 20
Mister Maker shows how to scrunch up your picture for a great effect, creates springy creatures that will surprise your friends and demonstrates how to make a hilarious big head mask.

[scotty]

Thanks Grumpy_Geoff. Beat me to it!
I see Ice has corrected the Friday one now.

Scotty

[Grumpy_Geoff]

...I see Ice has corrected the Friday one now.

I reported it to IceTV - http://forum.icetv.com.au/iceforum/icet ... 9#msg31509

[Grumpy_Geoff]

The short description is considered the same, so that explains why "Title and Short description" only generates one.
...

A 'Title and all descriptions' uniqueness check still only generates one timer.
Perhaps the plugin isn't grabbing the extended description?

[adoxa]

Well, 18, 19 & 20 are all sufficiently different from 17.

Code: Select all

>>> difflib.SequenceMatcher(lambda x: x==" ", "Mister Maker makes springy bugs in under a minute, transforms sponges int
o a work of art and shows how to turn an old plastic bottle into a fantastic firefly.", "Mister Maker transforms sticky
back plastic and tissue paper into a terrific work of art, makes a jazzy spinner in a minute and shows how to make a bri
lliant box puppet.").ratio()
0.3241590214067278
>>> difflib.SequenceMatcher(lambda x: x==" ", "Mister Maker makes springy bugs in under a minute, transforms sponges int
o a work of art and shows how to turn an old plastic bottle into a fantastic firefly.", "Mister Maker makes a sticky pic
ture using kitchen scourers, shows you how to create a fish tank in a minute and demonstrates how to make a stretchy lor
ry.").ratio()
0.3974358974358974
>>> difflib.SequenceMatcher(lambda x: x==" ", "Mister Maker makes springy bugs in under a minute, transforms sponges int
o a work of art and shows how to turn an old plastic bottle into a fantastic firefly.", "Mister Maker shows how to scrun
ch up your picture for a great effect, creates springy creatures that will surprise your friends and demonstrates how to
 make a hilarious big head mask.").ratio()
0.34017595307917886

I could attach a patch with additional logging, if you'd like to try and track it down.

[Grumpy_Geoff]

...I could attach a patch with additional logging, if you'd like to try and track it down.

Yep, I'll give it a go, but I could be quite busy for most of the day so the testing may have to wait until this evening.

The FTA EPG has only a short description with the same contents as Ice's extended description (as I posted previously, all timers are generated).

[prl]

The FTA EPG has only a short description with the same contents as Ice's extended description

That's because IceTV licences the ABC and SBS guides.

[Grumpy_Geoff]

This 'similar phrasing' uniqueness check has caused me issues previously for V8 Supercars: Highlights programs, as the description (short or extended, I can't remember) was something like "Highlights of race 15 of the Virgin Australia Supercars championship" for the race on the Saturday, and "Highlights of race 16 of the Virgin Australia Supercars championship" for the Sunday race. I'd only ever get one timer generated for the weekend if I applied uniqueness.

The same issue is happening for the full races this weekend -

• Sat: "Tune in for the first event of the annual supercars racing in Townsville for 2018."
• Sun: "Tune in for the second event of the annual supercars racing in Townsville for 2018."

The penny has now dropped.

[prl]

At the danger of repeating myself too often: the EPG cache (when using either IceTV and FTA) simply doesn't have enough information in it to reliably avoid recording repeats in the AutoTimer system. Even when you use repeat tagging in IceTV.

[Grumpy_Geoff]

At the danger of repeating myself too often: the EPG cache (when using either IceTV and FTA) simply doesn't have enough information in it to reliably avoid recording repeats in the AutoTimer system. Even when you use repeat tagging in IceTV.

Yep, sure, but here we are talking about timers failing to be generated if we apply a uniqueness check, not extra timers being generated for the events whether they be on the same or simulcasted services..

The uniqueness test 'hint' states it won't match events where another timer with the same description already exits. From what you and adoxa are saying, it is really applying a 'similar' description check, not a 'same' description check.

[adoxa]

The short description is considered the same, so that explains why "Title and Short description" only generates one.
[...] Presumably something similar is occurring with the IceTV description.

Ah, I think I know what's going on - it tests the timer, not the event. The timer only has one description, which for IceTV is the episode name. When the name is only the season and episode numbers, they're not different enough to be considered unique. The solution is to match exactly, either always or as another option (or modify the timers to somehow include both descriptions).

[prl]

At the danger of repeating myself too often: the EPG cache (when using either IceTV and FTA) simply doesn't have enough information in it to reliably avoid recording repeats in the AutoTimer system. Even when you use repeat tagging in IceTV.

Yep, sure, but here we are talking about timers failing to be generated if we apply a uniqueness check, not extra timers being generated for the events whether they be on the same or simulcasted services.

It all comes under the general problem of AutoTimer not having access to reliable repeat flagging.

[IanSav]

Hi Prl,

At the danger of repeating myself too often: the EPG cache (when using either IceTV and FTA) simply doesn't have enough information in it to reliably avoid recording repeats in the AutoTimer system. Even when you use repeat tagging in IceTV.

Is this a situation where comparing the episode CRIDs could help to see if an event is the same (repeat) or different occurrence?

Regards,
Ian.

[prl]

Hi Prl,

At the danger of repeating myself too often: the EPG cache (when using either IceTV and FTA) simply doesn't have enough information in it to reliably avoid recording repeats in the AutoTimer system. Even when you use repeat tagging in IceTV.

Is this a situation where comparing the episode CRIDs could help to see if an event is the same (repeat) or different occurrence?

It depends whether the CRIDs are from the same authority. A British crime series shown 10 years ago on ABC rerun on 7TWO definitely won't have the same CRIDS. Whether CRIDs are comparable between the metro networks and their regional affiliates is another unknown, as is whether even within the same broadcaster, CRIDs for that broadcaster are comparable even though their various channels have different authorities. There isn't even a clean way for a program to tell whether two authorities are from the same broadcaster or not.

Even then, there's no way of knowing whether a show is a repeat or not other than by the small window the AutoTimer manages of what's in the current EPG and in your recording. CRIDs don't tell you that an episode of The Avengers on 9Gem was first broadcast 50 years ago.

You could start gathering a personal database at least of shows that you'd recorded, so they wouldn't be recorded again, and perhaps even make a crowdsourced database of them, but all of that would be subject to the same issues of comparability of CRIDs across authorities above.

What CRIDs would allow you to do pretty reliably is actually have series recordings rather than try to guess whether an EPG entry is part of a series or not. At least while the series continues to be shown by the same broadcaster (or perhaps channel).

[IanSav]

Hi Prl,

I think you are thinking more globally that my comment was meant to highlight.

For this case I was thinking more along the lines of the AutoTimer looking at near term events, presumably on the same channel, like the racing events as described by Grumpy_Geoff. I suspect that in this, and similar, limited scenarios that CRID data could help.

Regards,
Ian.

[prl]

I think you are thinking more globally that my comment was meant to highlight.

My post before that one was about the inadequacy of EPG data for global repeat detection.

For this case I was thinking more along the lines of the AutoTimer looking at near term events, presumably on the same channel, like the racing events as described by Grumpy_Geoff. I suspect that in this, and similar, limited scenarios that CRID data could help.

In that limited context, it will probably do better in many cases, but there are still instances of "encores" running on different channels, but the same broadcaster, and that runs into possible issues as to whether different CRID authorities used by the same broadcaster are actually different namespaces or not. Probably not, but who knows?. The whole authority naming in CRIDs seems to be designed to make them as useless as possible.

[IanSav]

Hi Prl,

The issues you raise aside, having the CRID data available to the AutoTimers could help.

Iff the CRID data for a show matches exactly then we should have very high confidence that we have a repeat. If the authority is comparable, if not exactly the same, we could have a high confidence that we likely have a repeat. If the CRID tests don't provide any solid information then we still have the results of all the string matching with which to fall back to make or record / skip decision.

That is, I am advocating that the CRID tests should be an additional resource to determine a repeat and not the only mechanism. If the data looks good then perhaps CRIDs weighting can be biased to be higher than the string matching tests.

Regards,
Ian.

[Gully]

Reading the posts on CRIDs I am wondering in terms of near events whether they would identify repeats across ABC/ABC HD/ABC Comedy as an example?

There are a few shows that get repeated across the week, eg Media Watch is on a handful or so times, or a number of ABC shows first shown on ABC/ABC HD and then repeated later in the week on ABC Comedy, eg Julia Zemiro's Home Delivery.

[IanSav]

Hi Gully,

Reading the posts on CRIDs I am wondering in terms of near events whether they would identify repeats across ABC/ABC HD/ABC Comedy as an example?

There are a few shows that get repeated across the week, eg Media Watch is on a handful or so times, or a number of ABC shows first shown on ABC/ABC HD and then repeated later in the week on ABC Comedy, eg Julia Zemiro's Home Delivery.

If the CRID data that Prl reported last year is unchanged then the problem is that each ABC LCN uses a different authority. This makes exact CRID matching impossible. I do not have enough information to determine if a fuzzy match on the authority together with an exact match on CRID event and episode data would result in a valid repeat match. I am hoping that it would work as this could be very helpful for finding many more repeats than just matching on titles and descriptions.

Regards,
Ian.

[Gully]

If the CRID data that Prl reported last year is unchanged then the problem is that each ABC LCN uses a different authority. This makes exact CRID matching impossible. I do not have enough information to determine if a fuzzy match on the authority together with an exact match on CRID event and episode data would result in a valid repeat match. I am hoping that it would work as this could be very helpful for finding many more repeats than just matching on titles and descriptions.

It would be interesting to know if it could be made to work for even this as it is a fairly controlled simple example of repeated programs.

[prl]

If the CRID data that Prl reported last year is unchanged then the problem is that each ABC LCN uses a different authority. This makes exact CRID matching impossible. I do not have enough information to determine if a fuzzy match on the authority together with an exact match on CRID event and episode data would result in a valid repeat match. I am hoping that it would work as this could be very helpful for finding many more repeats than just matching on titles and descriptions.

It would be interesting to know if it could be made to work for even this as it is a fairly controlled simple example of repeated programs.

The problem is that I can't find any information about whether, when a broadcaster uses more than one CRID authority, that really means that the CRIDs within each authority are separate namespaces. If they are, then matching CRIDs between authorities from the same broadcaster can't be relied on. If they're not, and the broadcaster uses the same namespace, having declared via the different authorities that they don't use the same namespace, it's tricky to create a general rule that lets you compare two CRID authorities and decide "same broadcaster, therefore same namespace".

These are the CRID authorities I saw in Canberra last time I looked:
canberra.nitv.sbs.au
canberra.sbshd.sbs.au
canberra.sbsone.sbs.au
canberra.sbsthree.sbs.au
canberra.sbstwo.sbs.au
canberra.sbstwohd.sbs.au
can.sr1.win.au
can.sr2.win.au
can.sr3.win.au
can.sr4.win.au
can.sr5.win.au
can.sr6.win.au
can.sr7.win.au
canberra.1.sca.au
canberra.2.sca.au
canberra.3.sca.au
canberra.4.sca.au
canberra.5.sca.au
canberra.6.sca.au
canberra.7.sca.au
canberra.8.sca.au
canberra2.abc.net.au
canberra20.abc.net.au
canberra21.abc.net.au
canberra22.abc.net.au
canberra23.abc.net.au
canberraabcnews24.abc.net.au

Note that there were no CRIDs available at all for WIN at the time.

At around the same time, IanSav posted some of the CRID authorities for Melbourne:
seven.net.au (explicitly for all services)
nine.com.au (from 9HD, and perhaps implicitly for all services)
melbourne.sbshd.sbs.au (explicit per-service authority)
melbourne.ten.ten.au (from 10HD, and perhaps implicitly for all services)
melbourne20.abc.net.au (explicit per-service authority)
C31.community.com.au (only one service)

So in Melbourne, some broadcasters may be using a single authority for all their services, but ABC and SBS appear to be using per-service authorities. Also, at the time I collected the authority data for Canberra, the authority name for Viceland HD was canberra.sbstwohd.sbs.au.

I only have this information for a very small set of locations, but the consistency of what I have isn't encouraging.

[Gully]

I only have this information for a very small set of locations, but the consistency of what I have isn't encouraging.

That's a shame. Seems to defeat the whole purpose, or at least a major part of it, for using CRIDs.

[prl]

I only have this information for a very small set of locations, but the consistency of what I have isn't encouraging.

That's a shame. Seems to defeat the whole purpose, or at least a major part of it, for using CRIDs.

I completely agree.

[scotty]

Is it possible to get the long description added to the timer in addition to the short description and/or a uniqueness option for exact match?

Scotty

[IanSav]

Hi,

I still think there is value in making the CRID code available so that we can see if there is correlation between the event and episode CRIDs even if the authorities change. (In this context I am talking about matching within a single broadcaster. I don't expect CRIDs to be comparable between different broadcasters.)

If I get some time I may try to find the direct contact number for the helpful engineer I found at SBS. I will try and get some insight into the differences in authorities and, if appropriate, suggest that they be rationalised.

Regards,
Ian.

[adoxa]

Is it possible to get the long description added to the timer in addition to the short description and/or a uniqueness option for exact match?

I don't know what effect adding an extra field would have to timers, but that would be the ultimate solution (it would have benefits elsewhere, too). I can easily change "similar" to "identical"; a little more effort could make it an option ("Exact match", default off, "If off, descriptions only need to be sufficiently similar; when on, they must be identical.").

[prl]

I still think there is value in making the CRID code available so that we can see if there is correlation between the event and episode CRIDs even if the authorities change.

I have done so in the past. Even though I supplied information about how to extract CRID information from the logs, I didn't get much in the way of data for analysis, or data analysis by other people.

[adoxa]

I have done so in the past. Even though I supplied information about how to extract CRID information from the logs, I didn't get much in the way of data for analysis, or data analysis by other people.

I wanted the code, so I can add it to my own binary. I did mean to try yours, but never got around to it.

[prl]

I have done so in the past. Even though I supplied information about how to extract CRID information from the logs, I didn't get much in the way of data for analysis, or data analysis by other people.

I wanted the code, so I can add it to my own binary. I did mean to try yours, but never got around to it.

The source for the changes isn't not in the repository. At the moment it's just in a git stash. I could put it into a dev branch in my repository fork if you like. But I'd need to dust it off and re-merge it with the current version, and test it before I do that.

The old alpha patch is likely not to work in current firmware.

[adoxa]

I could put it into a dev branch in my repository fork if you like.

If you wouldn't mind.

But I'd need to dust it off and re-merge it with the current version, and test it before I do that.

No need, I could do that.

[IanSav]

Hi Prl,

I still think there is value in making the CRID code available so that we can see if there is correlation between the event and episode CRIDs even if the authorities change.

I have done so in the past. Even though I supplied information about how to extract CRID information from the logs, I didn't get much in the way of data for analysis, or data analysis by other people.

The patch was for a T4 which I didn't / no longer have! For me to run the test code I will need a T3 build.

Regards,
Ian.

[Grumpy_Geoff]

Hi Prl,

I still think there is value in making the CRID code available so that we can see if there is correlation between the event and episode CRIDs even if the authorities change.

I have done so in the past. Even though I supplied information about how to extract CRID information from the logs, I didn't get much in the way of data for analysis, or data analysis by other people.

The patch was for a T4 which I didn't / no longer have! For me to run the test code I will need a T3 build.

Regards,
Ian.

But at the time -

... Unfortunately my T4 is dead so I can't try the code at this time. ...

Is there a particular reason why you can't try the T4 code on your T3? I have tested it on a T3, and apart from it not writing to the front panel display, it works well enough for me to to all the testing that I think would be useful.

[peteru]

I think that going down the CRID path is a WOFTAM, but...

If you are going to use the mess that are Australian CRIDs, you are not limited to making your decisions based solely on the CRID data. It's easy enough to decide which authorities belong together on a particular install, based on other DVB data, such as transponder frequency or ONID.

[prl]

Hi Prl,

I still think there is value in making the CRID code available so that we can see if there is correlation between the event and episode CRIDs even if the authorities change.

I have done so in the past. Even though I supplied information about how to extract CRID information from the logs, I didn't get much in the way of data for analysis, or data analysis by other people.

The patch was for a T4 which I didn't / no longer have! For me to run the test code I will need a T3 build.

At the time I didn't know how to do a binary build for the T3. However:

This patch was built for the T4 firmware. The CRID functionality has been tested to work on the T2 and T3, but there are some small oddities in running the firmware on the wrong PVR. In particular, the front panel display on the T3 won't be updated when using this firmware.

[IanSav]

Hi Prl,

Given all the development efforts running on my T3 I can't afford to have any enigma2 based anomalies.

Regards,
Ian.

[prl]

Hi Prl,

Given all the development efforts running on my T3 I can't afford to have any enigma2 based anomalies.

Regards,
Ian.

The CRID patch was never meant to be run as day-to-day firmware:

This alpha firmware is experimental and is not intended for normal use.

[IanSav]

Hi Prl,

I only have the one machine to do all my development and testing, when it isn't actually being used as a production PVR. The other T3 is production only.

Regards,
Ian.

[Grumpy_Geoff]

I ran it on my 'production' PVR. Checking my logs, I can see I ran it for 5.5 hours.
I even dumped the use of IceTV for the task at hand.
It wasn't hard.

[IanSav]

Hi Grumpy_Geoff,

I ran it on my 'production' PVR. Checking my logs, I can see I ran it for 5.5 hours.
I even dumped the use of IceTV for the task at hand.
It wasn't hard.

My issue is not difficulty. It is potential conflicts with the development code like being unable to use the front panel.

If you are collecting the data successfully then you could work out if the event and episode CRIDs provide useful information with a broadcaster using different authorities.

Regards,
Ian.

[Grumpy_Geoff]

The short description is considered the same, so that explains why "Title and Short description" only generates one.
...

A 'Title and all descriptions' uniqueness check still only generates one timer.
Perhaps the plugin isn't grabbing the extended description?

As I thought, the extended description is currently ignored in a duplicates check -
"[AutoTimer] fix checking for duplicates with extended description #318"
https://github.com/oe-alliance/enigma2-plugins/pull/318

Assuming we've the same code...

[adoxa]

As I thought, the extended description is currently ignored in a duplicates check -
"[AutoTimer] fix checking for duplicates with extended description #318"
https://github.com/oe-alliance/enigma2-plugins/pull/318

Assuming we've the same code...

We have, and here's a patch for those wanting to try it out (although I've used > 1 rather than == 2).

[Grumpy_Geoff]

As I thought, the extended description is currently ignored in a duplicates check -
"[AutoTimer] fix checking for duplicates with extended description #318"
https://github.com/oe-alliance/enigma2-plugins/pull/318

Assuming we've the same code...

We have, and here's a patch for those wanting to try it out (although I've used > 1 rather than == 2).

That appears to work when I tried it for "The Block" which has the same short description of "The Block" and a different extended description for each episode.
The episodes are repeated again the same day.
Without the patch, only the first program had a timer generated.
After applying the patch, the other four unique programs for the week had timers generated. The five repeats for the week were ignored.

But...
For "Instinct" which has 'Require description to be unique' - 'On any service' in its definition:

Code: Select all

 <timer name="Instinct" match="Instinct" enabled="yes" avoidDuplicateDescription="2" searchType="exact" searchCase="sensitive">
  <bouquet>1:7:1:0:0:0:0:0:0:0:FROM BOUQUET "userbouquet.favourites.tv" ORDER BY bouquet</bouquet> <!-- Favourites (TV) -->
  <tag>Instinct</tag>
 </timer>

It generated a new timer, with same description, on a different service as a completed timer -
Instinct
Tue 17.07.2018 22:23 - 17.07.2018 23:43
ONE
Two members of an acting troupe are killed using sophisticated poisons; Andy worries that Dylan isn't fitting in, so he encourages Dylan to attend a barbecue being thrown by Detective Fucci.
waiting

The completed timer -
Instinct
Wed 11.07.2018 20:33 - 11.07.2018 22:01
TEN HD
Two members of an acting troupe are killed using sophisticated poisons; Andy worries that Dylan isn't fitting in, so he encourages Dylan to attend a barbecue being thrown by Detective Fucci.
finished

Is the plugin not looking at completed timers? I was sure it previously did.
This snippet from "A quick guide to Beyonwiz T series AutoTimers" says to me it used to:
"Once that's done, it may be a good idea to set MENU>Setup>TV>Recording settings>Remove completed timers after to 7 days or more (the default is 7). That will help Require description to be unique to work properly."

Has this fix tripped up the completed timers check? It's still okay for the waiting timers.

Edit:
Instinct only has an extended description if that makes any difference. If the code requires the short description to be present before it checks the extended description then I think that's the issue.

[adoxa]

Instinct only has an extended description if that makes any difference. If the code requires the short description to be present before it checks the extended description then I think that's the issue.

That may be the case. Dammit, I was almost going to add extra logging, which I have now done (updated previous attachment). It logs to /home/root/logs/autotimer.log.