Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[raldo]

This is a beta version of PvdImport, so install at your own risk!

Download the beta version here

I suggest you backup your MC database before you install PvdImport:
* 1.1.14
o Revert to MS Visual Studio 2005. Upgrading the plugin did not work (uninstall then install worked)
* 1.1.13
o The PvdImportConfiguration.xml file is now generated from default values when it doesn't exist on the user's system. Previously it was copied from the installer when changes had been done to the default version.
o When the file listed in the users  PvdImportConfiguration.xml file cannot be found, he Pvd field configuration file is generated from a default version, PvdImportFieldConfig_default.xml . Previously it was copied from the installer when changes had been done to the default version.
o Migration to MS Visual Studio 2008. This should have no consequences for existing users since the .net version is kept.

* 1.1.12
o Previously, "Send to\PvdImport" from the MC tree could not be done while AutoImport was enabled/running (an exception  would follow)
o Increase default auto import interval to 45 seconds
o Log window was disabled during auto import, it is now never disabled.

* 1.1.11
o Could not deselect auto import

* 1.1.10
o Logging: A Log.txt file is created in the installation folder. This file mirrors the log output view in the plugin pane.
o The log now contains time for each entry.
o If a default poster is selected in PVD, that particular poster will be imported
o A new stop button to stop "Run Once" functions
o Remove Test file function
o Set thread priority of auto update thread to "normal"

* 1.1.9
o Some more exception handling
o Increased thread priority of auto update check thread

* 1.1.8
o The thread priority of the auto update thread was increased

* 1.1.7
o Fixed crash - MC automation dll was excluded by error..

* 1.1.6
o New feature: Run Auto Import once.
o New feature: Run Auto Import at startup
o Auto import should load the system less
o More logging information during Auto Import (dates etc on changed file)
o Removed date modified from field config setup (avoids confusion on auto import setup)

* 1.1.5
o Updates to the Software User Manual on Auto Update functionality
o Reopening the PVD database didn't work as it should. Improved PVD database exception handling
o Some files did not get updated during Auto Update
o Remove test file and cover art folder text if they don't exist on disk.
o Attempt to preserve old configuration files.
o Better user information on erroneous configuration before scans or starting auto update

* 1.1.4
o Some improved exception logging and exception handling when loading the configuration files.
o All controls (except the ones needed for recovering) will be disabled when an exception occurs due to load/save errors of config files, etc.
o New Auto Update functionality ("Auto" check box). When enabled, changes made in Personal Video Database should be automatically imported into MC.

[raldo]

<This page intentionally left blank>

[rick.ca]

When enabled, changes made in Personal Video Database should be automatically imported into MC.

WOW!

Some installation an configuration issues, however...

The installation routine doesn't preserve an existing configuration file. I don't think upgrading users will be happy with that behaviour. It worked fine when I replaced the default file with my backup and restarted MC. But back to the default...

The disabling of controls in error situations is a good idea. My database is not in the default location, so this drew my attention to what needed to be fixed. Unfortunately, the controls remained disabled after I updated the database location. I had to restart MC to get it working. Other than the database location, what other error conditions result in this behaviour? I didn't encounter it elsewhere, although I (deliberately) created various "errors" due to invalid or empty test file and cover art locations.

The default values for the test file and cover folder should be something other than those from your system. They should probably be empty, so it's obvious they need to be set (or at least considered).

I think many are going to be so eager to get this going, they're going to stumble over the auto-import configuration. Very explicit instructions in the SUM and the release post will help. My first inclination was to set up the moddate field already in my field configuration (I wasn't using it, but I knew it was there). It was only after some experimentation I realized it only needs to be specified in the auto-import configuration. In other words, an SQL expression isn't required, and the existing item can be deleted from the field definitions. At least it seems so. Is there any point to keeping the moddate expression—for example, for importing moddate when auto-import is not being used?

The tooltip for the moddate box is very clear, but the error message that is shown on an attempt to activate auto-import without it could be better. Perhaps the wording should be exactly the same as the tooltip, except the last sentence, "The exact name of this MC field must be specified in the configuration."

The time interval box needs to be wide enough for at least five digits.

The log isn't being written.

Did you have an opportunity to consider this post? It's still replacing my posters with covers.

[raldo]

The log isn't being written.

