With more back catalogue titles only sellable on the cheap, we see more movies per disk. Especially "2 movies per disk" seem popular. So far, many times these are all from the same studio, like a number of recent Disney releases in the USA. But there has also been Bloodsport/Timecop (USA BluRay 883929132256). And I am seeing more combinations of movies not sharing the studios. Of course this is because it is the distributor that combines movies into one release.

Yet, studios and distributors are currently a release ("profile") attribute, for DVDp-historical reasons sharing the same database table.

In a new program release, I would like to see these split and also that 'studio' can be a per movie attribute, much like cast and crew are. A multimovie-singledisk would then need separators for each movie.
An alternative could be to have child profiles for such a release, but that would require some newly invented ID for the child (a movie ID  ). (it could be a stepping stone to a unified movie db as a part of the profile db, but let's not get ahead of ourselves...)

Any of the two would do for me, as it resolves the incorrect 'studio is a release attribute'.

I would much rather see this fixed correctly, which would mean a new primary key that could allow us to enter same disc in db more than once. Primary key could be for example a combination of UPC/Disc ID + Locality + running number. This would also allow us to profile short film collections correctly.

A multimovie-singledisk release can have different Genres, Running Time, CoO, Production Year, Audio Tracks, Aspect Ratio etc. for each film.

Quoting eommen:

Quote:
An alternative could be to have child profiles for such a release, but that would require some newly invented ID for the child (a movie ID  ).

I think this is the best solution (1 movie= 1 profile), and the program already allows to do it. For example, each time I have a short film as feature on a disc, I create a profile for it : no boxset, no dividers, data corresponding to each movie : everything is simple and clear.

You just have to create manual profiles each time you have no specific ID.

Quoting mediadogg:

Quote:
<...>
As you know, today all discIDs start with "I" as database key, with "M" for manual profile database keys, and with a digit (0 - 9) for UPC/EAN. All of them allow for locality. (For simplicity I haven't mentioned the rules for the following characters, but we all know those rules.)

No, I didn't know. Neither did I study the underlining coding rules.   

Quote:
So, could the solution be as simple as DVDP recognizing some new defined key structures (e.g. for a "movie" profile, or whatever - its a shame "M" is already taken  )?
<...>

How about "F" (from "film")?

Quoting Kulju:

Quote:
<...>A multimovie-singledisk release can have different Genres, Running Time, CoO, Production Year, Audio Tracks, Aspect Ratio etc. for each film.

Agreed, in principle. I just thought I'd start with a small request, rather than a wholesale refurbushing request. Mind you, the latter would be preferable. I agree with the items you named as movie/film specific, albeit that running time can also be the combined running times of whatever is on the disk (think TV episodes...).

Quoting Kulju:

Quote:
I would much rather see this fixed correctly...

I agree.  No more band-aids.  The next version should fix this issue once and for all.  Do it right the first time.

This has been my #1 request for years.  I'm tired of having to split sets into manual profiles so I can track things properly.

If it were for me, we's need an extension of the existing key.

A "variant" so to speak. This way we could cover all sorts of conflicts we have today: Multiple same-day releases, re-releases, UPC-reusage, multiple movies on the same disc and so forth.

In the program you'd say you wanted to create a variant of an existing profile, then the profile ID would change to the existing key + a determined suffix.

When you contribute a variant for the first time, it is not treated the same as a new profile in regards to voting.

It will have to go through the regular voting process, comparing the variant profile with the existing one and the contributor has to explain why (s)he deemed the variant necessary.

The contribution will appear to all owners of the original profile (and all other variant owners) who can read the contributor's reasoning and vote accordingly.

This way the database won't get flooded with variants of profiles which aren't really variants according to the rules just because a user wants his own version of the profile because he doesn't agree with other contributors of the same profile.

Once the variant has been accepted, the owners of the original profile (and other variants) will not get to vote on the variant anymore, because it has been successfully "branched off".

If I don't contribute a variant profile, it remains in my database just like any other manual profile.


Which brings us to the issue of the suffix ID part.

When I create a variant locally, I'd go with [UPC].[Locality].[MV1]

MV = Manual Variant.

When the MV is contributed (and not yet approved) there will be a new online ID created, e.g. [UPC].[Locality].[V4]

During the transmission of the data (which still happens in the program) the web server tells the local profile of this new ID and the V4 is stored within the profile data somewhere.

Once the V4 profile is accepted and the user runs his next update of his profiles, the program properly changes the ID of the profile from .[MV1] to .[V4].

If the contribution is denied or the user never completes the contribution process in the first place, his ID remains MV1.


The rest of the program behaves the same way it already does: When adding by UPC or DiscIDs if there are multiple profile matches, just show them in a list.

This could also be tied into a larger project to include TV episodes and short films, each of which has their own data for things like running time, production years, overviews, cast and crew, audio tracks...even aspect ratios ("Buffy the Vampire Slayer" had a special widescreen episode, as did the fourth season of "The Shield").