Made in Manchester now!
Thanks for the feedback.
Marcel
Made in Manchester now!
Thanks for the feedback.
Marcel
Hi, I am getting image corruption when transferring files to viewers or another server. If I manually copy the files the images are fine. Problem is just with dicom send. Went back to version 1719b and dicom send works as expected. Tested transfer to KPacs, Charruasoft and Microdicom as well as another conquest server.
OS= Centos 7 64bit
SQL= MariaDB 5.5.60
Hm,
sounds serious. Can you explain the nature of the corruption, maybe attach a corrupted example? The sender is 1.4.19d1 on Centos and 1.4.19b is fine?
Marcel
Yes, 1.4.19b works fine but when I load 1.4.19d1 all dicom send functions result in corrupt images. I am able to use a web viewer and view images on 19d1 with no problem. I am attaching an example of the corrupt file.1.2.392.200036.9125.9.0.253457335.150995136.756120174.zip
Hi,
Can you also post the uncorrupted image. What was the PDU size for the transfer?
Thanks,
Marcel
We installed the 1.4.19d1 update in our datacenter
While working with GE on some transfer issues afterwards, these are the notes I got back from them:
QuoteDisplay MoreI checked through the logs and I see these errors multiple times which I think is a series tag that it does not like:
2019-03-08 10:33:05 EST ERROR-|DicomServiceTemplate:271| Exception in creating dicom dataSpecified length (8792604) of PDU exceeds limit: 1048576
java.io.IOException: Specified length (8792604) of PDU exceeds limit: 1048576
2019-03-08 10:33:05 EST ERROR-|RequestHandler:108| dicomexception occured during handling the request1003
com.ge.med.terra.tap.dm.DMException: java.io.IOException: Specified length (8792604) of PDU exceeds limit: 1048576
Caused by: java.io.IOException: Specified length (8792604) of PDU exceeds limit: 1048576
So it looks like there is a PDU length issue playing here as well
Hm,
can you still send me an uncorrupted image?
Thanks
Marcel
If you send a small image (e.g. a CT slice), does the corruption still occur?
I hope you can help me to debug this issue, I will propose code changes that you than should test.
Marcel
Some studies seem to fail after 20 or so images, some die right away.
I'll see that I can find an image that triggers it every time and if it still does it after anonymizing.
If so, I'll send it over shortly.
Thanks,
I have not seen the issue on Windows.
Marcel
I was able to replicate it with a specific image, which was anonymized.
So 1 images from a dicom server runnin 1.4.19d1 on a windows server to a Linux based GE system.
In the GE logs, the main thing seems to point to:
2019-03-12 07:37:29 EDT INFO -|DicomServiceTemplate:102| Received association request from peer [Socket[addr=/10.x.x.xx,port=62752,localport=8118]].
2019-03-12 07:37:29 EDT INFO -|RequestHandler:82| Association request from the peer [Socket[addr=/10.x.x.xx,port=62752,localport=8118]] accepted
2019-03-12 07:37:29 EDT INFO -|EventManager:114| Firing the event for eventID 10003
2019-03-12 07:37:29 EDT INFO -|CognitoTokenService:93| --------- cognitoIdTokenExpired or FirstLogin... Getting new cognitoIdToken, cognitoIdentityId, openIdToken...
2019-03-12 07:37:30 EDT ERROR-|DicomServiceTemplate:271| Exception in creating dicom dataSpecified length (27265470) of PDU exceeds limit: 1048576
java.io.IOException: Specified length (27265470) of PDU exceeds limit: 1048576
...
2019-03-12 07:37:30 EDT ERROR-|RequestHandler:108| dicomexception occured during handling the request1003
com.ge.med.terra.tap.dm.DMException: java.io.IOException: Specified length (27265470) of PDU exceeds limit: 1048576
Uploading the image now and I'll send the link in a private message
PDU length is showing 16384 in log. Attaching original corrupt.ziporiginal.zip
Hi,
the corrupted image is correct in row 0, and breaks at row 1, column 504:
1 501 41376 41376
1 502 39481 39481
1 503 38962 38962
1 504 39640 11464 (word 936+504)
1 505 37644 11273
1 506 37464 10365
The first time I see this sequence 11464 11273 10365 in the uncorrupted image is at
row 140, column 156 (byte 936+504), i.e. 129756 words later. No obvious system in it.
Looking at changes between b and d1 they are:
pdata.cxx, line 198:
b: BlockSize = 4096;
d1: BlockSize = MaxSubLen-6; //16384; // was 4096;
buffer.cxx lines 53, 55:
#ifdef UNIX
b: # define DEFAULT_BREAK_SIZE 8192
d1: # define DEFAULT_BREAK_SIZE 262144 // was 8192
#else
b: # define DEFAULT_BREAK_SIZE 32600
d1: # define DEFAULT_BREAK_SIZE 262144 // was 32600
#endif
My impression is that all other changes are unrelated. Can you test reverting one or both of these changes? On windows the image transmits without problem.
Thanks,
Marcel
Marcel, making the changes to both the pdata.cxx and buffer.cxx corrected the problem with corrupted images during dicom send from Linux. Thank you.
Hi,
Can you also try one or the other please?
I would like to know what goes wrong.
Marcel
Is there anything I can change on Windows to test things?
Thanks,
but I see no issue on windows so far (in conquest-conquest transfer)
Marcel
Marcel, if I only change the pdata.cxx, images are still corrupt. If I only change the buffer.cxx, there were still some corruption on a few of the images.
Thanks. It is very strange.
Ok,
I think we should keep BREAK_SIZE 8192 on Linux (see also 20130416 comment in buffer.cxx).
For pdata.cxx, I would like to know what goes wrong. Would you mind adding this printf statement:
printf("MaxSubLen=%d\n", MaxSubLen);
BlockSize = MaxSubLen-6; //16384; // was 4096;
I am curious what is passed (it would show in the command line). There may be an issue reading this value from the association.
Marcel
Don’t have an account yet? Register yourself now and be a part of our community!