|
|
So far, I have discovered this about the program. Upon execution, the first for a day, PD deletes a block of scratch files that are over 5 days old, but not older than 21 days, although the date range may be variable. It appears to be using the date range as a determining factor, not any association with the script file that created them.
Subsequent executions of PD on the same day do not cause any more file deletions.
I was dismayed to find out that PD also reaches into a backup directory I had created, named ...\photoTmp\BU, below the scratch dir, where I put a copy of all the files for safekeeping. PD deleted some of those, too, but not the same block of dates!
PD seems to remove the R/O flag I put on all files so it can delete them. There is no warning given for any of these actions.
So I have been forced to save a copy of all scratch files on another drive where PD can't find them, and restore them to the scratch dir at least once a day.
It would sure be nice if there was some way I could disable this automatic deletion function. It cannot be considered a feature.
|
|
|
Update...
It appears that PD8 deletes the temp files after about a week of non-use, although there might be other factors involved. I tried restoring the deleted files, then PD could open the PDS file and edit as usual.
However, if I set the temp files as R/O and disabled any changes, PD8 would crash hard upon loading of the PDS script with an "appincompat" error.
So it looks like I will have to continue saving the temp files, then restoring them before reading the PDS file; setting attributes doesn't work.
Give me the PD source code and I'll fix it. Right, fat chance.
|
|
|
|
Thanks, JL_JL! Your experience closely matches mine, and your explanation of the "delete from disk" option matches what I would expect. I will chalk this up to a bug that Cyberlink doesn't want to acknowledge, admit that it exists, or fix, except by charging for an upgrade.
|
|
|
|
Quote:
As a temporary measure, until you find a proper solution, why not back up the files to another directory at the end of each session? You could create a pair of DOS batch files (anyone old enough to remember them?) to do the back up and restore and put shortcuts on the desktop so you can do it with a double-click.
That's what I have been doing, now that I know what is happening.
It was puzzling for a while, since it only happens if graphics are modified (stretched, cropped) in PD. The file name is not changed in the script (it still points to the original), and it takes a few days before the delete action kicks in. For those reasons, not all edits were affected, and the ones that were only showed up if I revisited the edit weeks later.
|
|
|
|
Quote:
Later versions of Powerdirector have the ability to delete PD temporary files.
Which is exactly what I am trying to avoid. Besides, vers 11 won't run in my machine.
Maybe uninstall then re-install.
So you have nothing, then. I'll deal with it.
|
|
|
|
Quote:
If you press Alt+C in the edit module, that will bring the Preferences window.
On the Confirmation Tab, Uncheck "Enable file deletion from the hard drive".
It has never been checked, so that must not be the option we are looking for.
|
|
|
By "Director's chair," I assume that's the unlabeled icon at the top left corner that says "Menu" when you mouseover? Under Edit->Preferences->Confirmation, there is an option "Enable file deletion from hard drive." It has never been checked, so that must not be the option we are looking for.
Right now, I have the temp dir set with limited privileges. With any luck, we will get an error message when the prg tries to delete files again, but it looks like it is a long (few days) timeout, and there may be another factor as well.
|
|
|
PD8 creates a temp graphic file for each photo from the original, storing it in the "C:\Documents and Settings\{Your name}\Application Data\CyberLink\PowerDirector\8.0\photoTmp" directory when the stretch mode is set to crop (and possibly other modes). This temp file addr is embedded in the PDS script file.
The files in this temp dir are deleted a few days after the PDS file is last used. I am unable to tell why or when; rebooting the computer or reloading the PD program does NOT instantly cause the deletion. No warning is given to the operator, and the files cannot be recovered from the recycle bin.
Deletion of these files renders the script useless unless you reconstruct the edits, which can be difficult.
How can this deletion be prevented? Alternatively, how can the temp files be stored in a safe place of my choosing so they aren't wiped out?
|
|
|
|
PD8, XP SP2, trying to read a MOV file. Latest version of Quicktime is installed. I get a "...lack of decoding filters..." error. How fix?
|
|
|
|
Thanks! That did it. I didn't know that option was available (an icon without text requires an operator to guess what it means, and there are unknown icons all over the place).
|
|
|
|
All of a sudden, I have no color boards in the palette. How can I restore them?
|
|
|
Why don't you ask what needs to be asked instead of going on a fishing expedition? Anything that rings a bell, suggests an approach, or requires special attention?
Don't ask me if the computer is plugged in, ask something that we can work on. Do I have enough RAM? Yes. Do I have enough disk storage? Well -- is 10TB enough?
|
|
|
|
Thanks for all the helpful replies. Apparently luck is all that is available. That really makes me want to run out and buy the latest version. Does it need luck to make it work, too?
|
|
|
Listing pages and pages of unrelated system specs is useless. If anyone has a specific item that relates to the question, just ask it. I described the major components of this system in the OP.
Besides, the phenomenon happens in two similar but not identical systems with 2 versions of PD. It's likely to be something that is in common, and what's most in common is the underlying PD software.
|
|
|
|
Twice on the old computer (PD5), once on the current one (PD8). I don't usually come to message boards without having done the obvious!
|
|
|
Thanks, Tony. The most basic audio editor I can think of has these functions, but I'm trying to avoid external work.
I have a procedure even simpler than the one you suggest. I can read an MPG file into Goldwave directly and it gets converted to audio during import. Then I can save it as WAV or whatever after audio processing and re-import to PD.
But once reimported, I have to be very careful to keep the audio/video tracks locked. Some editing works better without the lock, so I can't keep that turned on all the time. It's all too easy to get things out of sync and all too difficult to get them back in sync without a time code.
It's just too many steps with potential for error for something that should be quick, easy and foolproof.
Does PD9 have any kind of audio EQ? That would be useful -- nothing fancy, just the ability to boost a freq range. Parametric or graph -- I'll take what I can get, but it would be easier inside of the video editor than external.
|
|
|
I often get source files with only one stereo channel used and the other, blank. Is there any way in PD8 (or any other version) do combine both tracks so the output is mono (or 2-chan stereo)?
If not, this would be an incredibly useful function and I can't imagine it would be difficult to add to the program.
Another function that would be useful is a L/R channel swap (again, should be simple to program). I sometimes need this because I have recorded two speakers on separate channels, but on the video they are on the opposite sides of the image (the left speaker comes out of the right channel).
I know I can extract the audio and easily accomplish this external to PD, then import the audio back to the video edit. But this prevents future edits from being easily and safely made, and I have had some problems with re-syncing that I want to avoid at all costs.
And requiring submissions to be recorded differently is not an option.
So could the developers put some of these on their wish list for enhancements?
|
|
|
My PD8 frequently freezes during the popup video edit, and the only way to fix it is to disable the program in Task Manager and restart it. Of course, this means I have to save the script file frequently, as all edits performed since the last save will be lost.
This is an XPSP2 dual-core machine that is in perfect working order. No other program has this problem. PD8 will do this regardless of any other programs running in the background or not. Note that this is a lean, mean machine, with NOTHING in the startup group. There is ample RAM and disk storage. Auto backups (in PD) are disabled.
When the problem occurs, the CPU is running about 30-50%. This may be meaningless, but I have noticed that PD8 seems to use one of the cores much more than the other. Most other programs seem to use them about the same.
Another oddity. I just executed PD8, imported a video file, waited for about 3 minutes for the background processing to finish, executed a popup edit window, and the program froze. The CPU utilization of both PD8 and PDhanumansrvr showed 0. However, the cumulative CPU utilization was at 23% steady, and no other programs added up to anywhere near that. Closing the program in Task Manager brought the 23% down to near zero, so PD8 was definitely the cause. While the utilization was at 23%, only one core was in use.
I have tried with the background processing enabled or disabled, with or without the PDhanumansvr.exe. No difference.
I had this same problem with PD5 on another, older XP machine, again, a lean computer with nothing else acting up and no other program exhibiting this phenomenon.
Any ideas how I can fix this?
|
|
|
|
Quote:
There is more that just the drive letter involved here.
The serial number of the drive is different, the sizes of the drives is different.
I don't think so. See my followup post. The size of the drive is irrelevant to finding a specific file. And the serial number (do you mean Volume ID, label or other?) is apparently irrelevant, too. Most programs don't reference any of those things when opening a file.
If the first time you open an old PDS file, use browse to locate the files, re-save the pds, the next time you open that pds, all should work as expected.
Exactly what I was trying to avoid. That would take many hours for a 2TB drive full of video files. If I had to do that (and I do, if the drive letter is changed), that might involve, in the case of one PDS file I just worked on with 300 JPG images, 300 browse/find/fix operations. Not a fun way to spend a day.
Thank goodness I don't have to do that in this case.
Nevertheless, I appreciate your advice.
|
|
|
![]() It looks like the problem was entirely my fault.
After trying to change both the disk label and the volume ID with no good results, I noticed that I had mistakenly copied all files to the root of the new drive instead of one directory level down, in the M:\video sub-dir.
Windows is good about moving files within one drive, and is smart enough to know that a move operation only requires adjusting some pointers, not moving data. So I was able to fix the problem in just a few seconds instead of the 12 hour operation it would have taken to copy the data all over again from scratch to the correct directory.
So at least I learned that neither the volume ID or disk label is important in a disk swap like this. Makes it easier.
Now if only Power Director wouldn't store the drive letter in the PDS files, it would be better yet. Right now, if I copy files from M: to H:, all scripts point to the wrong drive. It's a common way of writing programs, but some are better about it. For example, PageMaker 6.5 stores the drive letter too, but if it can't find a file, then prompts the operator and the op manually fixes the path, PM is smart enough to know that other files it can't find might be fixed in a similar manner and doesn't need to prompt the op. That's pretty sophisticated, but it makes the user eternally grateful when it happens and saves hours of fixups.
Sorry... ![]()
|
