GP SoftwareTwitter
Opus FAQsManualCommandsObjects

Image Convert -> All, unresponsive with TeamViewer

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.

No problems here.

What type of conversion are you doing? Which type of images are the inputs, and what is turned on in the conversion dialog?

Are the images going to a destination folder? What kind?

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. :open_mouth:
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.

Hi Leo,

This is happening to me too..

I have emailed you the dump file as advised above, though it only zipped to 145mb! So I shared it on my google drive.

Could you please have a look, and see what the problem is?

Thanks, Chris

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).

1 Like

That fixed it, when I exit teamviewer - the image convert all process works as intended. Any ideas how to get them to play nice?

Thanks for the help! For now I have a workaround :slightly_smiling_face:

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.

Thank you!

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.

Glad I found this thread. Was having the same problem after installing on a new Windows 10 machine. Exiting TeamViewer v.13 helped. Thank you!

Here is a workaround for this problem:

  • Open TeamViewer's Options dialog.
  • Click Advanced.
  • 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.

1 Like