This is a problem I encountered the past months in DO11 and now also in DO12.
If I've selected multiple image files and I choose some options in the Image Convert window DO becomes unresponsive after I press the ALL button.
Behind the Convert window appears another window but I cannot see the contents because DO hangs. I have to terminate the program in the taskmanager.
When I select each image one by one the resize or convert works fine.
When I select multiple images and select the convert to (let's say) PNG button (command [Image HERE CONVERT=png]), all files are converted immediately.
Converting to another filetype, resizing the images by a percentage or both at the same time.
Additional options are Add filename suffix and Preserve aspect ratio. See pictures below.
I tried it with all kinds of filetypes and sizes.
I now notice DO also hangs when pressing OK. Pressing OK, when having multiple files selected, always resulted in one converted file.But not this time.
The other way around, selecting 1 file and pressing ALL, also works fine.
The problem seems to be in having multiple files selected.
In the first picture you can see the DO is unresponsive. I managed to move the convert window so you could see the window behind but that's not giving any information.
I did some more tests and suddenly no error. All files and all convert options work seamlessly.
Luckily I have the prove in the pictures below. But it doesn't make sense at all.
If it starts hanging again, and hangs for long enough to do so, please open Task Manager, then right-click the Opus process and choose the option to create a dump file. If you zip the dump it should compress to a fairly small size, and can be emailed to leo@gpsoft.com.au where I can see which function seems to be causing the delay.
My guess is something else is at play here, since converting a tiny image should not take any noticeable time, unless the drive it's writing to is slow to respond or something.
Based on the dump, it appears that the problem may be caused by TeamViewer (tv_x64.dll) which looks like it is interfering with the progress dialog and probably causing a cross-thread deadlock.
The dump only has enough information to make an educated guess, so this may not be correct, but it looks likely, and I can't see anything else that looks amiss within the dump.
I'd recommend updating, disabling or temporarily uninstalling TeamViewer (in that order; rebooting after any change) to see if it helps and to confirm whether my theory is correct.
If the problem still happens with TeamViewer uninstalled then it was not involved, and another dump file in that state may be useful as it may reveal something else that wasn't visible with the TeamViewer components still active. (e.g. It is possible something else is creating a problem which TeamViewer than runs into, rather then TeamViewer causing the problem itself).
You'll probably need to ask the TeamViewer developers to investigate if/why their DLL is causing cross-thread (or possibly cross-process) communication on UI threads, since that can lead to the threads deadlocking.
Their DLL is being injected into our callstack, rather than something we're talking to on purpose, and we don't really have any way to know what it does.
What version of Teamviewer are you using Bilko?
I'm always using the most recent ones and haven't had had any problems for months now.
If you're using an older version I recommend to update.
Hello,
same problem here, shutting down Teaviewer make it work. Thank you for the information.
My teamviewer version is 12.0.82216 Aug 17 2017
it seems tha problem happens on the premium license, and not in the free one.
Fwiw, no problems here converting images over Teamviewer session.
Multi-user license for Teamviewer in use, connected to Win2k8 R2.
Teamviewer is v8 on both ends.
Scroll down until you find the section about the QuickConnect button, then click Configure.
Add dopus.exe to the list of programs which QuickConnect breaks.
You may also want to turn off this awful QuickConnect feature entirely as it will break other software and cannot be worth it, whatever it does.
Click OK twice.
Screenshot of the process taken from a thread about the same issue in Adobe Fireworks. Of course, you want to add dopus.exe to the list, not fireworks.exe as shown in the screenshot. The other details should be the same:
Just to reiterate, this bug is entirely TeamViewer's fault and causes problems with all the programs they list by default, and I would assume many others. To be blunt, they should remove this feature if they can't fix it, as they clearly know it is not stable and causes problems in other people's software, which other people will be blamed for. I'm rather annoyed by this.
All of these threads are about the same problem, in different software, all with the same fix:
It's ridiculous. Some of those threads are several years old. Rather than fix the fundamental problem in this aspect of their software, they either ignore reports or add new things to the blacklist while continuing to cause problems with other software, making people think something else is faulty and wasting time and spoiling other people's reputations.
In Opus 12.7.1 and 12.8 we plan to try to detect if TeamViewer is installed and automatically add ourselves to the "list of programs TeamViewer should not cause to freeze". It probably won't be perfect, but it should mean the problem stops happening for people, at least after a reboot if not immediately. But you can also do the same for yourselves now by following the steps above.
