View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0002302 | HTML & PERL | Feature Request | public | 2015-07-18 01:52 | 2019-08-08 16:30 |
| Reporter | Hinoe | Assigned To | DerIdiot | ||
| Priority | normal | Severity | minor | Reproducibility | N/A |
| Status | resolved | Resolution | fixed | ||
| Summary | 0002302: Use file-file relations for smarter file deprecation | ||||
| Description | This is regarding the following criterion for deprecating files, quoted verbatim from the wiki: "another file by the same group with a newer version exists and is marked as file with verified CRC." Current situation: if a group releases 1080p and 720p and the 720p v1 has a muxing problem, the 1080p file will be deprecated by the 720p v2. This is highly undesirable, as it leads to added confusion when viewing the files for a group. It may even result in a TV release deprecating a subsequent BD release that includes script fixes and possibly animation fixes (because BD); that effectively means a worse file can deprecate a better file, which goes against the very purpose of deprecation. Considering that certain groups are known for having different releases and redoing them and can easily have an average of more than 5 files per episode for specific shows, that can be a real concern, especially if automatic hiding of deprecating files is on. I understand that the proper solution, actually handling separate releases for each anime-group, isn't easy to implement, but we can use file-file relations to create a makeshift solution to at least soften the issue. Suggested change: keep the current behavior if there are no "newer version of" file-file rels for the higher version file; if there are such relations, deprecate ONLY the files related as older version. If the older file is v2 or above, repeat process; if the v3 is linked to a v2 but the v2 isn't linked to any v1, deprecate all v1 files, but if it is, deprecate only the linked v1 file (and in either case also deprecate the v2 file in question, of course). Expected post-change behavior: if we add a relation between the two 720p files setting the v1 as the older version of the v2, the 1080p file is no longer considered deprecated; if no such relation is present, no change from current behavior. | ||||
| Tags | No tags attached. | ||||
|
|
Currently, I believe that deprecation already takes source into account. Also, we could just also group deprecation by resolution, sounds simpler to fix a lot of cases (not all cases of course). |
|
|
We could, but I still think the suggestion about file-file rels should be implemented. Otherwise, we'd see ourselves dealing with situations where we might want to implement deprecation by codec and 10bit flag and who knows what else; when all is said and done, even by resolution already essentially boils down to guessing releases, which is altogether a Bad Idea(TM). Still, using resolution *might* be an improvement, as long as we use general vicinities (e.g. 1080 and 1044 should be considered the same "resolution" for that). In any event, file-file rels should probably override such detection altogether, to avoid both false positives and false negatives. |
|
|
fixed differently |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2015-07-18 01:52 | Hinoe | New Issue | |
| 2015-07-18 22:16 | CDB-Man | Note Added: 0003566 | |
| 2015-07-29 07:01 | Hinoe | Note Added: 0003572 | |
| 2015-07-29 07:02 | Hinoe | Note Edited: 0003572 | |
| 2016-02-21 02:19 | DerIdiot | Note Added: 0003672 | |
| 2016-02-21 02:19 | DerIdiot | Status | new => resolved |
| 2016-02-21 02:19 | DerIdiot | Resolution | open => fixed |
| 2016-02-21 02:19 | DerIdiot | Assigned To | => DerIdiot |
