#PAR oddity
9 messages in this thread
On my PAR:
When rendering frames 392-4xx to filename TEST,
the first 8 frames (392-399) go to TEST0392.ANI
the next xx frames (400-4xx) go to TEST0400.ANI
I get a consistent break on a 100 frame boundary with frame ranges such as
392-452, 392-402, 389-402, 292-302, and 198-202.
Not a big problem, since the files are contiguous and can be joined quickly,
but annoying. Has anyone seen this behavior?
JKJ
This used to happen to me but then it stopped one day and hasn't
happened since. Are you optimizing the drive before sending the
frames to it?
— James — Choreo Motion —
I've optimized several times in the last few days since I'm on the last 100 MB
or so of this 1Gig drive. Do you think it's related to optimization? Could it
just be happening at the end of the drive? Either doesn't make sense to me – I
would think that the PAR would simply refuse to accept frames and/or play them
back poorly if space or optimization were an issue. This seems like something
in the file system. Maybe I'll ask Gus.
I have a 1.7G drive to add to the PAR when I get time – maybe I'll try
the same tests with that drive. PS: What version of PARDRV are you
using? Could the problem have stopped for you with a new version?
Hearing this I would say your problem is related to the drive being nearly full
you can not use it 100%.
I have a 1.7GB Micropolis and I can use it up until 1.3 to 1.4GB full after
that animations tend not to play perfect anymore and give problems. However I
never had a break when putting files on the PAR???? It puts them all on in one
go, however when nearing such a full drive animations tend to have speed
difficulties and the resulting green squares due to lack of diskspeed???
Christophe
>>par full?…
I don't think that's the problem. I'm familiar with the playback problems with
using the inner tracks, but I see none of that. This seems like more of a
driver problem, especially since the split is always on an even 100-frame
boundary. And I've can put much larger animations on the same drive without
the split. Oh well, no big deal!
JKJ
Yes I do think the problem is the same, because My drive was nearly full and
everything I tried to add got corrupted to at the same frame. Meaning the drive
was unusable further then that point at least at the Block factor used at that
time.
If I however removed afile and optimized the drive then the file that seemed
corrupted was OK???
This prooves in my opinion that the drive is to blame, meaning that one will
never use it 100% for animation.
Christophe Van Oyen
Christophe,
Thanks for your response. I may not have sufficiently explained the problem I
was having. Your experience does indeed illustrate the classic PAR "drive
full/block size" tradeoff.
In my case, all animations starting on certain frame numbers were getting SPLIT
on 100 frame boundaries into two (healthy) animation files. I could put many
of these at once on the drive and none were corrupted, just split. Other
animations which were added were not split into two files.
However, this has since been resolved. It turned out to be an obscure but
easily fixed insect in the PARDRV code. I mentioned it to the driver developer
and he found it and fixed it in about a nanosecond! We will check out the
updated driver as soon as possible after which it should be available thru DPS.
JKJ
I really have no idea what could be causing it if its not optimization (which
at this point I don't think it is). I am still using an old version of
PAR.EXE, 1.29 I think. I am going to be getting a new system soon so I am
waiting until then to do a major overhaul of my entire software suite.
Do you run the DPSPAR PXP each time before rendering to the PAR, or do you just
rely on default settings? I run it straight away when I start 3DS to make sure
it's configured properly. Of course, this is just a guess as to what might be
causing the problem.
— James — Choreo Motion —
>>do you run the DSPPAR each time?…
No, every time I've checked it, nothing changed, so I've quit running it when
rendering. I did try that when doing test files that produced the split, but
everything looked OK. Just one of those small mysteries of life in the fast
lane. <g> Not a show stopper.
I've been doing a lot of animating lately and yesterday I tried to imagine
doing without the PAR. Ack! Double ack! There is no way I could get this
much done with my single-frame rig. Life is rosy. 🙂
JKJ