Changelog wrote:files which match the following criteria are marked deprecated and will be displayed in grey (or even hidden if the profile option is set).
- the ep has >=50 users and the file has <=3 and is not marked crc checked
- the file is marked as crc incorrect
- the quality of the file is < low
- another file by the same group and in the same version exists and is crc verified while this file is not (this more or less implies that this file has a broken crc after all)
- another file by the same group and in a higher version exists and is crc verified.
When hiding deprecated files is activated, it is more important to not "hide too much", so I'd like to suggest:
- Don't hide (deprecated) files in one's mylist
And maybe:
- Only hide deprecated files for eps with > 2 or 3 files [see Tenshi ni Narumon]
- Ignore the deprecated-state if enough users have it in their lists (may be fixed, e.g. 25-50, or based on the ep's users / files) [see Angelic Layer, ep 13]
- files in mylist should now be unhidden automatically, they're still marked as being deprecated though.
- all files with more than 50 users are automatically unhidden.
- if hiding deprecated files would only leave <= 1 files left all files will be unhidden.
files owned by the current user are not handled specially as 99% of the time such a file would also be in the users mylist.
Another thing that I noticed, is that some other languages were getting marked as deprecated. There should be at least one file of each language combination that is not deprecated...
egg wrote:Another thing that I noticed, is that some other languages were getting marked as deprecated. There should be at least one file of each language combination that is not deprecated...
Well, this deprecated thing has a problem.
File added now are shown as deprecated... some kind of time filter should be added and files deprecated should have at least a month (?).
I guess it happens because there is no ed2k link in the added file entry or the CRC is not verified.
If there is no ed2k link, the entry is pretty much useless. So no problem in marking it deprecated there IMHO.
If the file was just released and the user who added the file did not check the CRC, he will notice that his file is deprecated and be encouraged to add the lacking information OR he will simply mark the file CRC checked even though he has no real info about the correct CRC. Since this is a pretty wrong behaviour there is not much we can do about this anyway and it is hard to say if the information can be trusted this way or the other and it might happen all the time. The deprecated flag might help those who still have some concience left might be pointed into the right direction
You really think that MD5 and SHA1 are not something a file can be destinguished by?
AoM generates ALL hashes and you can trust me the chance that two files have the same MD5 and same SHA1 and CRC32 and ed2k (MD4) is pretty close to zero.
AoM finds the File ID (!) via the ed2k link. It does not find "the file". It finds the information given in the file ID entry and then compares
the information, and it does so with ALL the information.
If the information AoM generated differs from the information in the DB, there will be feedback to the staff of AniDB or to the user.
So if AoM finds that there is no further information given except the ed2k hash, it will add all the other hashes. If there are other hashes and those are wrong, it will automatically correct them.
In the case that the ed2k link is wrong AoM will not know about it of course - there needs to be a user with the correct file. He will know that he has the correct file from the website or the bot he got the file from and then he will most likely inform the admins about it via a manual creq.
If there is no user with the correct file there is no way of knowing that the information in AniDB is in fact wrong. The only possible way that bogus information ends up in the DB is when some user adds a file only he has. And those files are marked deprecated and will most likely not spread anymore. If those files should be a problem in the future, it will be easy to find them and simply delete them from the DB. With AoM I don't really see a way where bogus information can end up in the DB and cause more people to get those files.
So like I said before. If the users have AoM and use it, then wrong information in AniDB can NOT persist. There simply is no way.
Especially not with me around ^_^
If I have a file for the same episode from the same group I will notice the difference and AoM will generate automated creqs or I will generate a manual one. Before AoM I did it manually (a couple of thousand times). That's the way it has always been and trust me, there _were_ lots of files with wrong ed2k hashes in the DB and I found them. Now AoM does it all automatically and I think PetriW for this cool tool. It's like "skywalka in a box", it's easy to use, and it does everything on it's own with close to no user input except the login information and the location where the files are.
/
), no group (
/
)"