Yes, I left it out on purpose (all greyed out), but I'll get on it once it's working well enough.

Did you have an opportunity to consider this post? It's still replacing my posters with covers.

I'll see what I can do. Can you create a new thread on this? I thought about this previously and the prelim conclusion was that since all images are fetched from the same record, we'll need some way of determining which record to get. How can this be done?

I'll get back to your other issues when I get the time...

[rick.ca]

I'll see what I can do. Can you create a new thread on this? I thought about this previously and the prelim conclusion was that since all images are fetched from the same record, we'll need some way of determining which record to get. How can this be done?

After studying the database structure, I see what you mean. I've asked nostra what the method would be in this post. I'm assuming he knows what programming language you're using and will tell you what you need to know. If this is not the case, or he need more information than I've provided, please add your comments there.

[raldo]

That's fine.

As for the fixes to the 1.1.4 version, I'll have something out within a few days.

Btw, the controls are greyed out upon "fatal" errors: Failure to open/close fb db, failure to find, open .xml files. I.e. errors that prevent you from using PvdImport. The main focus is to block the user from using the plugin in such a case, to give the user some info on what happened, and if possible, to give the user an opportunity to recover from the fail state.

In the coming version, I've also added some more feedback on nonfatal failures (missing cover art folder, missing moddate field, wrong interval times, etc.

I'll also analyze if there are some more situations which can cause crashes such as the ones Morrison and Maid are experiencing.

[raldo]

* 1.1.5
o Updates to the Software User Manual on Auto Update functionality
o Reopening the PVD database didn't work as it should. Improved PVD database exception handling
o Some files did not get updated during Auto Update
o Remove test file and cover art folder text if they don't exist on disk.
o Attempt to preserve old configuration files.
o Better user information on erroneous configuration before scans or starting auto update

[rick.ca]

I didn't test a new install this time, but installing as an update worked flawlessly. It forced me to enter my database location before doing anything else. And then the clearing of invalid fields made it pretty obvious what else had to be done.

I assume the poster issue will be fixed later.

I don't think I'll be leaving Auto Import set on. It uses, at least momentarily, too many CPU cycles. This may only be an issue on tired old machines like mine, but maybe it will affect things like video playback on faster machines as well. For me, the thing that's most valuable about it is that it detects whatever records are in need of updating. Under normal use, after updating, it's not likely anything will change until my next session. So, I'd very much like to see a few more options for how it's run. First, a Run Auto Import on startup option would be great. That would ensure things are up-to-date when a session starts—and then normally nothing else would need to be done. Second, since I will not have it set to run at intervals, it would be nice to have a Run Auto Import now command. That would would allow me to run it after changing records in PVD—without having to wait for it to finish so I can deactivate it.

o Set the Auto Import interval
o Set the MC ModDate field. This field must be added in MC under "Tools\Options\Library & Folders\Manage library fields"
o Select the "Auto" Tick box. Auto Import will now run at regular intervals.

I suggest this part of the SUM be revised as follows:

o Create a new field for PVD's ModDate ("Last Modified") data in MC using "Tools\Options\Library & Folders\Manage library fields." It may be named anything that does not conflict with existing fields.
o Enter the name of your new MC field in the ModDate box of the configuration.
o Set the Auto Import interval.
o Select the "Auto" Tick box. Auto Import will now run at regular intervals.

My purpose is to make it explicit enough to draw the reader's attention away from the otherwise reasonable notion something has to be done with ModDate in the field configuration. Deleting ModDate from the default field configuration would also help avoid such confusion.

Existing users are going to be primarily interested in the new Auto Import feature, and will be eager to try it out. To ensure the subtleties of it's configuration are not missed, I suggest this section of the SUM be mentioned early in the release post. Maybe "Please see section 4.3 of the SUM for instructions on the proper configuration and use of Auto Import."

[raldo]

I don't think I'll be leaving Auto Import set on. It uses, at least momentarily, too many CPU cycles. This may only be an issue on tired old machines like mine, but maybe it will affect things like video playback on faster machines as well.

It's not really a very CPU intensive operation: Only an SQL statement once every 20 (or whatever) seconds and then a loop which compares moddates. Once that loop has finished, the files that need updating are dumped to the standard file processing algorithm.

When all files have been updated, are you really seeing a major increased CPU load with Auto update enabled?

