Question and Clarification about Queue Manager
I've just heard from SMSupport that there was no update to QM with SR8. The version number 22.214.171.124338 of the Queue Manager bundled with Poser Pro 11 seems to be a complete Furphy. Without actually doing a binary comparison of the Download Manager installed QM 126.96.36.199999 and the Poser bundled QM, it's likely that the only difference is the version bundle information. +6, two-handed Herrings of Redness!
ctrl-shift last edited by
@anomalaus Any update on a resolution to this? I had this working with Mac requests to Windows render queue on an 11.0 build, but with the 11.1 upgrade the Windows queue manager just sits there at 0% progress and will not transfer files over. I've been able to load the queue up locally on the Windows machine, but it does seem to process anything from my Mac. I was thinking that a reinstall of 11.1 would be the next best step.
I'm keeping one workstation's P11Pro on 34338 until I see an update for Queue which matches the build number of Poser Pro.
The master workstation's Queue will only engage the remotes' Queue if the build numbers match.
I'm currently jumping through the hoops to verify that the QM 188.8.131.52510 release restores network queue rendering functionality in my setup. A local queued SuperFly render on the workstation and completed successfully, and after turning off 'Process jobs locally' there, a subsequent render is now being visibly transmitted to the remote QM, also updated to 184.108.40.206510. Progress on the remote QM render has reached 0.3% and all the texture files appear to have been deposited successfully in the Queue Manager temporary items cache.
I queued a third SF render from Poser after turning back on the workstation's local job processing and accept renders from network, but although the scene save file has been created, the Workstation's QM is making no acknowledgement of the third job. Hmmm. Maybe I'll see if a telnet kick to 4418 will engender some response... Nope. The comms showed up in my terminal nettop process, but QM did nothing.
Bouncing the workstation's QM at least shows it's still communicating with Poser, but now it's not showing the job queued remotely, just the two (one completed and one in progress) processing locally...
@anomalaus If feasible, try connecting a server to the router/switch via Cat5+ cable, either by running a cable between them in situ, or temporarily moving a server nearer to the router.
I've never connected mine by wireless, and I wonder if that might be the bottleneck.
Oh, I just caught up with the "...3rd...hammering" thread; so the Cat cable seems to be a solution?
@seachnasaigh no cable was necessary, I'm still using the Wifi Booster's network (to which both the workstation and remote are connected, so the router's firewall rules are probably never evaluated). I have a sneaking suspicion though, that manually forcing through a telnet connection to the 4418 port on the remote, from the workstation has some quantum tunnelling effect ;-). I will have to test that scientifically some other time, after I do some poring over the relevant man pages. The initial, identical render on the remote is still only up to 65% after 10 hours, while the workstation's two queued renders only took 2-2.5 hours each.
The workstation's QM process does seem to have lost sight of the remote render following a restart between the first and second workstation queued renders. Perhaps visibility will be restored when the remote completes its render and attempts to upload it (I assume that's how it works).
@seachnasaigh Oh dear. Now I'm mystified.
From the remote QM log.txt:
04:37:47 AM: Discovery query from 192.168.0.11 (port 4418). 1 Procs available 04:38:00 AM: Discovery query from 192.168.0.11 (port 4418). 1 Procs available 04:38:01 AM: Queue Procs now available: 0 04:38:01 AM: ...adding new Queue entry id 1 04:39:43 AM: Incoming file transfer. 04:39:43 AM: XML file will be /Users/XXXX/Library/Caches/TemporaryItems/Queue Manager/11/2019- 1-10_ 4h35m57s 2.xml 04:39:43 AM: Receiving file: /Users/XXXX/Library/Caches/TemporaryItems/Queue Manager/11/2019- 1-10_ 4h35m57s 2.xml 04:39:44 AM: ...done receiving file. 04:39:44 AM: Receiving file: /Users/XXXX/Library/Caches/TemporaryItems/Queue Manager/11/2019- 1-10_ 4h35m57s 2.objs 04:41:01 AM: ...done receiving file. 04:41:01 AM: Receiving file: /Users/XXXX/Library/Caches/TemporaryItems/Queue Manager/11/Stone-Road.JPG 04:41:01 AM: ...done receiving file. ... 04:42:03 AM: Receiving file: /Users/XXXX/Library/Caches/TemporaryItems/Queue Manager/11/LDStockings_NylonsTr.jpg 04:42:04 AM: ...done receiving file. 04:42:06 AM: Launching FFRender in RunCmd for render ... command line: /Applications/Queue Manager.app/Contents/Resources/FFRender 4415 /Users/XXXX/Library/Caches/TemporaryItems/Queue Manager/11/2019- 1-10_ 4h35m57s 2.xml /Users/XXXX/Library/Caches/TemporaryItems/Queue Manager/11/quRender 1 2.exr /Users/XXXX/Library/Caches/TemporaryItems/Queue Manager/11 05:48:58 PM: Render completed for frame 2. Sending final image... 05:48:58 PM: Starting final image transfer to 192.168.0.11 05:48:58 PM: Sending file: quRender 1 2.exr 05:49:22 PM: File quRender 1 2.exr sent successfully 05:49:22 PM: Done with final image transfer to 192.168.0.11 05:49:22 PM: Final image sent for frame 2 05:49:22 PM: Final image sent successfully for frame 2 05:49:22 PM: Returning Remoted result... 05:49:22 PM: Queue Procs now available: 1 05:49:22 PM: Queue Procs now available: 1
all of the required texture files were present in the remote folder, as well as the in-progress render file 'quRender 1 2.exr' while the render was happening. The transfer is reported as having happened, with these log.txt entries in the workstation's QM folder matching:
05:16:16 AM: ...adding new Queue entry id 1 05:16:16 AM: ...adding new Queue entry id 2 05:16:17 AM: Queue Procs now available: 0 05:16:17 AM: Launching FFRender for parsing... 05:16:17 AM: ... FFRender launched 05:16:17 AM: Parser process is ready to talk 05:16:17 AM: SetRequestedFrame OK 05:17:55 AM: Parser assets are ready. Updating qTask with filenames. 05:17:56 AM: Launching FFRender in RunCmd for render ... command line: /Applications/Poser 11/Queue Manager.app/Contents/Resources/FFRender 4415 /private/var/folders/7k/xt8wllys2_lck7zcxm5xgtkm0000gn/T/TemporaryItems/Queue Manager/11/2019- 1-10_ 4h35m57s 2.xml /private/var/folders/7k/xt8wllys2_lck7zcxm5xgtkm0000gn/T/TemporaryItems/Queue Manager/11/quRender 2 2.exr /private/var/folders/7k/xt8wllys2_lck7zcxm5xgtkm0000gn/T/TemporaryItems/Queue Manager/11 07:09:53 AM: Render completed successfully for frame 2 07:09:53 AM: Queue Procs now available: 1 05:48:58 PM: Incoming file transfer. 05:48:58 PM: Incoming final file transfer accepted for frame 2 of entry ID 2 in queue. 05:48:58 PM: Receiving file: /private/var/folders/7k/xt8wllys2_lck7zcxm5xgtkm0000gn/T/TemporaryItems/Queue Manager/11/quRender 1 2.exr 05:49:21 PM: File /private/var/folders/7k/xt8wllys2_lck7zcxm5xgtkm0000gn/T/TemporaryItems/Queue Manager/11/quRender 1 2.exr received successfully. 05:49:27 PM: Remoted frame completed successfully: frame 2
but the only file left in the workstation's QM folder is the log.txt file. I have done a system-wide search, and 'quRender 1 2.exr' does not exist anywhere! 13+ hours of remote rendering and nothing to show for it!?
I wonder if this is what @h-elwood-gilliland was referring to with:
Reliability on wireless has never been guaranteed.
The queued network remote render certainly seemed to happen, but the transfer failed? while being reported as complete, so the remote render file was then deleted. It's not even in the trash, that I can see.
@anomalaus When you send a job to Queue, it prompts you for a destination folder and a name for the image. Nothing there?
If you don't recall, and if the job is still on the queue, select that job, then use the go to folder button at the bottom of the Queue UI.
What's with the timestamps? The workstation seems to be assigning/sending a job at 0516; the remote accepting a job at 0438; the remote returning the render at 1748 (5:48PM); I see the workstation logging "render completed successfully for frame 2" at 0709.
I seem to recall that the workstation's Queue should say something like remote... received from 192.168.1.105
@anomalaus Please send me more information privately, I will PM you.