I’d like to request that the storage of job output paths be simplified into a single array. I really don’t understand why the filenames are stored in a separate array from their containing directories, and it makes post-submission updates more awkward than necessary.
Thanks.
Hey Nathan,
The reason we have it separate right now is in the case of some Job/submission types, we know the output directory, but not the output file. Keeping them as separate parallel arrays makes it explicit as to whether a file path is meant to be a file or folder; otherwise it might be hard to tell.
In the future, we could look at changing this to still have separate arrays for output directories and output files, but not have them be ‘matched up’. Changing the way this is stored implies breaking all of our plugins and submitters though, which is really the main reason why it hasn’t been changed.
This is something we can definitely look at as we plan our scheduling re-write for 9.0, since it will involve a lot of these kinds of breaking changes. In the meantime, we can at least look at adding a convenience function to make this less annoying, though… How are you guys changing these post-submission? Mostly through the python API, through REST, or DeadlineCommand?
I find the parallel arrays really help when using the Scripting API, controlling complex 3dsMax/Maya Jigsaw/Tile/Region render jobs or for downstream jobs involving DraftTileAssembler or standard Draft/Quick Draft. Personally, I’d prefer to see them stay as is, but provide a more friendly API//REST/DC wrapper function to get/set this info, as per Jon’s suggestion. ie: an array passed to a single function where we under-the-hood, set the output directory and output filename arrays and conversely, a single function to get all the output directories & filenames as a single array. #justmy2cents
OK, I can sort of buy that. However, not even the Monitor can keep track of which filename is supposed to be combined with which directory all the time.
I’m looking at a job right now with two output paths, and if I use a custom image viewer command to try and open the second one (by right-clicking the task, then going to “View Output → [filename #2] → [my custom command]”, Deadilne throws an error about a file not existing… except the path it’s complaining about is the directory of the second path combined with the filename of the first.
I think a better way of doing this might be having a single array of sub-documents, where each document contains a string value and some kind of an enum value indicating whether it’s a path, directory, or something else, and maybe some room for custom metadata or something.
Either using the Python.NET API (not the REST wrapper “Python API”) or writing directly to the job document. In addition to the clumsiness of having to call two API functions to get everything straightened out, it also leaves the door open for potential race conditions (as opposed to, say, setting two attributes on a Job instance and saving it).
Yeah, I understand that they may be nice for some really specific use-cases, but it would be just as easy to fetch a list of complete paths and split them into file and directory components yourself.
Don’t take this personally, but I’m more interested in trying to improve the flexibility and sanity of the core set of tools than I am in catering that core to things like Jigsaw/Draft/tile assembly that aren’t general-purpose components of Deadline (and as a result, we don’t use). If the foundation is well-designed, building abstractions like that on top of it becomes trivial.
Seems like this one got lost. Should I reiterate the bug with locating output paths in the normal support forum?
Sorry about that, I don’t know how I missed your reply on this – we can definitely address the bug with the output paths getting combined incorrectly when using a custom image viewer. Since we’re planning on doing more frequent bugfix releases with 8.0 (ideally every 2 weeks), you shouldn’t have to wait too long for the fix.
In terms of changing the way we store the paths, this won’t be happening in the 8.X cycle at this point, unfortunately. We do currently have some fairly in-depth refactoring slated for 9.0, so we can definitely have a look at it then 
Hey Nathan,
I actually haven’t been able to reproduce this on my machine on the latest 8.0. Were you seeing this in the latest version of 8.0? Would it be possible for you to get us an archived version of a Job that exhibits this bug? And what are the arguments defined for the custom image viewer that you’re using? I tested using just {FRAME} and {SEQ?} and those seemed to work.
No, this is in 7.2.1.10. We aren’t using 8.0 at all, since that’s a risky move to make in the middle of production, and I’d like to see how many bugs shake out of the release version in the wild.
Just “{FRAME}”.
Oh, gotcha. I just assumed you were referring to 8.0 since this was in the 8.0 forum 
It seems the bug has already been fixed in 8.0; I suspect we fixed it after your initial post and just forgot to update the thread, sorry about that!
Gotcha. Thanks for checking.