English > Support
Help Index
rick.ca:
Originally posted to lost topic IMDB downloaded wrong movie in October 2008...
You've discovered the surest way to resolve problem, but there is another way that is more convenient—if it works: Clear the erroneous information. Add something like "xx" to the title, and invoke the plugin again. It should then present a list to choose from—the "xx" preventing it from thinking it found an exact match.
rick.ca:
Originally posted to lost topic Adding a single season in August 2008...
Downloading all the information available for a series is the only reasonable thing for the program to do. You can use a filter to hide the seasons/episodes you don't own, if that's your preference. Or you can delete them. Given the series-season-episode tree structure used—a feature, I believe, most users want—I don't see any way to sort by season. The ability to add information at the season level has been requested. If that's implemented, and depending how it's implemented, you may get something close to what you want.
I suppose what you're really looking for is the ability to control the series-season relationship. For example, turn it off to "untie" seasons from their series—so they can be sorted by year. I think that would be a nice feature, but not worthwhile unless it were easy to implement. There is already something like this, on a very basic level. See the screen shot. Perhaps this is not very practical, but it demonstrates the flexibility of the program:
• download the series
• rename as one season, change year, delete other seasons
• repeat for next season
• in Preferences-Movies, set Do not create season group...
The screen shot doesn't show other series, so I should clarify... The single season series of Lost I created are "promoted" to the level of series. They sort correctly by year. All the preference option does is hide the unnecessary season branch.
[attachment deleted by admin]
rick.ca:
Originally posted to lost topic Series information not imported anymore in September 2008...
--- Quote ---If this is changed on imdb after the episode is aired i found no way to update the information in PVD by importing from imdb.
--- End quote ---
I thought this was the case too, until I realized it was because I had the Title overwrite flag set "off." The title placeholders are those used by IMDb. If the placeholder has been replaced with the actual title, updating the episode will update the title—as long as the overwrite flag is set "on." If I update the series, however, a duplicate episode record is created, rather than the placeholder being updated. Also, no other information (for the placeholder episode or the duplicate) is downloaded. So it seems the way to update the information correctly is to select the episodes in need of updating, and run the plugin.
I've long been frustrated by my need to configure the IMDb plugin differently for movies and series. The setting of the Title overwrite flag is one example of why I need different configurations. When I have used an English title for a foreign movie, I don't want the plugin to overwrite it (IMDb titles are generally the original titles). For series, however, it seems I need it set so new episode titles can be updated. There are a number of other things I set differently—as a matter of personal preference.
I've just "discovered" a workaround for this. I made a copy of imdb.dll, named it imdb_tv.dll, and reloaded PVD. Now I have two IMDb plugins—one set for movies, the other for series. Unfortunately, this only works for the overwrite settings; the other configuration settings are saved in imdbconf.cfg, so changing one changes both. Also, the description (the caption that appears in the menu) is the same, so the two are difficult to distinguish. Perhaps nostra will be so kind as to compile a version of the plugin that has a different name and description, and saves it's settings in a different file. Or maybe there's a more elegant way to facilitate multiple configurations that's easy to implement.
rick.ca:
Originally posted to lost topics Movie Collector database to PVD and Mass (bulk) additions of titles to the library in September 2008...
I was able to import both files without any difficulties. So I have no idea what might be causing the error, but it doesn't seem to have anything to do with your data or the format it's in. Maybe nostra will have some ideas.
Aside from that, I can offer a few suggestions based on your detailed data:
1. If you're exporting your data from Movie Collector, include the year, if you can. It will help PVD to correctly identify the IMDb entry.
2. PVD handles actors and roles as separate data, so your "actor as role" data is imported as an actor's name. I suggest you just leave this out, and let PVD download the correct information from IMDb.
3. I suggest you change your "Yes"/"No" Collection Status data to 1/0 or TRUE/FALSE and import it to a custom check-mark field.
4. You need to convert your "#.# star(s)" data to a 0 - 10 numeric field.
5. You can do things like 3 and 4 in a text editor, but it's much easier in Excel. Once your data is in Excel, you may as well use the Excel import plugin. It's functionally identical to the CSV plugin.
As we've already established, the import configuration must include the PVD fields in exactly the same order as they occur in the import file. It also includes three options which must be properly set:
Delimiter - mandatory - a character that indicates the end of a field; usually a comma or semi-colon (if a semi-colon is used, the file is still called a "Comma-Separated Value" file). When importing to PVD, it's a good idea to use a semi-colon as a delimiter so comma's occurring in the data (e.g., as normal punctuation in a memo field) are not interpreted as delimiters.
Text Qualifier - optional - a character used to enclose text; usually double quotes. Not necessary, but if present in the CSV file, specifying it here prevents the routine from including these characters in the data.
Ignore header - optional - set if the first line of the CSV file is a header, so it will not be imported as data. PVD does not use headers to map the import data to fields—this must be done "manually" using the field list.
--- Quote ---I also added ; as a text qualifier in the csv import options, if that made any difference.
--- End quote ---
I'm sure it did make a difference, especially if it was also used as the delimiter. Setting it as the text qualifier caused it to be ignored. If it were not, each line would consist of three fields, with only the second containing data. According to the field list, only the first would be imported.
Putting a " at the beginning of each line and specifying as a text delimiter would cause the routine to take everything between the first two quotes as the first first (only) field, and then ignore everything until the next line after the second ". It hurts my brain to think about it, but it seems a good way to skip every other title.
I suspect the source of the confusion here is that despite the fact only one field is being imported, the data must include a delimiter, and that delimiter must be specified correctly in the configuration options.
Originally posted to Import from MC in November 2008...
If it's not already clear from what blue and patch have said, you need to plan what you want to do with your data before attempting an import. The first step is to determine what data can be exported from Movie Collector. Assuming the example file you have provided includes all fields that can be exported, the next step is to examine this and decide how to import it into PVD. You can do this however you like—I would import it into Excel and create something like the attached screen shot...
The "-" in the PVD field column means I would not import this field—I would rather use PVD to download this from IMDb (or elsewhere). "Custom" means I would create a custom field to accommodate the data. In some cases, this is just to avoid conflict with IMDb data. If you prefer, you might decide, for example, to put Plot in Description, and configure the IMDb plugin not to overwrite this. In other cases, as I've noted under Comments, the required field has been added to version 0.9.9, but a custom field will be required if you would like to have the data in 0.9.8.
With such a "field mapping" done, it's much easier to prepare the import file, add the required fields to PVD and configure the import plugin without errors or omissions. Also, once you have a complete and properly prepared import file, many of your decisions about where to put the data in PVD are not that critical—because you can use the same file to do another import to put a particular field's data elsewhere. Let's say, for example, you put Plot in a custom field, and later decided you would rather use it for the standard field Description. You would just delete the custom Plot field, delete all fields but Title, Year and Plot from the import file, and import again. BTW, the import plugin will use Title and Year to match an existing movie in your database, so you should take care not to change these data if you want to be able to do these subsequent imports.
rick.ca:
Originally posted to lost topic Worrying discovery when saving my database in September 2008
Please do as nostra asks—update to the latest version. Just install "over" the existing. No data or settings will be lost. It's always "worthwhile" to update the program. Even if you don't think you need the fixes and new features, it becomes increasingly difficult for others to help if you are using a different version of the program. And, of course, we don't want to waste time isolating a bug that's already been fixed. I note from the Changelog "Issues with working directory" were fixed in 0.9.11, so it seems likely that's what we're doing here.
--- Quote ---it's not convenient to have all the films i have listed (which i've spent years working on) along with my dvd list as my dvd list is something i like to pass out sometimes so i guess i still need 2 databases really.
--- End quote ---
My point is the program is designed to handle different "categories" or "types" of movies (i.e., just like your situation) in one database. It's easy to generate a list of any particular type. I think the only "good" reason to maintain separate databases is if movie types are so fundamentally different they require the program to be configured differently (e.g., they cannot share the same fields). I believe the ability to combine two databases will be included in version 0.9.9.
--- Quote ---i didn't quite understand what u meant by using the comandline thing in PVD?
--- End quote ---
I think updating the program will solve your problem, but for future reference: Edit the shortcut used to start PVD to include "-debug" in the target (e.g., mine is "C:\Program Files\Personal Video Database\viddb.exe" -debug).
PVD is built on a true RDBMS—Firebird—that records all changes as they are made. There is no cache. All of your data is in the data file. It's pointless to attempt to "backup" the data by saving it in a different format (i.e., export to Excel). Your concerns about keeping your data safe need to be focused on an effective routine for the backup of the PVD data file. You may find this helpful: [another lost topic] ::)
--- Quote ---I appreciate that PVD includes a backup routine (and, yes, the default directory should be configurable), but I prefer to rely on my own backup routines. As with most database applications, the data is changing all the time, the most likely error is user-created, and it's likely to go undetected for a time. So I'd rather rely on an automated backup routine that retains a sufficient number of backup versions (in case I don't immediately detect a problem). In the case of PVD, my backup scripts backup the PVD data file every night, and keep the seven previous versions. I use the PVD backup routine to make what are more in the nature of "archives." For example, I would make a backup immediately before converting to a new version—just in case I need to "start over" with that new version (often helpful during beta testing). If I want to make a backup before doing something risky, I usually just make a temporary copy of the file. This is faster than the backup routine (I imagine because that's compressing the data as it saves the file). Whether I'm using the PVD backup or not, the backup file that saves my a__ 90% of the time is my automated nightly backup.
--- End quote ---
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version