Posted by: darichman
« on: April 10, 2009, 02:16:17 pm »Thanks! I haven't seen that thread - will check it out.
Posted by: raldo
« on: April 10, 2009, 01:53:56 pm »Like Rick, it seems to me that MC's approach to video metadata is certainly less than inclusive (although recent trends indicate this may change at some point)...I gather you're talking about displaying video metadata? Yes, it's completely incomprehensible.
I wonder why they haven't released the theater view SDK yet. That would have speeded up things a little..
Quote
The way PVD refers to fields has changed since this post, but it shows how you can go about creating an mpl from PVD: http://yabb.jriver.com/interact/index.php?topic=47538.msg326313#msg326313
If the resultant MPL were in a folder that MC could pick up in auto-import? I know it's not exactly what you had in mind, but we'd be halfway there at least...
Check out this thread too (in the PVD forum): http://www.videodb.info/forum_en/index.php?topic=1238.0
In there, I outline a way of making MC import the exported playlist "automatically" and immediately. It's not a "good" method, but it works.
Posted by: darichman
« on: April 10, 2009, 01:38:38 pm »I'm working on something these days, maybe you'll see something within a few weeks
I've not been too active here lately, but I'll watch this thread with interest. A quick and easy way to pull PVD database info into MC would be a useful tool!
I'm sure you're aware that you can use PVD's export feature to generate an MPL file which can then be imported into MC. That's the way I've been doing it for a while - works great but requires the manual step of exporting from PVD and importing into MC. If what you propose doesn't work out perhaps you might find a way to automate this process somehow as a solution.
It might also be worth considering sending fields to PVD and not filenames. If you have accurate fields in MC this bypasses the need for cleaning up filenames. I export [Name] and [Filename] from MC to [Title] and [Path] in PVD.
Like Rick, it seems to me that MC's approach to video metadata is certainly less than inclusive (although recent trends indicate this may change at some point)... for me, at least at the moment, maintaining a PVD database as well as a MC database seems the best option. The closer we can get the integration the better, however
The way PVD refers to fields has changed since this post, but it shows how you can go about creating an mpl from PVD: http://yabb.jriver.com/interact/index.php?topic=47538.msg326313#msg326313
If the resultant MPL were in a folder that MC could pick up in auto-import? I know it's not exactly what you had in mind, but we'd be halfway there at least...
Until Nostra swoops in and saves the day, of course
Posted by: raldo
« on: April 10, 2009, 11:56:18 am »To use PVD as a silent web retrevial engine would just give your sister & husband the impression it doesn't work.As I said earlier in this thread, PVD should ideally feed info/disambiguation back to MC.
I've also noted that PVD has certain rules for "cleaning up" filenames. Once you learn those rules, the results become a lot better (Example: use "(1of2)" instead of "part 1" in the filename)
Posted by: raldo
« on: April 10, 2009, 11:34:01 am »Version 1.1 has to be at least a year away, so I hope you don't plan on waiting. I realize you probably want to do it your way, regardless of my opinion. But might the "simpler approach" be something like what I suggest, and still be something you can build on later? If so, you might consider a successful "phase 1" plugin might generate enough interest to make things happen faster.I'm working on something these days, maybe you'll see something within a few weeks
Posted by: rick.ca
« on: April 09, 2009, 06:27:56 pm »Quote
The data integrity we are talking about is "Does the imported meta data correspond to the video I have?"
Thanks for elaborating, patch. Just to clarify, my idea of "data integrity" also includes the existence/seen status, consistent titles for foreign films, the updating of all items to the same state, adding missing information "manually" using Web search to find alternate sources, replacing posters of inadequate/consistent quality, comparing questionable data to alternate sources, etc. In many respects, data integrity in this respect can be determined from MC as well as it can from PVD—but it can't be readily corrected. Trying to manage this process from MC, even if one has a much looser idea of "data integrity," would be a frustrating experience.
Quote
you still need to review the results and make corrections where appropriate.
So I agree with this—in a much broader sense. I can assess the results almost instantly when they are "in my face" immediately after a download/update. And corrections can be made quickly and efficiently when all the necessary tools are at hand. Often a human judgement is necessary to select the right tool—change a setting and run the plugin again, use an alternate source, use Web search, make a manual correction, search and compare to other records, etc.
Posted by: patch
« on: April 09, 2009, 12:41:19 pm »It's not just that, though: Some users may have "lesser criteria" on data. For example, some of my friends use MC but complain about the lack of metadata possibilties for movies. Or my sister imports some movies into MC and her husband has no idea what the movies are about. A description, year, director might be nice for them.
But none of them are ready for PVD in its current state.
Have you actually used PVD to get metadata from the web?
It is true there is a silent mode but this is just used to reduce the time you need to wait for downloads to occur, you still need to review the results and make corrections where appropriate.
To use PVD as a silent web retrevial engine would just give your sister & husband the impression it doesn't work.
Some users may have "lesser criteria" on data. ...A description, year, director might be niceThe data integrity we are talking about is "Does the imported meta data correspond to the video I have?" It is not about how many fields from IMDB have been imported. So no you will not reliably get the above data from PVD unless you ensure it is accurately imported into PVD.
The reason is relatively simple. PVD tries to use a trimmed version of the movies file name to search for information on the internet. But the file names a human created and often do not uniquely specify a movie. Further more a movie often has multiple entries in the online databases.
A unique relation from file name to internet database is not going to occur so PVD (or any other program) is not going to work reliably in silent mode with out subsequent user checking data integrity.
Posted by: rick.ca
« on: April 09, 2009, 01:48:30 am »If that's the design premise, it's hard to imagine how your plugin will further the development of PVD.Why? You could still use PVD in the way you've always used it and prune the data. And then use an MC plugin for import. The difference would be that more people would use PVD.
You probably don't agree with it, but I do have a very clear premise. My experience as an MC and PVD user tells me it is very unlikely there will ever be a satisfactory solution for getting video meta data that is "built-in" to MC. J River might implement something, but it is likely to be simplistic and limited. It may satisfy casual users who don't care for more. I see no point in catering to them, however—they don't care!
The rest of us don't want to be restricted to one source of data, and want to be able to combine that data in any way we choose. That can require careful management of configuration settings and workflow which would be very difficult to control via a plugin. Yes, I know I could still do this and just use the plugin to import the results. But then why have the capability of controlling PVD from the plugin at all—for the users who have "simple" configurations requiring little maintenance? If that's the case, they should have no trouble running PVD.
I'm not really ignoring the "casual user" of MC. I just believe if one wants any control over the collection of meta data for video, they are better off using PVD directly. By "better off," I mean in ease of use, efficiency, ability to solve problems, and maintaining data integrity. I'm very much interested in more people using PVD. It's my hope a plugin that makes importing data from PVD much more user friendly would provide the incentive many MC users need. Once they try PVD, I believe they will discover for themselves this is the case. Also, I think the plugin will gain acceptance more readily if users understand PVD is doing the job of collecting and maintaining the meta data, and the plugin is just a rock-solid, one-click (once configured) tool for importing the results.
But all this seems rather moot...
I think I'll just add COM server to my TODO list for 1.1. I am pretty sure that it is the most recent version I will be able to concentrate on such things like controlling PVD from another App. Please use a simpler approach until then.
Version 1.1 has to be at least a year away, so I hope you don't plan on waiting. I realize you probably want to do it your way, regardless of my opinion. But might the "simpler approach" be something like what I suggest, and still be something you can build on later? If so, you might consider a successful "phase 1" plugin might generate enough interest to make things happen faster.
Posted by: raldo
« on: April 08, 2009, 04:35:38 pm »I think I'll just add COM server to my TODO list for 1.1. I am pretty sure that it is the most recent version I will be able to concentrate on such things like controlling PVD from another App. Please use a simpler approach until then.
Great! A com server is a more generalized solution than my proposal...
Posted by: nostra
« on: April 08, 2009, 12:09:23 pm »I think I'll just add COM server to my TODO list for 1.1. I am pretty sure that it is the most recent version I will be able to concentrate on such things like controlling PVD from another App. Please use a simpler approach until then.
Posted by: raldo
« on: April 08, 2009, 11:36:56 am »If that's the design premise, it's hard to imagine how your plugin will further the development of PVD.Why? You could still use PVD in the way you've always used it and prune the data. And then use an MC plugin for import.
The difference would be that more people would use PVD.
Posted by: rick.ca
« on: April 08, 2009, 12:32:39 am »Quote
But none of them are ready for PVD in its current state.
If that's the design premise, it's hard to imagine how your plugin will further the development of PVD. It would make more sense for nostra to give you his code so you can incorporate the acceptable parts of it into your MC plugin.
Posted by: raldo
« on: April 07, 2009, 11:35:58 pm »Yes, but one could still handle data integrity issues with a seamless system. You mentioned a new MC field "DateImportedFromPVD" which could be used to block import. Or some other mechanisms could be used.QuoteI'm interested in a system where the entire operation of metadata import can be done from MC.I don't think the benefits that might be had using this approach would come close to outweighing the data integrity issues I raised above. I wouldn't risk messing-up my database using it, even if it worked. And I'm sure it won't. It's already enough of a challenge controlling "the entire operation of metadata import" directly from PVD.
It's not just that, though: Some users may have "lesser criteria" on data. For example, some of my friends use MC but complain about the lack of metadata possibilties for movies. Or my sister imports some movies into MC and her husband has no idea what the movies are about. A description, year, director might be nice for them.
But none of them are ready for PVD in its current state.
couldn't the plugin still extract all the data temporarily to XML and import that?Yes, that's exactly what I am saying in the above posts. Use the mechanisms that are already there. (but pass the data through UDP instead)
Posted by: rick.ca
« on: April 07, 2009, 10:44:43 pm »Quote
I'm interested in a system where the entire operation of metadata import can be done from MC.
I don't think the benefits that might be had using this approach would come close to outweighing the data integrity issues I raised above. I wouldn't risk messing-up my database using it, even if it worked. And I'm sure it won't. It's already enough of a challenge controlling "the entire operation of metadata import" directly from PVD.
Quote
one somehow has to translate a user configuration into queries via code
I don't understand. Surely the database can be queried to determine the field names and types. And then all the data for records with a pathname can be extracted. I'm sure there may be complications I can't imagine for a process of querying the database one record at a time and updating the corresponding MC record. But if this is impossible, couldn't the plugin still extract all the data temporarily to XML and import that? It's been a while since I've done such an import to MC, but it seems to me you don't even have to worry about whether or not the media files or fields exist in MC—if they don't, they'll simply be ignored.
Posted by: raldo
« on: April 07, 2009, 07:38:42 pm »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.
Raldo, I don't understand your apparent reluctance to consider this may be the best solution.
Well, data retrieval is really not the issue at this point. As I've said before, I'm interested in a system where the entire operation of metadata import can be done from MC.
This also involves triggering a search for new data and resolving ambiguities in the results.
--------------
Btw, as I explained above, one issue with going directly at queries, is that one somehow has to translate a user configuration into queries via code. This mechanism already exists within Nostra's parsing language. Thus my apparent reluctance.
Posted by: rick.ca
« on: April 07, 2009, 06:56:06 pm »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.
Raldo, I don't understand your apparent reluctance to consider this may be the best solution.
Posted by: raldo
« on: April 07, 2009, 02:05:32 pm »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.Some other users in your forum have already solved this. I.e. we can Import metadata from PVD.
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.
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..
Posted by: nostra
« on: April 07, 2009, 01:53:00 pm »It is very difficult for me to say which method is the best as I have never worked with MC and it's API.
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.
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.
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.
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.
Posted by: raldo
« on: April 07, 2009, 01:40:29 pm »Nostra,
Are you interested in integrating PVD with MC as I outline above, considering that there will be needed sw changes on the PVD side?
On the other hand, do you think the method I outlined above is "good"? Is there maybe another way in which this can be made seamless?
Are you interested in integrating PVD with MC as I outline above, considering that there will be needed sw changes on the PVD side?
On the other hand, do you think the method I outlined above is "good"? Is there maybe another way in which this can be made seamless?
Posted by: patch
« on: April 04, 2009, 02:20:53 am »The way it would work (if possible) is as follows:Here I agree with rick.ca, PVD has put a lot of effort into collecting movie data from various sources so let it do it's job as it was designed to. Implementation options
(i) In MC, select one or more files and select "Import metadata from PVD"
(ii) The MC plugin signals PVD sequentially for each filename with with a request for metadata.
(iii) A receive thread on the PVD side processes each request and initiates a metadata scan.
(iv) When the scan for a file has finalized, PVD signals back to MC, either a disambiguation list of alternatives (as descibed above) or the "one and only result"
(v) If MC receives a list of alternatives, the MC plugin brings up a dialog from which the user can select the correct item. Then, MC requests data from PVD.
(vi) When the MC plugin has received data, it populates fields in the MC db according to user configuration in the MC Plugin.
Communication would take place via UDP.
Alternatively, MC could retrieve the data from the database (using the API some other user provided in "some other thread").
a) The simplest is get the user to run PVD first.
b) MC plugin requests data from PVD, then PVD use its full GUI to retrieve the data prior to returning it to MC plugin
c) Combine the above. MC plugin request data from PVD, if know to PVD it returns full information, if it is not in the PVD data base it returns what it knows (ie nothing).
Looking at the user work flow.
User loads movies into PVD, pulling metadata from various sources
User Quits PVD (firebird doesn't allow multiuser / multiprogram access in PVD). This assumes Media center plugin accesses PVD database directly. If piping between plugins the PVD would need to be left running.
User runs J. River Media Center
User runs plugin to pulls data from PVD/firebird database for all available or recently updated records
If intermediate tags were used the work flow would be
User loads movies into PVD, pulling metadata from various sources
User runs script / plugin in PVD to export tags for all or recently updated (I would like PVD to do this transparently eventually, maybe via an option to "Maintain tags")
User runs J. River Media Center
User runs plugin to pulls data from tags for all available or recently updated records (could be automated via a "Scan folders on start up option")
Other differences
The tag files approach results in
a) Multiple tag file being stored on the hard disk (which some users may object to).
The J. River Media Center plugin approach
a) Would probably require updating each time PVD or J. River Media Center was updated.
b) Implies low level access to the firebird database is available. Alternatively if implemented as matching plugins in PVD & J. River Media Center, then we need a pipe function between plugins transfering a data format which will probably be similar to the "tag approach". Reading tag data from J. River Media Center plugin via PVD plugin via firebird may be slower than pulling it directly from windows file system tags depending on incremental update optimisation done.
I don't think it's a sensible solution for what's being discussed here. Raldo is considering creating a plugin for J. River Media Center that would pull data directly from the PVD database into MC.
Fair enough.
We agree aiming for a no compromise solution is appropriate. We differ on what level of abstraction is ideal