I'll look into this CPU load issue a little more. I don't think that the process of just checking the files should load the system significantly. Fetching the metadata might, but that mechanism is exactly the same as before.

If you're working in PVD, updating movies, I shouldn't think that an increased CPU load should be an issue. Are you watching movies while using pvd?!

PS: I also think that the moddate handling on the PVD side needs improvement. It seems as if Nostra is debugging some issues on .14 presently. Maybe these changes could be added to, say, .15?

[rick.ca]

I'll look into this CPU load issue a little more. I don't think that the process of just checking the files should load the system significantly. Fetching the metadata might, but that mechanism is exactly the same as before.

All the files are up-to-date. It's just the process of checking the moddates. MC uses 75-85 of the CPU for about 50 seconds at a time. So the CPU is pretty much continuously at 100%. This effectively screws-up video playback, and just about anything else. I'm not expecting you to accommodate a tired old machine which (hopefully) will be replaced soon. But it's so extreme, it seems reasonable to expect this is cause for concern for some not so old machines. Even if it's not enough to cause problems, many people can't stand the thought of anything consuming CPU cycles unnecessarily. So I think what I've suggested will appeal to many who don't need it nearly as much as I do.

PS: I also think that the moddate handling on the PVD side needs improvement. It seems as if Nostra is debugging some issues on .14 presently. Maybe these changes could be added to, say, .15?

Is there more to that than poster changes not updating moddate? If not, that's rather minor, and doesn't affect the plugin, does it? I have no idea when nostra might release .14 or .15. This recent tweet suggests he may be preoccupied with other things for a while...

PVD updated to version 0.9.9.12! Now I can move to the new Delphi 2010

[raldo]

Is there more to that than poster changes not updating moddate? If not, that's rather minor, and doesn't affect the plugin, does it?

It does affect the plugin in the sense that Auto Update doesn't work the way one would expect it to work..

Also, if one reimports data from IMDB, noddate doesn't change. This even if IMDB rating has changed, I believe.

[rick.ca]

I meant minor assuming the user understood poster changes would not be detected, but they would as soon as the issue is fixed in PVD. I've updated to 0.9.9.14, but I don't believe .13 was any different... moddate is changed only if the IMDb update results in any changes to the record. I thought this was rather cool—I wasn't expecting it to be that "smart."

But I'm afraid I have more serious issues to report. When I was measuring the CPU usage for the purposes of my last post, MC crashed. Although the plugin was in the middle of its process of checking moddates, I assumed the crash was more likely the result of me messing with Process Explorer while the system was so busy. After the crash, any attempt to restart MC resulting in...

Microsoft Visual C++ Runtime Library
Runtime Error!
Program:
This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.

Ultimately, I had to uninstall and reinstall MC, which seemed to confirm my assumption the problem had nothing to do with PvdImport directly.

Today, I got the same error and was unable to start MC. This time, the first thing I did was uninstall PvdImport, and MC started without any problems. I reinstalled PvdImport, and the error returned. I uninstalled version 1.1.5 and installed version 1.1.4 and now everything seems to be back to normal. So it seems the problem is caused by some change in 1.1.5.

Using 1.1.4, the moddate update process uses a much more reasonable 40-50% of CPU cycles, and last for 20 seconds. I haven't tested it, but I doubt this would interfere with video playback—as 1.1.5 does. Maybe these two issues are related?

[raldo]

* 1.1.6
o New feature: Run Auto Import once.
o New feature: Run Auto Import at startup
o Auto import should load the system less
o More logging information during Auto Import (dates etc on changed file)
o Removed date modified from field config setup (avoids confusion on auto import setup)

[rick.ca]

MC is still crashing on startup with the same runtime error.

[raldo]

MC is still crashing on startup with the same runtime error.

Sorry about that, I misread your previous post. This should fix it:

* 1.1.7
o Fixed crash - MC automation dll was excluded by error..

[rick.ca]

That's better. MC now starts okay.

The installation routine still replaces an existing main configuration file with the default. I'm not sure about the field configuration—mine is named differently than the default.

Run once @ startup is showing the tooltip for Do cover art. While I'm mentioning trivia stuff... there's now room to make the ModDate box a little wider. The appearance of the Enable Auto-Import button is different than other buttons. That makes me think it's supposed to change when activated, but it doesn't.

