Allow to ''merge file and change type'' [DONE/DENIED]

wahaha · Post by **wahaha** » Fri Oct 01, 2004 6:41 pm

... specifically for one purpose: To easily get rid of corrupted 1*-user-files.

There would be no reason to leave such files in if there was a function to merge the 1*-user-file with the CRC-correct one while at the same time changing the type of it to "corrupted version/invalid crc" for those who have it.

*) Actually, I wouldn't hesistate to merge corrupted files with 3 users either ^^

DonGato · Post by **DonGato** » Sat Oct 02, 2004 1:24 pm

Shouldn't the AniDB client handle this as well? I mean to not add files with same data but different hashes?

Vortex · Post by **Vortex** » Sat Oct 02, 2004 1:57 pm

I think this is a good idea.

Perhaps, you could merge it and change the 'type' field for the users with the incorrect crc to "corrupted version/invalid crc".
A automatically generated private message might be good as i would assume most people wouldn't check the crc against the one filed in the db and might actually have the correct version (as opposed to the person who originally filed the entry) and then they can change the type back to "normal/original" themselves. Or perhaps, I'm just complicating the situation.

Post by **PetriW** » Mon Oct 04, 2004 12:06 pm

DonGato wrote:I mean to not add files with same data but different hashes?

How can files have different hashes when they contain the same data?

DonGato · Post by **DonGato** » Mon Oct 04, 2004 3:46 pm

I mean... same data (size, group, etc) but different hash. Or you think all those corrupted files have the same hash?

Post by **exp** » Wed Oct 06, 2004 8:39 pm

Hm,

I don't think we should merge files if more than one user has them in their mylist. This shows that the files have somehow "spread" and it's likely that some other user will end up with the same file.

By merging the corrupted file with the correct one we would make it impossible for AoM to identify these files.

To ensure that only one user has a given corrupted file I think we should wait at least 4 weeks before we merge/remove a file based on the amount of users who have it in mylist.

BYe!
EXP

wahaha · Post by **wahaha** » Wed Oct 06, 2004 9:21 pm

When I wrote that I'd also merge a corrupted file if it has 3 users I had a situation like "CRC valid file: >100 users // CRC invalid file: 3 users" in mind. Keeping such an entry isn't worth much, IMO, but I'm fine with leaving it alone.

(.. as long as we can get rid of the 1-user-files ^^)

Post by **exp** » Thu Oct 07, 2004 5:50 am

wahaha wrote:When I wrote that I'd also merge a corrupted file if it has 3 users I had a situation like "CRC valid file: >100 users // CRC invalid file: 3 users" in mind. Keeping such an entry isn't worth much, IMO

even in this case others might have that corrupted file and might want to use AoM to identify it. deleting it would then most likely only lead to someone readding that file later.

BYe!
EXP

DonGato · Post by **DonGato** » Thu Oct 07, 2004 9:48 am

That's why I said AoM should handle that and don't add files with same information that an existing one. I know is not that easy to do but if not then you will always have to remove those 1 single user file added while in fact they are corrupted versions of a well known one.

Post by **exp** » Thu Oct 07, 2004 12:00 pm

DonGato wrote:That's why I said AoM should handle that.

AFAIK that is technically imposible for AoM.

and I don't see a problem if we have some corrupted files with a lower user count in anidb, the deprecated files feature will hide such files anyway.

BYe!
EXP

egg · Post by **egg** » Thu Oct 07, 2004 5:44 pm

I agree with exp, if they are already in the DB, leave them, if they are being shared, they will just come back again at some point.

wahaha wrote:When I wrote that I'd also merge a corrupted file if it has 3 users I had a situation like "CRC valid file: >100 users // CRC invalid file: 3 users" in mind. Keeping such an entry isn't worth much, IMO, but I'm fine with leaving it alone.

I have actually used cases like this where the valid file does not have complete sources. I download the corrupted version, and when it completes parts that are missing in the valid file, I reshare that file as a valid file. A few times I have lucked out and the part(s) that were corrupted were not the parts I that were missing, so I was able to build a complete CRC valid file.

Also, just because a particular hash has more users in AniDB, that does not mean there are sources out there that reflect those numbers. I have had a few times where it was much easier to download a hash that listed only a few users than one that had a lot (I only do this if I can't get complete sources after a few weeks and/or no hash is marked as CRC valid).