Announcement: Our new CyberLink Feedback Forum has arrived! Please transfer to our new forum to provide your feedback or to start a new discussion. The content on this CyberLink Community forum is now read only, but will continue to be available as a user resource. Thanks!
CyberLink Community Forum
where the experts meet
| Advanced Search >
For AshJT and anyone else interested in this thread, I want to share an update to an earlier post.

On my first trial attempt to recreate this timing problem, I only added 5 of PD’s stock jpg images and the frame duration did not change, and that was the result I posted. Later however, thinking that perhaps a longer project might recreate the glitch, I added those same 5 images 10 times for a total of 50 frames, gave them all 9-second durations, and added 2-second fades between them all. I then closed and reopened the project to find that the duration of 19 frames were now different.

I have noticed that when the timing on one frame is changed, compensation is made on another frame. For example, with the 9-second frames, when one frame is changed to 8:29, compensation is made elsewhere by changing another one to 9:01. Also, on this trial run, 2 frames reverted back to the 5-seconds I had originally set for this trial, and 2 fades were completely removed.

After downloading build 2726 and reinstalling, the same timing issue remained (even with a new trial project using PD stock images). I haven’t worked with PD at all in a number of months and have yet to test it again with my own images. It just so happens that I am currently using an older PC and the CMOS battery may well be the culprit as suggested earlier. But I’m shopping for another system and once I have a new one, it will be interesting to see if the timing issue goes away.
Hi Dafydd,

Please see my PM ... thanks.
If you will read earlier in this thread, you will see that someone else suggested I try a project with the stock images in PD ... which I did ... and the timing glitch was not reproduced (which I can't explain). I don't claim to be a computer wizard, but it would seem to me that if it was a battery problem, the effect would be indiscriminate, causing the same timing issue with all images whether jpg, bmp, or what have you.
That's an interesting thought ... but then, why doesn't it happen with the stock images as well? Wouldn't the problem persist in all circumstances?
Will do, Dafydd … thanks.

And thanks to Tony as well. I appreciate you having a run at it. Every little bit helps.
Hi Adrian,

Thanks for the reply. I ran a quick test with the 5 stock jpg images that came with the program. After closing and reopening a couple of times, the timing remained in tact. Just for clarification, I purchased PD7 about a year ago and started out with build 1714. I have since downloaded and installed each new patch in hopes of repairing the glitches, but I've noticed this problem since the beginning. Question ... why would my own jpg images cause this problem with the timing? Most of them are nice digital images.

BTW, when I reopened the project I've been working on, the timing on most every one of the 107 frames had once again been changed (including 3 transitions). It gets very frustrating, and I appreciate your input.
I have been reading the forum messages regarding the timing issues in PD7. I have updated to the latest build (2726) but the problem I continue to have is the program changing the duration of the frames in the timeline.

All I am using is jpg images - no video clips. But each time I close and reopen my project, PD alters the time duration on probably 90% of the frames, even if only slightly. I can set the duration to display a frame/pic for 8:15, and after reopening (or just by going from the edit area to the creat disc area and back) the frame duration will be changed to 8:14 or 8:16 or something other than what I manually set. Sometimes it even changes the duration of the fade/transitions.

I realize that the change is only a fraction of a second, but with a long movie, it can make a difference. And besides, I should have full control over the project and not be having to deal with the program setting its own timing. Are there any fixes?

Thanks!
I would love to know the outcome of this situation as I’ve had similar problems with the menu (haven’t attempted to burn yet because I haven’t been able to get the menu to do what I want).
Update - - - I just received a replacement dll file from our resident Senior Contributor and it seems to have fixed the problem. The menu template area now loads just fine. Thank you Dafydd!
I'm experiencing the same problem even with version 7.1714 (as mentioned in the other reply). I receive an ‘Error signature’ that cites ModName: menutemplate.dll as the culprit. I wanted to check this area first for an answer because I dread to start the vicious loop with Tech Support. It's like trying to pull a tooth without anesthesia.
Go to:   
Powered by JForum 2.1.8 © JForum Team