green ring NFT on catalog has a duplicate

[TimDaub]

Greenring posted on Discord:

"""
Also, while I'm here, I have a specific question regarding making small corrections to neume. A duplicate of my song 'The Leap' was somehow minted by someone else on the catalog contract after me. Not really sure how it happened, but it went up right after I minted mine. I let catalog know, and it looks like they basically blanked out the NFT. The correct token ID on the Catalog contract for the song is 325, the fake one is 327. I only bring it up because there are currently two copies of the song showing on MusicOS so I'm guessing neume is indexing both. Just wondering if it is a straightforward or more involved fix to get neume to ignore this specific token.
Correct token:
https://opensea.io/assets/ethereum/0x0bc2a24ce568dad89691116d5b34deb6c203f342/325

Extra/Incorrect token:
https://opensea.io/assets/ethereum/0x0bc2a24ce568dad89691116d5b34deb6c203f342/327
"""

@il3ven commented:

"""
@TimDaub Upon a little inspection, I think this is because we fetch NFT on the block they were created. Catalog must have updated the tokenURI sometime after the mint. In neume, the tokenURI for tokenID 327 is still the old one.
"""

@il3ven do we need a "token ignore file" that we could e.g. set "0x0bc2a24ce568dad89691116d5b34deb6c203f342/325" to ignore?

[il3ven]

Should we take care of this on the music-os level? If not, then we will need a token ignore file.

[TimDaub]

I think its our responsibility

[il3ven]

At what level should we add the token ignore file? We can add it at the call-block-logs level or the music-os-accumulator level. I think it makes sense to be at music-os-accumulator level.

[TimDaub]

I think it makes sense to be at music-os-accumulator level.

ok