Auto-Import doesn't work. The "checking files" process seems to run very slow or do nothing. Using Run once, the log lists the files it's processing. The first time I ran it, it took a very long time (probably 5+ minutes before I aborted) to process 25 files. Normally, the entire scan takes only a few seconds. While it's detecting files that have changed, it also seems to be finding other files I'm quite sure haven't changed. ModDate is not being written correctly. Previously, it was written as a properly formatted date/time string; now they're being written without zero-padding (e.g., 9/20/2009 2:51:3 instead of 09/20/2009 02:51:30 PM).

This is difficult to test when it's not working properly, but it seems Run once @ startup is waiting the specified time interval. If so, that makes sense, as it allows time for MC's auto-import (if enabled) to run. It's unclear to me, however, whether that always runs immediately at startup, or how long it takes in various circumstances. Is it possible for the plugin to check if auto-import is running, and if so, wait until it's finished?

There should be an Auto-Import cancel/abort button—in case something goes wrong, or it's started accidentally.

BTW, were you able to resolve the image selection issue?

[raldo]

That's better. MC now starts okay.

The installation routine still replaces an existing main configuration file with the default. I'm not sure about the field configuration—mine is named differently than the default.

Yeah, I just don't remember how I fixed that on previous releases. It seems as if I have to research that all over again

now they're being written without zero-padding (e.g., 9/20/2009 2:51:3 instead of 09/20/2009 02:51:30 PM).

That change is on purpose and what I'm trying to do is to avoid the time culture settings which can change between users and even for a particular user! So I'm basically coding/encoding the time field myself, thus the lack of padding.

I thought my changes would work even for your setup (it works for mine). So: If you don't mind: clear all your MC moddate fields and do a new "Run Once). Once that's finished, do things behave as expected? I.e. does changing one record in PVD trigger a change in Auto Import?

[raldo]

There should be an Auto-Import cancel/abort button—in case something goes wrong, or it's started accidentally.

Yup.

BTW, were you able to resolve the image selection issue?

Not yet, lots of things going on these days...

[darichman]

Hi guys - sorry I'm not around very much at the moment! I'm in Sydney for a 5 week rotation... I guess that means I miss out on most of the fun

The new features look great raldo... I'll be around to test things out mid October if Rick hasn't sorted out all the issues by then Until then, spare a thought for me on my skeleton laptop with only Word, Endnote and a sporadic internet connection to keep me company...

[raldo]

Hi guys - sorry I'm not around very much at the moment! I'm in Sydney for a 5 week rotation... I guess that means I miss out on most of the fun

The new features look great raldo... I'll be around to test things out mid October if Rick hasn't sorted out all the issues by then Until then, spare a thought for me on my skeleton laptop with only Word, Endnote and a sporadic internet connection to keep me company...

Will you be able to get a hold of any 4X down there?

[rick.ca]

If you don't mind: clear all your MC moddate fields and do a new "Run Once). Once that's finished, do things behave as expected? I.e. does changing one record in PVD trigger a change in Auto Import?

There's definitely something wrong with the "Checking files" part of it. I cleared ModDate and did a Run Once. Of about 800 videos, it did 600 or so reasonably fast (a minute or so), and then slowed considerably for the next 100 (maybe 1/second). For the last 100, it became erratic. Maybe one every 2 seconds, then a spurt of 3 in a few seconds, then nothing for several minutes. Shouldn't the whole process be done in a few minutes, if not seconds? I didn't hang around to see how long the whole thing took. At the rate is was going, it was probably about an hour.

Once that was done, I modified a few records in PVD, then ran it again. According to the log, it found the modified records reasonably (maybe 30 seconds—still much slower than I would expect), but then apparently wasn't finished the "Checking files" routine. I suppose whatever problem it had when updating all the records it also has when checking for changes. After a very long time, it finished and moved on to updating the records. I tried it again with just one record changed. I let it run for about 10 minutes, and it didn't find it.

[raldo]

There's definitely something wrong with the "Checking files" part of it. I cleared ModDate and did a Run Once. Of about 800 videos, it did 600 or so reasonably fast (a minute or so), and then slowed considerably for the next 100 (maybe 1/second). For the last 100, it became erratic. Maybe one every 2 seconds, then a spurt of 3 in a few seconds, then

