Personal Video Database

-- I'm not sure where to begin...
-- maybe (at least in this case) better fill this thread with loosely related subjects ...
-- If there is some part of this that requires more discussion and is of interest to others, we can alway quote parts of this into new topics.

That's what i meant ... doing several separate precise threads for important parts, and keeping lengthy posts to a single thread which others are able to ignore if not interested.

You do a very good job of figuring out how things work. That's good, because PVD is a powerful and in some ways complex program. I think you're moving a little too quickly from understanding how something works to judging how it should work. Your suggestions are welcome, but try to bear in mind you're not the first one to figure out how something works and consider how it might be better.

in some cases, i have a strong opinion on how something should work (or at least how it shouldn't work), like the problem with the suffix, but in most other cases it is only what I myself expect (and then i am surprised when it is different) or what i would think would work best for me. a few things are also caused by the complexity and missing info (missing meaning "i couldn't find it" :-) like what you explain below on how PVD probably identifies unique records (which i find important since uniqueness appears at several places like on entering new movies, cleaning up the database, etc). thus please take it only as impressions of someone using it and being surprised sometimes, and as I wrote in another post "if it doesn't apply or is too complicated, skip it or move it behind the end of the todo list" ...

All that your talking about here has been discussed in the past, and most of it has seen program changes and refinements based on those discussions.

I read forums for quite some time, and also looked at the wiki etc, but the amount of data is overwhelming and many threads in forums start on problems with old versions. too bad when i skipped such threads while there might be nice info which applies to new versions at their ends. thus i decided at some time to stop reading only and tried starting to use PVD :-)

I don't think either of the two bugs you've found are urgent—they can wait until the next update.

of course not — of course :-)
for me, priorities on bugs are:
- find how to reproduce it and whether it is a bug at all
- find how it might be caused and what can be done against it
- know the bug and avoid it if possible, waiting for a fix in some future release
and only for program-breaking bugs (like conversion errors on the database :-) I expect a fix (or other reaction like a "reroll") really fast (as fast as one can expect from voluntary work on a free program :-)

back to bugs and features ...

---

So the bug is that the program fails to add the PVD extension if an apparent extension is provided. This shouldn't happen—databases obviously should not be named "Test.TXT" but it should be possible to use something like "Test.abc" (without it becoming an "ABC" file). Hmmm... I see that does work properly—the filename becomes test.abc.pvd. But "Test.exe" becomes test.exe.

sorry, you didn't get the whole point of what i wrote ...
I just tried the name "new.abc" and it stayed that way, NOT appending .PVD !!!
(you probably use "new..." while i am talking about what happens when you use "open...")

The problem is that both "new..." and "open..." can be used for creating a new database and for opening an existing database. while "new..." appends (with additional conditions like already registered suffixes etc) the .PVD suffix if a new database is created like you said, using "open..." to create a new database NEVER adds the .PVD suffix, neither on a name like "new.txt" nor "new.abc" nor on a word without any suffix or dot in it like "TEST".

I don't care much whether .PVD is appended to the names of new databases or not, but i think it should be done consistently, either in both "new..." and "open..." or in neither of them, and I am confused a bit that there are two commands for the same purpose (to create a database if it didn't exist as well as to open it if it exists or was created). if "new..." would only create a new database and open that database but not open existing databases, and "open..." would only open existing databases, there would be no such problem with the suffixes.

Thus i would consider the bug/feature/problem to be that "new..." doesn't give a warning when used for an existing database and instead quietly opens the existing database (hehe, at least it doesn't silently purge it and create a new one), and that "open..." also accepts typing errors and creates a new database if the user didn't intend to (why would he have used "open" instead of "new" in the first place) instead of giving an error or at least a warning that the selected name doesn't exist.

my suggestion for a fix: either implement the above restrictions for "new..." (don't open existing databases or at least warn) and "open..." (don't create new databases or at least warn), or merge the two commands to a single "open/new" command which behaves like it currently does. For security reasons, I would prefer the former (two commands with warnings).

BTW, I just had to try... executing "test.exe" does nothing.

never believe what someone else tells you :-)
C:\PVD\_mydata_>test.exe
Program too big to fit in memory

C:\PVD\_mydata_>


---

It's helpful (for those of us who are so full of questions) to understand PVD is running ...
Records in the movie table are referenced by MID—a field maintained and strictly controlled by the software and Firebird...

yes, those are the basics I want to know. Even if not in great detail, i immediately get a better understanding of lots of software (not only on PVD) when i get some foundation to build my guesses and beliefs on :-)

