Personal Video Database

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.

I have modified the script to conform to changes in the original provided with 0.9.9.5. It's attached to the first message above.

In an attachment there is a script which works both with www, and without www.

Nostra, the version attached to your first message should probably be replaced with this version. (Pending a better way to keep track of these things. )

There's a known issue in the program causing the problem with search results. Hopefully, this will be resolved in 0.9.9.5—due out shortly. I don't believe I've seen any division by zero errors. Do you see any pattern?

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.

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.

I haven't even started writing code yet

I understand, and I hope you don't mind this kind of input at this stage.   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."

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.

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.

This seems to be a "phase 2" issue.

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

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

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.

Is the best suggestion to wait until this weekend?

I suppose that depends on what you are waiting for, and why. It sounds like there are improvements coming that should interest you, but then there are considerable improvements already available in 0.9.9.4. As long as you take the recommended precautions, there's no reason not to run a beta and 0.9.8.20 at the same time. Then you can make your own decision as to which to use on a regular basis. (You probably don't want to run two databases "in parallel.")

It may not be a good idea for you to rush in switching to 0.9.9.5. Allow a little time for more experienced users to discover if there are any significant problems. On the other hand, if you can't wait, you could try 0.9.9.4 right now.

From the comments Reset has made, I assume his script will work in both beta versions, and he plans to write a separate one for 0.9.8.20.

I'm still curious... Is PVD not extracting the same information from your video files that you have been getting with GSpot?

Okay. We'll just wait for that to go away.

I was not aware of the MediaInfo program

It's the DLL used by the program to read video file information when it scans them. Are you not seeing any such information (in the separate section toward the bottom of the video panel)?

I guess the script that Reset is willing to make will work quite well in integrating with PVD and pairing the correct poster with the correct video.

Yes. And on an ongoing basis, I expect you'll be able (in 0.9.9) to use one of your automatic screenshots as a poster in a one-step operation.

Welcome to the forum, lilhill.

I understand you're talking about custom videos, but I'm otherwise completed baffled as to why you might want to handle them this way. PVD uses MediaInfo to automatically extract video file information. Is there other metadata in your files that GSpot extracts that MediaInfo cannot? If so, how did it get there? PVD includes a screenshot maker (and 0.9.9 an automatic screenshot maker, although it presently works only for AVI's). If you want to include your existing screenshots, I suggest you consider using them as posters—which don't otherwise exist for custom videos.

Reset, if you're willing to write a script, it should be done in a way that it would be versatile and benefit the most users. This is something that some of us have wanted for some time. My suggestions:

• If you're only going to do one version, it should be one for 0.9.9.
• Match image files first by video filename, then by Title (or Title + Year) if there is no video file.
• Allow the user to specify the image type to be saved as—poster, cover or screenshot. This could be done, of course, by using three different scripts. If that's to much trouble, then I think most users would want this for posters.
• Add the imported images, rather than replacing existing images. If the script can't handle multiple images per video, it could still be run multiple times on different image file sets.