Strange, I've got 1400 movies and Auto Import churns through all of them in 6-7 seconds. What kind of processor load are you seeing?

The "checking routine" should take approximately the same time with clear .ModDate as when your MC Db is completely up to date (I.e. your "I suppose..." is correct). The reason is that PvdImport needs to check each and every moddate field every time.

I'll be away for a few days (work related), but I think a prelim log for your "Run once" case will be a good idea....

[rick.ca]

What kind of processor load are you seeing?

That doesn't seem to be an issue. MC is using 40-50% most of the time.

I think a prelim log for your "Run once" case will be a good idea.

Attached. The log includes the last of several trials. Each one seemed to be the same. It's taking about 11 minutes to complete the "Checking files" process. Changed files are detected and updated at the end of the process. For sake of comparison, I reinstalled version 1.1.4, initialized a new moddate field, and ran the same test. It took less than 20 seconds (it appeared to use the processor fully).

[rick.ca]

Any progress on this?

[raldo]

Any progress on this?

In a sense. I'm just wondering how to proceed since things are ok at my end but not on your end. I've been seeing ok response even with interval auto import enabled over a long period of time now.

In the release you're testing, I've taken some measures to reduce the load off the system so I'm kind of stuck as to why it's not  behaving well.

I've seen that MC seems to be unresponsive sometimes, even without my plugins installed. Have you noticed that? That may explain why the plugin, when installed, hangs for longer periods of time.

It would've been interesting to test on a third persons system, but darichman is even further down under nowadays...

[rick.ca]

Just to reiterate my test results...

The dramatic change in the "checking files" process happened when you changed how the dates were handled. So it certainly looks like the problem has something to do with the conversion, manipulation or comparison of dates.

There doesn't seem to be much variation what I'm seeing. It's consistently very slow (11 minutes!). The CPU doesn't seem to be overworked, nor does there seem to be a memory problem. So I don't think its caused by anything MC is doing, or because of too much load on the system. Do you see any significance in the pattern of the process starting out relatively fast (but still slow) and then slowing to a crawl?

Still, I realize my old/slow machine is suspect—but it was able to complete the same process before in about 20 seconds. What else is different? I'm running XP. Are dates in Firebird or this process affected by regional settings?

[raldo]

Still, I realize my old/slow machine is suspect—but it was able to complete the same process before in about 20 seconds. What else is different? I'm running XP. Are dates in Firebird or this process affected by regional settings?

* 1.1.8
o The thread priority of the auto update thread was increased

Can you test v 1.1.8, please?

There were some other changes between 1.1.4 and 1.1.7, among other I moved the check for file changes away from the GUI thread. In the 1.1.4 release, this meant that the GUI was unresponsive and that the priority of the test was the same as the GUI thread (relatively high).

In 1.1.8, the priority has been increased to normal. Now, the check finishes in 10 sec. with an average load of 50-60% on my amd3500+ system.

[rick.ca]

Can you test v 1.1.8, please?

There's no discernible change.

[raldo]

There's no discernible change.

Strange.

* 1.1.9
o Some more exception handling
o Increased thread priority of auto update check thread

Can you see change now? Do you see any "Error:" messages?

[rick.ca]

No change for the better. It seems stuck on "processing files." There are no files be being reported as updated and no error messages. It's running now—but I'm tired of waiting. It may be my imagination, but the processor seems busier than before (80-100% compared to 40-60, if I remember correctly).

[darichman]

Ok, I'm back in action! I've rebuilt my system (using Windows 7 now) and updated everything to the latest version. Have also restructured my movies drives/directories since I got back, so that's been plenty of fun

So I'm a bit behind with new developments on both the MC and PVD side of things I just did a batch import with PVDImport for ~700 movies and it didn't break a sweat. I'm going to turn on the auto-update feature and give it a test run over the next few days (love your work here, by the way!) - will let you know how that turns out.

Is there anything specific I can do to help out as far as testing is concerned?

Thanks again... cheers guys

Windows 7 64-bit
MC v14.0.84
PVD v0.9.9.14
PVDImport v1.1.9

[rick.ca]

So I'm a bit behind with new developments on both the MC and PVD side of things...

