Personal Video Database

Outstanding! 

Guess that'll learn me for not exploring all the options... 

Aimhere

Hey, I don't suppose you're working on getting the script to import the rest of an actor's biographical information? Right now, I have to visit IAFD and copy everything from the "AKA" through "Website", then paste into Personal Video Database's "Biography" field. I know you already parse/extract some of this stuff and use it to fill in alternative names, birth date, and so on, but it'd be cool to have the rest imported automatically as well.

Aimhere

Hi,

Sometimes, I find that when I close PVD, it doesn't really quit. The window and tray icon both disappear, but the process is still in memory (as shown in Windows' Task Manager). And the process has the database file open/locked, so that the next time I launch PVD, it throws up errors about not being able to open the database.

(note: I usually put my PC into hibernate when I'm not using it, so it never shuts down, and the leftover process remains in memory. No doubt an actual full shutdown would clear the condition.)

If I use Task Manager to end the PVD process, then re-launch it, I'm able to open the file successfully. But I'm always worried it might get corrupted one of these days. (I do make backups of my 500+MB database fairly often, but I'd hate to lose my work since the last backup.)

This failure to quit happens maybe one out of ten uses of the program, give or take. I'm running 0.9.9.21 on a fully-patched Windows XP SP3 system, Athlon XP processor, 2GB RAM.

Could nostra look into this, please? I'll try to remember to run PVD in -debug mode for awhile, and see if I log any error messages that might point to a cause.

Thanks,
Aimhere

It was last updated on February 8—when 0.9.9.16 was released. I don't normally add minor items or ones that are not yet documented. Is there anything in particular you think should be added to the list? The complete lists of changes are available in Changelogs.

Sorry, rick, I didn't realize the changelogs were available separately on the forum. My bad. 

When a piece of software is updated, I'm the sort who HAS to know WHAT exactly changed...

Aimhere

Quote from: AimHere on March 06, 2010, 08:26:15 pm

This is the only behavior that would really make sense to me, and I suspect, the majority of users.

You've got to be kidding! The majority of users aren't even aware of the issue or haven't found a reason to care. Most of the rest are confused because the technical operation of the NULL operator does not yield a result that is intuitive in the circumstances. It's the lack of consideration of what is sensible to the average non-technical user that is the source of the problem in the first place.

I suppose so. I'm only saying "if it were up to me"...

Quote

And the conditions "IS NULL" and "= 0" should NOT be equivalent. A value  of zero is still a value, not a "null". Then "null/not null" would have NO relation to "zero" (or any other value) other than the obvious (i.e. if the field contains "zero", then it is NOT "null").

This is technically correct, but doesn't have any bearing on the question at hand, until it's decided it should. I contend that it should not. As I've pointed out a number of times in a number of different ways, there's no reason why NULL and 0 should not be equivalent—if that is simpler and appropriate for the situation at hand. I'm not suggesting there's no circumstance in which different meanings would be appropriate—but they do seem difficult to find. For most users in most situations, they both mean the same thing, and any attempt to make a distinction therefore only causes unnecessary confusion.

I see your point.

Quote

And the various "Rating" fields should make a distinction between "blank/null/unrated" and "zero", instead of treating them as equivalent!

And this is the perfect illustration of my general point. There's absolutely no justification for the assertion there "should" be "zero" rating. As a rating scale, there's nothing wrong with it starting at 1. It is, in fact, far more sensible than what you suggest. Using stars alone, there's no practical way to distinguish between NULL and 0. And there's no reason to rate something 0 when you can just as easily decide 1 has the exact same meaning. It's also obvious most users will find it perfectly intuitive the way it is. With a 0 rating allowed, we'd be forever explaining the distinction between "0" and "unrated."

Also true enough.

I'd settle for having "IS NULL" versus "IS NOT NULL" testing return consistent, intuitive results regardless of which field is being tested.

Aimhere

Another follow-up to my earlier post.

I tried doing searches based on the "Budget" field. This field, like "Rating", is numeric... you can type any text you want into it in Edit Mode, but only numeric values will be saved when you save the record (non-numeric input will be "silently" rejected).

Now, it so happens that NONE of my movies have any budget data recorded for them in my database... "Budget IS NULL" returns 1364 out of 1364 records. But "Budget IS NOT NULL" returns 403 records!

In this case, the anomaly can be explained by this: When I first started using PVD, each new record added had a blank "Budget" field, whether I added the movie manually, by "New Movie Master", or by scanning files on disc. So those records have a truly NULL value for "Budget". BUT, at some point (possibly around the end of May '09), the behavior of PVD changed so that new records got a "Budget" value of ZERO if not otherwise specified. (A "Budget" of zero does not appear in the normal viewing mode, but will show up in Edit Mode, i.e. the field will actually have a "0" in it, as opposed to the older records where "Budget" is BLANK).

So, those 403 records are merely the ones that have true zeroes in "Budget", as opposed to the earlier NULL value. A search for "Budget = 0" returns the SAME 403 records.

The same thing goes for the "Box Office" and "Year" fields... earlier releases of PVD left them NULL if not specified, while newer versions set them to zero.

Note the difference between this behavior and that of the "Rating" field, as discussed earlier. For "Rating" and its siblings, "Rating = 0" and "Rating IS NULL" are equivalent (returning the same group of records), but that's not the case for "Budget"! "Budget = 0" returns ONLY the movies that have a budget actually equal to zero, NOT the ones that are NULL. "Budget IS NULL" returns movies with either zero or NULL budgets!

(Remember, I think that PVD always stores a numeric zero for unrated movies, even if that zero isn't displayed in Edit Mode, which is why "= 0" and "IS NULL" are equivalent for "Rating". "Rating IS NULL" is still returning records with either zero OR NULL values, but since "Rating" is never truly NULL, the condition simply returns all records with a rating of zero. That's not the case for "Budget", etc., which, as I've found, can have a truly NULL value, at least on older records.)

What it boils down to is this: the "IS NULL" condition will return records with (numeric) zero or (text) blank values AS WELL AS true "null" values, no matter what field you're searching on.

The "NOT NULL" condition always returns all records for which the tested field has ever been assigned ANY value (other than true NULL), regardless of the field's current value.

As mgpw4me has pointed out, there really is no way to set a NULL value on any field in PVD. Not-NULL values are created anytime a value is assigned to a field, and remain not-NULL forever, even if the field is cleared out or set to zero.

So if anything, the "IS NULL" testing is technically broken, as it technically should only return records for which the field is truly NULL (has never had any value assigned by either PVD or the user), not fields containing numeric zeros or empty strings. "IS NOT NULL", on the other hand, actually works as intended.  

Aimhere

Okay, I've done a little more testing, and I think I've figured out how the "NULL" and "NOT NULL" conditions really work.

"NULL" means that a field currently has no value (as you might expect), which is useful for searching text fields. So you could, for example, search for "Description IS NULL", get a list of all movies which have no descriptions, and fill them in.

"NOT NULL", on the other hand, seems to mean that a field has had data in it at some point, regardless of whether or not it currently has data.

As a test, I ran two advanced searches: "Tagline IS NULL", which returned 1263 records out of 1364 movies, while "Tagline IS NOT NULL" returned 107... but 1263 + 107 = 1370, not 1364! The six-movie difference can be explained by the fact that six movies preciously had values in the "Tagline" field, which were subsequently cleared out. Since they're currently blank, they are included in the "NULL" condition... but they had data in them at least once, so they are ALSO included in the "NOT NULL" condition!!! In other words, "NULL" and "NOT NULL" are NOT mutually exclusive.

If I pick a random movie which has never had a tagline and give it one, then re-run both searches, the counts change to 1262 and 108. I then re-edit the movie's record, clear out the tagline, save, and run the searches once more... 1263 and 108! So, while the "NULL" result might fluctuate up or down as fields are given data or cleared out, the "NOT NULL" results will only ever increase with normal program usage.

Given this counter-intuitive behavior, I'd recommend avoiding the use of the "NOT NULL" condition for anything. A real database guru might be able to provide a valid reason for this logic, but for most people it's totally useless.

Aimhere

Thing is, what happens if I turn off the "Show selection dialog" option in Preferences, and try to add a movie which is already in the database somewhere (usually in one or more actor filmographies, though not as a visible record in Movies View)? Does PVD automatically overwrite the first matching movie's record in that case?

And what if there are more than one matching records, as I've seen in the past (e.g. I try to add "Generic Movie Title" and the actor filmographies already include "Generic Movie Title", "Generic Movie Title 2", and "Some Unrelated Movie With The Same Generic Words In The Title, Vol. 6"  )? Would PVD always choose the closest match in that case?

I really do prefer to be kept informed of such things when adding movies, so I'm just going to leave the dialog enabled for now and deal with the peculiarities...

Aimhere

Would it not be more productive to report such errors to IMDb?

Of course, I do report errors to IMDB whenever I have the time (and mind you, their reporting process takes some time to fill out the update forms). But submitting an update is no guarantee that it will be accepted. And until/unless they agree that two separate actor/actress records really ARE the same person, I'm still left with multiple URLs for one performer in MY database.

I'd rather maintain duplicate records (to match the duplicate URL's) until the source is fixed.

I'd rather not.  One person, one record, even if that person requires multiple URLs.

Maybe what we need is the ability of the plugin to remove or flag records for which URL's no longer exist (because it was recognized to be a duplicate and deleted). I'm not sure what it does now. 

Good idea.

I'm also not sure what Optimize Movies does, but I assume it does not recognize a record to be a duplicate if its URL is different.

Your guess is as good as mine. 

Aimhere

An old favorite: "Star Trek: The Motion Picture." 

And a recent addition: "Star Trek" (2009)

The former was criticized for many reasons: being too long, too closely resembling a TV episode, the actors went around like they hadn't aged in 15 years, not enough action for a theatrical movie, the costumes looked like pajamas, etc. etc.  But it did launch the franchise onto the big screen; also, I love the music and F/X, and the refit of the U.S.S. Enterprise. I like it enough that I got the 25th Anniversary Director's Cut, which tweaks certain elements to make a more cohesive whole.

As for the latter, one could write a book on the gaping plot holes and violations of Star Trek canon/lore committed by the writers and director, not to mention the redesign of the Enterprise looks awkward and ungainly compared to the original. But I still felt it captured the feel and spirit of "Star Trek", and it was pretty entertaining in its own right.

Aimhere