Personal Video Database

when navigating on a list filtered by tag cloud a backlink to the tag cloud will appear on the upper right corner.

Thanks!

Well done. Thanks for sharing the correct method.

Welcome.

Any Suggestions ?

A stab in the dark... I may not understand the 'problem signature', but I wonder about...

Fault Module Name:   fbembed.dll_unloaded

That's the embedded Firebird, which shouldn't be involved if the server is being used.

Did you use the Firebird Server Manager (a Control Panel applet) to start the Firebird service? Are you sure it's running? Check in Resource Monitor or Process Explorer.

I find PVD finicky when it comes to changing from a local connection (i.e., using Firebird Embedded) to the server. Sometimes I have to load some other database, then enter the server connection string to the original database.

Sorry, I don't know what the 401 errors are about, but...

Possibly the Firebird client is not running correctly - no idea how to check this out

...maybe we're both right.

Please use separate topics for different issues. In this case, it doesn't really matter because you're not clear enough or haven't provided enough information that anyone could help.

• [ID] is a user field (i.e., not downloaded from some external source). You can assign one yourself, or let the program assign one sequentially (or re-index it). I have no idea what you're comparing it to or on what basis you're deciding it's incorrect.
  
  
• I've never heard of this one. I assume this is a crash with no error message. Are you sure the database has been deleted, or is the program just looking in the wrong place?
  
  
• Deletes from where? When doing what?

This should be correct... I'm sure Rick or Nostra can confirm it.

Sounds right, although I can't think of any good reason to continue changing from one to the other. The only case I can think of for maintaining images outside the database is if the same images are to be shared by other applications. And that doesn't include most media manager applications—which would require them to be exported beside the media files anyway. So maybe an image editor is used to modify and maintain the images. Most users, however, would be happy to do whatever modifications are necessary immediately after download, and then save the result in the database. They can always be saved externally again (individually) for making further modifications.

Okay, I can think of one good reason. That would be to move all images outside the database so they can be processed in bulk by an external editor to resize and/or optimize them. Once that's done, they can be brought back into the database and the database optimized. I don't know if there's any advantage to doing one of those steps first.

Then - I'll try merging with this merge button!

I'm not sure what you're looking at, but probably a function for merging an added recorded with an existing one. The function you're looking for is Append (i.e., as in append one database to another). That hasn't been added yet, but there is a button and shortcut for it in the beta—suggesting it is on nostra's list of good intentions.

So how do i go about merging one to the other with out loosing the data from my prefered set up and preference db?

I don't know, but you could backup the image folder and your databases and experiment. Try combining the image folders to one and point both databases to it.

Is there anything to watch out for when merging them? settings etc etc?

Yes. A feature that merges databases.

It's been requested before, but I imagine it's not easy to implement.

I wish nostra would comment on your conjectures, but he seems to have the good sense to stay out of such discussions.

PVD is basically by all rights very similiar to a website - it uses css and xml as for it's templates - I think we can agree on this.

The fact a skin is defined by XML and an export template may include CSS doesn't make it similar to a website anymore than anything displayed on a computer screen is similar to website because they're both displayed on a computer screen.

It is well known the smaller you can make the weight of a page - the faster it will load. - we can agree on this as well I'm sure.

Can we agree an imperceptible load time makes no difference? Do you use low-res posters too, because each movie 'page' has to load one? [Edit: OMG, it seems you do!]

I saved you over 100k - which will load faster at full rez - the 119k of course.

Yes, I could have 'optimized' the preview, but why bother? It's just a preview. It's already a compressed jpeg. It's not being transmitted over the internet. And...

Now PVD loads from what I've seen, at start-up all templates.

...if by 'templates' you mean previews, it doesn't.

So lets say you have 1000 images for a 1000 movies - each weigh say 200k each. That comes to... what a mear 100 megs of photos - then add your database itself. that's a pretty heavy database.

Now you're talking about posters and other images. Yes, I have more than 1,000 movies, many of which are 'heavier' than that—my database is 1.6 Gb, and most of that is obviously images, none optimized in the way you're advocating. That's because I want to be able to view them in the viewer at as large as my monitor will allow. If I have time, I do optimize them at that resolution, but it doesn't matter much if I fail to do so. To me, spending any time looking for and choosing the best images for a movie is a waste if you're going to then save them at a low resolution (e.g., a poster optimized for the size at which it's displayed in the skin).

If my database were being accessed over the Internet, I'd likely do it differently. If I were offering my database to others by download, I'd tell them it's big, but worth the download if they like good art.

Again, it makes no perceptible difference to how quickly PVD loads or displays a record.

Do you really go through your data base and look at all the preview images? Or more honestly do your preview images simple serve as a reminder of what the movie or song or album was?

You apparent use of the word 'preview' to mean both the preview of a skin or template and a poster or other art is very confusing. A poster is not a preview, it's a poster. And no, I don't use them as thumbnails to remind me of what the movie is. I collect posters, just like I collect other movie meta data—that's what the program is for. I don't want to butcher a good poster, just like I don't want to butcher a comprehensive review because it's 'too heavy.' Since previews have no impact whatsoever on the performance of the database, I'd much rather (as explained in my last post) have images that convey as clearly as possible the nature of the skin or template. Many of those things I rarely use, so a good preview will very likely save me from loading or using something only to then discover it's not what I want.

Go to a JPG and optimize it - add a tad of sharpening or clarity and you drop 50% or better off a JPG. Let alone what you save off a PNG.

Is there some reason you think I don't do this?

image your 1.75 Terri database only weighing in at 750 megs or less once optimized.

That's not difficult. I'd be sacrificing a very significant and valued degree of quality in images for a very small improvement in performance. Why would searches be faster? Do you understand how a database works?

just my two cents but - bet mine runs faster now it's optimized even with a mear 166 titles. Actually - I know it does.

I'm glad you're happy and sorry to be argumentative, but I don't think this sort of analysis helps others understand the program better and use it to their advantage. I would agree there is value to understanding digital images in general and what is meant by things like 'optimization' (which, BTW, you didn't explain). But that doesn't have much to do with PVD. It uses the Firebird database, which is very forgiving of things like image size. If someone had reason to collect very high resolution images (i.e., way beyond the needs for displaying on a monitor), there would be no reason for them not save them in their database—if that's what works for them (e.g., for keeping them organized and secure).

I took a moment to optimize the preview images for some of the skins for PVD. I really didn't see the sense in having 200k - 500k images for a preview image. And it may be my imagination, but PVD seems to load a little faster since doing so.

Sorry, I don't see the point in this. If anything, the resolution of the images provided it too small. If a preview is shown, there's no reason why it should be a fuzzy one. And while the dimensions are probably appropriate for the resolution, the dialog does resize them to fit. If the user wants to make the dialog full-screen to get a good look at a preview, there's no reason why they should not be shown a suitable image. The best preview to use is the largest screenshot you can get (assuming an aspect similar to that of the dialog—most will be). That will work with the dialog at any size. The size has no impact on how long it takes the program to load or display the preview.

To illustrate, which is the most effective preview?...

[attachment deleted by admin]

The database should not get larger that 4 Tb in size AFAIR

Well, that's a big relief. I was concerned the entire IMDb might not fit. Extrapolating my current database, it seems it should only require 1.5 Tb or so...