I’m having an issue where windows 10 boxes running either DL8 or 10 aren’t clearing the Quicktime “Unsupported Display” popup even thought the handler has been added to the plugin. We believe it was working in the past, so we’re wondering if anyone has a guess as to why it has stopped.
Thanks!
We are seeing something similar actually with some popups. It seems that the popup handler kicks in as soon as we give window focus to the rendering application, but does not if the application does not have focus. Very odd.
If I recall correctly, that pop-up is owned by whichever process is the current consumer of QuickTime. The fun here is that because 32bit DLLs can’t be used in 64bit apps (I believe), many different applications spawn a child process do to that. I know both Nuke and AE have their own little QT Helper binaries.
Now, Deadline is supposed to walk the ancestry to find all Windows, but I think AE breaks that completely by doing an RPC to a different app. So, for this problem we’ll need to figure out who owns that pop-up… I believe you can use the “Go to details” option in task manager on Windows to do that. Knowing the app that’s affected will probably give me a good handle on what’s up. For fun, try giving it focus too. I don’t think it’s the same problem but shouldn’t hurt.
Talking about possible workarounds, we might be able to walk all open windows on a system. There’s a danger though that an artist or pipeline dev who has a Slave running could be affected if we went that route.
Hey Edwin,
If im not incorrect, deadline puts all the spawned processes into its own JobObject constuct on windows. I’m not sure whether the Quicktime wrapper process would also belong to it, but there is a pretty good chance that it would (by default, all child processes inherit the existing jobobject of the parent). So the best solution might be to query the processes that belong to the slave application JobObject, and only walk those windows instead of all processes on the system.
cheers
laszlo
Well, the fun thing here is that if I’m remembering correctly, Adobe spawns some processes at boot that won’t be part of the job process. When AE reaches out to them we don’t know about it.
I think most apps do live inside the process group though, so I don’t think this issue with Max is part of them. In chatting with Conrad we thought about continually trying to raise the Max window, but that’s a challenge and not the right solution as a few users just run a Slave on their Desktop.
Why is the focus important though?
We’re not actually sure since we’re just walking window handles last I checked the code there.
Since I think your issue is different, let’s keep the conversation rolling over in forums.thinkboxsoftware.com/vie … 10&t=15663 on that one.
Can’t access the other forum thread, but I can say that it appears that the pop-up we’re seeing is a separate process, and I can’t identify a parent. So it’s definitely an issue that, it appears, the current handler can’t deal with.
Yeah, without a proper chain of ownership, we can’t be sure which pop-ups to close. Just in case we see this again, what app are you seeing this with?
Hi, I couldnt get to the other thread either. Is there a workaround for this?
Sam.
docs.thinkboxsoftware.com/produ … d-meanings
Search for: “Error: “Unsupported Display” QuickTime pop-up dialog / “quicktimeShim.exe” application hangs”