Personal Video Database

I assumed it was a typo for Tag

Oh. I thought he had discovered a new standard for video tags. 

Еag export/import (like ID3 for mp3)

Never heard of this... What does EAG stand for? Any useful links for explaining what this is?

Customizable views would be very useful, for exampe I would like to have a feature to define the ciriteria movies of an actor are sorted in the people view. At the moment they are sorted by year, but how about sorting by Rating or by Alphabet?

See the Sort by and Group by items on the View menu and the list pane context (right-click) menu.

I had assumed that it was proposed a server version on PVD would need to be run...

No, no, no! I know it's confusing, but this is a three-way conversation. My recommendations are never the same as nostra's. 

I understand why you would prefer not to run a server version of PVD. I was agreeing with you in recommending each user run PVD stand-alone, using their own separate database. I was merely pointing out it would not be as much work to create those separate databases as you seemed to think it would be.

The only way I can see this being achieved is if the manual selections made during the initial scan are stored with the movie file.

Again, I'm not questioning the means, I'm questioning the objective. Your scheme is only necessary in the event one needs to rebuild a database starting with nothing but the movie files. This is not necessary if you are just changing the location of files—the rescan function works with 100% accuracy (I tested it since my last post). It is not necessary if you are creating a new database that is a subset of an existing one (your vacation scenario).

I understand you want any user to be able to build a database by selecting files and letting PVD do the rest. I've already suggested your request may be easy to implement. Please don't think I'm arguing this because I don't think you should have the feature you want. Nostra is perfectly capable of weighing the pros and cons and the amount of effort required. I'm countering your implication there is something fundamentally wrong with PVD when it's actually performing extremely well—according to its intended purpose. If any further effort is required in this area, I have to wonder if it should not be directed to making the initial scan more accurate. Everyone would benefit from that.

Has writing cataloguing data back to the movie files been considered...

When I first read this, I found the idea appealing. It would offer greater peace-of-mind PVD would not be "confused," should I move or rename movie files. I'm trying out Media Center, and one of my disappointments is I cannot import PVD data into it. Probably just as well—I don't want to be maintaining two databases. But if PVD could write back to the movie files, I suspect MC would read the information automatically. In stark contrast, I've always maintained my music information in ID3 tags, and all of it is seamlessly available in whatever software I choose to use.

I'm not familiar with the tagging convention, but a lot of meta information can be saved in AVI files. I imagine the first issue here is MediaInfo (the DLL PVD uses to get information from movie files) only reads, does not write information. So nostra would have to figure out how to do that. And what about other file formats? While writing only to AVI's for this limited purpose may not be difficult, it opens the door to what could be a major new feature that would probably not be easy to support: What about other programs using the same information? Being able to get my PVD information into MC would be great, for example, but what would PVD do when MC wrote its version of the information back to the tags?

Movie files are stored on a file server and accessed by multiple users / computers within the home...

I suppose each user would want to maintain their own database, but based on the same store of movies on the server. Nevertheless, would it not make sense to built a "master" database of all movies on the server? Then each user could start with a copy of that, and delete the movies they're not interested in.

Probably the easiest way to achieve this is if PVD had "*.id3" export and import formats.

I thought ID3 was for music only. Much of the information is the same, but does it provide for tags unique to movies? I suppose a tagging convention—if that's what it is—doesn't necessarily address the issue of how such tags are included in various file types. Thus your suggestion the information could be saved to separate files. I've never come across anything, however, that would suggest other programs could make use of information saved this way. Even if this works for your specific purpose, saving the information in the movie files removes the risk of the files getting separated.

but it is possible to enable users to setup how PVD should parse the file names.

But then it would be my fault if it didn't work! 

The scanner has a complex algorithm for detecting where to put files and how to combine them, but it is certainly not perfect...

Your programming skills never cease to amaze me, but I have a hard time seeing how this ever will be perfect. I think you have the "right" to dictate to users a file naming convention to be used for files to be recognized by the program. Hopefully it would be flexible, but surely you need some degree of consistency. And users need to know what will be recognized. Some will have large collections named in a manner that doesn't comply, but it's not very difficult to rename files using a batch renaming utility (or a "home-made" batch file).

In the case of episodes, there are so many different ways they may be organized and named, it's probably easier for all if you decided how it should be done. I like Dadeo's ..\Title\Title.S02E01.episodename.avi, especially if, with that format, your routine could consistently identify titles—whether the episode files are in a separate sub-folders or not.

Nostra said i'd need to keep the plugin configured for all fields...

