Personal Video Database

It is very difficult for me to say which method is the best as I have never worked with MC and it's API.

Well, I was more thinking in general terms. Would you view this as a good "general method" of integrating with a front end type of system?

If I would need existing data from PVD I would just query the PVD database directly using SQL and then put data into MC using it's API. This seems like most powerful and universal way to me.

Another approach that is much easier is to create an export template for PVD and write an import plugin for MC that understands files generated using the template. 

If i would need to get data from MC into PVD I would just write an import plugin that uses MC API.

Some other users in your forum have already solved this. I.e. we can Import metadata from PVD.

But it requires several manual steps and that's what I'm trying to "fix" with the solution outlined above. I.e. what I'm trying to achieve, is a tighter integration between MC and PVD which doesn't require several steps and switching back and forth between applications after the user has acquired and imported new movies in MC.

I have no problem adding some kind of communication protocol in PVD if it would make sense, but I do not see a need for this at this point.

Fair enough, It's your call..

I take it your thinking is media may be first imported to MC, and therefore the plugin needs to be able to induce PVD to create a record and download the metadata. Slick, but I think there are too many things that could go wrong. Even if it does work, the plugin is more likely to need updating when PVD (the program) is updated. But most importantly, this doesn't make sense from a work flow point-of-view. If PVD is being used to collect and manage metadata for videos, then it should be allowed to do that—with user supervision—before the data is imported to MC. Otherwise, the data may be incomplete or erroneous. To make matters worse, it will remain that way in PVD until the user recognizes this is so.

Yes, I suppose things could go wrong, especially the first time you export from PVD to MC. But you could still browse the received data in MC. I'm not saying that we don't *need* the PVD GUI, I'm just saying that, hopefully, MC's theater view browsing will improve over time...

But after that, when you do one movie at a time, detecting errors should be easier..

It seems to me this has to be much simpler, and doesn't violate the work flow premise. It would be reasonable to assume that, whatever the state of the data at the time the plugin is run, it's appropriate to import it. Also, rather than requiring the user to select items in MC to be updated, the plugin could automatically update items based on PVD's Date updated (new in 0.9.9.5). There would need to be an equivalent field in MC that the plugin updates. Knowing the MC user can choose to use Auto-import or not, it makes sense to ignore records that exist in PVD but have not yet been added to MC. Such records would be updated after they have been added to PVD.

This seems to be a "phase 2" issue. Remember, I haven't even started writing code yet I am not even sure yet if it will be possible to do my outline from above...

