Posts by GEN

Dedicated DICOM Ping from Philips system gives logs without errors.

A-ASSOCIATE-RQ Packet Dump
    Calling Application Title : "DIDIC90         "
    Called Application Title : "DCP3            "
    Application Context : "1.2.840.10008.3.1.1.1", PDU length: 16000
    Number of Proposed Presentation Contexts: 1
    Presentation Context 0 "1.2.840.10008.1.1" 1
Server Command   := 0030
Message ID       := 0003
0000,0002     18 UI AffectedSOPClassUID    "1.2.840.10008.1.1" 
0000,0100      2 US CommandField           48 
0000,0110      2 US MessageID              3 
0000,0800      2 US DataSetType            257 
0002,0010     19 UI TransferSyntaxUID      "1.2.840.10008.1.2.1" 
C-Echo
Arena 0:
system bytes     =    1138688
in use bytes     =     986720
Arena 1:
system bytes     =   19456000
in use bytes     =       2240
Arena 2:
system bytes     =   32157696
in use bytes     =     425024
Arena 3:
system bytes     =    2129920
in use bytes     =     424736
Total (incl. mmap):
system bytes     =   55017472
in use bytes     =    1973888
max mmap regions =          3
max mmap bytes   =   39464960

...edited....

Hah, when i leave on machine just SCU/SCP Transfer ExpliciLittleEndian with available SCU/SCP CR/DX Storage/Processing SOP Classes, the communication works with real images transfer. however the Dicom association test still gives termination and i suppose that it may be some newest features checking for integration with philips vna systems. For now, i let it just work and monitor the logs. Thank You Marcel for time!

Sorry i meant that i've updated to the latest dgate.dic file from github (https://github.com/marcelvanhe…6931df09e925981002fe9d672) as i thought i may be connected to my case.

dgatesop.lst file attached (didn't touch anything)

Dear Marcel,

maybe it's not bad to write my case here (this topic). Today i'm trying to connect newest Philips Diagnost C90 and we can't go through association test. When I turn on debug lvl 2, i get logs just like below:

Connected by address: 030110ac

Testing transfer: '1.2.840.10008.1.2.1' against list #0 = '1.2.840.10008.1.2'

Testing transfer: '1.2.840.10008.1.2.1' against list #1 = '1.2.840.10008.1.2.1'

Testing transfer: '1.2.840.10008.1.2.1' against list #0 = '1.2.840.10008.1.2'

Testing transfer: '1.2.840.10008.1.2.1' against list #1 = '1.2.840.10008.1.2.1'

Testing transfer: '1.2.840.10008.1.2.1' against list #0 = '1.2.840.10008.1.2'

Testing transfer: '1.2.840.10008.1.2.1' against list #1 = '1.2.840.10008.1.2.1'

Arena 0:

system bytes = 1138688

in use bytes = 986416

Arena 1:

system bytes = 442368

in use bytes = 421760

Total (incl. mmap):

system bytes = 1716224

in use bytes = 1543344

max mmap regions = 2

max mmap bytes = 446464

UPACS THREAD 2: STARTED AT: Wed May 25 13:59:38 2022

*** connection terminated

UPACS THREAD 2: ENDED AT: Wed May 25 13:59:38 2022

UPACS THREAD 2: TOTAL RUNNING TIME: 0 SECONDS

I've updated dgate.lst (to latest from github. Could You Marcel point me some solution here please, i'll be very grateful fo help.

I've decided to close Fedora case and come back to Oracle Linux 7, so there is very good compliance with conquest

As You proposed, changing to 'type' makes compilation further. But if I want for example to read files for worklist generation, parseHL7 function doesn't' affect such scenario?

I've double checked that in 1.5.0.a version which i compiled with success nearly year ago, has much smaller dgate.cpp file but the parseHL7 function is the same. Marcel, do you think the reason of error could be too fresh gcc and rest of libraries in Fedora 34?

Hello Marcel,

i'm trying to do my first worklist test lab and right now i have some challenge with compilation the newest sources (https://github.com/marcelvanherk/Conquest-DICOM-Server) on fresh/updated system. Fedora 34 (kernel 5.12) with gcc v11.11.1, lua 5.4.3 (and additional 5.1 installed). While running maklinux script, after I choose to install any DB type (finaly i'd like to use mariadb) i get error like below:

<code>

/usr/bin/install -c rdjpgcom /usr/local/bin/rdjpgcom

/usr/bin/install -c wrjpgcom /usr/local/bin/wrjpgcom

/usr/bin/install -c -m 644 ./cjpeg.1 /usr/local/man/man1/cjpeg.1

