Should be fixed with latest changes time geomtry construction.

This task was closed here on Phabricator since it was migrated to GitLab. Please continue on GitLab.

Hi there! 🙂

Hi there! 🙂

@gaoh thanks for pointing there, I will close this one as a duplicate

T28207 describes how to test it without the wDB. When searching for DICOM query retrieve there are already different tasks open with all similar problems

Hi there! 🙂

Fixed in T26164: DICOM Query/Retrieve doesn't work at least in Ubuntu release installers.

@thomass could you check if the problem was realy just cuased by slow network drive and is solved. If this is the case, could you close the task? If the problem still exists, may be the issue solved by Stefan is a solution.

Maybe this is related to T26164: DICOM Query/Retrieve doesn't work at least in Ubuntu release installers.

Possibly as duplicate of T26164: DICOM Query/Retrieve doesn't work at least in Ubuntu release installers. There's a workaround in the task that you could use to verify if it is the same issue.

PS: as an explanation, one theory is that the install-zip-package still references libraries from the build machine which causes the different behaviour

In T27669#211004, @schererj wrote:

@nolden I tried the "make package" and it went through without any issues.
Should I upload the result here? Or is it just about the information that there are no error?
Could you please explain what you mean with "target machine"?

@nolden I tried the "make package" and it went through without any issues.
Should I upload the result here? Or is it just about the information that there are no error?
Could you please explain what you mean with "target machine"?

@schererj we looked at the debug output, thanks. Unfortunately it seems to be complicated ... I would ask you to try another thing:

Yes, the workbench is starting without any issues.

Did you your "release ldd" Workbench started and worked properly at all? Seems like most of the SOs could not be loaded correctly. Not even MitkCore. I would assume that workbench does not even start?!?

I hope I did it right..

@schererj we just discussed this in the MITK meeting. Could you try something? It would be interesting to compare the outputs of

In T27669#209003, @floca wrote:

@kislinsk As a linux noob please pardon my question. Can we directly debug the nightly bild by the CI on e.g. Jonas system? I would like to see some of the parts of volume generation process running to see whats happening. My be it helps us getting a lead. At least we now a setup directly on site that makes the problems.

I just received an E-Mail that the problem could be related to the data source (some server or network drive) so maybe no MITK issue after all :)

Some additional questions:

• Was your laptop used to build the binaries? If yes, could you check, if yuo can produce the error behavior if you pick a non-mitk-developer maschine and try to load the data there?
• How many frames does the 4D Dicom have? What is its resolution?

In T27669#209010, @thomass wrote:

The log information in the console which Jonas reported doesn't turn up. So the console doesn't show any new information after the reader is selected.
I will ask about the HDD / IO.

The log information in the console which Jonas reported doesn't turn up. So the console doesn't show any new information after the reader is selected.
I will ask about the HDD / IO.

In T27669#209008, @thomass wrote:

she doesn't even get to the logging point. It doesn't show anything, it just stops (She closed the workbench after 10 Minutes).

What do you mean with logging point?

I am not sure if that is related but today one of my cooperation partners reported that she couldn't open an 4D image in MITK (Latest develop installer).
On my laptop it just works fine. On her laptop, however, she doesn't even get to the logging point. It doesn't show anything, it just stops (She closed the workbench after 10 Minutes).
I asked her whether it was an ancient laptop, but no ;)

In T27669#208901, @schererj wrote:

It is pretty weird since it even:

suggests 1 3D blocks

I agree to @floca and I am quite sure this is related to installer vs. starting from build directory.