Ingesting the same song twice won't return results at lookup

[andrei4002]

Has anyone tried ingesting the same mp3 file twice ?

When I ingest it once, if I query for a fragment of it, it returns the correct track id

When I ingest it again, and use the fp utility for querying, it won't return any results.

I tried to do some debugging on it and noticed that in return for the query, the script receives both track ids, but at some point near the end, it discards them both and returns no result.

Anyone knows what's going on?

[alnesbit]

This is a known issue. What happens is that when you ingest the same song twice, you end up with the same fingerprint codes ingested in each case, but you get different track IDs each time and therefore it considers them to be different tracks. When querying, the scores in the matching algorithm are identical or very similar and the server doesn't whether (a.) they represent the same track; or (b.) they represent different tracks. In the case (b.) there is no clear winner because the scores are so similar and so the server must reject the match to minimize the chances of returning a false positive.

At this point in time the solution is to try to avoid ingesting the same track twice if possible. We are working on a more robust solution which will allow duplicate tracks to be handled.