/usr/bin/install: cannot create regular file '/usr/local/man/man1/cjpeg.1': No such file or directory

make: *** [Makefile:205: install] Error 1

Please ignore the errors above

Please choose DB type

1) mariadb

2) postgres

3) sqlite

4) dbase

5) precompiled

6) Quit

#? 3

In file included from ./src/dgate/src/total.cpp:175:

./src/dgate/src/dgate.cpp: In function ‘void parseHL7(char**, char*, char*, char*, char*, char*, char*)’:

./src/dgate/src/dgate.cpp:26659:33: error: ordered comparison of pointer with integer zero (‘char*’ and ‘int’)

26659 | else if (strstr(type, ".DATE")>0) // date was returned, now get time

| ~~~~~~~~~~~~~~~~~~~~~^~

cp: cannot stat './dgate': No such file or directory

cp: cannot stat './dgate': No such file or directory

cp: cannot stat './dgate': No such file or directory

cp: cannot stat './dgate': No such file or directory

Regenerate the database?n

n

Install as service?n

n

[root@worklist temp]#

</code>

I've checked in /src/dgate/src/dgate.cpp:26659:33 so this is in fact parseHL7 function, but rather have no clue where the error cause is.

Hello Marcel, sorry for my very late answering. Last time i had time only to change to nki compress method and forget so the pacs for Philips images were working fine. Still, of course i'd like to keep on the track in solving this strange problem.

Last days i've checked logs from all of pacs instances and noticed that not only Philips was sending images with some (jpgls processing) errors in log. Similar situation touches (bur very rarely) instance used for CT (GE Optima) archiving and Siemens Angio also but with different jpgls error info. The Xray FCR images are being archived properly without any errors.

Additional info here:

- some of the images form GE CT are missing so i'm resending them manually with the same jpgls compress method without problem

- the images from Siemens Angio, despite logged errors, are archived properly (i can download them to any dicom workstation)

I've attached proper, cut files of logs from appropriate instances, please take a look.

For the clearance, CT console is sending to pacs uncompressed images. In acrnema i have also 'un' in line for this connection. When i change store compression form 'js' to 'nk4', there is no error. Strange is that such situation is only with Philips systems (cr and mr also), on GE or FRC is ok.

Today i've heard very strange thing form the ct technicial. When the system is sending images in automode, the errors occure but when he send exam manually, it is storen in pacs without errors. I checked it and it's true, so now i really don't know what to search for

oh there is another strange error during storing from Philips:
Mon Aug 17 09:11:37 2020 ***[CompressJPEGLS]: Failed to get image height.

Hello Marcel,

nowadays i've noticed that in trouble log i get lines like below:

Tue Aug 25 10:09:03 2020 ***[CompressJPEGLS]: Unknown or unsuported color space RGB, Trying RGB

We are receiving images from Philips Ingenuity 64, these data are stored inproperly (some of the images are stored, some not). The doctor's (philips) workstation can store images sent from CT directly and send it to pacs so the problem is in scenario ct-pacs only i think. Still, i'm not sure if i have some configuration problem or there is some problem in pacs compilation (based on the latest github sources) or jpeg library itself or anything else i can't comprehend

My dicom.ini has entries:

FileNameSyntax = 4

FixPhilips = 1

# Configuration of compression for incoming images and archival

DroppedFileCompression = js

IncomingCompression = js

ArchiveCompression = as

Could You please point some way i should look for.

ps.

Storing from GE CT and Fuji CR systems with same compression configuration is working without any jpgls errors.

Uh, while ago i've checked and surpisingly it failed again with transfers. Now, it stopped because of no free storage left where the ROUTER instance is installed. Router data dir had lot of exams despite i have destroy formula after forwarding. I checked that there are much different modality names in studies of these exams. I suppose right now i understand all of this strange situation. Pitty it was so long story :). Unfortunately during few years, old Conquest saved studies data with different 'modality name' (because of different DI machines). When we had tests of exact day to movestudies, and i had hidden space before MAGDevice entry in dicom.ini line (attached below), there was an error of no space left when ROUTER finally get from OCTOPUS exam with unknown modality to compare in rule.

Now i've written more converter rules, like below and hope that it will be enough.

ImportConverter0 = ifequal "%m", "MRI"; { forward to DCP1; destroy; }

ImportConverter1 = ifequal "%m", "MR"; { forward to DCP1; destroy; }

ImportConverter2 = ifequal "%m", "MR/PR"; { forward to DCP1; destroy; }

ImportConverter3 = ifequal "%m", "PR/MR"; { forward to DCP1; destroy; }

ImportConverter4 = ifequal "%m", "PR"; { forward to DCP1; destroy; }

