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

old granted and denied feature requests

Moderator: AniDB

Locked
wahaha
AniDB Staff
Posts: 1497
Joined: Sun Nov 17, 2002 3:33 pm

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

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 ^^

User avatar
DonGato
Posts: 1296
Joined: Sun Nov 17, 2002 9:08 pm
Location: The Pampas, The land of the Gaucho!
Contact:

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
Posts: 30
Joined: Sat Jun 19, 2004 7:39 am

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.

PetriW
AniDB Staff
Posts: 1522
Joined: Sat May 24, 2003 2:34 pm

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? 8O

User avatar
DonGato
Posts: 1296
Joined: Sun Nov 17, 2002 9:08 pm
Location: The Pampas, The land of the Gaucho!
Contact:

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? 8O

User avatar
exp
Site Admin
Posts: 2438
Joined: Tue Oct 01, 2002 9:42 pm
Location: Nowhere

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
AniDB Staff
Posts: 1497
Joined: Sun Nov 17, 2002 3:33 pm

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 ^^)

User avatar
exp
Site Admin
Posts: 2438
Joined: Tue Oct 01, 2002 9:42 pm
Location: Nowhere

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

User avatar
DonGato
Posts: 1296
Joined: Sun Nov 17, 2002 9:08 pm
Location: The Pampas, The land of the Gaucho!
Contact:

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.

User avatar
exp
Site Admin
Posts: 2438
Joined: Tue Oct 01, 2002 9:42 pm
Location: Nowhere

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
Posts: 769
Joined: Tue Nov 11, 2003 7:17 am

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).

Locked