New post
0

Hiero ShotgunTranscodeExporter error

Avatar
Bruno Guerreiro
None
Follow

Hi support team

 

I have been trying to adopt Hiero <-> Shotgun in the studio.

I follow this tutorial https://www.youtube.com/watch?v=R2MKdS1J8rg

But i can get the Shotgun Transcode Exporter to work correctly. Whenever i export using Shotgun Shot Processor i get an error on the last step of the exportation (as you can see in the attached image) basically saying: Nuke Errors: [11:21.03] ERROR: Write1: Couldn't open file

I am running windows 7 64 with Hiero 1.7v3

Would it be possible to get some more info on the subject?

 

Thank you 

 

Bruno

 

 

 




shotgun_hiero_trasnscode_exporter_error.jpg
Date Votes

7 comments

  • 0
    Avatar
    Rob Blau

    Hi Bruno, lets see if we can figure out what is going on.

    There is a setting on the transcode task that lets you keep the nuke script that is doing the transcode.  By looking at that script we should be able to see what is happening.  With that setting turned on, you should find a nuke script in the directory that the output media is being written to.  Could you check that setting and send on the resulting script?

    Export.png

     

    It would also be useful to see the full error rather than just the tooltip.  That should be in the script editor, which you can turn on or click the eye to let Hiero take you there.  Could you copy the contents of the script editor and send that on?

    Hiero.png

     

    Note that this is a public forum, so if there is content that you want to keep private, you can open a support ticket at toolkitsupport@shotgunsoftware.com and attach those files to that ticket.  If you do that, then we'll make sure to bring the answer back to this topic in case anybody else runs into the same problem.

  • 0
    Avatar
    Bruno Guerreiro

    Thank you Rob,

    Sorry for the previous rushed email, it was will based on a test project which i have no problem sharing, never the less thanks for the side note.

    One thing that i noticed right when i open the script editor tab is that there is already a few errors logged in, here is what i had:


    ERROR: Plugin C:/Users/user.COMPANY/.hiero\Python\StartupUI\NukeShotExporterUI_withShotBin.py could not be loaded: 'module' object has no attribute 'debug'

    Traceback (most recent call last):

    File "C:/Program Files/The Foundry/Hiero1.7v3/Plugins/site-packages\hiero\core\find_plugins.py", line 42, in loadPluginsFromFolder

    module = imp.load_source( moduleName, p )

    File "C:/Users/user.COMPANY/.hiero\Python\StartupUI\NukeShotExporterUI_withShotBin.py", line 9, in <module>

    import NukeShotExporter_withShotBin

    File "C:/Users/user.COMPANY/.hiero\Python\StartupUI\NukeShotExporter_withShotBin.py", line 351, in <module>

    hiero.core.debug( "Registering NukeShotExporter_withShotBin" )

    AttributeError: 'module' object has no attribute 'debug'

    ERROR: Plugin C:/Users/user.COMPANY/.hiero\Python\StartupUI\NukeShotExporter_withShotBin.py could not be loaded: 'module' object has no attribute 'debug'

    Traceback (most recent call last):

    File "C:/Program Files/The Foundry/Hiero1.7v3/Plugins/site-packages\hiero\core\find_plugins.py", line 42, in loadPluginsFromFolder

    module = imp.load_source( moduleName, p )

    File "C:/Users/user.COMPANY/.hiero\Python\StartupUI\NukeShotExporter_withShotBin.py", line 351, in <module>

    hiero.core.debug( "Registering NukeShotExporter_withShotBin" )

    AttributeError: 'module' object has no attribute 'debug'

     

    I feel that this is the source if the problem.

    Never the less i runned the  ShotgunTranscodeExporter and attached the nuke script that was created with it.

    On the same folder where the .nk script was there was a .log file with this info:

    HieroNuke 7.0v8, 64 bit, built Jun 7 2013.
    Copyright (c) 2013 The Foundry Visionmongers Ltd. All Rights Reserved.
    [ 9:40.03] ERROR: Write1: Couldn't open file

    Writing Z:/Projects/test_hiero3/sequences/Sequence1/VP_BB/editorial/2014_06_06/plates/HieroTest3_v002_VP_BB.mov took 0.04 seconds
    Total render time: 0.04 seconds
    Write1: Couldn't open file

     

    I open the nuke script and although it was reading correctly the source (an image sequence), the write node was not properly working.

    Whenever i pressed the render on the write node it would say that it was rendering but no .mov file would be outputted in the specified folder. 

    I did change the export format to .jpeg sequence and it did export correctly.

     

    Any feedback on this will be much appreciated

     

    All the best

     

    Bruno

     

     

  • 0
    Avatar
    Rob Blau

    Hey there Bruno,

    I think that error may be a red herring.  The hiero logging methods used to be named things like hiero.core.debug, but now are called things like hiero.core.log.debug (note the new log part of the path).  Probably you just have some old code in your .hiero directory from some previous hiero work you've done.

    If you open the script, then save it, and open the saved one, does the write node from the re-saved script behave itself better?  Or if you adjust the settings in hiero for the transcode task that is generating the mov file, does it behave better?

    If so, then the default values we're using for the quicktime output don't seem to be working for you.  You can take a look at the settings from a working nuke script, and have them be the default values by overriding the get_quicktime_settings hook.  The current default looks like:

    file_type = "mov"
properties = {
    "codec": "avc1\tH.264",
    "quality": 3,
    "settingsString": "H.264, High Quality",
    "keyframerate": 1,
}

    You could update that hook to get the settings you want (and you'd need to click the button to reset the preset defaults to pick up the change), which you can find by looking at the knob settings on the Write node from the script that results from a successful transcode.  If any of that works out, it would be great to know what settings you end up going with to see if our default needs to be smarter.

    Does that make sense?

  • 0
    Avatar
    Bruno Guerreiro

    Hi Rob,

    This one was a hard one to fix. And even after we got it to work i am not completely sure what was the exact problem. However i will share what was not, and what was it related to.

    After some troubleshooting it became clear that Nuke was not able to write .mov files to our Z: drive, but it was able to do it in the other 2 main network drives drives we normally use. 

    The difference between the Z: drive and the other ones was  that the Z: drive was just a network shared folder that was mapped in each windows machine as Z (something that looks like this in the network \\folder\where_projects_and_software_is), the other network drives are mapped at logon by a script running on our windows 2012 server...

    What we ended up doing was re-install Toolkit and directing all the action to one of the drives that nuke was able to write .mov files.

    According to our IT guy QuickTime does not like windows 64 that much(who does?...), and as for writing QT files goes it does seem to have some problems dealing with network directories that live inside of \\ . That or it was an issue related to administrator privileges. Or both.

    Thanks for the support

    All the best

     

    Bruno

     

     

     

     

  • 0
    Avatar
    Rob Blau

    Hi Bruno, thanks for the update!
    I'm glad that you guys figured out a solution (and that you shared it with everybody else).

  • 0
    Avatar
    KP

    It turns out, this is a long-standing bug in Quicktime for Windows. Rendering to any other drive letter aside from the first drive letter listed in your system will fail. The current workaround for this are to use the primary drive on your system or, more likely, use UNC paths. If you switch your local storage root from using a drive letter to a UNC path, as long as the location is the same for both, your previous data and links in Shotgun Toolkit should still work.

  • 0
    Avatar
    Patrick Macdonald

    Hi KP,

    Is this QT bug still the case? Does this mean that mapped drives are effectively out of the question if we need to render quicktimes? 

    Thanks

    Patrick

Please sign in to leave a comment.