Release

Concept of releases

Instead of grouping files by group only (anime-group) we could introduce "Releases" in which files could be grouped completely aribitary. That is both files from different groups and files without group.

Why

• Fix ag-state, or rather an addition to ag state (240, 145)
• Grouping and states for no-group files
• Multiple relases per group; DTV/DVD, low/high quality, avi/mkv, xvid/h264, etc. instead of version abuse

Why not?

• More data to store.
• More administration.

Possible tables

 releasetb(
  id int4,
  date int4,
  update int4,
  uid int4,
  edituid int4,
  aid int4,
 -- cached gids
  gids int4[],
  status int2,
 -- cached ep map, only for anime with known number of eps, only normal eps (and O)
  completion bitstring,
 -- comment?
  other varchar
 );

 releasefiletb(
  id int4,
  date int4,
  releaseid int4,
  aid int4,
  eid int4,
 -- only one file per eid, deprecated files would not be part of any release
  fid int4,
  gid int4,
 -- maybe, requests could possibly be related to releastb instead
  update int4,
  uid int4,
  edituid int4 
 );

I am not sure about that assumption of one file per ep. I.e. what happens with releases which have external subtitles? (We could of course use the file-file relations for that info.) How would you handle a case where a release contains files from multiple groups and one or more eps were actually subbed by more than one group? I.e. group A released 1-10 and group B released 1-3 and A&B released 11-12. That cached ep map mentioned earlier is not the status int2, right? Would releases need a name? Or would there be different "types" of releases?

Exp 18:56, 8 July 2007 (UTC)

1. a release is supposed to represent one possible "pack" of files that covers an anime (to assist you when you're wondering what to get) and in that regard only one file per ep is needed. you usually don't watch several files of the same ep unless you want to compare (or is rewatching). so, using your example, we'd have to choose whether we want 1-3 from A or B in the "release". this could (and probably will) lead to some political issues, but in worst case two relases can be added; one with 1-3 A and one with 1-3 (as one file can be part of several releases). allowing several files per ep (disregarding subtitles and split files for now) breaks the initial idea of releases, although it would still solve most of the issues it was supposed to address. (on a side note; new versions of files would "push out" the old versions in a release. complete reencodes would be added as new releases).
2. the cached ep map = eprange in animegrouptb, meaning eprange was based on that idea.
3. releases would usually be addressed by group names, but could have both name and type too. the "other" bit is the alternative, meaning if a release needs some additional explaining it would go there. --Epoximator 13:11, 10 July 2007 (UTC)

Interface

• On file add: select one of the existing releases or create a new release (only if epno is 1)
• Request file to be added/removed from a release (from anime/group/file page)
• Replace/merge/add to group box @ anime page, new release page (per anime)

Questions

Can it replace animegrouptb?

Don't think so. A release can not be 'dropped' because it would break the purpose of it self (at least partly). And since a system like this can't be fully automated, the ag table is (most likely) needed as the basic way of file grouping.

Can it be semi-automated?

It should at least be possible to build the initial content based on some general rules. This might not be wanted though; it could only be an addition to animegroups. Meaning releases would only be used where it is needed (sort of like file/ep rels are used today). It should at least not be needed for movies/ovas (only one "ep").

As you've already pointed out such a release system would not fully replace the automatically generated animegrouptb data. Which would meant that there would probably be no reason to duplicate the data. For all those releases where the animegrouptb approach works fine, we wouldn't need to add any release info. Release info would only be manually added for the hard cases. And even there we might want to look for an approach which can handle the group<->subgroup releases mostly automatically.

Exp 18:50, 8 July 2007 (UTC)