Well, let me bring you up-to-date. Thanks to the new benchmarking tool, raldo finally realized I was testing his plugin with the crappiest computer on the planet. So I believe he gave up trying to figure out what my problem is and intends to release with the hardware requirement, "anything better than rick.ca's crappy computer." Meanwhile, I broke down and ordered a new computer. I hope it will be fast enoungh you won't be able to tease me any more.

Is there anything specific I can do to help out as far as testing is concerned?

I think all it needs is a little polish. The logging functions need to be added. I think it would be helpful if the log included a time index as well. There should be a control for stopping or aborting an auto-import in progress.

[darichman]

Well, let me bring you up-to-date. Thanks to the new benchmarking tool, raldo finally realized I was testing his plugin with the crappiest computer on the planet. So I believe he gave up trying to figure out what my problem is and intends to release with the hardware requirement, "anything better than rick.ca's crappy computer." Meanwhile, I broke down and ordered a new computer. I hope it will be fast enoungh you won't be able to tease me any more.

Rick, that post is the funniest thing I've read in months haha You'll have to let us know what you end up with...

The plugin seems to be working a charm... I'm slowly updating all my series now and it looks like the auto-update is doing a good job keeping up. The only problem is that I keep my movies and series in separate PVD libraries, so I need to keep swapping.

[rick.ca]

You'll have to let us know what you end up with.

Dell Studio XPS 8000 with an i7-860, 8 GB RAM and a GeForce GTX260 1792 MB. I hope it arrives soon. The more I think about it, the slower this machine gets.

I keep my movies and series in separate PVD libraries.

Why?

[raldo]

Ok, I'm back in action! I've rebuilt my system (using Windows 7 now) and updated everything to the latest version. Have also

Greetings and welcome back!

A question for you (and Rick): Did you have any problems installing Firebird etc. on your W7 system? Did you use Vista before?

I've been struggling with PvdImport at a friends house for the past few hours. Most likely a Vista issue? The message I'm getting in PvdImport is 'failure to complete network request at host "localhost"' or something similar.

Pvd works quite well (Network=1 in pvdconf.ini) but I'm not sure if Pvd has connected via firebird embedded or server. Is there a definite way of seeing how PVD has connected?

Browsing through the other long PvdImport thread made me realize that this is most likely the problem that Steveklein encountered which was not resolved .

[rick.ca]

A question for you (and Rick): Did you have any problems installing Firebird etc. on your W7 system? Did you use Vista before?

My new machine will have Vista pre-installed. I have to wait for it to arrive before I can order W7. So I'll be using Vista for a week or so, then doing an in place upgrade. If I learn anything about PVD/Firebird/PvdImport through that process, I'll let you know.

Is there a definite way of seeing how PVD has connected?

I've never had any reason to question what it indicates in the titlebar (i.e., "[computer name]:[database path] Network"). If you have reason to doubt this, you could run Firebird as an application rather than a service (using the control panel applet). I believe it then gives you some indication of connections.

Browsing through the other long PvdImport thread made me realize that this is most likely the problem that Steveklein encountered which was not resolved.

While it may not have been "resolved," I was under the impression the problem went away.

[darichman]

I was using XP before I upgraded. I had to download the "Win64" version for Windows 7 (Firebird-2.1.3.18185_0_x64.exe from here) - it installed fine and seems to work as expected. Is your friend using 32-bit or 64-bit windows?

[raldo]

Is your friend using 32-bit or 64-bit windows?

32bit

Did you install as administrator? Did you change any file security settings?

[darichman]

I am the administrator, but didn't have to do anything special as far as installation went - just ran the install and said "Yes" when windows asked me if I wanted to allow it to access my system... I guess that's not of much help to you though

[raldo]

I am the administrator, but didn't have to do anything special as far as installation went - just ran the install and said "Yes" when windows asked me if I wanted to allow it to access my system... I guess that's not of much help to you though

Well, It may be of use; his user may not have been admin. So it'll be a thing to check/try.

[raldo]

* 1.1.10
o Logging: A Log.txt file is created in the installation folder. This file mirrors the log output view in the plugin pane.
o The log now contains time for each entry.
o If a default poster is selected in PVD, that particular poster will be imported
o A new stop button to stop "Run Once" functions
o Remove Test file function
o Set thread priority of auto update thread to "normal"

[raldo]

Hold on before you install, there is an issue with the "Enable auto import" button...

[raldo]

* 1.1.11
o Could not deselect auto import

