This feature is ok but I want to be able to click on the task in the job and view the output of that specific task live.
I would rather not have to look at which node is rendering and then have to go to the slave list, etc.
From my (end user!) pov, I’d love to have those steps handled by the UI so that I can check stdout/stderr.
It would be interesting to have a pane for that in case someone really likes watching output 
rob
Added to the todo list!
We won’t be able to add it as a panel though, since it’s actually a separate process. The reasoning for this is that you could have multiple slave windows open without impacting the Monitor’s performance, or each other’s.
Cheers,
Sounds like a reasonable compromise.
thanks!
Also is there a way to see the output history? It’s nice to see a live-stream but I often want to see the full task’s output not just what has happened after opening the viewer.
Oh it doesn’t do that? Yes of course it will need to show all the stdout
ha!
No, there isn’t a way to see the output history. The slave itself doesn’t keep a history. It just flushes it to the window/console and to disk when the lines come in. We were thinking of keeping a buffer so that when you connect, you get a bit of history.
When viewing live stdout from a node, I always want to see how the render started and where the problem occurred.
This issue is something that I would love to see resolved. Renders fail. Being able to check the stdout easily while the render is going is crucial for some tasks that don’t have percentage runs, like random python scripts, etc.
If the task fails, you’ll still be able to view the log in its entirety from the Monitor. The remote log window itself is capped at 5000 lines (just like the slave’s log window), so there is never a guarantee that you could see the task from its beginning. This is done for memory and performance reasons. The slave flushes the task logs to disk, which is why you can view the entire log from the Monitor after it is saved. Note that the log is kept locally on the slave until it finishes, which is why you can’t view it from the monitor until it has been copied to the repository after the task completes/fails. Again, this is to cut down on network bandwidth.
By adding a buffer, you’ll be able to see the last 2000 characters that the slave printed out before you connected to it, and then you’ll have a live stream of everything after. That should be reasonable enough in many cases.