The process of ensuring duplicates are not created is entirely up to the user and the program logic. The latter will use the title, original title, year, and perhaps the URL to make that determination. ...... Often the user is asked to resolve an ambiguity.

Since I want to use PVD to take care of many tasks and make work easier for me, I want to be asked to do decisions as rarely as possible, even more so when doing "batch work" (working or updating lots of movies at once). That's why i tried so hard to learn about uniqueness, and/or to try and create uniqueness with the methods available in PVD.
I am also a bit spoiled by the IMDB which on one hand created some rules to make all titles unique while on the other hand not caring at all for duplicate entries in mymovies. I didn't like all of these rules, but it was a framework to build on.

Don't change Original title—that's meant to be, well, the original title (and it's probably pointless for any of us to second guess IMDb's determination of what that is).

Since i don't live in the USA (not even in an English speaking country) or in many other countries which produce movies, I used the original title (from IMDB) almost not at all, except for having unique identification of one movie. and the rules for those names on IMDB are relatively simple: it is the title in the language of the film's original country of production (transcribed if chinese etc), followed by the year of first release (not production), with additional markers for the type and in a few cases with an index added to the year. But since i didn't use it much, the only important thing for me was its uniqueness, and that is partially lost on the PVD's original titles (without year/index and flags).

But you got me thinking .... For other users who don't use IMDB as their main or only source, this uniqueness probably is less important and might not apply at all if the different services use completely different standards to find original names.

Use Title however you like—probably "localized," and so the records visually distinct in the list. How that's done is a matter of personal choice. I remove prefixes, structure the name so movie series appear in order and display the list as Title (Year).

I probably will use the title only for storing the "german original title" and put other info in custom fields, eg for media location and movie series ... it would be nice if i could setup several schemes for "tree view nodes" to easily and quickly switch between them and not have to go through preferences to change that, for viewing lists sorted by movie series name and sequence (eg 007, Godzilla), or theme series and sequence (eg "other japanese monster movies" :-) or sorted by folder/box where i keep the DVD, etc. And the same might also be an idea for a set of advanced searches, to be able to select a subset of movies and display them in a nice tree :-)
... but i just started experimenting with what might suit me best among the currently available options.

but there is one problem with the title field: when i have movie connections to series, the title of the series and the episode number are included in the link, and PVD puts them in the original title and in the title. when i update this record, the plugin will change the original title to the episode title (or i have to switch that off every time i update an episode) and thus series title and episode numbers are lost from that one field. When i also put the german title in the title field, all this additional info would be gone from the other field too and thus be lost completely.

another problem with those links from connection info probably has been discussed already a hundred times, but i just stumbled about it and almost broke my leg :-) ... when i have a series added to PVD and there is some movie connection to episodes of that series, it would be nice to have them point into the series and not create "virtual movie entries" (and an option could select whether PVD might create a partial tree for conections to a series which doesn't exist yet), else i will end up with dozens or hundreds of simpsons and south park episodes in the main movie list. That applies even more if i already have nicely prepared a series (with all details, posters, whatever) and those connections still point to "virtual movie entries" for the episodes which have no info at all besides a title and an URL. ... I know that those features are deeply connected to the database structure and also to all related plugins and are not easy to do, but I hope such features might be somewhere down (but not too far :-) on the todo list for some future versions?

Don't use dummy names for titles—you'll just screw-up the program's attempts to avoid adding duplicates. Yes, include the URL if you can (that eliminates the plugin's need to do a search), but this has nothing to do with the creating of a record.

it has not ? ... I tried creating a new record with only an URL and neither title nor original title, and it didn't work. on doing the "apply changes", the edit session was closed and nothing happened. the record was lost. (btw: i see it as missing feature when i am not warned about losing a record with possibly lots of data because of having neither title nor original title.)

thus: how do i create (or import) a new record with an URL to get all details from a plugin later, when i may not use "dummynames"? Do I really have to cut&paste the URL and also cut&paste the correct corresponding title, only to be able to apply the changes to the record and a moment later overwrite the title i just copied when using a plugin on that URL ?
That's why i had thought about how a dummyname should look like:
- never look like a real movie title (thus ""dummyname")
- never look like other dummynames (thus adding the number from the URL)
- not be a title (which i spare from overwriting in plugins)
- be an original title (which will be updated from a plugin)

It might be best to use New until you fully appreciate how things work. That way, you'll see whether the record is already in the database (when the database is large, it usually is, because it's in someone's filmography or it's connected with another movie).

that's how i added most movies until now: first added one single movie, then followed connections to movies i knew (have as DVD, taped, or wishlists, etc), update those records too, follow more connections ... but since i have many more movies than i thought and already partially have sorted them (using categories in IMDB for remembering storage locations), i wanted to try the other approach of using the URLs from mymovies, importing them all (together with some fields and custom fields, like wish, seen and storagebox) and then let PVD work by its own, updating all records.