BTW, we discussed in the MC forum how perhaps credits can be handled using two fields in MC. For example, for actors, import [Name] to Actors and [Seq#]. [Name] as [Role] to a second field (Actor credits?). Are you planning on building that into your plugin? I don't see a special-purpose credits field being added to MC, so this is probably the way to go.

I haven't really "solved" yet how field mapping should be done. I think that Nostra's excellent system of field mapping/parsing could be used as is (see, for example, plain text export). The advantage of this is that it has already been done and the parsing engine is designed around the database. The parsed output, one per file, would then be transmitted to MC via UDP. MC would then simply stick the field mappings into the proper MC fields.

The plugin on the PVD side would then be installed together with a default template (with a "pages template" for Credits which would surely accomodate your sequencing request).

What do you mean with "scan"?

Scan: When you first have set up your "watch folders" and then select "scan folders" to retrieve metadata. (PVD isn't installed on this PC so I'm not completely sure what the exact wording is)

By "Scan results" I mean the disambiguation dialog that pops up when you import meta data. For example to select between the original "Open your eyes (abre los ojos)" and the Hollywood remake.

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...

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.

types of data (e.g., ordered lists of [name] - [role]/[function] for credits) and they ask for a list of fields needed for movies, I have to

Do you mean the annoying reordering of lists into alphabetical order? I agree that there should be another ordered list type.

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

Then, maybe they'll find a way to accommodate both approaches.

Yes, I agree with you on this.

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

[..]
Yes. I see you just replace all commas with semi colons. I used a separate export to do that only for list fields—so it wouldn't replace commas in fields like Description.
[...]

Yeah, I guess I can live with some extra semicolons.. Since the MPL file can be reimported, I guess I can do it all over again if those semicolons start bothering me!

[..]
I attempted to explain here some new field types that would be required to properly handle movie information, but there's no sign yet they "get it."
[...]

Notice how JRMC did the GUI design in cooperation with the users on the forum. I'm pretty sure they'll come around with a proper list of meta data for movies. As far as I understand, they're also working on theater view meta display view for movies.

It'd be interesting to know how the various online databases overlap and differ wrt. meta data. Has anyone done a survey?! The intersection between these services + some of the "Good differences" I guess should be the standard for what they end up with...

So, does this achieve a level of integration you're satisfied with, or do you think there might be a better solution?
[...]

It looks like this is as far as we can get without code changes on either side. It's pretty good, I'd say...

The best solution, of course, would be a plugin on the JRMC side with direct communication to PVD.

To split files use this code in main template file:

Code: [Select]

Files:
{%value=path template="pages\files.ptm"}
And this in files.ptm

Code: [Select]

{%value}


P.S. You will need to use field number instead of "path" if you use 0.9.8.20

Nostra:

This is a step forward but consider this: In the resulting MPL file, I would like one <item> section per File. When I do what you suggest above, I get one item section where the filenames appear twice.

I tried moving the Item section into files.ptm, but then %value=xx didn't parse into the resulting mpl file.

Can a child template somehow inherit  the values from the parent template?

[...]
That's slick. Would you like to share your routine? I'm also curious about how you handle the list fields.
[...]

I'll post the scripts when I get back home later on today.

I assume you're talking about semi colon (after replace in output script) delimited fields? I have posted some suggestions over at the mc forums regarding this.  http://yabb.jriver.com/interact/index.php?topic=51208.0. It'll be interesting to see if for example "Director" (MC) will be changed to accomodate this.

[...]
Except for the problem you mention, it sounds like you've come pretty close to an ideal. Even if it has to be done manually, it only takes a few minutes. Beyond that, I can only offer some conflicting thoughts...

Since PVD uses a Firebird database, there's a possibility of the data being pulled directly from the database. This would probably be child's play for MC developers, but they're not going to do it for a handful of users using PVD.

Most people willing to make the effort to collect the information are going to use custom fields, use standard fields for other uses, and have differing preferences as to how data elements are handled in PVD and MC. Accommodating all the possible variations makes closer integration more difficult. In fact, with this in mind, the flexibility of exporting to XML starts to look pretty good.

A user with sufficient programming knowledge could write an application that reads the database and writes a MPL file. The advantage of that is it could be scheduled to run at regular intervals, and MC could be configured to import it regularly. The fact that both the export and import would run automatically would make it seem the two applications were integrated.

While it doesn't seem like a big deal, there is user data created in MC (e.g., date played, rating) that has no way of being recorded (automatically) in PVD. As a practical matter, I suppose the best way to deal with such things is to import the PVD counterparts into separate fields—for comparison to the MC values. In MC you would have the choice of displaying one, the other, or a calculated result, and would be able to report at any time what needs to be updated in PVD to bring it in sync.

Regardless of the integration issues, I'm convinced MC will never have an information gathering ability of it's own that will come close to what PVD can do. So, hopefully, we can work through the integration issues. Meanwhile, I'm enjoy using PVD with my "Theater View" skin to "collect, organize and play" my movies.

But what about the following solution which requires "smaller" changes on the PVD side? And practically NO changes on the JRMC side:
o Use send to external in MC (with filename as parameter) to pass parameters to PVD (Similar to how JRMC can receive parameters)
o Implement a silent mode on the PVD side, where search, update and export are done "behind the curtains".
o PVD's export function "runs" the exported MPL file
o  -- OR even better: PVD sends a core command to MC with mpl filename attached. Doesn't require OS to trigger import
o JRMC dialog pops up when import has finished.

[...]
It would require a text editor that uses regex, and the regex for finding and deleting the text between the first "|" and "</" of the filename tag.

Yes, that's possible. Still, It's cumbersome.

It's a pity because I have a setup that's relatively simple to use now:

Open PVD, search folders and export. The export launches a batch file which again launches MC with import playlist command line options. Done.