Deprecated Files [DONE]

Elberet · Post by **Elberet** » Mon Sep 29, 2003 9:49 pm

Yare yare, look at the files listing for Seikai no Monshou... Since Anime_Fin had to release a v2 and v3 for the first few episodes, a pretty long and confusing list has built up there. Not to mention the near-dead no-group files.

Hence, it might be a good idea to allow files to be declared "deprecated". This doesn't change anything about the stats or the availabilit of the file, but could be used to re-arrange the file listings so that active and interesting files are listed before dead or broken ones, even tho they're smaller. (Also consider showing deprecated files grayed out and separated from the rest with a horizontal line. Or something like that.)

All in all, the "deprecated" flag could be interpreted as a recommendation: "Don't download this file, it'll either never complete because it's dead, or you'll just waste your downstream and someone else's upstream."

Iceman[grrrr] · Post by **Iceman[grrrr]** » Tue Sep 30, 2003 1:50 am

if implemented, all crc reported bad and anterior version of files should be flagged!

wahaha · Post by **wahaha** » Tue Sep 30, 2003 9:39 am

Elberet wrote:Yare yare, look at the files listing for Seikai no Monshou...

For the lazy people like myself: http://anidb.ath.cx/perl-bin/animedb.pl ... ll=1#eid_1

I'd prefer some automatic way to sort and even hide files instead of letting people set flags for them.

For example:

Hide files for which newer versions exist (v1 and v2 from anime_fin)
Hide files with less than the x% of the average users/file (20% would hide all files with < 4,4 users)
Unhide all files with at least one person sharing it (would unhide anime_fin v2)
Unhide all files with at least x users (10 or 20, wouldn't unhide anything)
Sort by score instead of size. That score could be based on many values, thus even be meaningful ^^;
Something based on: User-values (total, deleted, sharing, release), file-rating and maybe group-rating

Post by **PetriW** » Tue Sep 30, 2003 10:57 am

Just don't make hiding and stuff the default behaviour.

Elberet · Post by **Elberet** » Tue Sep 30, 2003 11:09 am

Files shouldn't be hidden at all, IMO. It's not possible to make 100% sure that an important file does not get hidden, and users who want to get a new anime would be "forced" to get certain files.

wahaha · Post by **wahaha** » Tue Sep 30, 2003 11:48 am

1) Hiding files:
Addendum to hiding files:
- Should only kick in with a minimum amount of files/ep... 3-5 for example

PetriW wrote:Just don't make hiding and stuff the default behaviour.

Should be a user-customizable setting anyway, IMO.

Elberet wrote:Files shouldn't be hidden at all, IMO. It's not possible to make 100% sure that an important file does not get hidden

Sure, you can never reach a 100%-accuracy of automatically meeting the user's preference when hiding files, but if* it would make using anidb easier for the majority of the users, it'd be worth it.

* can't prove that of course ^^;

Hiding files should allow a better overview and also partly solve the initial problem of users "clicking the wrong link". There should nonetheless be some way to really show all files and a notification-line ("3 more files for this ep...").

Elberet wrote:users who want to get a new anime would be "forced" to get certain files.

Wasn't that the point of "deprecated files", to prevent users from (trying to) download a certain version?

2) Once more about automatic sorting vs a user-controlled flag:
IMO, the knowledge to mark a file as "deprecated" can also be gained from what anidb knows about the files. Is there anything that actually needs a human being to classify the files?

Iceman[grrrr] · Post by **Iceman[grrrr]** » Tue Sep 30, 2003 3:23 pm

wahaha wrote:
Elberet wrote:users who want to get a new anime would be "forced" to get certain files.
Wasn't that the point of "deprecated files", to prevent users from (trying to) download a certain version?

Not really... the file is still listed... the user could shoose to download this one if he wanted! It's just easier to spot downloadable files.

Elberet · Post by **Elberet** » Tue Sep 30, 2003 4:08 pm

Well, first and foremost I was sick of seeing a list of 9 files that contains 2 broken ones (because the encoder made a mistake and released v2 and v3), and some dead files nobody even added to their mylists. Since deleting or making files inaccessible would not follow AniDB's spirit (it's supposed to be a database listing all anime-related files people had, sort of like an inventory - releasing is done at AR and SR), I wanted to come up with a way to get such "bad" files out of the way without breaking with the tradition.

Marking a file as deprecated tells users who which to download that anime that they should better look for a different file. This particular file floats around somewhere (and is therefore listed), but if you can get a better one, don't bother about the deprecated one. On the other hand, hiding a file is like lying about it's existence...

wahaha · Post by **wahaha** » Tue Sep 30, 2003 5:15 pm

Iceman[grrrr] wrote:the file is still listed... the user could shoose to download this one if he wanted! It's just easier to spot downloadable files.

I think this "easier to spot"-part isn't really neccessary. It isn't hard to figure out which files to choose if you know the values - such a function would mainly be for newbies who are still a bit irritated by all the information presented.