You'll see how adding the year will resolve ambiguity, and adding the URL will eliminate the need for a search. NMM is intended as a convenience for adding one movie. If it's not a convenience, don't use it. In other words, if you need to see the IMDb search page, then use the IMDb search page (you can use a Web search to get there).

no objections :-) but after looking it up on the web, do i really have to manually start creating a record, fill it with an URL and a title (and possibly a year too) which will be overwritten soon, apply the changes, and then use one or more plugins, or wouldn't NMM be the ideal tool to add a move when i feed it an URL (just like i can feed it a title or a file now) ?

---

Quote

currently this aka field is empty for many movies although the list exists on the website (BUG!). and if it exists in PVD, it doesn't include the additional info like languages or versions to which the aka apply.

yes, i use the AKA search option.
and no, the info i was missing was not only available on the AKA site, but every movie now seems to have one page .../releaseinfo with all releasedates and all AKA names.

example: there are five movies in the old "planet of the apes" series of movies. four of them have their aka field filled after using the IMDB plugin, but "Conquest of the Planet of the Apes (1972)" only has an empty aka field although there is aka information (just like on the other four) at http://www.imdb.com/title/tt0068408/releaseinfo.
can you please check whether you get the same result (or non-result) ?

---

... appending additional information to Title would be pointless and contrary to its purpose (as mentioned above). I would agree there may be some merit in downloading this information to a new Type field.

agreed ... i never meant to ask for it to be saved at a specific location, but only to please preserve the info somewhere so that it can later be used again, eg to search/filter on the type or recreate movietitle strings with an export filter ... and i think it is at least as valuable as the top250 or similar info which currenly already can be stored to custom fields.

It might be a little tricky, as all that is appended to the title is TV, V or VG. In some cases (only for TV, it seems) additional information (like "TV series 2000-2003") appears as a subtitle. I suppose the best way to do it would be to get the subtitle if it exists, and otherwise the appendage.

some time ago, they have changed the display on some pages. the internal titles themselves should still always be formatted with (TV) appended, or with "title" instead of title for series, etc, but to make it prettier, it might be displayed differently on some pages, like a subtitle "TV series 2000-2003".

the unique name should not be too "tricky" exactly because of what you say: all that is appended to the title is almost only (TV), (V) or (VG). in addition to these three flags they used to have another flag (mini) for TV miniseries, and series are not marked with an appended flag but by putting the title in quotation marks ("series") which automatically implies that it is a TV series and thus (TV) is omitted from the "series" (TV) (although i think that was a bad design decision since cinema series like Flash Gordon Conquers the Universe (1940) are now only listed as movie and not as series, thus not being able to have episode titles for them; but that has no influence on the uniqueness of the title). The most difficult part might be to determine whether to store an additional index (roman numerals which are appended to the year (yyyy/II) if everything else would not be unique) to the same or yet another custom field, or maybe simply copy everything behind the title (year, optional index and optional suffix) to a custom field just like they appear (with parentheses etc).

maybe we should talk about the details (name of field, what to store, etc) later and someplace else if someone has decided to implement something. For now, I only wanted to try convincing somebody that such a feature (storing unique identifiers which are available anyway) would be useful at all.

If all databases first created with 0.9.9.11 are now unusable in 0.9.9.13, then we have a huge problem. !'m quite sure this is not the case.

true, but since i didn't add much info of my own yet (besides the list of movies itself and some titles chosen from the aka instead of using the original title), at least *I* don't have to take a risk and can start over with a newly created database in v13 or v14, importing a CSV with only title/otitle/year/URL.

btw: which are the minimum fields needed by PVD to get uniquely identified movies when importing a CSV?
when i have a list of URLs, that should be good enough to get exactly the movies i want by using an import plugin (filling the title and/or otitle and a year, and without need to search or get a selection dialog), but I don't think that PVD likes a database with only URLs in it and neither title nor otitle (or the same dummy title "xyz" for all of the movies).

