Page 1 of 1
RSS - no download duplicates
Posted: April 11th, 2008, 5:21 pm
by jk2587
Hi,
With the old RSS setup I used the option to not match multiple items so that after a match the entry was removed from the rss filters. It required adding a filter for each episode of every show, which was very time consuming.
As far as I can tell there's no way to do that in the current beta, which with the tv season picking up again meant I had multiple copies of 5 different shows (wasting around 3GB bandwidth - and thats just one day).
An ideal solution would be the option to have the RSS parser not match items named the same as any appearing in the history or queue. If that's not possible even just going back to the old way of being able to remove a filter once its matched would work out nicely.
Thanks
Re: RSS - no download duplicates
Posted: April 12th, 2008, 10:03 am
by shypike
Are you talking about the extact same titles?
Because that's the only way to check a job against the queue/history.
Almost identical would be unworkable.
Cannot you use Reject filters to reject the type of shows you do not want?
I don't think the old single-match system was perfect. It did not work once a show
re-entered the RSS feed again after its twin had left.
For identical titles, maybe we can do something like examining the queue/history.
For almost identical ones you should use filtering.
We could re-introduce the single match system again, but with the above limitation.
E.g. a prefix {once} for the filter would be relatively easy to do.
Re: RSS - no download duplicates
Posted: April 12th, 2008, 10:06 am
by switch
shypike wrote:
We could re-introduce the single match system again, but with the above limitation.
E.g. a prefix {once} for the filter would be relatively easy to do.
I think a checkbox for every filter would work better than a prefix.
Re: RSS - no download duplicates
Posted: April 12th, 2008, 10:30 am
by shypike
And change the GUI again? I'd rather not.
Re: RSS - no download duplicates
Posted: April 12th, 2008, 12:03 pm
by jk2587
shypike wrote:
Are you talking about the extact same titles?
Because that's the only way to check a job against the queue/history.
Almost identical would be unworkable.
Cannot you use Reject filters to reject the type of shows you do not want?
I don't think the old single-match system was perfect. It did not work once a show
re-entered the RSS feed again after its twin had left.
For identical titles, maybe we can do something like examining the queue/history.
For almost identical ones you should use filtering.
We could re-introduce the single match system again, but with the above limitation.
E.g. a prefix {once} for the filter would be relatively easy to do.
Yes the titles are exactly the same, and in fact the attributes for the reports on newzbin are identical too so I can't even just adjust my searches. For this reason I can't use a reject filter because there is no way to distinguish the two reports.
A prefix would work, but since the titles are identical matching up against the queue/history would be the best as I wouldn't have to create filters for every episode. I'm currently using a filter like: - x*, any better suggestions??
I realize that sometimes I will still get duplicates when the posts aren't named consistently, but for most cases this will eliminate duplicates.
Thanks
Re: RSS - no download duplicates
Posted: April 13th, 2008, 4:37 am
by shypike
Using "once" and preventing duplicates is not exactly the same.
The RSS-function removes jobs that are no longer present in the RSS feed. That's the limitation I was talking about. So if later the job reappears, it will match again.
Checking queue/history for duplicates would be more reliable, but only as long as you don't purge the history.
What's your opinion?
Re: RSS - no download duplicates
Posted: April 13th, 2008, 4:53 am
by switch
Do we not keep a list of the downloaded jobs that gets displayed in "Match/Show". Could just match against that.
Re: RSS - no download duplicates
Posted: April 13th, 2008, 9:47 am
by jk2587
Yes matching against the queue/history makes the most sense to me, even if i purged the history i could add a couple reject filters to filter out everything that's already been downloaded.