Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[raldo]

I have made a new export script for Personal Video Database (PVD) which exports to an MPL file with several of the new database fields from build .143

[...]
13.0.143 (03/20/2009)

[...]
4. NEW: Added new video fields "Director", "Producer", "Screenwriter", "Original Title", "MPAA Rating", "MPAA Rating Description", "Country", "Tagline", "Video Standard", "Aspect Ratio", "Actors", and "Studios".
[...]

Comments:
o There can be more than one director, thus MC's "Director" database field should be a semi colon delimited list
o Add IMDBRating as a default field? (Should be a decimal number)
o Add a new semi colon delimited field called "Tags"?

[Yaobing]

What are "Tags"?

[raldo]

Well, I guess "Tags" is similar to "Keywords".

But "Tags" is used in Movielens and PVD.

[Yaobing]

Well, I guess "Tags" is similar to "Keywords".

But "Tags" is used in Movielens and PVD.

In that case, perhaps the existing "Keywords" field should be sufficient.

[raldo]

In that case, perhaps the existing "Keywords" field should be sufficient.

True.

Btw. Composer, Screenwriter should also be made into comma delimited string fields..

[raldo]

Awards - Comma delimited field

[rick.ca]

I've often wondered why users are asked what new fields they would like added to MC, when we can add whatever custom fields we might need. It now dawns on me maybe we are being asked so that if the handing of any particular field needs to be optimized in any particular way, that can be "built-in" as well. For example, perhaps People and Keywords are optimized (e.g., they are handled in a relational fashion), but if we were to add custom fields for actors and tags (i.e., the exact same data types) their handling would not be optimized.

Is there any truth to this? If there is, is it likely to make much difference? It would be common for users to have 1,000's of movies, but not 100,000's.

If this does matter, we need to understand. PVD is built on a relational database, and allows users to add any type of custom field they want. Importing all of this into MC won't be a problem if it's just a matter of adding custom fields as needed. On the other hand, if "special" fields need to be used for certain data types, we need to understand that. And we may need to think harder about what additional fields we might need. For example, I can map my "tags" to Keywords, but what should I do with my "themes" and "tones"? Can I just add custom fields, or should I be asking for more fields like Keywords?

[raldo]

[...]Can I just add custom fields, or should I be asking for more fields like Keywords?

The main reason why I'm asking for more default fields, is, I guess, more out of altruism. I have recommended MC to several friends/relatives and the fact that some desired fields do not exist, make it cumbersome to assist these people in setting up their systems.

I'd like to request a new field type: An ordered list, similar to the current comma delimited list but *without* the alphabetical auto reordering feature. Why? Because Credits in movies need to be ordered in the original order...

[Yaobing]

We are adding default fields so we can import data into these fields, and so that users do not have to create custom fields on some common ones (obviously custom fields will always be needed for some users, no matter how many default ones we add, but having some common ones ready is nice).  We have added the functionality of importing from xml files produced by "My Movies".  I believe I have the most important fields imported.

[rick.ca]

Thanks, Yaobing. So, stock video fields are just for convenience—there's no reason why custom fields cannot be used instead, or in addition to, the fields provided. A few more questions...

Why are stock fields "locked" in respect of Flags and Data/Edit Type? I suppose this may be necessary so the user doesn't change something the My Movies import relies on. But if my import requires a different field type, I can't use the one provided. I can use a custom field, but—not being able to delete the unused stock field—I have to change it's display name. This seems unnecessarily complicated, and the result (unused, renamed stock fields) potentially confusing.

Is there a way to record actors' roles or production credits' titles/functions? An actor could be entered as "[name] - [role]," but that would make more difficult the most common filtering—displaying movies with a particular actor. How are roles handled in the My Movies data?

I suppose the ability to handle roles is similar to the ability to order the list. Both would require a field type with three parts—a sequence number, a value (e.g., name) and a descriptor (e.g., role). Then the role could be displayed with the name, but would not affect filtering by name, and the list could be ordered. I can imagine it, but I don't have a clue if it's feasible.

[Yaobing]

Thanks, Yaobing. So, stock video fields are just for convenience—there's no reason why custom fields cannot be used instead, or in addition to, the fields provided. A few more questions...

Why are stock fields "locked" in respect of Flags and Data/Edit Type? I suppose this may be necessary so the user doesn't change something the My Movies import relies on. But if my import requires a different field type, I can't use the one provided. I can use a custom field, but—not being able to delete the unused stock field—I have to change it's display name. This seems unnecessarily complicated, and the result (unused, renamed stock fields) potentially confusing.

Is there a way to record actors' roles or production credits' titles/functions? An actor could be entered as "[name] - [role]," but that would make more difficult the most common filtering—displaying movies with a particular actor. How are roles handled in the My Movies data?

I suppose the ability to handle roles is similar to the ability to order the list. Both would require a field type with three parts—a sequence number, a value (e.g., name) and a descriptor (e.g., role). Then the role could be displayed with the name, but would not affect filtering by name, and the list could be ordered. I can imagine it, but I don't have a clue if it's feasible.

Actors in My Movies are imported as "[name], as [role]."  This, as you know, is not an ideal solution, and I do not have a better answer.  Likewise I do not know how to answer your other questions.

[raldo]

Actors in My Movies are imported as "[name], as [role]."  This, as you know, is not an ideal solution, and I do not have a better answer.  Likewise I do not know how to answer your other questions.

I have experimented with expressions to see if it's possible to "parse" from "[name], as [role]" into a "[name]" only list.

As far as I can see, this isn't possible because you cannot use a regular expression type "*" in the MC expression language:
ActorOnlyField=Replace([Actor], /, as*/;,/;)

But one could possibly import both Actors, KeyGrip, ... in *addition to a* Credits=[Name], as [Actor|Grip|GeyGrip] [(role1,role2,...)]

[rick.ca]

Good point, Raldo. Although it would be much preferable to have a new field type that would handle credits, they could be dealt with using two fields. The second could handle the ordering requirement as well, by importing data in the form: 1. [Name1] as [Role1]; 2. [Name2] as [Role2];...

Now if someone could show me how to create that using a PVD export template...

[raldo]

[Genre] should be a comma delimited string field. Movie information usually contains multiple genres...

[darichman]

[Genre] should be a comma delimited string field. Movie information usually contains multiple genres...

I agree, as should some other fields like Country and Artist. I think J River wanted to keep these standard string to ensure compatibility with other hardware/software.
The option to change the defaults would be very welcome.

[rick.ca]

[Genre] should be a comma delimited string field. Movie information usually contains multiple genres...

True, but music normally has only one genre (and possibly multiple Styles). Personally, I see no harm in making it a list field, but others may object because it would allow the "error" of multiple genres for music. It may be better to add a separate Video genres field.

I think J River wanted to keep these standard string to ensure compatibility with other hardware/software.

I don't know—maybe it's necessary to comply with existing music tag standards, although it would still be possible to convert lists to strings for writing to tags.