New mylist file flag: corrupted [DONE]
Moderator: AniDB
New mylist file flag: corrupted [DONE]
Many want to add their files to the mylist, however they don't want to add it if it's corrupted, so they create a new entry, leading to Skywalka growing more insane each day.
How about if the user could add the file to the mylist but mark it corrupted? If a file is marked corrupted it's no longer added to toward total users who have the file but *ding ding* the user has it in his mylist.
This along with the file add sanity check suggested might be something quite nice. Plus it might encourage people to not add bogus files.
Notice, this would be a new fields so you can still add it as on hdd but corrupted.
How about if the user could add the file to the mylist but mark it corrupted? If a file is marked corrupted it's no longer added to toward total users who have the file but *ding ding* the user has it in his mylist.
This along with the file add sanity check suggested might be something quite nice. Plus it might encourage people to not add bogus files.
Notice, this would be a new fields so you can still add it as on hdd but corrupted.
And as the creator of AOM, if possible also add some means to add the ed2k of the corrupted file to that specific mylist entry. This way AOM can still autorename it etc once it's been associated with the file entry through the mylist. 
User gets to enter his ed2k, Skywalka gets to keep his sanity. (If there ever was one!)

User gets to enter his ed2k, Skywalka gets to keep his sanity. (If there ever was one!)
I second the 2nd post ^^, but IMO it'd be nice to even have the full set of hashes for the corrupted file and also have this hash associated with the file (globally, instead of only the single mylist-entry).
A big question for the usability of this feature is whether there's any hash-like function that can help in determining two "similar" files...
A big question for the usability of this feature is whether there's any hash-like function that can help in determining two "similar" files...

Problem with this is you get soooo many more file entres in the file table, it'll kill AOM!wahaha wrote:I second the 2nd post ^^, but IMO it'd be nice to even have the full set of hashes for the corrupted file and also have this hash associated with the file (globally, instead of only the single mylist-entry).
If part two of this feature request isn't filled I'm certain I can make a hack in AOM for it.~
As I see it, the problem here is similar to that with shadow files - a current 'file' needs to be split into several different parts.
For example:
Episode 1 / Episode 2 - Running Time
|
File Group Info - File Size, Group, Source, Langs, Quality, Codecs
|
Specific File A / B - ed2k Hash, Crcs, Corruption
Grr... Shadow files still making my head hurt.
Rar
For example:
Episode 1 / Episode 2 - Running Time
|
File Group Info - File Size, Group, Source, Langs, Quality, Codecs
|
Specific File A / B - ed2k Hash, Crcs, Corruption
Grr... Shadow files still making my head hurt.
Rar
OTOH, if these ed2k-links were associated with one's mylist alone, they couldn't be identified anymore by anyone but the one person who added it.PetriW wrote:Problem with this is you get soooo many more file entres in the file table, it'll kill AOM!wahaha wrote:I second the 2nd post ^^, but IMO it'd be nice to even have the full set of hashes for the corrupted file and also have this hash associated with the file (globally, instead of only the single mylist-entry).
Since there are widespread files with a corruption, this would create two different kinds of entries for corrupted files: Those with their own entry and those with only a private entry in one's mylist.
I really think adding such possibly corrupted files in private would defeat the concept of seperating the filelist and the individual mylists.
well,
my current stand on this one is:
a) wide spread corrupted files should be added to anidb as normal file entries with the crc-invalid flag set. all the ideas here apply only to files with individual corruption (aka (almost) no one else has a file with the same hash).
that's why we have the deprecated files hiding feature after all.
b) i will probably auto-add one "special" file per ep someday. That one would have no size, no group and would be shown differently. It would be possible to add it to mylist like any other file though.
this file would mainly be usefull to those who have an ep on dvd or watched it on tv bc they no longer have to add some random file for each ep to their mylist.
that could then also be used by ppl who have a corrupted version of a file.
they would of course "loose" the group info by doing that but they could also add the uncorrupted file to mylist and set the state to deleted.
c) about the 2nd request, as stated in a) if multiple ppl have the same corrupted file it should have it's own file entry so as i see it atm this one is pretty useless.
BYe!
EXP
my current stand on this one is:
a) wide spread corrupted files should be added to anidb as normal file entries with the crc-invalid flag set. all the ideas here apply only to files with individual corruption (aka (almost) no one else has a file with the same hash).
that's why we have the deprecated files hiding feature after all.
b) i will probably auto-add one "special" file per ep someday. That one would have no size, no group and would be shown differently. It would be possible to add it to mylist like any other file though.
this file would mainly be usefull to those who have an ep on dvd or watched it on tv bc they no longer have to add some random file for each ep to their mylist.
that could then also be used by ppl who have a corrupted version of a file.
they would of course "loose" the group info by doing that but they could also add the uncorrupted file to mylist and set the state to deleted.
c) about the 2nd request, as stated in a) if multiple ppl have the same corrupted file it should have it's own file entry so as i see it atm this one is pretty useless.
BYe!
EXP
It doesnt have to have an invalid CRC just because its corrupted.exp wrote: a) wide spread corrupted files should be added to anidb as normal file entries with the crc-invalid flag set. all the ideas here apply only to files with individual corruption (aka (almost) no one else has a file with the same hash).
that's why we have the deprecated files hiding feature after all.
They could have released it as a corrupted file, and just ignored making a V2.
well i am talking about files corrupted @ download or storage here.yidaki wrote:It doesnt have to have an invalid CRC just because its corrupted.exp wrote: a) wide spread corrupted files should be added to anidb as normal file entries with the crc-invalid flag set. all the ideas here apply only to files with individual corruption (aka (almost) no one else has a file with the same hash).
that's why we have the deprecated files hiding feature after all.
They could have released it as a corrupted file, and just ignored making a V2.
if the group released a defective file that one could of course still be crc-verified @ anidb.
BYe!
EXP
Woudn't it be an idea to buffer new ed2k-hashes for about a week and count how often those are submitted by different users.
Design:
1. The file's details should be saved in a duplicate of the original file-table.
(not too much work on the DB)
2. There should be a cross-table recording which users submitet the new hash. (2 Cols: tempFID, UserID)
3. Trigger: daily(?)
If a file reaches a defined threshold, it would become a regular file by moving its entry in the original file-table, otherwise it would be discarded after 7 days. It might be a nice feature to autoadd this file to the submitting user's mylists.
While a file is 'on hold' people should be able to find it via search and it would be nice, if there was a list of all 'on hold' files linked (count possibly included in the link) somewhere on the anime-detail-page.
That way AOM would be able to auto-add unknown files to the DB and only the good ones would be added permanently.
For people with individually corrupted files and DVD/TV-seen the pseudo-file-entry would be an good addition to this sceme.
Design:
1. The file's details should be saved in a duplicate of the original file-table.
(not too much work on the DB)
2. There should be a cross-table recording which users submitet the new hash. (2 Cols: tempFID, UserID)
3. Trigger: daily(?)
If a file reaches a defined threshold, it would become a regular file by moving its entry in the original file-table, otherwise it would be discarded after 7 days. It might be a nice feature to autoadd this file to the submitting user's mylists.
While a file is 'on hold' people should be able to find it via search and it would be nice, if there was a list of all 'on hold' files linked (count possibly included in the link) somewhere on the anime-detail-page.
That way AOM would be able to auto-add unknown files to the DB and only the good ones would be added permanently.
For people with individually corrupted files and DVD/TV-seen the pseudo-file-entry would be an good addition to this sceme.