Most databases use a primary key, or they need to generate one from other fields. In PVD, the index is optional. Thus:
- which fields does PVD use to uniquely identify a record? Is that the original title plus the year? If yes, then what about movies like "Dinotopia (2002)" (there are two of them!), or a movie and a videogame with the same title and year?
info for people who don't know IMDB closely: they make "title (year)" unique by adding unique info either to the title (using "title" for series), and/or after the year (like mini, TV, V, VG), and if all this is not enough by adding an index to the year (like yyyy/I, yyyy/II, etc). similarly, an index is added to actors/directors/etc with the same name. Thus it would be really nice if I could use such additional info on searches, and if PVD (or the IMDB plugin) would be able to store such info in some field or custom field (the plugin seems to store other IMDB specific info in custom fields too, like top250).
- is there any method to specify an URL in addition to or instead of a title/otitle/year when adding movies? It would be nice to be able adding new movies (eg with "new movie master") when i found them on some website, by just doing a cut&paste of the URL ... (it would be pure luxury to have a browser plugin that allows for a single click to add the current URL as new movie to PVD :-)

I'll give an example here in more detail (so that you don't have to do all this yourself :-), for different attempts to add one specific of the two Dinotopia movies:
1. specifying just Dinotopia as original title in "new movie master" presents a selection dialog with two of the list's entries being identical Dinotopia (2002) and showing nothing else (like aka titles, additional suffix, index, etc), which requires me to open the browser and check each of them. btw: doing similar work on people is easier since the IMDB people plugin also omitts the index, but at least lists all the additional info which is presented on the selection webpage.
2. specifying the exact "Dinotopia" (2002/II) as original title in "new movie master" avoids the selection dialog and immediately downloads the correct movie. This also sets the title to "Dinotopia" (2002/II) and the original title to Dinotopia (i have set options to overwrite the original title on doing IMDB imports to keep titles current in cases like "Bond 23", and set the option to not overwrite the title). Thus the unique original title is lost and only preserved in the title (caused by the import plugin and not by PVD itself; but as i understand, original titles in PVD never should have a year included?)
3. creating a new record with a dummy title xxx and the correct URL (without dummy title, nothing is stored when i try to "apply changes" to the edit, and i even don't get a warning about it), followed by doing the import manually. This works but requires several steps and causes problems when I first add several movies with URLs and identical dummy titles and then update all of them (occasionally presenting me with a "what should I do, apply changes to xxx or add a new movie?")
4. specifying the exact URL of the movie in a line between "original title" and "Files(s)" in "new movie master" avoids the selection dialog and immediately downloads the correct movie. ... hehe, I started dreaming after doing experiments 1-3 :-)


to sum it up: when i have a list of URLs (no matter whether i have titles and years too), it probably would be best to import them from a CSV which holds pairs of "dummytitleNNNNNNN" for the "original title" field and "http://www.imdb.com/title/ttNNNNNNN/" for the "URL" field, plus more optional fields like my own titles, wish/seen status, etc !?!

isntall the latest update 0.9.9.13!

yes, thanks to your fast actions.
a few hours ago it was still 12 and that version wasn't very old either yesterday :-)

I now have installed the new version 0.9.9.13 and on a new database, I no longer get conversion errors when I add movies.

But when one problem is solved in any software, i always find two others :-)
eg that I have to manually refresh the list of movies with F5 after changing the filter settings (why doesn't that happen automatically?) and that most movies which i add with "new movie master" are added twice :-(

Reading in the WIKI explained that the latter happens when the spelling of title, original title and the spelling on the internet (eg in IMDB) don't match 100% exactly. but I couldn't find info on what it means to click checkmarks once (grey) or twice (white) in a movie selection dialog.

example: adding any title with a "different" spelling results in two entries with the original title (selected from the list), one with the typed title (as I would expect) and an URL "www.imdb.com/..." and a second entry which uses the original title as title and an URL "imdb.com/..." (added 10 seconds after the first). I also noticed that the effect might be related with the checkmarks on the movie selection dialog since it seems to happen only when a checkmark was clicked twice (making it white and not only grey).

my guess: only one checkmark can be grey and that is the entry which gets the typed title while all other checkmarks can only be white and their entries get their title set from the original titles to avoid having several identical titles. this is probably the intended behavior ?
and now the error: when there is no grey checkmark because of selecting only one checkmark and clicking it twice, PVD first (erronously) treats the selected movie like a grey one (adding it with the typed title) and then does the normal work of adding it with the original title as title like it does for all white checkmarks.

Restore the backup from 0.9.9.11 ...
If you do not have a valid backup: ...instructions...

thanks for these instructions.
I don't know yet whether i need them (please note that i had written "using (of course after a backup :-) the old database"), but they give a lot of insight anyway :-)

ps: after typing this lengthy text and doing experiments for the above theories, i saw the new posts when previewing my own post ... seems to be best for me to stay with version 11 for a few hours and export my database which was created with v11, and then reimport it with v14 !?
besides some own or modified fields (like title) which fields do i need to export (to CSV) to uniquely identify movies for recreating the database? In theory a single URL should do but i probably have to use some dummy title too ?