Further development check for previous recordings function

[majstang]

Hi!

 

I love the check for previous recordings function entirely. No doubt about it has made life easier considerably. Not as much time is spent on checking the recording timers created by the autosearch any longer in order to avoid recordings of re-runs. The function is nearly 90% accurate.

 

However there is still a feature missing that would make the function closer to 100% accurate and would require no time at all backchecking the autosearch generated recording timers in the future. In an ideal world all series season/episode numbering format would of course be the same, but it is not unfortunately. For example if all numbering would be according to the S01E01 format, with both season and episode information everything would be perfect and working with the present function. I have a couple of channels that only uses epsiodenumbering (for example E05) for all thier series. Things gets complicated when they throw in re-runs from seasons way back in the middle of the present season. So if E05 (from a previous season) already has been recorded the problematic part arises when the check for previous recordings function deactivates the E05 recording timer from the present season and it never gets recorded.

 

If, it would be possible to have the function to check the description of the E05 in the recordings history database against the description of the E05 (present season) from the EPG. If they match the timer will be deactivated, if not the timer stays activated. Having such a feature and be abled to activate it for all searchpresets on these two channels would be great. The successrate for such an addition to the function would be good, cuz these two channels always uses induvidual descriptions from one episode to next and when airing a re-run they always uses the identical description used for the première episode. Any chance for this idea?

 

Regards

majstang

Edited February 4, 2012 by majstang

[majstang]

Perhaps adding something like this:

 

; haystack description taken from recording: 20120421_06-24-01_Animal Planet_Krokodiljägaren - E10.txt
haystack=
(
Djungeln i molnen. Följ med på en tropisk resa bland mangroveträd på Nya Guineas kust och genom låglandsslätternas ångande djungler. Del 10.
)

