[feynman]

Had always purged all three as you suggested. Did a new cooperative render. Resuming is always done by using the right mouse button in the Monitor and then typing new SL and/or desired duration. Deleted the furniture and books from scene and pulled out two Library items. This is the outcome:

Pre-resume Monitor


Post-resume Monitor


Post-resume Render


Pre-resume, post-resume and post-post resume rendering - non-colour managed preview window ;)


Now, apart from the SLs which are all wonky, each resume with this MXS results in less noise. That's at least something. But that's without the objects I want to render... Here is how the original (not de-noising on resume) scene was cobbled together: A room MXS (from two weeks ago) + a furniture MXS (from April) + a books MXS (from last week) were opened/imported in that order, unwanted objects from all three were deleted. Then the shit hit the fan.

Oh boy, everything's gone to shiiiit!! :mrgreen:

If there is indeed an issue here with resuming, it will be fixed, but it's very weird that it lets you resume and then actually shows a lower SL. It could be that it's finding older MXI files in the temp folders and instead resuming those...

Can someone else run a simple test?

Try first clearing all temp folders from Manager, Nodes, Monitor (File>Purge temp folder).

Then, run ONE single coop test. Check the final SL of the result.

Then try resuming and see.

Otherwise it's very difficult to know what is going on...

[Mihai]

So now resuming worked ok. Now try your original scene, add it as a new job. Are you setting the output paths to be network paths? Was that scene saved in Maxwell 2.7 or 2.7.10 before?

[feynman]

Output path goes to machine running Manager, etc. or a dropbox folder for colleagues to work on. This worked in 2.6. The scene which degrades was put together as described in 2.7, its three parts were done in 2.6 (furnitures, MXMs used) and 2.7 (room, books). Will surely try again with problematic scene.

Do you know where that 1 SL has disappeared, as shown above when comparing Monitor with Render?

[Bubbaloo]

Too many variables...

Start simple. Test. Add complexity. Test again. Repeat.

[feynman]

Well, if I could only know which variable to look for :] only thing I know is this:

1. One scene I set up entirely in 2.7 did improve upon resumption (SL rises, noise decreases)
2. All scenes I put together from 2.6 scenes and 2.7 scenes so far degraded upon each resumption (SL rises, noise increases)

Now I try resumes of an old scene entirely set up in 2.6...

[feynman]

Six consecutive resumes of a 2.6 scene

Job 6 - 30:12 render time / 1.599.600 bytes size / 14.4441 SL PC1, 13.6006 SL PC2
Job 7 - 30:13 render time / 1.600.361 bytes size / 14.4539 SL PC1, 13.5936 SL PC2
Job 8 - 61:14 render time / 1.413.290 bytes size / 16.1862 SL PC1, 15.3313 SL PC2
Job 9 - 90:07 render time / 1.337.359 bytes size / 17.1930 SL PC1, 16.3263 SL PC2
Job 10 - 60:13 render time / 1.415.176 bytes size / 16.1834 SL PC1, 15.3231 SL PC2
Job 11 - 90:14 render time / 1.332.541 bytes size / 17.2021 SL PC1, 16.3351 SL PC2 / Monitor SL 19.764, Render SL 18.51

and corresponding image snippets, animated GIF as suggested



Job 10 image is the odd one out, SL goes down, more noise ensues. Job 11 looks like Job 9 again; Job 11 shows big discrepancy in SL between Monitor and Render display.

So, resuming 2.6 scenes in 2.7 is not reliable in my case :( What could be the fix for these resumption issues?

[Bubbaloo]

You resumed job 9 for 90 minutes, and it lost 1 S.L.? That's impossible.

[feynman]

It is possible, as you can see. I reinstalled the software on all PCs over night. I updated Windows 7. I faithfully copied the figures from the console. I faithfully copied the image from the preview window. Sometimes, the second resume was noisier already and the SL lower, sometimes a later resume is noisier and the SL lower. That's why I can never tell, if a resum will improve image quality. So far, I have destroyed all renderings since the 2.7 update as I posted before.

In any case, the Monitor's SL display and the Render's SL display never matchtes, with initial renders or resumed ones, there is always a difference of 1-2 SLs displayed.

Not good at all.

ps: Just did another test. Joint SL displayed goes up, individual SLs go down, resumed image noisier, then better again...

Initial render: joint SL 17,4841 / SL PC3 16,1796, SL PC4 15,2947
First resume: joint SL 19,0000 / SL PC3 15,7642, SL PC4 14,8882 lower SL = visibly more noise
Second resume: joint SL 20,0765 / SL PC3 17,8963, SL PC4 17,0304 markedly less noise
Third resume: joint SL 21 / SL PC3 18,0508, SL PC4 17,1848 very hard to tell if better than second

If my fried brain remembers correctly, a resume always took off (number displayed in Monitor) with the SL it had previously reached, now all resumes always begin with 0. Maybe that's a hint of any kind?

[feynman]

BUMP!

Anybody out there got any ideas, how arcane they might be, why since the 2.7 upgrade, my resumes of 2.6 MXSs or mixes of 2.6 and 2.7 MXSs are so unpredictable? I really don't want to go back to Bunkspeed Shot as an emergency measure. Just had two new occurrences where from SL 19 the render went "up" to ~SL 16 after giving it an extra two hours...

[Bubbaloo]

I think the only way it can lose S.L. after a resume is if it can't find or write over the original MXI. Make sure all render nodes have access to the original MXS and MXI before you resume. Ideally, they should be stored on a network drive.

[feynman]

Thanks, I see, but nothing has ever changed in terms of IP numbers, cabling, etc. Maybe that resumes start always at SL 0 is a bug in the update, or - yes - something can't be found or whatever; in no case there are alerts in the consoles of Nodes, Manager, Monitor. Customer support is looking at it this week...