ImportConverter5 = ifequal "%m", "CT"; { forward to DCP2; destroy; }

ImportConverter6 = ifequal "%m", "SC/CT"; { forward to DCP2; destroy; }

ImportConverter7 = ifequal "%m", "SC"; { forward to DCP2; destroy; }

ImportConverter8 = ifequal "%m", "TK"; { forward to DCP2; destroy; }

ImportConverter9 = ifequal "%m", "XR"; { forward to DCP3; destroy; }

ImportConverter10 = ifequal "%m", "CR"; { forward to DCP3; destroy; }

ImportConverter11 = ifequal "%m", "DX"; { forward to DCP3; destroy; }

ImportConverter12 = ifequal "%m", "MG"; { forward to DCP3; destroy; }

# We have no mammo but some of xray are saved with such modality name (strange)

Maybe it could be good to add some information in general documentation that ROUTER functionality saves exams (despite destroy rule) to it's MAGDevice when the incoming data with e.g. modality name or any other compared variable is missed.

I think i should learn LUA now.

Dear Marcel, just noticed my fault entry in router's dicom.ini

Firstly i had commented MagDivice lines and partially transfers were working, eventually ending with the 'no space left' errors. Even with enabling magdevice lines there were same errors. I realized there were space chars before configuration entry in each lines of magdev. Without spaces it's working...

Sorry for delay,

After destroy only configuration, the situation is nearly similar. Take a look:

1. Sending OCTOPUS instance shows in PacsServerstatus:

...
MyStudyRootRetrieveGeneric :: RetrieveOn

RetrieveOn: givenout < 8508

Sending file : /PACS_SYSTEM/OCTOPUS/data/DICOM_0/62080704245/1.3.46.670589.11.0.0.11.4.2.0.10530.5.3732.2017112911311171000_0000_000000_15119518577b75.v2

Image Loaded from Read Ahead Thread, returning TRUE

ReadAheadThread: readahead > 8516

Retrieve: remote connection dropped after 8508 images, 1529 not sent

***preretrieve/forward xxx to: remote DICOM error

C-Move (StudyRoot)

UPACS THREAD 3: ENDED AT: Sun Jul 12 12:34:31 2020

UPACS THREAD 3: TOTAL RUNNING TIME: 367 SECONDS

2. And the Router (destroy) instance shows in PacsTrouble:

Sun Jul 12 12:34:31 2020 ***Error getting free store for device NULL

Sun Jul 12 12:34:31 2020 *** Out of disk space

Strange, after so many images retrieved with DB NULL DRIVER. BTW the situation is the same for that day i'm testin (exacly after 8508 images) when i put in ROUTER dicom.ini MagDvice enabled or not.

I'm using linux mysql 8 version and i think the only parameters i could change are like on official site and there is no such option like in windows maybe.
https://dev.mysql.com/doc/refm…n-variable-reference.html

Hmm, when i start command with different day, the logs are like below, example 1:

| Locating file:MAG0 77072016952/1.3.46.670589.26.702420.2.20171211.

│100831.285762_0001_000001_1512982401000c.v2

│Locating file:MAG0 48111104341/1.3.46.670589.26.702420.2.20171211.

│95851.285758_0001_000001_15129817990008.v2

│Locating file:MAG0 48111104341/1.3.46.670589.26.702420.2.20171211.

│95945.285759_0002_000001_15129818700009.v2

│ReadAheadThread: readahead > 0000

│RetrieveOn: givenout < 0000

│Sending file : /PACS_SYSTEM/OCTOPUS/data/DICOM_0/31070703720/1.2.3

│92.200036.9125.3.144177281241575.64861121429.236201_1001_001001_15

│129865460553.v2

│Image Loaded from Read Ahead Thread, returning TRUE

│ReadAheadThread: readahead > 0001

│ReadAheadThread: readahead > 0002

│ReadAheadThread: readahead > 0003

│ReadAheadThread: readahead > 0004

│ReadAheadThread: readahead > 0005

│ReadAheadThread: readahead > 0006

│[recompress]: recompressed with mode = un (strip=1)

│ReadAheadThread: readahead > 0007

│ReadAheadThread: readahead > 0008

│Retrieve: remote connection dropped after 0 images, 1392 not sent

│***preretrieve/forward xxx to: remote DICOM error

│C-Move (StudyRoot)

│UPACS THREAD 21: ENDED AT: Mon Jul 6 18:53:59 2020

│UPACS THREAD 21: TOTAL RUNNING TIME: 5 SECONDS

the ROUTER instance gives only in Trouble:

