Welcome to our community

Be a part of something great, join today!

Log in
  • Hey all, just changed over the backend after 15 years I figured time to give it a bit of an update, its probably gonna be a bit weird for most of you and i am sure there is a few bugs to work out but it should kinda work the same as before... hopefully :)

redrushes hangs

I

Irri

Banned
Joined
Mar 29, 2007
Messages
499
Reaction score
0
Points
0
I have a problem using redrushes. The interface stops updating (showing the render progress), but is still responsive. The redlines continue to work for some time then drop 0% CPU and never close the file. So I have lots of unrendered files.

I have tried on a few machines and they all do the same thing.
Latest version of RedAlert, MacPro 8 core, running off a SAN.

Any thoughts?
 
How far does it render?

Can you check activity monitor to see what the REDline is doing?
 
I see this problem only in three scenarios:

1. Too many inputs in your batch.
2. Rendering to a HDD in Fat32 with the 2 Gb. limitation.
3. Trying to add more files when the render is working

Any other scenario I work fine with Rushes. As fine as a Beta version can work... :unsure:
 
  • Thread starter
  • Banned
  • #4
Deanan said:
How far does it render?

Can you check activity monitor to see what the REDline is doing?
Click to expand...

Sometimes it will get through a few clips, sometime it will hang before it has finished any.

I use top for monitoring. There are usually 4 instances of redline running at quite high percentages then they drop to 0% CPU without completing the render.

There were about 30 long clips in the batch.
HD is a SAN made of HFS disks
I never tried to add more files.
 
  • Thread starter
  • Banned
  • #5
This seems to be SAN related as I have just run RedRushes on a local drive for hours with no problems. What is strange is that I ran two instances of RedCine for 17 hours yesterday on the SAN with no problems. Is there any major difference in the way RedCine and RedRushes work?
 
Irri said:
There were about 30 long clips in the batch.
HD is a SAN made of HFS disks
I never tried to add more files.
Click to expand...

We found an issue with the way OSX was dealing with long clips. This is fixed in the next release.
 
Deanan said:
We found an issue with the way OSX was dealing with long clips. This is fixed in the next release.
Click to expand...

Great!!
Thanks RTeam!!
Deanan, with B17 and 4k HD shooting Rushes speed up the scale to 1080?? anybody??
 
vico said:
Great!!
Thanks RTeam!!
Deanan, with B17 and 4k HD shooting Rushes speed up the scale to 1080?? anybody??
Click to expand...

Yes, because 4K HD is four times HD, when you do a half res debayer, you go straight to 1920x1080. This is faster because you don't have to do an additional scale to fit the image into 1920x1080.
 
  • Thread starter
  • Banned
  • #9
Deanan said:
We found an issue with the way OSX was dealing with long clips. This is fixed in the next release.
Click to expand...

Thanks. Interesting, but confusing as the clips that wouldn't render on the SAN are now rendering fine on a local RAID. I wonder which is causing the problem.
 
Irri said:
Thanks. Interesting, but confusing as the clips that wouldn't render on the SAN are now rendering fine on a local RAID. I wonder which is causing the problem.
Click to expand...

Can you try outputting a script from RR and running a the command driectly in the terminal?

The issue that was fixed was related to changes apple made regarding soe filesystems when they went from tiger to leopard.
 
Oh, in my case, I have no problem rendering to metaSAN with all the latest software versions.
 
I'll try running the RR from the command line and report back.

Ours is a metaSAN too, so it's nice to know yours is working.
 
You must log in or register to reply here.
Back
Top