English > Scripts and Templates
Export template for J River Media Center
rick.ca:
--- Quote ---Do you mean the annoying reordering of lists into alphabetical order?
--- End quote ---
Yes. It's critical that lists of credits remain in credits order.
--- Quote ---I don't understand the syntax "[name] - [role]/[function]". Is this a new field type?
--- End quote ---
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.
--- Quote ---Do you want to start a new thread on this in the MC forums? The timing is correct now...
--- End quote ---
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. ;)
--- Quote ---I was just suggesting a generic approach ("New Plugin Type") but a simpler solution may work as well.
--- End quote ---
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. :-\
--- Quote ---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.
--- End quote ---
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:
--- Quote from: rick.ca on March 27, 2009, 02:56:13 am ---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.
--- End quote ---
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..
--- Quote ---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. ;)
--- End quote ---
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..
--- Quote ---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.
--- End quote ---
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:
--- Quote ---At some point, If JRiver decide to make a metadataview, you coud use their language (smart lists) to pick actors, key grips, etc., directors
--- End quote ---
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.
--- Quote ---That'll "refresh your package" and make it easier for others to get into your train of thought.
--- End quote ---
It would help if I had a train of thought that goes in one direction. ;D
--- Quote ---Yes, one's balancing a thin line between ease of use and flexibility.
--- End quote ---
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?
--- Quote ---Open PVD, search folders and export... Done.
--- End quote ---
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:
--- Quote from: rick.ca on March 27, 2009, 11:06:13 am ---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.
--- End quote ---
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?
--- Quote ---It would help if I had a train of thought that goes in one direction. ;D
--- End quote ---
Yes. Doable and concise suggestions may be implemented. Other, vague ideas are hard to implement because there is no "design".
nostra:
--- Quote ---Nostra, are you the owner of PVD?
--- End quote ---
Yes
--- Quote ---If yes, would you be interested in cooperating towards making a JRMC plugin where PVD serves JRMC's needs for meta data?
--- End quote ---
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 ;)
--- Quote ---Also, do you think they'd be able to make MC that fast with a relational database?
--- End quote ---
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.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version