Export template for J River Media Center

[rick.ca]

Do you mean the annoying reordering of lists into alphabetical order?

Yes. It's critical that lists of credits remain in credits order.

I don't understand the syntax "[name] - [role]/[function]". Is this a new field type?

Yes. That's just my way of describing a generic format for all credits. More specifically, it would be "[name] - [role]" for actors, and "[name] - [function, position or job title]" for production credits. It could then be used for any type of credit. For example, you could chose not to have a separate Director field, saving "[name] - Director" in a Production Credits field, along with "[name] - Key grip", etc.

Do you want to start a new thread on this in the MC forums? The timing is correct now...

I think I've already expressed my views in the thread I mentioned. But if you have something to say, I'll probably find it impossible not to add my 2 cents.

I was just suggesting a generic approach ("New Plugin Type") but a simpler solution may work as well.

I'm sure I don't understand all the technical ramifications, but if you can write a MC plugin that accesses the database directly and doesn't need PVD running as a server, that has to simplify the task considerably. On the other hand, if it's simplified too much, it doesn't do much more than the export-import approach.

I imagine this would be something that would necessarily determine all the fields used in a particular PVD database, and facilitate the mapping of any or all those fields to fields in a particular MC database.

What I was leading to with this half-thought is that what most users need help with is the configuration, which is largely a field mapping exercise. Maybe a plugin would be most helpful to the extent it made that as painless as possible. Starting with the premise users are able to configure PVD to get exactly the information they want, imagine this: Your plugin reads their database and sets out all the fields used. For each field, it lists the fields available in MC for mapping, or the option of creating a custom MC field—of the appropriate field type. It would revisit this mapping configuration whenever it detects a field has been added, renamed, changed in type or deleted in PVD. It might even create a default Library View—to arbitrarily display all the fields being populated from the PVD database. I think something like this would be a big help to the "average" user in configuring and maintaining the integration of the two applications.

[raldo]

Yes. That's just my way of describing a generic format for all credits. More specifically, it would be "[name] - [role]" for actors, and "[name] - [function, position or job title]" for production credits. It could then be used for any type of credit. For example, you could chose not to have a separate Director field, saving "[name] - Director" in a Production Credits field, along with "[name] - Key grip", etc.

What if you use semicolon delimited lists for: Roles = name1 - role1; name2 - role2; ...

For example:
Credits = Peter Sellers - Actor (German RocketScientist, The President, English Colonel); Raldo - Key grip; ...

You could use their language to pick actors, key grips, etc., directors.

The flexibility of the metadata view would be even as important. There should be a default config, and flexibility for advanced users..

I think I've already expressed my views in the thread I mentioned. But if you have something to say, I'll probably find it impossible not to add my 2 cents.

I'm thinking: Take the essence of the beforementioned thread and start over again in a new thread. That'll "refresh your package" and make it easier for others to get into your train of thought..

What I was leading to with this half-thought is that what most users need help with is the configuration, which is largely a field mapping exercise. Maybe a plugin would be most helpful to the extent it made that as painless as possible. Starting with the premise users are able to configure PVD to get exactly the information they want, imagine this: Your plugin reads their database and sets out all the fields used. For each field, it lists the fields available in MC for mapping, or the option of creating a custom MC field—of the appropriate field type. It would revisit this mapping configuration whenever it detects a field has been added, renamed, changed in type or deleted in PVD. It might even create a default Library View—to arbitrarily display all the fields being populated from the PVD database. I think something like this would be a big help to the "average" user in configuring and maintaining the integration of the two applications.

Yes, one's balancing a thin line between ease of use and flexibility. A plugin with a default, unchangeable map and then additional configurable maps would be the way to go.

[rick.ca]

At some point, If JRiver decide to make a metadataview, you coud use their language (smart lists) to pick actors, key grips, etc., directors

You're right. I'm too used to thinking about from a relational database point-of-view, which MC is not. So an actor is not related to a movie via a role in MC—it can only search selected fields for the text of the actors name. This also means my idea of using one list field for all credits is not a good one. MC would not be able to simple things like list movies of a particular director—you would have to search for "[name] - Director" in Credits, rather than "[name]" in Director.

That'll "refresh your package" and make it easier for others to get into your train of thought.

It would help if I had a train of thought that goes in one direction. 

Yes, one's balancing a thin line between ease of use and flexibility.

