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