Can't do smart episode matching

[GoogleCodeExporter]

I'm using a common tv bittorrent feed, with download<n> matches like:

download1 = the.colbert.report
download2 = the.daily.show

And I find that if the feed contains multiple torrents for the same
episode, rssdler will end up downloading all of them, resulting in multiple
video files of the same episode, for example:

the.daily.show.S20E08.HDTV.XviD-NoTV.[VTV].avi
the.daily.show.S20E08.HDTV.XviD-NoTV.[EZTV].avi
the.daily.show.S20E08.PROPER.HDTV.XviD-NoTV.avi

I don't want to construct a regex that will narrow down what I download,
but I would like rssdler to know that these are equivalent files and if one
of them has already been downloaded, not to download the others as well.

If possible, it would also be nice to be able to prefer the PROPER download
over the others, in the case that a feed check finds all three available at
the same time.

Is there a way to support smart episode matching on regular expressions? 

Original issue reported on code.google.com by phili...@gmail.com on 4 Apr 2008 at 3:24

[GoogleCodeExporter]

Well, I certainly wouldn't call this a defect, rather an enhancement request. 
Anyway,
there are ways to do this with regular expressions, but given the inconsistency 
in
naming conventions as well as some other issues, you are not going to get 
better than
80% or so accuracy. Further, there is no way to choose the "proper" over the 
others
unless it waits to download for X days and doesn't see a proper and then 
downloads
it. but then, you just wasted tons of time that you could've been seeding. And 
your
choice of daily show is informative, as it goes by year/month/day not 
season/episode.
Trying to guess if the release is supposed to be YY/MM/DD or DD/MM/YY or 
MM/DD/YY or
MMM.DD.YYYY etc. is not something i'm terribly interested in trying to guess 
at. Then
the storage mechanism has to be completely redone. 

Unless fool-proof methods for doing this can be suggested (aka with patches), I 
am
not going to implement this. It has been requested in the past, and I'm just not
interested in implementing features that will inherently only kinda sorta work,
sometimes.

Original comment by lostnihi...@gmail.com on 7 Apr 2008 at 3:12

• Changed state: WontFix
• Added labels: Priority-Low, Type-Enhancement
• Removed labels: Priority-Medium, Type-Defect

[GoogleCodeExporter]

Ok, i realized that with just a small addition to Config and a 
postDownloadFunction,
this shouldn't be TOO hard, though i'm leaving the regex'ing mostly to the 
user. Some
rudimentary form of this is now in svn (r138). There is some way to manipulate 
it
through the use of your config file, though the default is (somewhat) sane. Not
tested whatsoever. wanted to commit

Original comment by lostnihi...@gmail.com on 23 Apr 2008 at 5:57

• Changed state: Accepted

[GoogleCodeExporter]

Original comment by lostnihi...@gmail.com on 23 Apr 2008 at 5:58

[GoogleCodeExporter]

I believe this is working in current svn, compared to the broken implementation 
in
r145. Please let me know. Quick explanation:

The function you want to use is advanceEpisode in userFunctions.py. In its 
current
form, you cannot use it directly as a postDownloadFunction. This is to reflect 
the
fact that it is a hack based on the approximate expected form of the filter you 
are
using, but that you need to specifically call it from another function. An 
example is
specified in the docstring of advanceEpisode.

It works by editing your config file which means any comments you have will be 
lost
due to the way python's config library works. 

For your specific example of daily show, you still have problems, as the 
releases are
done by by day,month, and year. So advancement of the day is not guaranteed to 
work.
Maybe in a future version a more appropriate solution can be used.

Original comment by lostnihi...@gmail.com on 26 Apr 2008 at 4:38

• Changed state: Fixed

[GoogleCodeExporter]

I must confess, I've not been able to figure out how to make use of this 
feature. A
specific example of how to use this feature would be useful. Or perhaps I just 
need
to spend more time figuring it out myself...

Original comment by phili...@gmail.com on 18 Jun 2008 at 1:31