Elberet wrote:Since deleting or making files inaccessible would not follow AniDB's spirit [...] I wanted to come up with a way to get such "bad" files out of the way without breaking with the tradition.
[...] hiding a file is like lying about it's existence...

"Hidden" as in "click here to see them" - there's no way to improve a "long and confusing list" without hiding information IMO, especially files with only one or even zero users. One should then have to do one extra click to get the additional (file) information - I didn't mean to suggest making it inaccessible.

Elberet wrote:Marking a file as deprecated tells users who which to download that anime that they should better look for a different file. This particular file floats around somewhere (and is therefore listed), but if you can get a better one, don't bother about the deprecated one.

Yes, but: ^^

The conclusions which would make the "advanced user" set such a flag for the "newbies" are most likely based on the values anidb already knows.
"This file's a v1 where a v2 exists, only 2 people have it and nobody shares it -> deprecated." is too simple to not leave it to a program, so I think we shouldn't go with a user-controlled flag.

Elberet · Post by **Elberet** » Tue Sep 30, 2003 5:31 pm

wahaha wrote:only 2 people have it and nobody shares it -> deprecated.

The big problem is the tiny detail: How many users are needed to rate the file significant enough not hide it? How are users with an unknown state or on-cd state taken into the calculation? What if there's only one user who's sharing the file but 200 who have the v2 yet nobody's set their file state to shared?

All of these conditions are debateable and depend highly on everyone's personal opinion. The inevitable result is a huge debate here. A user-controllable flag might result in contradicting creqs, but the moderators can deny these easier then endlessly discuss the hide conditions.

wahaha wrote:there's no way to improve a "long and confusing list" without hiding information IMO

Code: Select all

File 1: high quality, 20 users, group A, v3
File 2: high quality, 50 users, group B, v1
File 3: medium quality, 40 users, no group
---
File 4: high quality, 2 users, group A, v2
File 5: high quality, 1 users, group A, v1
File 6: bad quality, 2 users, no group
File 7: ...
File 8: ...
...

Looks much better to me then sorting the files 4-8 together with files 1-3 into the same list, by file size...

Post by **exp** » Wed Oct 01, 2003 9:22 am

hm,

i see your point. And i also think that if we do this it should be automated and not controlled by a flag which would have to be set manually.
this leads one to the big question of exactly what makes a file deprecated.
and btw. IMHO the internal sorting should stay @ sort by size
however normal and deprecated files could of course be shown (and sorted) seperatly.

BYe!
EXP

Elberet · Post by **Elberet** » Wed Oct 01, 2003 12:39 pm

exp wrote:and btw. IMHO the internal sorting should stay @ sort by size
however normal and deprecated files could of course be shown (and sorted) seperatly.

That's exactly what I was aiming at.

exp wrote:And i also think that if we do this it should be automated and not controlled by a flag which would have to be set manually.

It's your choice (as always), but if it's done automatically, there should still be a flag to manually override the DB's automatic decision - a tri-state flag with a "don't care" state.

exp wrote:this leads one to the big question of exactly what makes a file deprecated.

Indeed.

Option 1:
- less then 5 users, none are on shared or released
- added at least 4 weeks ago.
- at least one file with similar quality and more then 30 users.
problem: in some cases, DTV-captures would push DVD-rips over the edge and make them deprecated. Not a good idea.

Option 2:
- at least one file from same group and same source with a higher version
- less then 5 users, nobody shares or releases.
Problem: Look at SnM. There's still someone who shares the v2, even tho that file is completely broken. Another problem is that some files have unknown source and quality. There's no way for an automatic system to reliably find and flag deprecated files (that are deprecated because a new version was released) in that case.

Option 3:
Umm... can't come up with one. But regardless of what combination of conditions and exceptions I think of, there's almost always a special case that can't be covered.

kidan · Post by **kidan** » Wed Oct 01, 2003 2:27 pm

why not use this:

newer version availiable -> deprecated

corrupt (optional: and file of same size for this ep) -> deprecated

noone who set this file to shared/release (and more then 5 users having the file) -> deprecated

Elberet · Post by **Elberet** » Wed Oct 01, 2003 2:35 pm

kidan wrote:newer version availiable -> deprecated

What's with files where the group released a v2 long after the initial release only to fix a few minor typesetting problems while the v1 has already been well spread over the network? Some people may not want to wait ages to download a rare file when a fast loading file with many sources is available, only because the subs are a little better readable.

Taking that decision away from the user (or the group) doesn't sound right.

wahaha · Post by **wahaha** » Wed Oct 01, 2003 3:35 pm

Elberet wrote:[Only minor changes from v1 to v2]

Then it should be overridden by some of the other conditions.
If a v2 really didn't fix anything important (e.g. Stellvia 15v2 just fixed a wrong preview-title IIRC, but was released within a few hours) it would be reflected by the user-values: A "high" (as in "not low") user-count or even some people sharing that v1.

Ok - it's obviously possible that some strange person shares a v2 although there's a v3... well, be it so. I already admitted that one can't achieve a 100% right classification (with such a strange user-behaviour). In this case, it'd be better to send that user a notice instead of trying to fix something in the classification.