Loop, D:\TV\test\old\*.txt
{ 
  txt_files := A_LoopFileFullPath
  ;msgbox, % txt_files
  FileRead, Description, *P65001 %txt_files%
  RegExMatch(Description, "Description=(.*)", SubPat)
  ;msgbox, % SubPat1
  needle=i)(*UCP)%SubPat1% ; move (*UCP) after the option
  if RegExMatch(haystack,needle,output)
     msgbox, **Match found in:`n"%txt_files%" `r`n`r**Description for matched show:`n%output%
}

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

new 222.ahk

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

**Match found in:

"D:\TV\test\old\20120114_07-14-02_Animal Planet_Krokodiljägaren.txt"

 

 

**Description for matched show:

Djungeln i molnen. Följ med på en tropisk resa bland mangroveträd på Nya Guineas kust och genom låglandsslätternas ångande djungler. Del 10.

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

OK

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

Played around with the info files (txt) as base for this script and it is pretty quick finding a potential match amongst 700 txt:s. I suppose a sql query is much faster. The match has to be 100%. If something is added and differs from the première episode description it's a no-match. In case of having description matching for the few channels in question and only if a description match is found timer will be deactivated.

 

Despite occasionally no-matches, implementing something similar into RS check for previous recordings function would definitely improve the overall accuracy. Especially when taking into account having Rec.Event as matching decider for these cases doesn't work at all.

 

A recent example is I've missed out on 10 new episodes of Gold Rush Alaska second season (Discovery Channel), just because i forgot to delete all entries for the first season.

 

Regards

Majstang

Edited April 21, 2012 by majstang

[Lars_MQ]

I'm not sure it is that easy. It might be in your special case, but for most this would be useless or even cause problems. So I'm not really convinced this should be implemented...

[majstang]

I'm not sure it is that easy. It might be in your special case, but for most this would be useless or even cause problems. So I'm not really convinced this should be implemented...

First of all...sorry for this very long exposition! I can't omit myself from trying my best to convince you

 

Yes, I can partly agree with your doubt. However I do not agree with my special case is uncommon in any way. On the contrary they are

very common when the broadcaster doesn't bother to assign a season number in the serie show description (where the Rec.Event is taken from) and we end up with having to delete entire previous seasons from Rec.db (the deletion has to be timed well also), cuz else next season wont be recorded at all. Applies of course also to re-runs of episodes from previous seasons in the middle of current season. These broadcaster descriptions are distributed all over the place, for example i-net, and eventually ends up in the EPG. It is quite impossible to convince EPG sites to assign season numbering for all the series when all they do is ripping off what the broadcaster distributed in the first place. Influencing the broadcasters to always use season numbering one can forget about. They do not listen, cuz that would imply more work coming their way.

So i don't see how an introduction of a Description Match option would be useless. Provided we accept the fact RS never reach 100% accuracy for the check for previous recordings function. I do not see any hindrance to at least try to get as close as possible.

 

An introduction of a Description Match option could cause problems is on the other hand a righteous objection. So how to avoid it? As I see it everything comes down to making the autosearch algoritm abled to analyze the Rec.Event string. And that is the hard part to accomplish, especially when I'm not having any clue if it's possible from a sequential point of view or how the format folks are using inside Rec.Event may differ.

Although for example conditioning it like this:

- If both season and episode numbering exist, deactivates Description Matching (internally) and proceeds according to normal rules.

- If only episode numbering exist, Description Matching takes priority and deactivates a timer if match is found.

- If only episode numbering exists and if Description Matching fails (no-match), both Rec.Event and Description matching deactivation gets overridden and timer stays activated.

 

This example is for folks that insist to enable all the check for previous recording options there are, without knowing exactly what they really do. If disable the Description Match option the original deactivation rules will apply. There is also no good reason to enable Description Matching for all searchpresets, cuz many channels/broadcasters does a fairly nice job putting season numbering in the description. In those cases it wouldn't be necessary. Sadly the development in my case lately is they seem to mix frequently between season and no season numbering, which creates extra work for me backchecking the autosearch results.

 

Looking at it in more detail this is what the autosearch algoritm does today:

- The autosearch deactivates a timer when a match for it has been encountered in the Recordings History Database.

Based on the searchstring: (Rec. Title) - (Rec. Event)

- The autosearch also deactivates timers which name is encountered twice within the current and previous autosearch.

Based on the searchstring: (Timer Name)

Now, the good part with these two rules is they cover most cases...lets say 90% of all cases.

 

 

Experimental searchstring: (Rec. Title) - (Rec. Event) - (Description Match)

 

Lets see the imaginary results we get with the experimental searchstring and algoritm Rec.Event analysis:

Show 1: Gold Rush Alaska - E01 (season 2)

Show 2: Gordon's great escape - S02E02

 

Case 1 for Show 1: Gold Rush Alaska - E01 (season 2) has already been recorded and a re-run timer of the same episode gets created. In this case the autosearch algoritm finds a Rec.Event match (E01). If Description Match is enabled this one should take priority over Rec.Event as deactivation rule. It will find that both shows has 100% description match and timer will be deactivated.

 

Case 2 for Show 1: Gold Rush Alaska - E01 (season 2) has never been recorded before. When the timer gets created for Gold Rush Alaska - E01 (season 2), the autosearch algoritm finds a Rec.Event match (E01), cuz E01 from season 1 has already been recorded. If Description Match is enabled this one should take priority over Rec.Event as deactivation rule. Descriptions for this case won't match. Timer stays activated. New episodes never recorded before definitely shouldn't be deactivated just because it's title and episode number exists in the Rec History Db.

 

In cases where the created timer and the Rec.Event match in Db actually are the very same episode despite a description no-match, the broadcaster probably changed something in the description and in uncertain cases to avoid aggravation the show not being recorded, it would be better to leave it activated. These few cases can be disregarded as statistical non-response and fits in amongst the few percentage left to 100% accuracy goal of the check for previous recordings function. Along with the other case i've found that doesn't work - the function can't detect any difference between upper and lower letters. The main thing is the overall accuracy would be improved further, compared to if holding on to the current version.

 

Lets see the results for Show 2:

Case 1 for Show 2: When the timer gets created for Gordon's great escape - S02E02, the autosearch algoritm finds a Rec.Event match (S02E02). Now if having Description Match enabled Rec.Event should take priority as long as we have season numbering.

 

 

Furthermore, there is probably cases I can't come up with at the moment, where things could go wrong and cause problems. To avoid that

in an experimental phase, provided you do decide to give the suggestion a try, perhaps it might be a good idea to only have the Description Match option enabled through the tweaktool. Then it can be evaluated in peace and quiet without triggering forum error reports.

 

Best regards

Majstang

Edited April 24, 2012 by majstang

[majstang]

Hi Lars!

 

I suppose I didn't managed to convince you about implementing this idea. Well, one lose some and win some

It is turning up more situations where check for previous recordings fails and the latest example fails due to the broadcasters using inconsistent season and episode numbering format between premiere show and re-run. Pleading to make it more consistent won't work (i've tried it) and asking you guys to consider a solution apparently doesn't work either. So, what's left to do...yes, the old "do it yourself"

 

Scrutinizing the conditions to make a script abled to compare descriptions, yields it's kind of hard to accomplish. Especially to retrive the description from a recording timer to compare it with the descriptions in the info text files in db backup. There are no descriptions in the svctimers.xml. Retrieving it from the EPG.dat, yeah that is a whole adventure in itself.

 

So my question is, if nothing is going to be done about to improve the check for previous recordings function further, could we at least get the description added to the timers in svctimers.xml, so there would be a fighting chance to script something that works?

That would be an awesome gesture from ya

Edited June 6, 2012 by majstang