From: Abraham Schneider <aschneider@(email surpressed)>
Subject: Problems with submit scripts after 102.42a6 update
   Date: Wed, 28 Jun 2006 10:30:54 -0400

Hi!

/
/
/
/
/
/

Thanks, Abraham

--
Abraham Schneider
VFX Compositor

ARRI Film & TV Services GmbH
Tuerkenstr. 89
D-80799 Muenchen

Phone: +49 89 3809-1269
Mobile: +49 173 5719842
Email: aschneider@(email surpressed)

Abraham Schneider wrote:

But the problem now is: after the update the "browse" function does not work properly. For example: if I go to / in the browse window it shows me a list like this:

/
/
/
/
/
/

instead of showing me the correct content of the folder. So I can't use the browse function and have to insert the path manually.

	Hmm, I've seen this once before with the file browser.

	What OS is the machine you're running the submit-submit GUI on,
	and what kind of file server (linux/osx/windows? 32bit or 64bit?)

--
Greg Ercolano, erco@(email surpressed)
Rush Render Queue, http://seriss.com/rush/
Tel: (Tel# suppressed)
Cel: (Tel# suppressed)
Fax: (Tel# suppressed)(new)

** NOTE:
**	I will be on vacation July 11th through July 20th.
**	During that time, orders and email response may take over 24 hours.
**

Abraham

Greg Ercolano schrieb:

[posted to rush.general]

Abraham Schneider wrote:

But the problem now is: after the update the "browse" function does not work properly. For example: if I go to / in the browse window it shows me a list like this:

/
/
/
/
/
/

instead of showing me the correct content of the folder. So I can't use the browse function and have to insert the path manually.

    Hmm, I've seen this once before with the file browser.

    What OS is the machine you're running the submit-submit GUI on,
    and what kind of file server (linux/osx/windows? 32bit or 64bit?)

--
Abraham Schneider
VFX Compositor

ARRI Film & TV Services GmbH
Tuerkenstr. 89
D-80799 Muenchen

Phone: +49 89 3809-1269
Mobile: +49 173 5719842
Email: aschneider@(email surpressed)

Sorry, mistyping: "... before the update" was meant!

Abraham


Abraham Schneider schrieb:

[posted to rush.general]

The machines are 32bit linux workstations and the server also has a 32bit linux.

Strange thing is: it worked fine with the same configuration before the setup!

Abraham

Greg Ercolano schrieb:

[posted to rush.general]

Abraham Schneider wrote:

But the problem now is: after the update the "browse" function does not work properly. For example: if I go to / in the browse window it shows me a list like this:

/
/
/
/
/
/

instead of showing me the correct content of the folder. So I can't use the browse function and have to insert the path manually.

    Hmm, I've seen this once before with the file browser.

    What OS is the machine you're running the submit-submit GUI on,
    and what kind of file server (linux/osx/windows? 32bit or 64bit?)

--
Abraham Schneider
VFX Compositor

ARRI Film & TV Services GmbH
Tuerkenstr. 89
D-80799 Muenchen

Phone: +49 89 3809-1269
Mobile: +49 173 5719842
Email: aschneider@(email surpressed)

Abraham Schneider wrote:

[posted to rush.general]

The machines are 32bit linux workstations and the server also has a 32bit linux.

Strange thing is: it worked fine with the same configuration before the setup!

	I'm guessing if you rename out the current /usr/local/rush/examples/bin/input
	program, and copy in the old one in its place, your scripts will still work.

	Thing is I can't replicate this on any of my machines (Fedora3 and Redhat9)
	with 102.42a6.

	Need more details: what distro?


--
Greg Ercolano, erco@(email surpressed)
Rush Render Queue, http://seriss.com/rush/
Tel: (Tel# suppressed)
Cel: (Tel# suppressed)
Fax: (Tel# suppressed)(new)

Workstations:

Any ideas?

Abraham

Greg Ercolano schrieb:

[posted to rush.general]

Abraham Schneider wrote:

[posted to rush.general]

The machines are 32bit linux workstations and the server also has a 32bit linux.

Strange thing is: it worked fine with the same configuration before the setup!

I'm guessing if you rename out the current /usr/local/rush/examples/bin/input program, and copy in the old one in its place, your scripts will still work.

Thing is I can't replicate this on any of my machines (Fedora3 and Redhat9)

    with 102.42a6.

    Need more details: what distro?

--
Abraham Schneider
VFX Compositor

ARRI Film & TV Services GmbH
Tuerkenstr. 89
D-80799 Muenchen

Phone: +49 89 3809-1269
Mobile: +49 173 5719842
Email: aschneider@(email surpressed)

ok, checked some more stuff with our admin:

        libstdc++.so.6 => not found
        libm.so.6 => /lib/i686/libm.so.6 (0x40028000)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x4004a000)
        libc.so.6 => /lib/i686/libc.so.6 (0x40052000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

Abraham


Greg Ercolano schrieb:

[posted to rush.general]

Abraham Schneider wrote:

[posted to rush.general]

The machines are 32bit linux workstations and the server also has a 32bit linux.

Strange thing is: it worked fine with the same configuration before the setup!

I'm guessing if you rename out the current /usr/local/rush/examples/bin/input program, and copy in the old one in its place, your scripts will still work.

Thing is I can't replicate this on any of my machines (Fedora3 and Redhat9)

    with 102.42a6.

    Need more details: what distro?

--
Abraham Schneider
VFX Compositor

ARRI Film & TV Services GmbH
Tuerkenstr. 89
D-80799 Muenchen

Phone: +49 89 3809-1269
Mobile: +49 173 5719842
Email: aschneider@(email surpressed)

Abraham Schneider wrote:

[posted to rush.general]

ok, checked some more stuff with our admin:

your redhat9-package won't run on our redhat9! If I do a 'ldd rushd' on this version I get:

        libstdc++.so.6 => not found
        libm.so.6 => /lib/i686/libm.so.6 (0x40028000)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x4004a000)
        libc.so.6 => /lib/i686/libc.so.6 (0x40052000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

we don't have libstdc++.so.6 on our machines but libstdc++.so.5. Is this a different problem or do they belong together?

	I went through this recently with a customer over the weekend;
	there have been subtle changes in the kernel/library releases
	that caused me to have to make separate redhat9 vs. fedora3 releases.

	Can you double check the fedora3 vs redhat9 tar file
	from the download page:
	http://seriss.com/rush/releases/Readme-102.42a6.html

	(Your admin should have the user/password for that page.
	Do not share/request password info here on the group.)

	The redhat9 on that page was built on redhat9, the fedora3
	was built on fedora3.

--
Greg Ercolano, erco@(email surpressed)
Rush Render Queue, http://seriss.com/rush/
Tel: (Tel# suppressed)
Cel: (Tel# suppressed)
Fax: (Tel# suppressed)(new)

** NOTE:
**	I will be on vacation July 11th through July 20th.
**	During that time, orders and email response may take over 24 hours.
**

Hi again!

Abraham

Greg Ercolano schrieb:

[posted to rush.general]

Abraham Schneider wrote:

[posted to rush.general]

ok, checked some more stuff with our admin:

your redhat9-package won't run on our redhat9! If I do a 'ldd rushd' on this version I get:

        libstdc++.so.6 => not found
        libm.so.6 => /lib/i686/libm.so.6 (0x40028000)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x4004a000)
        libc.so.6 => /lib/i686/libc.so.6 (0x40052000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

we don't have libstdc++.so.6 on our machines but libstdc++.so.5. Is this a different problem or do they belong together?

    I went through this recently with a customer over the weekend;
    there have been subtle changes in the kernel/library releases
    that caused me to have to make separate redhat9 vs. fedora3 releases.

    Can you double check the fedora3 vs redhat9 tar file
    from the download page:
    http://seriss.com/rush/releases/Readme-102.42a6.html

    (Your admin should have the user/password for that page.
    Do not share/request password info here on the group.)

    The redhat9 on that page was built on redhat9, the fedora3
    was built on fedora3.

--
Abraham Schneider
VFX Compositor

ARRI Film & TV Services GmbH
Tuerkenstr. 89
D-80799 Muenchen

Phone: +49 89 3809-1269
Mobile: +49 173 5719842
Email: aschneider@(email surpressed)

Abraham Schneider wrote:

[posted to rush.general]

Hi again!

My previous test already was with the redhat9 version. But I tested it again and also with the fedora3 version. I get the same "libstdc++.so.6 => not found" error with both versions!

	Please re-check the redhat9 version from the website,
	ie. download it again. It was updated over the weekend.

--
Greg Ercolano, erco@(email surpressed)
Rush Render Queue, http://seriss.com/rush/
Tel: (Tel# suppressed)
Cel: (Tel# suppressed)
Fax: (Tel# suppressed)(new)

** NOTE:
**	I will be on vacation July 11th through July 20th.
**	During that time, orders and email response may take over 24 hours.
**

Thanks, Abraham


Greg Ercolano schrieb:

[posted to rush.general]

Abraham Schneider wrote:

[posted to rush.general]

Hi again!

My previous test already was with the redhat9 version. But I tested it again and also with the fedora3 version. I get the same "libstdc++.so.6 => not found" error with both versions!

    Please re-check the redhat9 version from the website,
    ie. download it again. It was updated over the weekend.

--
Abraham Schneider
VFX Compositor

ARRI Film & TV Services GmbH
Tuerkenstr. 89
D-80799 Muenchen

Phone: +49 89 3809-1269
Mobile: +49 173 5719842
Email: aschneider@(email surpressed)

Ok, I can answer that to myself :)

Thanks for your help, Abraham


Abraham Schneider schrieb:

[posted to rush.general]

Ok, sorry, you're right. Works fine with the newly downloaded version. So we will install this.

Do you think that my browse problem will be solved with this version or is it something completely different?

Thanks, Abraham


Greg Ercolano schrieb:

[posted to rush.general]

Abraham Schneider wrote:

[posted to rush.general]

Hi again!

My previous test already was with the redhat9 version. But I tested it again and also with the fedora3 version. I get the same "libstdc++.so.6 => not found" error with both versions!

    Please re-check the redhat9 version from the website,
    ie. download it again. It was updated over the weekend.

--
Abraham Schneider
VFX Compositor

ARRI Film & TV Services GmbH
Tuerkenstr. 89
D-80799 Muenchen

Phone: +49 89 3809-1269
Mobile: +49 173 5719842
Email: aschneider@(email surpressed)

Abraham Schneider wrote:

Ok, I can answer that to myself :)

We just installed this updated redhat9 version and now the browsing works fine! Maybe that helps to avoid this problem for the future.

	Yes, updating the page last weekend seemed to solve the problem,
	so hopefully no one should run into this.

	I've also fixed up the download page so that it's more clear
	about which tar files go with which linux distro:

 Redhat6 - Redhat8: rush-102.42a6-redhat6.tar.gz -- OLD releases only
 Redhat9 - Fedora2: rush-102.42a6-redhat9.tar.gz -- includes RHEL1-2
 Fedora3 - Fedora5: rush-102.42a6-fedora3.tar.gz -- includes RHEL3-5 and up

	That should clear things up a bit, I hope.

--
Greg Ercolano, erco@(email surpressed)
Rush Render Queue, http://seriss.com/rush/
Tel: (Tel# suppressed)
Cel: (Tel# suppressed)
Fax: (Tel# suppressed)(new)

** NOTE:
**	I will be on vacation July 11th through July 20th.
**	During that time, orders and email response may take over 24 hours.
**

Hi greg,

I don't know if this was covered before but the solution is to add

setAttr "defaultRenderGlobals.startFrame"     $opt{sfrm};
setAttr "defaultRenderGlobals.endFrame"       $opt{efrm};

in the mel part of our submit script so it would read like this:

if ( !`pluginInfo -q -l "Mayatomr"` )
    { error("Make sure 'MAYA_PLUG_IN_PATH' set correctly."); }

// Scene file existence check
string \$scene = `file -q -sn`;
if ( size( \$scene ) == 0 )

// Initialize Mayatomr globals
miCreateDefaultNodes();

// Init mray globals
setAttr "mentalrayGlobals.startFrame"     $opt{sfrm};
setAttr "mentalrayGlobals.endFrame"       $opt{efrm};
setAttr "defaultRenderGlobals.startFrame"     $opt{sfrm};
setAttr "defaultRenderGlobals.endFrame"       $opt{efrm};
setAttr "mentalrayGlobals.byFrame"        1;
setAttr "mentalrayGlobals.startExtension" $opt{sfrm};
setAttr "mentalrayGlobals.byExtension"    1;

////                     Tried Mayatomr (-project,-dir).
////
//// // Image dir specified?
//// if ( "$opt{ImageDirectory}" != "-" )
//// {
////     // Force Mayatomr to use our ImageDirectory. -erco 02/09/04

//// }

// Generate .mi file.
if ( "$opt{Debug}" == "off" )
{
    // Use -binary if not debugging.
    Mayatomr -mi -binary -padframe 4 -perframe 2 -xp "1111111111"
             -verbosity 0 -file "$opt{mipath}" $opt{MayatomrFlags};
}
else
{
    // No -binary if debugging.
    Mayatomr -mi -padframe 3 -perframe 2 -xp "1111111111"
             -verbosity 0 -file "$opt{mipath}" $opt{MayatomrFlags};
}

EOF

hope this helps and sorry if it is a repetition.


Luigi Tommaseo
Digital Systems Manager
Senate Visual Effects
Twickenham Film Studios
St.Margarets
Twickenham
Middlesex
TW1 2AW

Tel: (Tel# suppressed)
luigi@(email surpressed)
www.senatevfx.com

On 29 Jun 2006, at 16:28, Greg Ercolano wrote:

[posted to rush.general]

Abraham Schneider wrote:

Ok, I can answer that to myself :)

We just installed this updated redhat9 version and now the browsing works fine! Maybe that helps to avoid this problem for the future.

	Yes, updating the page last weekend seemed to solve the problem,
	so hopefully no one should run into this.

	I've also fixed up the download page so that it's more clear
	about which tar files go with which linux distro:

 Redhat6 - Redhat8: rush-102.42a6-redhat6.tar.gz -- OLD releases only
 Redhat9 - Fedora2: rush-102.42a6-redhat9.tar.gz -- includes RHEL1-2

Fedora3 - Fedora5: rush-102.42a6-fedora3.tar.gz -- includes RHEL3-5 and up

	That should clear things up a bit, I hope.

--
Greg Ercolano, erco@(email surpressed)
Rush Render Queue, http://seriss.com/rush/
Tel: (Tel# suppressed)
Cel: (Tel# suppressed)
Fax: (Tel# suppressed)(new)

** NOTE:
**	I will be on vacation July 11th through July 20th.
**	During that time, orders and email response may take over 24 hours.
**

Luigi Tommaseo wrote:

maya 7 apparently doesn't look at the mentalrayGlobals.startFrame and mentalrayGlobals.endFrame anymore therefore it was generating an mi file for each frame in every single box before passing just 1 mi to mentalray for rendering.

hope this helps and sorry if it is a repetition.

	Right, that's this posting:
	http://seriss.com/cgi-bin/rush/newsgroup-threaded.cgi?-view+1023+1022+1023

	The 102.42a6 upgrade that went out last June has this fix, and others.
	Also, the "submit-maya6" script avoids all that inline mel stuff that
	was typical in the older submit-maya script (which was needed for the
	older releases of Maya.)

	The submit-maya6 script in 102.42a6 is the best script for rendering
	with all versions of maya 6, 7 and up.
	
--
Greg Ercolano, erco@(email surpressed)
Rush Render Queue, http://seriss.com/rush/
Tel: (Tel# suppressed)
Fax: (Tel# suppressed)
Cel: (Tel# suppressed)

Hi,

thanks

Luigi Tommaseo
Digital Systems Manager
Senate Visual Effects
Twickenham Film Studios
St.Margarets
Twickenham
Middlesex
TW1 2AW

Tel: (Tel# suppressed)
luigi@(email surpressed)
www.senatevfx.com

On 4 Aug 2006, at 08:58, Greg Ercolano wrote:

[posted to rush.general]

Luigi Tommaseo wrote:

maya 7 apparently doesn't look at the mentalrayGlobals.startFrame and mentalrayGlobals.endFrame anymore therefore it was generating an mi file for each frame in every single box before passing just 1 mi to mentalray for rendering.

hope this helps and sorry if it is a repetition.

	Right, that's this posting:

http://seriss.com/cgi-bin/rush/newsgroup-threaded.cgi?-view+1023 +1022+1023

The 102.42a6 upgrade that went out last June has this fix, and others.

	Also, the "submit-maya6" script avoids all that inline mel stuff that
	was typical in the older submit-maya script (which was needed for the
	older releases of Maya.)

	The submit-maya6 script in 102.42a6 is the best script for rendering
	with all versions of maya 6, 7 and up.
	
--
Greg Ercolano, erco@(email surpressed)
Rush Render Queue, http://seriss.com/rush/
Tel: (Tel# suppressed)
Fax: (Tel# suppressed)
Cel: (Tel# suppressed)

Abraham Schneider wrote:

[posted to rush.general]

Ok, sorry, you're right. Works fine with the newly downloaded version. So we will install this.

Do you think that my browse problem will be solved with this version or is it something completely different?

	That should solve the browse problem.

	It sounds like you had the 6.1 binaries running on redhat9,
	which is just a little too old to run reliably, and was probably
	causing that browse problem.

	64 bit support is new relative to those older distros, so
	the kernel interfaces have had to change a bit to support
	both 32 and 64, that's where a lot of the weirdness has snuck in.

	As the 32/64 bit interfaces have evolved, this will smooth out.

<digression>
	It has definitely been tricky to try to find a path of releasing
	executables that works on as many linux systems as possible,
	without having separate tar distros for each linux release.
	There's so many linux releases now. I've already filled a
	68 CD case with /just/ linux install CDs. Redhat 6.1 all the way
	through Fedora5, some 32bit, some 64bit.

	The problem is, if you go with dynamic executables you run into the
	problem of missing .so files. But if you go with static executables,
	you run into trouble with the library <-> kernel interface.

	In general static compiles run on more platforms (makes larger executables),
	but it doesn't solve all problems, and depending the library interfaces,
	can cause new problems the dynamics don't have.

	The linux distros often don't include .so files for old executables,
	so you're kind of forced to either use static or partially static compiles,
	or go with separate executables for each distro (which is insane IMHO).

	Currently I have 3 separate tar files to cover the linux spectrum:

		linux -- covers redhat 6.1 thru redhat8
		redhat9 -- covers redhat 9 thru fedora2
		fedora3 -- covers fedora3 on up

	For the most part these work on 64bit systems as well, but every
	once in a while, someone's using a special config (like LDAP) where
	the 32bit binaries don't like the 32bit libs included with the 64bit
	boxes, so sometimes I have to run off a special 64bit compile for
	those platforms. :/

</digression>

	

--
Greg Ercolano, erco@(email surpressed)
Rush Render Queue, http://seriss.com/rush/
Tel: (Tel# suppressed)
Cel: (Tel# suppressed)
Fax: (Tel# suppressed)(new)

** NOTE:
**	I will be on vacation July 11th through July 20th.
**	During that time, orders and email response may take over 24 hours.
**