[rick.ca]

o Could not deselect auto import

Yes, I found closing MC and editing the config file to disable it not very user friendly.

o If a default poster is selected in PVD, that particular poster will be imported

For this to work, it seems the poster must actually have "Use as default" set in PVD (the paper clip icon on the poster). If the desired poster just happens to be the one visible, it may not be the one selected by PvdImport. I'm not sure, but I think this might even be the case where there is only one poster—and therefore there's no apparent need to designate it as the default—but there are screen shots and/or covers as well. I don't imagine there's anything that can be done about this, other than making users aware that's how it works.

o Set thread priority of auto update thread to "normal"

Auto update still doesn't work for me (the new computer hasn't arrived yet), but I'm surprised to find a regular update (by search or Sendto) now runs at about one record per second—a huge improvement over the 20 seconds or so per record I was experiencing before. What did you do? Maybe I didn't need to buy a new computer!

[raldo]

but I'm surprised to find a regular update (by search or Sendto) now runs at about one record per second—a huge improvement over the 20 seconds or so per record I was experiencing before. What did you do? Maybe I didn't need to buy a new computer!

Yes, I did find (and fix) a suboptimal way of looking up files in the code.  Unfortunately, the change had nothing to do with the autoupdate search function so I guess i dont owe you an i7 after all:)

[raldo]

* 1.1.12
o Previously, "Send to\PvdImport" from the MC tree could not be done while AutoImport was enabled/running (an exception would follow)
o Increase default auto import interval to 45 seconds
o Log window was disabled during auto import, it is now never disabled.

[darichman]

Hi Raldo... I just tested build 1.1.12

- Mass import
- Auto-import
- Send to >

All worked without a hitch

I also ran a Send to > command while an auto-import was running. The new files I added were appended to the list of files to be processed... this was nice.

I agree things are very close to being finished! If there was one thing I would change, it would be to find a way to have PVD and PVDImport running in MC at the same time, without needing to change the config file. That's probably something a bit beyond what we can do with the plugin though... I have 2 PVD libraries (maybe this is a bad idea to begin with) so it's caused me a few troubles.

Nice work again... I look forward to your facetagging solution


Windows 7 Ultimate 64-bit

[raldo]

[...] it would be to find a way to have PVD and PVDImport running in MC at the same time, without needing to change the config file. [...] I have 2 PVD libraries (maybe this is a bad idea to begin with) so it's caused me a few troubles.

Exactly why are you running two libraries? I only have one library (.pvd file) and that works very well for me.

If the reason is that PVD and MC (PvdImport) can only run exclusively towards one library, then your problem most likely is that PVD runs with the embedded Firebird client and thus locks down the database. see :

http://yabb.jriver.com/interact/index.php?topic=52145.msg362897#msg362897

Nice work again... I look forward to your facetagging solution

Thanks,

Facetagging: if you've seen my post on the beta board, you'll see that I'm waiting for an answer on two questions regarding the MC text stamp mechanism which I'm using to display names in the images: what's the format of the font part of the XML in the "Edit Info" field. Also, I'd like to be able to turn the text stamps off since they sometimes ruin a good picture! Otherwise it's working quite well, but I feel that these two issues stop release for now...

[darichman]

Well... I've had two libraries, for TV and Movies, for ages. It's not the best way of doing it, but I wanted a way to keep them separate as I use different lookup criteria for movies vs series. I probably should have used different coloured bookmarks or something

I saw the post re text stamping - lets hope something comes out of it!

[raldo]

Well... I've had two libraries, for TV and Movies, for ages. It's not the best way of doing it, but I wanted a way to keep them separate as I use different lookup criteria for movies vs series. I probably should have used different coloured bookmarks or something

Yes, I seem to remember this now that you mention it. Is it a big job to merge the two DBs, or did you maybe add a lot of fan art to your TV DB?

I'm thinking you could probably use rick.ca's method of export-import + special image handling to merge the DBs...

I saw the post re text stamping - lets hope something comes out of it!

Well, I'm getting no reply from JRiver on any of my API questions, so I'll put it on hold for a while. It's a pity since I'm quite close to a good solution. Maybe I'll just post my current code for people to try, though. I am getting names in correct locations in the images so it's kinda cool. But the font size varies with the image size so some images just look ridiculous