#PAR Backup
12 messages in this thread
Christophe:
I ran some test with my PAR setup and was not able to produce the corrupt file
with bad frames after about frame 900, as you have mentioned. I tried the
following:
1) Copy 1360 frame file from PAR to DOS and back to PAR using both DOS and
PAR.EXE.
2) Copy 2700 frame file from PAR to DOS and back using PAR.EXE.
In each case the files play without error and appear to be correct, although
the one time I did a compare (using DOS FC after copying from PAR to DOS) the
file had numerous mis- compares.
This may be a stupid question, but are you using the same DOS/NTSC version of
the PAR board that I am? Mine is model DR-2100. Other system information:
Gateway 2000 P5-60 Pentium computer (PCI/ISA bus) MS-DOS 6.22 SCSI hard drive
Future Domain TMC-1680 SCSI controller, v3.5 BIOS PAR drive – Micropolis 2217A
PAR.HEX version 1.10 PARDRV version 1.4 (386) PAR.EXE version 1.09
I know that my drivers aren't the latest, but they have worked reliably, albeit
with a long list of bugs (which DPS would undoubtedly consider to be
version-specific-features).
Let me know what you are using and I'll try to duplicate your problem on my
system. By the way, what tape backup system are you using?
Cal
Well I'm using the PAL version DR.3100
However it could well be that the bug if it is one causing this backup problem
only came about with release 1.27 of PAR.exe, I believe it was not there
before???
But I do not think any of the other facts you mention are relevant however I'll
check am out.
BTW I'm not using any Tape backup at the moment, I'm just copying to my
harddrive, and to an MO128, however waiting until the problem is solved to get
a DAT.
Christophe
>> I believe it was not there before???
That's correct. I did not have the problem on my older version either, judt
since upgrading to the newer version.
Christophe:
Do you have the option of dropping back to the level of PAR drivers that I am
using? It might help narrow the problem down if you could try it. Do you get
the problem if you use DOS to copy files to and from the PAR drive — this
would eliminate PAR.EXE from the equation and leave only the file drivers.
Let me know if I can help out further.
Re tape backup, I have a Sony SDT-5000 4mm DAT drive set up and seem to be able
to backup the PAR drive, I still can't verify or restore without loading the
.ANI files onto my DOS drive, however. They way I verify now is to restore
from DOS and see if the .ANI file plays. It turns out to be about as fast to
copy the files from PAR to DOS then back up from there, the prolem is that I
don't have enough space to back up the entire PAR drive.
Cal
I unfortunately only have drivers from 1.27 up.
BTW the problem certainly stays the same when I just copy files in DOS, so it
is not related to PAR.exe directly.
Also to note to you, this discussion has been going on for about nearly 2
months I believe, and we slowly are getting more knowledge about the problem,
sooner or later it will be solved I think.
Christophe
Christophe:
What driver levels are you using? I have been using: PARDRV V1.4 PAR
initializer V1.13
Cal
Cal:
>> …if you use DOS to copy files to and from the PAR drive… The way I
>> verify now is to restore from DOS and see if the .ANI file plays.
That is the recommended method. People seem to forget that the PAR is NOT a
DOS drive, it is jumping through some incredible hoops to even look like one!
Many people are now looking into this to see if there is a 100% reproducible
case that can be found. If there is a reproducible case, it can be fixed. If
something like this only happens once-in-a-while, and on different files in
different places on different machines with different configurations, it can be
_incredibly_ difficult to find.
But believe me, it is being looked into. It is just surprising that the PAR
has been in use for oveor a year, and this issue is just coming to the surface
the last few months!
Greg Pyros
Gregory,
I really think that the problem of the backup/restore is already on the PAR.
and the only additional problem that backup/restore brings us is that all
frames get corrupted after this frame. Sometimes you can find the "strange
looking" frame within thef animation and removing this frame solves the
problem( and these files have never been backuped/restored) .
It looks to me that it has something to do with a pointerproblem in the
file on the PAR.
Theo
Theo:
Interesting theory!
Greg Pyros
What driver levels are you using?
Cal
Cal,
I installed the latest 1.33B PAL-version, i downloaded this version last week
from the DPS bulletin board. It solved for me the problems of the PAR getting
corrupted after optimise and deleting projects which were in the earlier
release. But the problem that came with this new version (no big problem
though) was that my whole system crashes when i start the PAR-software
after using 3DstudioR3 and it didn't solve the problem about the backup
/restore. So i still have to split and split my animations…..
But a new weekend is coming up to investigate.
Bye
Theo
Gregory:
<<If there is a reproducible case, it can be fixed.>>
I agree, but all I get from DPS is lip service. They reason that if THEY can't
reproduce it, it must not be THEIR problem. That attitude is naive at best.
Are you able to produce the problem?
Also, re copying from DOS not being the recommended method for PAR access:
This has worked well with me in my current configuration, so I am inclined to
stay with it. I am using old (version 1.09) software with raft of bugs, but
they are relatively benign bugs that I have work-arounds for. Most of my
work-arounds involve copy to/from DOS.
I would be interested in situations that you know of where a DOS copy, either
direction, causes problems.
Finially, software has to jump through a lot of hoops to access a SCSI or
network drives, yet it hasn't cost me any data!
Thanks!
Cal