PAR backup!
24 messages in this thread
Brick:
I also have the >896 frame export problem w/ v1.30b. I'm running on a Gateway
Pentium 60 (Intel Mercury1 motherboard) with a Novell 3.12 network.
Speaking of Novell, did you get my email from while you were gone? In case
not, here it is:
—————————————————————————–
I've got a PAR in a Gateway P5-90, which, in turn, is on a Novell 3.12 network.
I've been using the NETX 3.32 shell and the PAR with no problem. Then, I
decided to try Novell's latest version of the VLM redirector (v1.20). Now I
find that when I run certain programs (the two I've specifically discovered so
far are Norton Utilities DS [dir-sort] and NCD [Norton-change-dir]), QEMM
(v7.5) reports receiving an exception 13 error.
If I choose the "terminate program" option (as opposed to "reboot") that QEMM
offers, and immediately run the same program again, this time it works — and
it continues to work. Also, the other program will work as well. (ie, if I run
DS, it reports the ex13, I choose "terminate", I re-run DS w/ no problem, I run
NCD w/ no problem — or — if I run NCD, it reports the ex13, I choose
"terminate", I re-run NCD w/ no problem, I run DS w/ no problem).
When I don't load the PAR driver, there's never an error. When I don't use the
VLM (and use NETX.EXE instead) there's no error. It does this even though none
of the involved software is loaded high. The PAR software is v1.14 (the PAR
initializer) and v1.4 (386) (the PAR driver).
I'm going to CC a copy of this message to Gus — do you have any ideas?
—————————————————————————–
Thanks, Dave
>> I also have the >896 frame export problem w/ v1.30b. I'm running
on a Gateway Pentium 60 (Intel Mercury1 motherboard) <<
I have essentially the same hardware as you do and I DO NOT have the
frame >896 problem. I am using a Gateway P5-60, Micropolis 2217A PAR
drive, SCSI DOS hard drive.
PAR software:
PAR initializer V1.13
PAR.HEX V1.10
PARDRV V1.4
PAR.EXE V1.09
I do backups directly from PAR to a SONY DAT tape drive.
I do restores from tape to DOS, then copy from DOS to PAR using the
DOS copy command.
Verifies always fail, but the ANI files look and play correctly.
What version of PAR.HEX are you using? I backed down from version 1.27 when
my PAR drive got corrupted and DPS told me they don't beta test prior to
upload.
I'de be happy to try to replicate you problem.
Cal
>>I backed down from version 1.27 when my PAR drive got corrupted and DPS told
me they don't beta test prior to upload.
Actually, the recent uploads ARE beta versions and we who use them are the beta
testers.
>> Actually, the recent uploads ARE beta versions and we who use them are the
beta testers. <<
Disagree. A proper beta program has at least three things:
1) A list of known bugs — so the testers don't spend time tracking down bugs
that are already known. (If DPS has one, nobody I know of has seen it)
2) A method of tracking bugs and bug reports. (DPS won't take a bug report
over the phone: "If you have a REPEATABLE case, you can FAX it in, and MAYBE
we'll look at it")
3) A staff committed to FIXING the bugs and working CLOSELY with the BETA
testers. (DPS has the annoying habit of attributing any problem to "a DOS
problem, etc." — whatever it is, it's never THEIR bug)
Before I started rooting around up here I made the mistake of trying to get
some help from DPS about backup problems. I was flatly told that all the
backup problems that had been reported had been traced to "incompatibilities"
in various hardware configurations, etc.. — I come up here and find out that
was a BOLD FACED LIE! The "frame >896" problem was being hotly debated. So
far I haven't found anyone who is DIRECTLY backing up a PAR drive to tape and
directly restoring it — the work-around is tape to DOS to PAR.
I started contacting DPS in with backup problems in May, and they still don't
appear to have taken OWNERSHIP of the problem!
I LITERALLY BEGGED dps to LET me work with them to resolve the backup problem.
I was told that "We have over a THOUSAND units in the field, we're JUST TOO
BUSY to do that… send us a FAX" (FAX THIS you arrogant BA$|_rd!) I've
participated in Microsoft beta tests with over 5,000 beta testers — they
weren't too busy to work out a problem with MAJOR implications for the end
users. Or maybe DPS doesn't think backup problems are worth their precious
time?
Don't misunderstand, I think the PAR hardware is wonderful, Gus Grubba did a
wonderful job with the drivers, its just the tech support that bites.
Ahh. I feel better now! (flame off)
Cal
>>Disagree. A proper beta program has at least three things:…
Your utopian wish is noted but the reality is that many companies will "beta"
test their products just the way DPS is doing. ie an informal program of
feedback. I agree with you that a structured beta program is the best way to
do it but the informal approach as in the way DPS operates is at least better
than no testing at all. And, as a matter of fact, Brick did advise us of some
problems when he uploaded the "beta" versions for us to try and evaluate. He
also was present to accept feedback from the forum members as to new problems
and responded to us in public forum comments as to fixes in the works.
As for Microsoft being your shining example???? I can assure you that they are
no different, well maybe their customer relations people are more skilled at
telling you in an arrogant fashion with a smile and charm but it's still
arrogance just the same. I had complained to MS about WFW and the problem with
their Intel ethernet cards not being able to handle the packet load in a
graphics environment for a year and they denied it. After Metcaff published
his article about the problem and that he had been working with MS since the
mid 80's on it did MS finally admit they had a problem with WFW. And, I
believe you were off a bit on the beta program as the figure was more like
50,000 testers. I was one of them. In fact I've been involved with hundreds
of beta test software and hardware and only a handful of these have been formal
testing programs in a structure as you suggest.
As for DPS' specific backup problem I think they are working on it but don't
feel an obligation to report to you their progress.
Poor software quality has killed more than one good company…
Be a shame to see it happen to PAR.
Cal
Well, I doubt the lack of >896 frame backup capability is going to be anything
that will cause ME to loose sleep over since 99% of my animations worth saving
are under 20 seconds anyway. I only save my archived project files. If I have
a need for restoring the animation two years from now I'll just have to suffer
through another rendering. I don't mean to blow off this problem but, frankly,
I think I'd be more productive worrying about sunspots.
Don:
/_____________From your message_____________\\
I doubt the lack of >896 frame backup capability is going to be anything that
will cause ME to loose sleep over
_______________________________________________
I'm losing sleep as I have the >128 ceiling. My animations are usually longer
than 4 seconds <G>.
Bob
Have you always had this limitation? DPS has alluded to this being a hardware
compatibility problem. Do you have another platform you could move the PAR to
for a Test? What sort of computer do you use? My PAR happens to reside on an
EISA DX2 66 machine with AMI Bios and 1 Meg od Cache. I also use an EISA DPT
cache controller for the SCSI II hard drive. Maybe we should all compare
notes. I didn't realize there was a difference in the limitation as well.
Replying to your suggestion to robert to put the PAR in another PC.
I did that with mine and the problem stays the same, at frame 896 after copying
to DOS drive and back to PAR the file is corrupt.
First the PAR resided in
olivetti M4-82 Pentium60 PCI/ISA with a seagate ST3655A 528MB drive and a SCSI
Barracuda 32MB RAM
then I put it in
olivetti M6-440 486/66 VLB/ISA with a conner 528MB drive and 12MB RAM
On both machines 72pin RAM chips
And problem is identical
I just do not understand Cal Haines does not seem to have this problem.
Is there anyone else around that does not have the 128 or 896 frame backup
problem????
If so then it has to be hardware related I think, could a switch on the PAR
card itself standing in a different possition be the cause????
Otherwise I still think the best results concerning the cause where obtained by
Theo van Bruggen.
If Brick Eksten is listening, help???
Christophe
Cal is NOT using 1.30b, but, rather, v1.09.
Dave
FYI: and others who have accused DPS of arrogance to this issue:
I received this via E-mail today:
>> Guess what? I'm only kinda back. We are still working on hte >896 frame
limit. I will keep everyone posted. I also want everyone to know that this is
at the top of our priority list, its just a tough one to nail down.
Brick<<
I hope this says it all.
Don Landis
Don:
/_______________________From your message________________________\\
Have you always had this limitation?
__________________________________________________________________
The >128 frame problem has always been a problem for me.
/_______________________From your message________________________\\
Do you have another platform you could move the PAR to for a Test?
__________________________________________________________________
I may be able to swap it for a test, good suggestion.
/_______________________From your message________________________\\
What sort of computer do you use?
__________________________________________________________________
I am using the PAR on a DEC xl566 pentium with SCSI-2 controller.
Bob
Don:
>> I only save my archived project files. If I have a need for restoring the
animation two years from now I'll just have to suffer through another
rendering.<<
Of course, we all have different needs. We need reliable backups for several
reasons:
1) We do strictly forensic work. We feel that we must be able to produce the
actual .ANI file used in an animation, if so ordered.
2) Some of our animations require hundreds of hours of rendering time. In
some cases (using ray-traced shadows) individual frames can take up to an hour
to compute on a Pentium. I get pretty nervous as I approach that time when the
available machine hours exceed the time required to re-render a project —
lawyers don't tend to be very understanding when it comes to hardware-related
excuses.
3) Its not uncommon in our business to do an animation for a client, not hear
a thing from them for six months, then have them call with some minor change
that they want just before trial.
4) Any time I can keep from re-rendering a project I save money, particularly
if I have to re-render for free. Machine time is a billable commodity in my
biz.
Actually, backup is not the problem. The problems are 1) verifying that the
backup is error free; and, 2) restoring the backup to the PAR drive. Both
require copying files to the DOS drive. It ain't pretty, but it allows me to
sleep at night.
What I really want to understand is the frame >896 problem. We don't have it,
but knowing that its out there bugs me!
Cal
I understand your situation more now. What I do here for critical animations
is save an archive tape betacam or VHS depending on the client, that is an
exact copy of what I gave them for my records. If I need to make changes I
would have to rerender anyway. I just found saving digitally vs. in video
format more costly and slower.
If you don't have the >896 problem, which problem do you have with respect to
backup/restore? I'm trying to get a handle on what it is that generates the
problem as you know some people don't have it at all and others have it at
>128. I know DPS is working on it and it would be good if we can offer some
real data to help resolve the issue with the many platforms we have on this
forum.
Don:
>> which problem do you have with respect to backup/restore <<
Compared to the frame*128 problem that others report, my troubles are few
indeed! In fact, they only arise if I NEED to restore a backup or WANT to
verify that a backup is valid. So far this has only bit me once, when I
ignorantly deleted a project from the PAR drive and scrambled it in the
process! I was ultimately able to recover everything that was "mission
critical", but it cost me a lot of time and a large percentage of my remaining
hair. The incident prompted me to push for a reliable backup solution.
Basically, my situation is this: I can backup from PAR to 4mm tape, but if I
want to verify that I have a good backup I have to go through a number of very
time consuming steps:
1) clear enough space from the DOS drive for the .ANI files
2) restore the .ANI files from tape to DOS
3) create batch files to copy the files from DOS to PAR, one at a time (copy
*.* doesn't work — stops after the first file for some reason)
4) clear enough space on the PAR drive that I can restore the copy of the .ANI
files for inspection — this may not be easy, as I'll discuss later.
(remember, the goal of the verify is to make sure I backed up the .ANI files
without error, so I can't restore to the original location — I want to keep
those files until I'm done with the verify)
5) execute the batch file to copy the .ANI files from DOS to PAR
6) use PAR.EXE to play the .ANI files and visually inspect them for errors.
I'd much prefer a binary compare, but for some reason, files copied from DOS to
PAR do not compare, even though the copy on PAR plays OK. Copying the files
from PAR to DOS does seem to allow a binary compare to succeed – curiouser and
curiouser.
My problem — mostly a head-space problem — is that its such a royal pain to
verify a backup, and there seems little point to doing a backup that MAY OR MAY
NOT be good, that I tend to put off backups. The result is that I wind up with
so much stuff on my PAR drive that its hard to find free space to restore the
files for inspection.
Paranoia usually forces me into a backup/verify when I approach that magic
moment when rerender time exceeds available machine time. Unfortunately, this
is always the point when project related stress is greatest and time at a
premium. Plus I need the machines for RENDERING, not file transfer related
fun-and-games! I wish I could justify a second PAR station so I could lay
critical animations down redundantly, then I wouldn't loose sleep worrying
about a crash of the PAR drive or something.
I've considered alternatives:
A) Render to .TGAs on the DOS drive, backup and verify the .TGAs, then send
em to the PAR station. This requires huge amounts of disk space, and removes a
lot of the benefit from the PAR system.
B) Backup by clearing space on C:, copying .ANI files to C:, verifying DOS to
PAR, backing up the C: files to tape with verify. But I just don't trust this
approach at this instant in time. I figure that if I can load a file onto PAR
and it plays OK, I can do it again. The idiosyncrasies in file compares from
PAR to DOS just make me nervous. Its more of a piece-of-mind issue than
anything else.
As you have noticed, a restore operation is a subset of a verify operation a
la Cal. So if I can verify, I can restore. The problem is ultimately one of
TIME! Damnit, I figure if I can COPY a file from DOS to PAR, I should be able
to copy from 4mm to PAR, but Corel SCSI backup won't do it nor will the QIC-80
lash ups that I've tried.
Anyway, that's my story and I'm sticking to it.
Cal
This is really to everyone.
We have been able to duplicate the 896 frame limit after a fashion on most any
machine we want to now that we know what to look for. Its been a slow bug
chase for various reasons but the gist of it is that we are still plugging away
at it.
We hope to have a resolution very soon.
Brick Eksten
Product Manager
Digital Processing Systems
Thanks Brick!
Dave
Brick:
>> We have been able to duplicate the 896 frame limit after a fashion on most
any machine we want to now that we know what to look for <<
Is it simple enough to share? Might help us keep our feet out of holes in the
mean time.
Cal
Don,
See the messages i have send to several people and also to the DPS-BBS-board. I
spent more than 200 houres in testing this problem.
I'm sure i pointed them in the right direction.
Theo
Don, maybe your animations are short enough but we do ( and our clients) do
anims of about a minute and rerendering them is just not feasible. At the
moment we have a project which took 1200 hours of rendering on a pent/90 and I
would hate to redo it.; Some backup facility is paramount !
Well I agree that rerendering them is not feasible. And breaking up a 3600
frame ani file into <896 frame segments is a pain too. So What's wrong with
just saving the animation on video tape, say… component betacam SP. Having
the master ani file in this analog format is just about the next best thing.
Just a year ago we all stored our animations in video format. And I don't ever
recall saving some 900-3600 tga's to Jumbo 250 tapes. I couldn't afford the
tape stock. <G> So what has changed to cause all the panic with this NEED to
save huge *.ani files?
Cal:
Ah, you're running 1.09! Yeah, I've not had problems with that version, but
I've really needed the enhanced join/duplicate/etc functions in 1.30. Once I
learned not to delete proj dirs, and to exit the PAR software immediately after
an OPTIMIZE, I haven't had any other _functional_ problems, other than the
export.
PAR INIT 1.15 PAR Bd H/W rev 1.0 Super-8 Rev 00000111 Micropolis 2210A, Fimware
rev 775-08 PAR DRV 1.4 PAR.EXE 1.30b (How do you tell the rev number of
PAR.HEX?) My local drives are IDE WD Caviars/Pirahna's, but I've been exporting
to the network drive, which is a Micropolis SCSI.
Are you on a Novell network? Did you see my other message about a clash
between the PAR drivers and Novell's VLM DOS requestor? THAT's something I'd
like to see someone else verify.
Dave
David:
>>(How do you tell the rev number of PAR.HEX?)<<
PAR.EXE V1.09 displays it when you select PREFS — ABOUT … According to my
notes, PAR.HEX was at version 1.11 — one rev higher than what I am using — as
of PAR version 1.27b. My copy of PAR.HEX 1.10 has date of 3/2/94, size 26,024
bytes.
I think I heard that DPS fixed some directory bugs, since PARDRV is still at
version 1.4, the fix must have been to PAR.HEX? Maybe they added a few
"features" as well?
>> Ah, you're running 1.09! Yeah, I've not had problems with that version,
but I've really needed the enhanced join/duplicate/etc functions in 1.30.<<
Have you tried restoring by copying files from DOS to PAR using the DOS copy
command? Assuming that the problem with the corrupted frames exists there,
maybe the next thing to try is to drop back to PAR.HEX V1.10? PAR.EXE 1.30
might run on top of PAR.HEX 1.10 (I'm guessing).
I'll download 1.30b and (wince) give it a try. (We who are about to die
salute you).
>>Are you on a Novell network?<<
No, we're using Windows for Workgroups, but its generally disabled when PAR is
active.
Let me know what you find out and I'll see if the bug comes up on my system.
Cal