The main idea behind my view is to use PVD to collect the data in an organized and controlled fashion. Having done that, all that's required is a way to dump it all into MC in some reliable fashion (i.e., data going into the correct field type, no conflicts with existing field use, etc). Once it's there, the user can decide what to display and make use of. I have no problem with the idea of providing default field mappings for the sake of ease of use, but at the same time, I believe the whole thing needs to be fully configurable. Mapping Director onto Director and Genre on to Genre is reasonably safe. Title is pretty obvious, but some will think "the title is the title," while others understand there are titles, original titles and AKA's. And despite what many may think, there is no standard meaning for things like Category and Tag—you can't even say for sure what field type is required. All the potential for confusion is removed if all the database design decisions are made in PVD, and then the plugin preserves that in the transfer to MC.

But I'm getting ahead of myself. I have no idea how difficult it is to create a plugin that might do things like this. Do you think it feasible to make one that lists PVD fields (and their types), offers default mappings to compatible field types and offers to create additional custom fields if necessary? Or were you thinking of something considerably more basic than this?

Open PVD, search folders and export... Done.

If, in the end, you can say the same sort of thing about a plugin, I'm sure you would make many MC users very happy. Most who are interested probably don't have the time or inclination for anything that's not quick and efficient. Once they realize MC is not going to collect the data automatically for them, they'll appreciate the solution: "Configure PVD to get whatever data you want. Install the plugin. Done!"

[raldo]

You're right. I'm too used to thinking about from a relational database point-of-view, which MC is not. So an actor is not related to a movie via a role in MC—it can only search selected fields for the text of the actors name. This also means my idea of using one list field for all credits is not a good one. MC would not be able to simple things like list movies of a particular director—you would have to search for "[name] - Director" in Credits, rather than "[name]" in Director.

Yup, that's exactly the point. Datamodelling is *hard* and I think that's one of the reasons why JR probably sticks to their current model. Also, do you think they'd be able to make MC that fast with a relational database?

It would help if I had a train of thought that goes in one direction. 

Yes. Doable and concise suggestions may be implemented. Other, vague ideas are hard to implement because there is no "design".

[nostra]

Nostra, are you the owner of PVD?

Yes

If yes, would you be interested in cooperating towards making a JRMC plugin where PVD serves JRMC's needs for meta data?

I am interested in everything that can improve PVD user experience. The only problem is that I do not have too much time  for thing like this. Rick knew it and so he asked if you could write the plugin.
The MC API looks pretty good indeed and I think the best way for your task is writing a PVD export plugin that uses the API to add/update records in MC. You will also be able to add a configuration window to set up fields easily. Once the plugin is set up the only thing you will need to do to update information in MC will be hitting the Export button in PVD

Also, do you think they'd be able to make MC that fast with a relational database?

I can't tell for sure what they are using, but it is in fact the best way to achieve good performance in managing big datasets is to use a relation database. I think the MC guys are using one as well.

[rick.ca]

I can't tell for sure what they are using, but it is in fact the best way to achieve good performance in managing big datasets is to use a relation database. I think the MC guys are using one as well.

That's the interesting thing. They're not using a relational database. Following is a comment from the lead developer. It's from years ago, but I'm sure he would say the same thing today.

The buzz about using a "relational database" on Interact is mostly misguided.  MC uses a system highly-tuned for storing the kind of data that's thrown at it.  That same system would allow relational artist and album tables, but this isn't something we think makes sense in the UI for most users.

I think this means they've decided it best it look and behave like a flat file database, but if some part of it needs to be handled as a relation for performance reasons, they will do so. The result is very impressive. It apparently handles very well with databases having 100,000's records.

Raldo, this make me think of something we should probably clarify. I've always wondered why MC developers bother asking what fields they would like to see added to the database, when users can easily add their own custom fields. One reason might be so they can consider the optimal handling of each that is added. So, for example, perhaps the existing Genre and People are handled in a relational way, so they can be used for movie genre and actors. But maybe if custom fields are added for category, actors, director, etc., those would just be handled as regular flat file fields. So the mapping of PVD fields to standard fields provided for the same or similar purpose in MC may be important. I've added a question to your New default video database fields topic at the MC forum.

[raldo]

to add a configuration window to set up fields easily. Once the plugin is set up the only thing you will need to do to update information in MC will be hitting the Export button in PVD

Ok, I'll take a look at you plugin examples when I get back from vacation in a weeks time.

In the meantime, could you please point me in the direction to a workable/compilable plugin example, preferably in C++? I know there are som examples in the forum, but it'd be good to start off with the newest version of a workable example...