PAR backup?
32 messages in this thread
Has anyone had any luck backing up a PC-based PAR card to tape? If so, what are
you using?
I have tried several QIC-80 and DAT tape solutions and I have yet to find one
that will backup and RESTORE. In all cases the system APPEARED to be backing
up, but the files did not restore correctly.
Any suggestions would be appreciated!
Cal Haines, 70305,3153
I use my PAR drive's full capacity for most projects now. I do lots of slomo
and special effects as well as animation from 3DS and Elastic Reality.
Because of this I generally backup first to my DOS drive as the disk
gets full. I later backup to the QIC-80 tape for archive purposes
after the client pays the bill. When I've ever had to restore to do
some video editing with these files, I have not had any problem
restoring to the dos drive first, then I port the *.ani file to the
PAR drive using the PAR.exe import feature. I have never had a
problem. I have been doing this since the first week I owned the PAR.
I gather most problems people are having with the PAR drive is that
they think of it as a common dos drive. It is not a common dos
drive! If you start thinking of it as an animation playback tool
that requires special software to operate you will probably have
fewer problems. I've heard many horror stories about the PAR,
including people using Norton utilities, FDISK etc. crazy!
How come you have no problems with backups???
I have had problems with all files larger then about 1000 frames.
When copying those to a DOS harddrive, and then restoring them by copying them
back on the PAR they are lost from a certain frame on mostly nearing the 900
???
BTW I'm not the only one with this problem.
Christophe
re: No problems with [PAR] backups???
I have certainly done a successful backup of a file that was over 1000 but I
can't remember if it was in pieces or not. I will check and get back to you.
One possibility is that I was using version 1.09 or 1.10 PAR drivers. I have
since gone back to 1.10 from 1.27 – at least I know what most of the problems
with 1.10 are! I should mention that the backup method mentioned above was the
tried and true copy to DOS, backup DOS, restore DOS, copy to PAR method.
Cal Haines, 70302,3153
I certainly think this is not a problem DPS should ignore, otherwise the PAR is
working great but this is to me a MAJOR problem, and it costs time to me, I
just happen to need longer animations I'm not just in the short animation
business like logo fly ins.
I have not yet checked if with the most recent software I installed 1 week ago
the delete project problem had gone
Do.,
<< then I port the *.ani file to the PAR drive using the PAR.exe import
feature.>>
Do you save your files as .tga's and then re-import them.. or are you saving
them as the compressed .ani files. I also am expieriencing this corruption of
frame around the 900 frame point of a 2250 frame animation. I never have a
problem if I save the files as .tga's to my dos drive and tape…but as .ani
files when i copy them back to the par drive they are corrupted…
And I have tries this with the new as of today 1.34b PAR software…
Optimize works much better as an IPAS than PAR routine…:<)
Kurt and others:
I STAND CORRECTED!
After hearing all those having problems it was pointed out that the problem
occurs after around frame 900. I did 5 animations at 900, 1000, 1500, 2000 and
2500 frames. This took most of the evening because as you know transfers are
slow. I just dropped them to my dos drive and back again using my usual
procedure. All 5 animations switched to black frames for the remainder at
frame #896 or 897 frames into the animation. BTW, I did this restore to a
freshly formated PAR drive and to a freshly defragged DOS drive. The number
896 appears to be significant and should be of some use to DPS is defining and
correcting this problem.
Fortunately, I do not have a problem here with backups because I have never had
to archive a "client" animation longer than 750 frames except for two. I guess
they are gone! The only time I do animation on the PAR longer than 900 frames
is for frame grabs and other similar temporary work not worth archiving. I do
recall restoring, last April, a file of 30 second animation and don't recall
any problems. I was using ver 1.25 at that time.
Solution/work around.: I will split all my future animations to less than 500
frames or so before exporting. Slight inconvenience but as I said I seldom
have to do this.
Alan and Martin, can you confirm this too?
Truthfully, Don, I found the newer software pretty buggy, so with Brick going
to Europe for a while, I just went back to the older stuff.
I'm not sure if the version I am using (1.27b) has the problem you describe, as
I've been "backing up" animations to BetaSP tape instead of digitally saving
them. If I get a chance, I'll try it and let you know.
-Alan
Buggy? Actually I have had very little problem with 1.30b. The del project
and now this > 896 frame backup problem. The manner in which I use the PAR
drive, these problems don't usually surface here. I really had to do a test to
see if i could duplicate Christophe's and other's complaint.
Don,
I haven't had any animations >=896 frames yet. Maybe that's why I haven't seen
a problem.
Yes, most (except for two) have been smaller too. When I heard of the problem
was related to the larger file size I created some larger files using the join
feature just to test what Christophe was complaining about. Even in a 900
frame ani the last three frames were black after restore. How about that?
Don,
I guess I'll give it a test, but it sounds like it's universal. Has it been
fixed in 1.34b? I don't have that yet.
Neither do I as I'm a little busy right now to do any PAR experimentation.
Cool, Don. I think I'll install it now!<g>
Seriously, I thought I had heard alot about file/project/directory/joining/etc
problems with that rev. If it's running well for you, then I think I will go
ahead and try it out.
-Alan
Well, if you do be very careful about deleting any project directories. I like
the new software because it works very well for me in DOS file selection and
the GPI trigger arm is up front. These are the two main reasons I will
continue with it. I also use some of the new time lapse features.
Hi Don,
I can confirm the frame number 896 being the last good frame when restoring
ani files to the PAR. I had a project last week that I had this problem
with…..well, it wasn't really a problem, I also had the individual .tga files
to rebuild it.
Later,
-Jeff
Don I can confirm that it happens at frames 896 or 897 always same for PAL
version as NTSC version, this is a significant frame.
Christophe
I have just purchased a PAR but cannot work out how on earth to network render
to it using 3D Studio R4.
I am currently network rendering to my standard Hard disk in the server (the
PAR is in there also)
Any help appreciated as the local distributer in Australia doesn't have a clue
thanks….
Sorry but I have no experience on this I have no network currently although
that might change soon.
Better to ask Greg Pyros, or Gus Grubba. I believe they have an IPAS routine
that dumps all TGA's straight to the PAR in while rendering in network. I do
not know if you can do this without this utility???
Christophe
Christophe:
>> I do not know if you can do this without this utility???
No, you cannot!
Greg Pyros
Stuart:
There is no way to network render to the PAR. If you think about it, every
machine finishes rendering independently, so there would be no way to make sure
that frame 0001 was finished before frame 0002 and copied over.
This is why we developed NDUMP.IXP (NetworkDumper). It intelligently checks to
see what files are rendered and copies them out to the PAR (or any other
device) in order, and optionally deletes them from your network if you desire.
MSRP = $195.
Feel free to contact me if you have any other questions!
Greg Pyros
Stuart:
You need to contact Greg Pyros and get a product called NDUMP.ixp. It runs in
video post and will, through a batch file, take the rendered tga's as they come
in from the slaves and move them in order (and this is the secret) to the PAR.
Then, at your option the tga's can be deleted from the dos directory as part of
the function of the batch file. The IXP and a sample batch file are what the
product consists of. Also, in order to work the PAR must be resident on your
machine that started the rendering and is running VP. ie. it cannot be
resident on a dedicated server. There is a product that Greg has that is
supposed to work on servers but I haven't tested it. It is a dos version of
NDUMP. I don't use a dedicated server.
This is how you must do it but be forewarned that NDUMP will only move tga's
from the workstation with 3DS running to the PAR. If you need to render where
you use rotoscoped files for animated maps from the PAR then it won't work.
You will have to move the maps ani's to the dos drive as sequential tga's to
work with them while using a network. For the past 3 months I've been working
with lots of this kind of stuff so my network rendering has been slowed to a
single mackine for awhile. I could sure use a bidirectional NDUMP but I've
been told by Greg that this is too difficult a task to do.
This problem has been there I believe since the beginning exporting ANI. files
corrupts them, you can not backup ani files larger then about 1000 frames.
I hope they solve this problem soon because it is eating away my harddisk
space
>>I hope they solve this problem soon because it is eating away my harddisk
space
As we said before, just split the ani file into safe frame counts and then back
them up. I also hope DPS gets this fixed so I won't have to worry about it
when I need to restore > 896 frame ani file.
<<I also hope DPS gets this fixed …>>
DPS assures me that there are no PAR problems with backup. Only buggy backup
software and incompetent users. THEIR software is THOROUGHLY tested INTERNALLY
before they put upload it.
So, I asked them the stupid question: What backup software/hardware do you
use. MUCH to my SUPRISE, they reply that they don't have any files that are
important enough to back up, so they don't do back ups. So much for THOROUGH
INTERNAL testing! This would also tend to explain why there are so many
problems with backup!
Unlike DPS, I have PAR files that ARE important… but then, I'm just a stupid
user, not an Amiga Wizard.
Cal Haines, 70302,3153
Cal,
First off you may be surprised to find that we don't use the Amiga for
ANYTHING except copying floppies, and some troubleshooting. We use Adpatecs
backup software that comes with thier SCSI controller boards. (EZ-Backup). We
think that we have found a situation that may cause backup and restore problems
on some machine configurations, basically a memory problem. We are looking
into it and hope to have a fix soon.
Brick
Brick,
Hope you get into this problem as fast as possible. It is annoying, I haven't
been able to backup or copy ani's larger then about 1000 frames back without
this problem they all get corrupted after 896.
Christophe
<< I never have a problem if I save the files as .tga's to my dos drive and
tape>>
Are you exporting a PAR .ANI file from PAR to DOS, then backing up and later
restoring? I have experienced noticable degradation of image quality when I
copy a file from PAR to DOS and back as a .TGA since the PAR compression method
is not lossless.
Cal Haines, 70302,3153
Don and all,
I am not sure if you have read my message's about these backup/restore
problems. I also split my ANI-files into 500 segments.
But it is not always the 896-problem. I did a backup/restore directly
to my tapeunit of a 4752 framefile. No problem what so ever.
But doing a compare gives me the message "files are different" When i
go step by step, i notice some strange looking frames, which hardly
can be seen when you play the animation. When i remove this/these
frames and backup/restore again there are no problems. But when i
restore from tape the ANI-files with the "bad frames"in it. The file
is corrupted from this "bad-frame" to the end of the file.
Another thing i noticed. When i backed up/compared files to tape i
got the "files are different" message. Then i split them an joined
them again to my slavedrive. When i did a backup/compare of that
joined file everything was ok.
In short, i cannot get the exakt clue of the problem, but maybe the
DPS-people can. And this is of some help for them ?!
Theo,
so far every problem I had also corrupted at that frame, I haven't had any good
backup of ani's larger then about 1000 frames
<<
<<doing a compare gives me the message "files are different">>
I did a little test using DOS. I found that if I copy a .ANI file from DOS to
PAR, then do a DOS FC file compare, there are compare errors in about 5 bytes,
30 bytes into the file.
If I then copy the file from PAR back to DOS and compare, the files compare
without error. The new file on the DOS drive differs from the origional in the
same 5 or so bytes mentioned.
I also noted that the file name is stored in the first few bytes of an
ANI file, so two IDENTICAL files with different PAR names will not compare.
What's interesting is that you can duplicate a .ANI file on the PAR drive, copy
the origional file from PAR to DOS and get a valid compare with both the
origional and duplicate PAR file and the DOS copy.
Cal Haines, 70302,3153
I agree that copying files to a DOS drive and backup up from there works just
fine. The problem is that it takes a lot of manual steps if you want to back
up an entier 1.6G PAR drive, especially if you don't have enough space on your
DOS drive to do it all at once. Also, QIC-80 drives don't hold enough to make
frequent backups very attractive (too much tape swapping). I usually use DOS to
move the .ANI files back and forth by means of a batch file. What I am looking
for is a SIMPLE solution that lets me backup and restore the entire PAR drive
with no manual steps. This would make it easier to switch from one major
project to another. Thanks for your help!