This really isn't that complicated. What nostra was trying to say, and what I attempted to clarify with my previous post, was you must configure the plugin exactly according to the columns that exist in your Excel file. It doesn't matter whether you have two columns or twenty. The plugin has no way of determining which field the data in each column should be put unless you tell it—for each and every column.

If i only selected to import title and length then surley the length would end up in my 'B' column which is my description column.

Maybe the reason you're not getting this is that you think your Excel file is "fixed." When I suggest you can import just the length field, I'm assuming you will make a copy of your Excel file, delete all the columns except title, year and length, and then save this new file for importing to PVD. If you insist on importing from your original Excel database each time, you will have to be very careful that your plugin configuration is correct. Furthermore—as you have discovered—if anything goes wrong, it's much more difficult to figure out what happened.

About the 'Length' columns, i have simply typed in the runtime like this: 60mins, 54mins etc.

I'm not sure exactly what format the plugin is expecting (i.e., "hh:mm" or "mmm"). I'd be surprised if it understood "60mins" (and, it seems you have already found it does not). I see PVD exports length in minutes ("mmm"), so let's assume the import plugin will recognize that. Since you're not comfortable using formulas, try this: Select your length column, Edit-Replace "mins" with nothing (i.e., delete all occurrences of "mins"), and format the column as text. This is confusing, but... what you want your minutes to look like numbers, but to actually be text.

The plugin must always be configure for all fields.

That is, all columns in the Excel file.

Change the type to "Text".

Nostra, does it matter whether the text is in the form "hh:mm:ss" or just "hh:mm" or "mmm"?

If the data in Excel is a number displayed as time, then make a new column using =LEFT(TEXT(TimeCell,"hh:mm:ss"),8). Select the new column, Copy it, and Paste-Special-Values it to another column (or on top of itself, if you like). This column will be text you can import (subject to what nostra may say about format).

Time to start a new topic—continued from Where do i begin??? Help File???

I don't think I've seen this behaviour before, but maybe I never tried importing something with blanks in it. Can you run a test with a small sample (e.g., three records—two "good" ones, with a "problem" one in between) to isolate the problem? Maybe it's a bug. And maybe you'll discover a workaround is just to put something (like a "-") in otherwise blank fields.

I tried testing the Excel import plugin—to see if I could replicate ruffa's problem and to answer some of my own questions about how it works. This is what I have learned...

It seems the plugin is not dependent on headings in the Excel file. As long as the configuration has the correct sequence of columns specified, it will work even if there is no heading row. On the other hand, it does recognize the first row is headings, if that's what they are. So I'm not sure what the implications are of excluding it. My preference is to include headings to help keep track of what I'm doing. Attached is a screenshot illustrating how I view my Excel file while entering the configuration. The Excel headings are not necessary for the plugin, but I do need to list the fields in the configuration in exactly the same order as the columns in Excel.

When importing additional information to existing records, the attached confirmation dialog appears. It may seem straightforward, but can be a little confusing when one appreciates the import works on a field level, not just for each record as a whole. This is what each option does:

Update adds source (Excel) field if destination record exists (as determined by matching ID, Title/Year or URL); otherwise does nothing.

Merge adds source (Excel) field if destination field (PVD) is null; otherwise leaves destination data intact.

Add adds all the source fields to a new duplicate record; the existing record is unaffected.

Do not add skips the record; continues the import with the next record.

Overwrite replaces the destination field with the source field; if the source field is null, the destination field is left unchanged.

Cancel terminates the import.

This dialog will appear for each record already in the database unless "do not show again is checked"—then the response is applied to all records imported.

It's easy to assume all records will be "updated" when choosing Overwrite. It can be important to recognize blank fields in import records will not cause existing data to be "deleted." If this is what is intended, blank cells in Excel should be changed to "null" or "delete me," which can be deleted in PDV after importing (if available for the field, using multiple movie editor).

Now, back to ruffa's problem: I was unable to replicate the problem with any combination of blank cells or special characters (like common field delimiters) in the data. Once the import was properly configured, it worked without error both initially, and when used again to add or change data. I only found this kind of error (data in wrong field for some records, not others) when changing columns the Excel file and not making the same change in the plugin configuration (or vice versa). For the reasons already mentioned, the corruption resulting from this can be difficult to interpret because some records are affected and others are not (e.g., a record is not updated because the import field is null, or the destination is not). Furthermore, for the same reasons, if the configuration is then fixed, running the import again will not fix the corruption unless all the affected fields are included, none of them are null, and the overwrite option is used. In most cases, it would be easier to restore from backup or start a new database than to "undo" an import that has run amuck.

[attachment deleted by admin]