How is this different than seen plugin?

Seen is cross task and persists between runs.

Only by default, it can be used locally

@liiight does the "seen" plugin apply for the current entries, or only for entries seen before this run?

If you mean for entires in the same task, I don't think so, but possibly.
But why would you receive the same entries several time during the same task?

Usage example:

1. I'm searching for a torrent of MOVIENAME
2. I get 30 results
3. I run lookup_trakt
4. I use the "duplicates" plugin with the movie_name field, only passing one torrent belonging to MOVIENAME

Why? Why not use movie_list or something?

I don't want to use movie_list. I don't its assumption that a movie is "done" as soon as it's torrent is accepted.
I'm working on a different approach that moves the persistent state out of Flexget's DB.

I'm not sure I fully agree with this PR but if the old behaviour still works without having to change config, then we can see about merging it when issues have been worked out.

At a glance it seems highly inefficient. You iterate through the list of entries for every entry ie. O(n^2) -- my brain is pretty fried so there's probably a tighter upper bound than O(n^2). Is there no way to optimize this?

If there is a better way to achieve this without using duplicates I'll be happy to know about it. Ideally I'd have an only_one plugin that gets a list of fields, and rejects every item that shares these fields with an already-accepted item.
I basically played around with the existing duplicates plugin code - I guess it was largely unused if it's so under-optimized (it did a full n*n iteration)

For the movie situation, there is the seen_movies plugin already

seen_movies is based on seen (which has the side effect of persisting), and cannot be generalized towards other uses

You can put seen_movies in local mode, to have it apply to just one task. That being said, I'm not necessarily against a better general way, I just worry about things being even more confusing with multiple ways to do the same thing.

@gazpachoking I toyed with the idea of modifying seen to immediately reject entries based on earlier entries in the same run, but figured it will break more stuff than adding functionality to duplicates. If the will of the Flexget masters is to modify seen, I can look into this

@BackSlasher This change might be fine, haven't thought about it fully. @paranoidi You made duplicates plugin, right? Any input?

@paranoidi Ping
Reminder: we can merge this or enrich seen, I think it's a good idea to merge this for starters.

@gazpachoking ping

It is semantically very weird to use duplicates plugin to get first unique match. I would make a separate plugin for that purpose which is more suitably named (ie. unique). I was hesitant to even add the action support for this plugin originally. I'm declining this due that concern. I would be willing to accept this refined as a separate plugin though :)

@BackSlasher Consider doing another PR. Contributions are appreciated!