Mon Jul 6 18:54:11 2020 ***Error getting free store for device NULL

Mon Jul 6 18:54:11 2020 *** Out of disk space

But in the User.log ROUTER says:

Mon Jul 6 18:53:51 2020 "C-Store","OCTOPUS "

Mon Jul 6 18:53:59 2020 "C-Store","OCTOPUS "

Mon Jul 6 18:54:11 2020 "C-Store","OCTOPUS "

sometimes it ends like this:
Retrieve: remote connection dropped after 8508 images, 1529 not sent

mysqld.log are fine (no errors), is it possible in host i want to send from (OCTOPUS) i have strangely written data?.

Ok, i got by with phpmyadmin connection lost so i know mysqld works fine. So there is problem with:
Retrieve: remote connection dropped after xxx images, xxx not sent

Any clue what to check?

Dear Marcel,

i have some more strange behaviour. Please have a look below, the log of sending host (OCTOPUS) to the virtual router, after command dgate --movestudies from 1 day only:
/dgate -v --movestudies:OCTOPUS,ROUTER,20171130-20171130

Sending file : /PACS_SYSTEM/OCTOPUS/data/DICOM_0/87111108436/1.2.840.113704.7.1.1.1236.1512058566.155_80136_000002_1512058920165f.v2

Image Loaded from Read Ahead Thread, returning TRUE

ReadAheadThread: readahead > 5854

MyStudyRootRetrieveGeneric :: RetrieveOn

RetrieveOn: givenout < 5847

Sending file : /PACS_SYSTEM/OCTOPUS/data/DICOM_0/57061212794/1.3.46.670589.11.0.0.11.4.2.0.10530.5.5108.2017113010415431007_0000_000001_15120372840495.v2

Image Loaded from Read Ahead Thread, returning TRUE

ReadAheadThread: readahead > 5855

Retrieve: remote connection dropped after 5847 images, 542 not sent

***preretrieve/forward xxx to: remote DICOM error

C-Move (StudyRoot)

UPACS THREAD 169: ENDED AT: Mon Jul 6 15:04:08 2020

UPACS THREAD 169: TOTAL RUNNING TIME: 417 SECONDS

The connection dropps regardless of association lever studies or image set in router. In Router dicom.ini i have only this:

[sscscp]

MicroPACS = sscscp

# Network configuration: server name and TCP/IP port#

MyACRNema = ROUTER

TCPPort = 1117

# Host for postgres or mysql only, name, username and password for database

# SQLHost = localhost

# SQLServer =

# Username =

# Password =

# PostGres = 0

# MySQL = 1

# SQLite = 0

# UseEscapeStringConstants = 0

# DoubleBackSlashToDB = 1

# Configure server

ImportExportDragAndDrop = 1

ZipTime = 05:

UIDPrefix = 99999.99999

EnableComputedFields = 1

FileNameSyntax = 4

# Configuration of compression for incoming images and archival

DroppedFileCompression = un

IncomingCompression = un

ArchiveCompression = as

# For debug information

PACSName = ROUTER

OperatorConsole = 127.0.0.1

DebugLevel = 0

# Configuration of disk(s) to store images

# MAGDeviceFullThreshold = 1000

# MAGDevices = 1

# MAGDevice0 = /PACS_SYSTEM/ROUTER/data/

#-----------------------------------------------------------

# MOJE TESTY ROUTINGU DO ROZDZIALU NA MODALNOSCI

ForwardAssociationLevel = SERIES

ImportConverter0 = ifequal "%m", "MRI"; { forward to DCP1; destroy; }

ImportConverter1 = ifequal "%m", "CT"; { forward to DCP2; destroy; }

ImportConverter2 = ifequal "%m", "XR"; { forward to DCP3; destroy; }

ImportConverter3 = ifequal "%m", "DX"; { forward to DCP3; destroy; }

#-----------------------------------------------------------

[lua]

association = package.path=package.path..';'..Global.basedir..'lua/?.lua'

Maybe I should suspect sth with mysql database behaviour because i noticed few times that in phpmyadmin i got lost connection during query process while no operations occured.

I thought it's working fine but unfortunately it's still bad. With monthly spliting i got about 240k images transfered and it stopped. I tried in different split ways, even split batch movestudies into weekly loop and deleted chanel * from routing rule with changing assoclevet to study, everything stops in different time, generally stops on source (sending) side with errors like below:

Mon Jun 22 12:16:09 2020 ***preretrieve/forward xxx to: remote DICOM error

Mon Jun 22 12:28:39 2020 ***preretrieve/forward xxx to: remote DICOM error

Mon Jun 22 12:31:27 2020 ***preretrieve/forward xxx to: remote DICOM error

