English > Scripts and Templates
Export plugins for J River Media Center
rick.ca:
--- Quote ---My suggestion below is for a "seamless interface" where no action needs to be taken on the PVD side.
--- End quote ---
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.
--- Quote ---Alternatively, MC could retrieve the data from the database
--- End quote ---
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.
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.
raldo:
--- Quote from: rick.ca on April 02, 2009, 08:23:02 pm ---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.
--- End quote ---
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..
--- Quote ---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.
--- End quote ---
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...
--- Quote ---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.
--- End quote ---
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).
rick.ca:
--- Quote ---I haven't even started writing code yet
--- End quote ---
I understand, and I hope you don't mind this kind of input at this stage. :-X I assume it's preferable to design, then code. At the same time, I do understand design ideas often have to radically change when you're doing the coding and discovering what actually works and what doesn't. So please consider my comments as having a helpful intent, in the spirit of "talk is cheap." ;)
--- Quote ---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.
--- End quote ---
The point I'm making has nothing to do with which GUI is preferred. It's that the critical database management function of ensuring the completeness and accuracy of the metadata is being performed using PVD. Once I've done that, I don't want it undone by the MC plugin adding more records (with a significant likelihood of inaccuracy or incompleteness) I don't "know" about. Yes, it's possible to detect errors in MC, and it's possible to determine what records the plugin has added to PVD (so I can check them for completeness and accuracy). But why would I want to waste time doing so? Why would I want to give up the peace-of-mind of simply knowing the metadata in MC is exactly the same as that which I ensured was complete and accurate in PVD?
Perhaps few users take data integrity as seriously as I do, but I really believe my point is far from an academic one. Maintaining some degree of data integrity in one database is challenging enough. Doing so with two databases is that much more difficult. There's not much that can be done about the two being out-of-sync because of timing differences in the importing of media files (including the possibility one or the other import routines fails for a particular file). If MC is being updated using the PVD database, the user has a known point of reference, can assess the results, and deal with those matters. If the plugin is adding items, however, the point of reference is lost, and the user has no way of telling what the difference is, or whether it matters. Once users see their data is out-of-sync and they can't determine why (or, more likely, just become confused), they will lose confidence in the plugin.
--- Quote ---This seems to be a "phase 2" issue.
--- End quote ---
What do you mean—the ability to update only changed records?
I was assuming a reasonable "phase 1" would be simply importing directly from the database data for matching media files in MC, and things that might require the plugin to interact with PVD would be "phase 2."
--- Quote ---The plugin on the PVD side would then be installed together with a default template (with a "pages template" for Credits which would surly accomodate your sequencing request).
--- End quote ---
Yes, I can see that working, but it seems to be a very indirect method of accessing information in an open SQL database. Are there not software "tools" you could use that would provide the core functionality you need? I'm sorry—I don't have a clue what I'm talking about—it just that pulling data from a database to put in another seems to be such a "generic" requirement.
Regardless of the technical challenges, I think there is a more serious problem with this. Having to configure a template is not very "user-friendly." Those of use who are used to this system (who are also MC users—all 4 of us?) could handle this. For MC users coming to PVD for a video metadata solution, however, I fear it adds too much to the learning curve. Also, it would make the whole exercise not that much different than the current export/import solution. I was imagining what I consider to be a fairly common field mapping interface. In it's simplest form, it would display all the fields (standard and custom) found in the database in one column. In a second column, drop-down boxes would be used to select from the fields available for mapping the data to. A fancier version would display field types and assist in the selection of a compatible MC field type, or other types the plugin is able to convert the data to. It might also offer default mappings, and allow the adding of new MC fields "on-the-fly."
For the MC user coming to PVD, the experience I'm hoping for is one where they can focus on learning PVD and building a database, without concern about how the information is going to get into MC. When they're done, the plugin will provide them with a user-friendly means of mapping and importing the data, regardless of what information their database contains or how they want it imported to MC. Furthermore, I think it reasonable to assume—especially in early days—users will want to make regular changes to their configuration. They should be able to do so directly in the plugin interface, at any time.
So, this has been my very long-winded way of suggesting... Maybe the simplest and best solution is one which pulls the data directly from the PVD database, and maps it to MC fields based on a flexible (map anything to anything) configuration interface.
patch:
--- Quote from: raldo on April 02, 2009, 10:03:13 am ---I'm "working on" an export plugin for JRiver mediacenter.
Now, I think I have worked out a way of doing the file selection and metadata import "seamlessly" on the MC side.
--- End quote ---
Why not emulate what is done for electronic music.
Music files are tagged, the taggs are written back to the music files, other programs can then read the metadata.
Music files often use id3 or similar. Unfortunately mediainfo.sourceforge.net will not support tag writing in the forseable future, so we won't be able to do it that transparently. http://sourceforge.net/forum/forum.php?thread_id=1695277&forum_id=297609
What we could do is get PVD to write text data to a tag file located near the movie file (and with the same name). This could be a .txt or better still a .xml maybe easier to maintain. Image data could be written to a similarly named & located .jpg or similar file.
Once written this data could then be read into another program such as JRiver mediacenter or another instance of PVD.
The main advantage of using a relatively standardised tagging format is changes can be made on either side with relative independence. Also the interface is likely to have broader applicability.
http://www.videodb.info/forum_en/index.php?topic=1002.0
http://www.videodb.info/forum_en/index.php?topic=870.msg2516#msg2516
http://www.videodb.info/forum_en/index.php?topic=1249.0
rick.ca:
--- Quote ---What we could do is get PVD to write text data to a tag file located near the movie file (and with the same name). This could be a .txt or better still a .HTML maybe easier to maintain. Image data could be written to a similarly named & located .jpg or similar file.
--- End quote ---
I appreciate you have other reasons for wanting to see something like this implemented, but 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. That will be far more efficient, reliable and easier to maintain than writing a text and an image file for every video file. True, it will have no relevance for other applications, but MC users won't care about that—they're using MC to manage and view videos. This plugin has the potential to bring a portion of a large and sophisticated user base to PVD, but I believe it has to be something which serves their needs—without compromise.
Maybe Reset would be willing to advance your idea. We already have the script for getting information from a text file. He's going to do a plugin for importing images "beside" the video file. Maybe he'd be willing to expand that project to include importing and exporting images and text. That would have of value as a versatile utility function, as well as, hopefully, serving your need.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version