Mon Jun 22 12:35:08 2020 ***preretrieve/forward xxx to: remote DICOM error

Mon Jun 22 12:40:13 2020 ***preretrieve/forward xxx to: remote DICOM error

Mon Jun 22 12:41:26 2020 ***preretrieve/forward xxx to: remote DICOM error

Mon Jun 22 12:50:08 2020 ***preretrieve/forward xxx to: remote DICOM error

Mon Jun 22 12:50:19 2020 ***preretrieve/forward xxx to: remote DICOM error

Mon Jun 22 12:57:32 2020 ***preretrieve/forward xxx to: remote DICOM error

Mon Jun 22 13:15:38 2020 ***preretrieve/forward xxx to: remote DICOM error

Mon Jun 22 13:37:22 2020 ***preretrieve/forward xxx to: remote DICOM error

Mon Jun 22 13:43:01 2020 ***preretrieve/forward xxx to: remote DICOM error

Mon Jun 22 14:13:50 2020 ***preretrieve/forward xxx to: remote DICOM error

Mon Jun 22 14:37:38 2020 ***preretrieve/forward xxx to: remote DICOM error

Mon Jun 22 15:10:58 2020 ***Failed to Listen () - bind error

Mon Jun 22 15:11:08 2020 ***Failed to Listen () - bind error

Mon Jun 22 15:11:18 2020 ***Failed to Listen () - bind error

Mon Jun 22 15:11:28 2020 ***Failed to Listen () - bind error

Mon Jun 22 15:11:39 2020 ***Failed to Listen () - bind error

Then on router log i can see:

Mon Jun 22 12:50:19 2020 *** Out of disk space

Mon Jun 22 12:57:32 2020 ***Error getting free store for device NULL

Mon Jun 22 12:57:32 2020 *** Out of disk space

Mon Jun 22 13:15:38 2020 ***Error getting free store for device NULL

Mon Jun 22 13:15:38 2020 *** Out of disk space

Mon Jun 22 13:37:22 2020 ***Error getting free store for device NULL

Mon Jun 22 13:37:22 2020 *** Out of disk space

Mon Jun 22 13:43:01 2020 ***Error getting free store for device NULL

Mon Jun 22 13:43:01 2020 *** Out of disk space

Mon Jun 22 14:13:50 2020 ***Error getting free store for device NULL

Mon Jun 22 14:13:50 2020 *** Out of disk space

Mon Jun 22 14:37:38 2020 ***Error getting free store for device NULL

Mon Jun 22 14:37:38 2020 *** Out of disk space

Mon Jun 22 15:10:46 2020 *** connection terminated

Mon Jun 22 15:15:45 2020 *** ImportConverter1.1: Forward failed to send DICOM image to DCP2

Finally on target instance log we get:

Mon Jun 22 15:10:47 2020

***Client Error: command ffff failed **

Mon Jun 22 15:10:47 2020 ***Connection Terminated

Right now i'm out of new ideas. I've noticed You changed 1.5.0 to (a) and made some updates on github. Could You ogive me a clue please.

Yes, i've checked on forum similar topics and came to conclusion and already started to make just like You wrote, batch in bash script in monthly "while" loop. Works

whatever I try with movestudies i get sth like below, hmm

./dgate -v --movestudies:OCTOPUS,ROUTER,20120101-20200630

│(QualifyOn) (mapped) IP:172.16.1.111, PORT:1117

│MyStudyRootRetrieveGeneric :: SearchOn

│Query On Image

│Issue Query on Columns: DICOMImages.SOPClassUI, DICOMImages.SOPInstanc, DICOMSeries.SeriesInst, DICOMStudies.StudyDate, DICOMS

│tudies.StudyInsta,DICOMImages.ObjectFile,DICOMImages.DeviceName

│Values: DICOMStudies.StudyDate >= '20120101' and DICOMStudies.StudyDate <= '20200630' and DICOMSeries.StudyInsta = DICOMStudie

│s.StudyInsta and DICOMImages.SeriesInst = DICOMSeries.SeriesInst

│Tables: DICOMImages, DICOMSeries, DICOMStudies

│Protocol error 0 in PDU:Read

│***preretrieve/forward xxx to: association lost

│Arena 0:

│system bytes = 1196032

│in use bytes = 1044176

│Arena 1:

│system bytes = 1368064

│in use bytes = 1366768

│Arena 2:

│system bytes = 450560

│in use bytes = 421120

│Total (incl. mmap):

│system bytes = 3149824

│in use bytes = 2967232

│max mmap regions = 2

│max mmap bytes = 446464