Posts by mparamas

This (UINT) is exactly the problem. File size is given above, and is 4305879424 > 4294967295 by 10912129 bytes. Vendors are now switching to EnhancedImageStorage format resulting in larger files at least for research data sets. Clinical whole body dynamic scans and functional MRI scans may also face this problem in future.

There is an option to take the EnhancedImageStorage format and split it as individual smaller DICOM files before sending, but that is inefficient. Looks like I will have to change receiver from dgate to storescp for now. Please let us know if the code changes in future. Thanks.

I have a "4.1 GB" single DICOM file (no-PHI) from Bruker animal scanner to send to Conquest/dgate. This is a dynamic scan with EnhancedPETImageStorage. Conquest dgate(64-bit) fails to receive this file. But DCMTK's storescp received this file fine on the same commandline.

I have dgate 1.5.0a 64-bit in linux (RHEL7), with DB as NULL driver. dgate's purpose is only to receive and store. Nothing odd in dicom.ini file; storing as "as" is.

dgate: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.24, BuildID[sha1]=72f8f701116ba429eb8b09134f049c9f1cb8092d, not stripped

This machine has 8 GB RAM.

I also tried 1.5.0.b 64-bit dgate on different machine with 16 GB RAM. Still the same problem. Is there a fix for this in dgate?

Culprit seems to be in: "Protocol error 217 in PDU:Read". Details below.

File:

-rw-r--r-- 1 user group 4305879424 Feb 22 16:23 EnIm1_1.dcm

Sending:

storescu -R -d -aec CTP localhost 4143 EnIm1_1.dcm

Sender with verbose <trimmed>:

..............................................................................................................................................................................................................................

E: Store Failed, file: EnIm1_1.dcm:

E: 0006:0317 Peer aborted Association (or never connected)

I: Peer Aborted Association

Sender with debug <trimmed>:

D: ======================= END A-ASSOCIATE-AC ======================

I: Association Accepted (Max Send PDV: 4084)

I: Sending file: EnIm1_1.dcm

D: DcmMetaInfo::checkAndReadPreamble() TransferSyntax="Little Endian Explicit"

D: DcmDataset::read() TransferSyntax="Little Endian Explicit"

I: Converting transfer syntax: Little Endian Explicit -> Little Endian Explicit

I: Sending Store Request (MsgID 1, PIe)

D: ===================== OUTGOING DIMSE MESSAGE ====================

D: Message Type : C-STORE RQ

D: Message ID : 1

D: Affected SOP Class UID : EnhancedPETImageStorage

D: Affected SOP Instance UID : 2.16.756.5.5.100.8323328.43296.1644938863.35.0

D: Data Set : present

D: Priority : medium

D: ======================= END DIMSE MESSAGE =======================

E: Store Failed, file: EnIm1_1.dcm:

E: 0006:0317 Peer aborted Association (or never connected)

I: Peer Aborted Association

Conquest (--debuglevel:4 on screen):

Before sending data:

Arena 0:

system bytes = 1056768

in use bytes = 738864

Arena 1:

system bytes = 516096

in use bytes = 379840

Total (incl. mmap):

system bytes = 1708032

in use bytes = 1253872

max mmap regions = 3

max mmap bytes = 16936960

At failure when sending:

Arena 0:

system bytes = 1056768

in use bytes = 738864

Arena 1:

system bytes = 111824896

in use bytes = 96233744

Total (incl. mmap):

system bytes = 113016832

in use bytes = 97107776

max mmap regions = 3

max mmap bytes = 16936960

debug log from file <trimmed>:

UPACS THREAD 4: STARTED AT: Fri Feb 25 11:49:42 2022

A-ASSOCIATE-RQ Packet Dump

Calling Application Title : "STORESCU "

Called Application Title : "CTP "

Application Context : "1.2.840.10008.3.1.1.1", PDU length: 16384

Number of Proposed Presentation Contexts: 2

Presentation Context 0 "1.2.840.10008.5.1.4.1.1.130" 1

Presentation Context 1 "1.2.840.10008.5.1.4.1.1.130" 1

Server Command := 0001

Message ID := 0001

0000,0002 28 UI AffectedSOPClassUID "1.2.840.10008.5.1.4.1.1.130"

0000,0100 2 US CommandField 1

0000,0110 2 US MessageID 1

0000,0700 2 US Priority 0

0000,0800 2 US DataSetType 1

0000,1000 46 UI AffectedSOPInstanceU "2.16.756.5.5.100.8323328.43296.1644938863.35.0"

0002,0010 19 UI TransferSyntaxUID "1.2.840.10008.1.2.1"

Protocol error 217 in PDU:Read <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< Culprit?

Failed STORAGE

Link.Connected false in PDU:Read

UPACS THREAD 4: ENDED AT: Fri Feb 25 11:49:58 2022

UPACS THREAD 4: TOTAL RUNNING TIME: 16 SECONDS

DCMTS's storescp receives fine:

D: ======================= END A-ASSOCIATE-AC ======================

D: DcmDataset::read() TransferSyntax="Little Endian Implicit"

I: Received Store Request

D: ===================== INCOMING DIMSE MESSAGE ====================

D: Message Type : C-STORE RQ

D: Presentation Context ID : 1

D: Message ID : 1

D: Affected SOP Class UID : EnhancedPETImageStorage

D: Affected SOP Instance UID : 2.16.756.5.5.100.8323328.43296.1644938863.35.0

D: Data Set : present

D: Priority : medium

D: ======================= END DIMSE MESSAGE =======================

D: DcmDataset::read() TransferSyntax="Little Endian Explicit"

I: storing DICOM file: ./PIe.2.16.756.5.5.100.8323328.43296.1644938863.35.0

D: DcmFileFormat::checkMetaHeaderValue() Version of MetaHeader is ok: 0x0001

D: DcmFileFormat::checkMetaHeaderValue() use SOPClassUID [1.2.840.10008.5.1.4.1.1.130] from Dataset

D: DcmFileFormat::checkMetaHeaderValue() use SOPInstanceUID [2.16.756.5.5.100.8323328.43296.1644938863.35.0] from Dataset

D: DcmFileFormat::checkMetaHeaderValue() use new TransferSyntaxUID [Little Endian Explicit] on writing following Dataset

D: DcmFileFormat::validateMetaInfo() found 8 Elements in DcmMetaInfo 'metinf'

I: Association Release

Sender command:

storescu -R -d -aec CTP localhost 4112 EnIm1_1.dcm

Sender's debug:

D: ======================= END A-ASSOCIATE-AC ======================

I: Association Accepted (Max Send PDV: 16372)

I: Sending file: EnIm1_1.dcm

D: DcmMetaInfo::checkAndReadPreamble() TransferSyntax="Little Endian Explicit"

D: DcmDataset::read() TransferSyntax="Little Endian Explicit"

I: Converting transfer syntax: Little Endian Explicit -> Little Endian Explicit

I: Sending Store Request (MsgID 1, PIe)

D: ===================== OUTGOING DIMSE MESSAGE ====================

D: Message Type : C-STORE RQ

D: Message ID : 1

D: Affected SOP Class UID : EnhancedPETImageStorage

D: Affected SOP Instance UID : 2.16.756.5.5.100.8323328.43296.1644938863.35.0

D: Data Set : present

D: Priority : medium

D: ======================= END DIMSE MESSAGE =======================

D: DcmDataset::read() TransferSyntax="Little Endian Implicit"

I: Received Store Response

D: ===================== INCOMING DIMSE MESSAGE ====================

D: Message Type : C-STORE RSP

D: Presentation Context ID : 1

D: Message ID Being Responded To : 1

D: Affected SOP Class UID : EnhancedPETImageStorage

D: Affected SOP Instance UID : 2.16.756.5.5.100.8323328.43296.1644938863.35.0

D: Data Set : none

D: DIMSE Status : 0x0000: Success

D: ======================= END DIMSE MESSAGE =======================

I: Releasing Association

Receiver command:

storescp -d +xa 4112

Receiver's debug:

I: Association Accepted (Max Send PDV: 16372)

I: Sending file: EnIm1_1.dcm

D: DcmMetaInfo::checkAndReadPreamble() TransferSyntax="Little Endian Explicit"

D: DcmDataset::read() TransferSyntax="Little Endian Explicit"

I: Converting transfer syntax: Little Endian Explicit -> Little Endian Explicit

I: Sending Store Request (MsgID 1, PIe)

D: ===================== OUTGOING DIMSE MESSAGE ====================

D: Message Type : C-STORE RQ

D: Message ID : 1

D: Affected SOP Class UID : EnhancedPETImageStorage

D: Affected SOP Instance UID : 2.16.756.5.5.100.8323328.43296.1644938863.35.0

D: Data Set : present

D: Priority : medium

D: ======================= END DIMSE MESSAGE =======================

D: DcmDataset::read() TransferSyntax="Little Endian Implicit"

I: Received Store Response

D: ===================== INCOMING DIMSE MESSAGE ====================

D: Message Type : C-STORE RSP

D: Presentation Context ID : 1

D: Message ID Being Responded To : 1

D: Affected SOP Class UID : EnhancedPETImageStorage

D: Affected SOP Instance UID : 2.16.756.5.5.100.8323328.43296.1644938863.35.0

D: Data Set : none

D: DIMSE Status : 0x0000: Success

D: ======================= END DIMSE MESSAGE =======================

I: Releasing Association

Received file with DCMTK's storescp:

-rw-rw-r-- 1 user group 4304155776 Feb 25 13:46 PIe.2.16.756.5.5.100.8323328.43296.1644938863.35.0

I prefer to use Conquest's dgate than DCMTK's storescp. Please suggest a fix. Thanks.

Sundar

dgate compilation failed in Linux (RHEL 7.7) for 1.15.0b and also for the lastest master from github.

I followed linuxmanual.pdf, and did

chmod 777 maklinux

./maklinux

choose option 3 or 5

<trimmed>

[sudo] password for xxxxx:

/usr/bin/install -c cjpeg /usr/local/bin/cjpeg

/usr/bin/install -c djpeg /usr/local/bin/djpeg

/usr/bin/install -c jpegtran /usr/local/bin/jpegtran

/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 -c -m 644 ./djpeg.1 /usr/local/man/man1/djpeg.1

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

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

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

Please ignore the errors above

Please choose DB type

1) mariadb 3) sqlite 5) precompiled

2) postgres 4) dbase 6) Quit

#? 3

/usr/bin/ld: cannot find -llua5.1

collect2: error: ld returned 1 exit status

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?

$ rpm -aq | grep lua

lua-5.1.4-15.el7.x86_64

lua-devel-5.1.4-15.el7.x86_64

Pre-compiled (option 5) from github's latest master worked. It was a 64-bit binary. The precompiled dgate under 1.15.0b was a 32-bit binary.

I really would like to compile. Why do I get "/usr/bin/ld: cannot find -llua5.1"? Am i missing any other library? Or is there is fix in maklinux file?

Please let me know the fix. Thanks.

CTP's dicom export sends data directly to conquest's AET & port.

>>The safest fix would be to set patient ID 0000000 to empy there
Conquest does this automatically when it sees data sets with no PatientID. And, I like I mentioned before, I would rather not see PatientID tag in anonymized data sets. We already anonymize PatientName.

If PatientID tag is mandatory in conquest, I can simply copy PatientName value into PatientID tag as work around.

I have data sets that are passed through Mirc CTP anonymizer (http://mircwiki.rsna.org/index.php?title=MIRC_CTP) end up in conquest server. These data sets have PatientID removed intentionally. Both the CTP and conquest severs are only stages in the anonymization pipeline. Anomymized data gets sent out to Horos PACS.

I use conquest instead of DCMTK's storescp since the storescp tends to create multiple directories for the same StudyInstanceUID. Data sets are CT images in thousands.

Problem is that the Conquest server re-introduces PatientID tag in data sets with 0000000 as value in them. Since I just want to use conquest server to receive the data sets, and not to store permanent, I have to do one extra step of removing these PatientID tags from data sets from several thousands of images, using DCMTK's dcmodify. I use FileNameSyntax as %name\%sopuid.dcm in dicom.ini.

Perhaps have PatientID as mandatory is the default behavior of any PACS. I am just wondering it would be ever possible not to introduce PatientID on data sets, when it is not present in data sets. Please let me know. Thanks.

OS and Mysql were sitting on 7200 rpm SATA drive. The dd read/write speeds were not the issue on this disk; I was getting ~160+ MB/s write speeds, and this should have yielded much more than 8 MR images per second; though I was writing to mdadm array. It had to do with FC17/mysql related issue. Instead of spending too much time troubleshooting the cause of slowness on an unsupported OS, I figured trying on latest stable platform would be the best and fastest option. Conquest data itself resides on mdadm as mentioned above. I just took the OS install (upgrade) opportunity to pull out spinning disk and replace with SSD.

Now performance is not an issue. Thanks.

Thank you both.

Before making any changes to MySQL database, I was getting only 4 MR images per second in storage. After database setting changes as shown below, it only improved to 8 MR images per second.
innodb_buffer_pool_size=10G
innodb_log_file_size = 512M
max_connections was not an issue.

Clearly, regen was not an option and OS/database issue had to be dealt with. Then on a test machine installed RHEL7.2 with mariadb, imported conquest database, compiled and installed dgate 1417d version. Operating system disk was a SSD. This setup gave speed of 65 MR images per second in storage. With this result, I switched operating system from FedoraCore17 to RHEL7.2. I also replaced spinning disk with SSD for OS disk. Now I am getting 65 images per second in storage, and I do have the above database settings in /etc/my.cnf.

Thanks again!

Hi,

Conquest's data storage is on a RAID storage (mdadm) and conquest data stored is now at 4.6 TB out of 12 TB space. Conquest which was performing fine before, now is performing very slow in storing and retrieving data. RAID is just fine and I get pretty good write/read speeds via dd tests. I tried to regen from stored data. I issued "dgate -v -r > /tmp/log 2>&1" on last Friday evening at 4:30 PM and it was still running at 1:40 PM on Tuesday (today). It would be nice if Linux version of dgate regen shows % completed in verbose mode. I aborted the regen and restored conquest database from /var/lib/mysql backup that I did before the regen. I am still faced with slow performance.

I would like to know what causes slowness in dgate's storing and retrieving. Also I would like to know how to make the regen process faster. I guess I can also do simply "./dgate -r" that is without verbose. Machine has 8-Core 3.6 GHz CPU and 16GB RAM. Other processes such as storescp etc., works faster on the same machine.

I would also like know if there any mysql specific configuration that people are using with conquest.

OS: 3.9.10-100.fc17.x86_64

./dgate -v
DGATE (1.4.17alpha, build Mon Dec 3 10:54:01 2012, bits 64) is running as threaded server
Database type: native MySQL connection

I can also take this to dgate 1.4.17d if that helps.

Please let me know. Thanks.

Sorry for the late update. This just turned out to be database issue, and regenerating it resolved it. Now it takes about 2.5sec which took 46min before, on the same machine.

MySQL 5.5.32-1.fc17.x86_64. Meanwhile RAM was upgraded to 20GB, and still I run into slow query the first time.
/etc/my.cnf has these:
[mysqld]
innodb_buffer_pool_size=14G
query_cache_type = 1
query_cache_size = 256M

First time run of this query took 46min. While running top command showed:
CPU usage at 99% and RAM usage at 10%

Second time run took only 2 seconds, due to settings above. Memory upgrade did help for repeated queries.

If there is a dgate setting to improve the performance of query involving NumberOfStudyRelatedInstances, please let me know since this more of a CPU intensive task. Thanks.

Sundar

I am running into extremely slow query response for dgate 1.4.17alpha with 2M images (46 min), especially when doing image count on all studies. My machine is Dell T5300, 64-bit, Dual core 2.6 GHz with only 4GB RAM, and I just about to upgrade to 20GB RAM. I have external 16TB software RAID-6 storage via eSATA for data and its performance is pretty good. OS is Fedora17. Performance started to slow down with increase in number of images, due to hardware resources.

Image count (Number of study related instances) query used (with dcmtk's findscu):
time findscu -aet MYAET -aec DGATE -S -k 0008,0052=STUDY -k 0020,000D -k 0020,1208 localhost 1234

With same OS, same dgate version, 2M images, and same external RAID storage, but with 8 core CPU and 16GB RAM, the same query response is about 6 seconds.

I would like to know what hardware resources are adequate for conquest with 2M images and up. Is there a hardware/DB/OS table for conquest put by users to take a look at, from performance standpoint?

Sundar

I have 1.4.17alpha running on Linux (Fedora 17), with ~2M images, with MySQL. I want to cold install Fedora 20 with MySQL, and run the latest 1.4.17d, with same data mount points (from external software RAID array), after a full backup.

1.4.17d compiled fine and tested fine on a Fedora20 test machine.

After cold install, since MySQL tables will be blank after cold install, I plan to do "dgate -r" to re-initialize database tables, and this could take a while. Is this the only recommended option?

Sundar

We are running dgate in Linux (3.6.10-2.fc17.x86_64). Recently we came across two crashes on different dates. I am reporting here the one from yesterday, and the dgate process got killed this time. I recall manually killing dgate and starting it last time. Restarting dgate works. But I would like to know the cause of this crash and/or debug options.

/var/log/messages file shows:
Nov 18 10:29:44 scpnode kernel: [350772.193163] dgate[15729]: segfault at 0 ip 0000000000497047 sp 00007f51e88b2cf0 error 4 in dgate[400000+1a3000]

PacsUser.log file shows:
Thu Nov 14 08:58:18 2013 "C-Store","CTXYZ "
Mon Nov 18 10:29:44 2013 "C-Move ","CTXYZ " <<<<<
Tue Nov 19 16:41:18 2013 "C-Store","CTXYZ "

dgate:
DGATE (1.4.17alpha, build Mon Dec 3 10:54:01 2012, bits 64) is running as threaded server
Database type: native MySQL connection

The is no record in PacsTrouble.log for this time frame. abrtd daemon catches this crash, but says "abrtd: Executable '/var/www/cgi-bin/conquest/dgate' doesn't belong to any package" and does not create any folder.

Thanks in advance.

Sundar

RESOLVED!

jogr and Marcel,

Yes, it appears to be 2.6.x Vs 3.x issue. Since Fedora14 kernel matched ubuntu 10.10 (2.6.35), I compiled dgate (version 1.4.17alpha) under Fedora14, and took everything to FC17, and I could send and receive. I even viewed the retrieved image to make sure. Thanks to tips from jogr.

One obstacle I found: libmysqlclient.so.16. Since Fedora17 had libmysqlclient.so.18, dgate was looking for libmysqlclient.so.16 even though I made a link on Fedora17 from /usr/lib64/mysql/libmysqlclient.so to /usr/lib64/mysql/libmysqlclient.so.16. I had to tar /usr/lib64/mysql/ folder on Fedora14 and extract it under /opt/local/lib64/mysql folder, and
export LD_LIBRARY_PATH=/opt/local/lib64/mysql
Then, cd /var/www/cgi-bin
./dgate -v -r
./dgate -v worked for send and movescu/retrieve operations.

jogr and Marcel,

Machine OS: Fedora Core 17 (3.5.2-3.fc17.x86_64). GCC version 4.7.0. I could not use jasper libs included in source. I used rpm's instead:
jasper-devel-1.900.1-19.fc17.x86_64
jasper-libs-1.900.1-19.fc17.x86_64

The problems reported by jogr and mine are the same; I found out that images received through movescu with bit-preserving mode were corrupted.

I also compiled v1.4.17alpha version on the above Linux. When I ran dgate, the problems were identical.
I could compile v1.14.15 only if I replace npipe.cpp from upper version (from v1.4.16). When I ran dgate, still the problems were identical.

If Conquest worked under Fedora, would be an ideal solution. I will look into ubuntu 10.10 next. Thank you for your help.

acrnema.map (with x.x replaced below):
HPSS_QR 127.0.0.1 5679 un
TESTPC 134.68.x.x 5001 un

dicom.ini:
[sscscp]
MicroPACS = sscscp
Edition = Personal

# Network configuration: server name and TCP/IP port#
MyACRNema = HPSS_QR
TCPPort = 5679

# Reference to other files: known dicom servers; database layout; sops
ACRNemaMap = acrnema.map
kFactorFile = dicom.sql
SOPClassList = dgatesop.lst

# Host for postgres or mysql only, name, username and password for database
SQLHost = localhost
SQLServer = conquest
Username = xxx
Password = xxxxx
PostGres = 0
MySQL = 1
SQLite = 0

UseEscapeStringConstants = 0
DoubleBackSlashToDB = 1
#IndexDBF = 1
#PackDBF = 0
#LongQueryDBF = 1000

# Configure database
TruncateFieldNames = 10
MaxFieldLength = 254
MaxFileNameLength = 255
FixPhilips = 0
FixKodak = 0
UIDPrefix = 99999.99999
EnableReadAheadThread = 1
PatientQuerySortOrder =
StudyQuerySortOrder =
SeriesQuerySortOrder =
ImageQuerySortOrder =
EnableComputedFields = 1
TCPIPTimeOut = 300
FailHoldOff = 60
RetryDelay = 100
QueueSize = 128
WorkListMode = 0
WorkListReturnsISO_IR_100 = 1
DebugLevel = 2
Prefetcher = 0
LRUSort =
AllowTruncate =
DecompressNon16BitsJpeg = 1
UseBuiltInJPEG = 1
IgnoreOutOfMemoryErrors = 0
PadAEWithZeros = 0
FileNameSyntax = 4

# Configuration of compression for incoming images and archival
DroppedFileCompression = un
IncomingCompression = un
ArchiveCompression = as

# Names of the database tables
PatientTableName = DICOMPatients
StudyTableName = DICOMStudies
SeriesTableName = DICOMSeries
ImageTableName = DICOMImages
DMarkTableName = DICOMAccessUpdates
RegisteredMOPDeviceTable = RegisteredMOPIDs
UIDToMOPIDTable = UIDToMOPID
UIDToCDRIDTable = UIDToCDRID

# Banner and host for debug information
PACSName = HPSS_QR
OperatorConsole = 127.0.0.1

# Configuration of disk(s) to store images
MAGDeviceThreshhold = 0
MAGDevices = 1
MAGDevice0 = /RAIDvol1/conquest/data

Hi,

I am using 1.4.16 in Linux with MySQL5.5.28. PACS receives data sets fine. Remote devices can query, but is not able to movescu or retrieve, even though dgate sees those devices correctly in acrnema.map. From the PACS, I can manually send images from data folder (saved in DICOM format) using dcmtk's storescu command to remote device's storescp just fine. But the same study when "pushed" from Conquest's web interface, or when movescu command was used on the remote device fails.

./dgate -v shows:
Sending file : /RAID01/conquest/data/XXXXXX/1.3.12.2.1107.5.2.32.35043.xxxxxxxxxxxxxx.dcm
Image Loaded from Read Ahead Thread, returning TRUE
Retrieve: remote connection dropped after 0 images, 953 not sent
C-Move (StudyRoot)
UPACS THREAD 27: ENDED AT: Wed Nov 28 14:45:58 2012
UPACS THREAD 27: TOTAL RUNNING TIME: 1 SECONDS

Remote station's movescu shows:
I: Received Store Request: MsgID 507, (MR)
RECV: .................................................................................................................................................E: DcmElement: Unknown Tag & Data (736c,2265) larger (572661794) than remaining bytes (586632) in file, premature end of stream
W: DIMSE Warning: (HPSS_QR,TESTPC): DIMSE receiveDataSetInMemory: dset->read() Failed (Invalid stream)
E: Store SCP Failed: 0006:020d DIMSE Failed to receive message
E: DIMSE failure (aborting sub-association): 0006:020d DIMSE Failed to receive message
E: DIMSE failure (aborting sub-association): 0006:020d DIMSE Failed to receive message
E: 0006:020c DIMSE Read PDV failed
E: 0000:0000 Normal
I: ===================== INCOMING DIMSE MESSAGE ====================
I: Message Type : C-MOVE RSP
I: Message ID Being Responded To : 1
I: Affected SOP Class UID : MOVEStudyRootQueryRetrieveInformationModel
I: Remaining Suboperations : 0
I: Completed Suboperations : 0
I: Failed Suboperations : 953
I: Warning Suboperations : 0
I: Data Set : none
I: DIMSE Status : 0xfe00: Cancel: Suboperations terminated due to Cancel Indication
I: ======================= END DIMSE MESSAGE =======================
I: Releasing Association

EDIT: The problem seems be to in Transfer syntax. When I used movescu in bit preserving mode, I got all of the images.

Hi,

Thanks. I would like to share that the following worked for me:

[lua]
QueryConverter0 = if ((Data.PatientID=="*") or (Data.PatientID==nil)) and ((Data.StudyDate=="*") or (Data.StudyDate==nil)) and ((Data.PatientName=="*") or (Data.PatientName==nil)) then script('destroy') end

Now for example:
findscu -v -aec HPSS_QR -aet HPSS -S -k 0008,0052=STUDY -k 0010,0020 -k 0008,0020 -k 0010,0010=* -k 0020,000d localhost 5679

Result:
C-Find RSP: MsgID: 1 [Status=Failed: UnableToProcess]

Hi,

In dicom.ini :
[lua]
QueryConverter0 = if (Data.Date=='') or (Data.PatientID=='') then script('reject') end

Shows no effect; returns query results with all PatientIDs and StudyDates. I tried with ./dgate -v for the following queries using dcmtk's findscu:
findscu -v -aec HPSS_QR -aet HPSS -S -k 0008,0052=STUDY -k 0010,0020 -k 0008,0020 -k 0010,0010 -k 0020,000d localhost 5679
findscu -v -aec HPSS_QR -aet HPSS -S -k 0008,0052=STUDY -k 0010,0020 -k 0008,0020="" -k 0010,0010 -k 0020,000d localhost 5679
findscu -v -aec HPSS_QR -aet HPSS -S -k 0008,0052=STUDY -k 0010,0020 -k 0008,0020='' -k 0010,0010 -k 0020,000d localhost 5679

Lua script in general works, since I was able to see results of this:
[lua]
QueryConverter0 = print("====>>",Association.Calling, Association.Called, Data.PatientID)

How can I stop blind/wild queries? Please let me know. Thanks.

I plan to store both raw data and image data in conquest PACS server version 1.4.16 in Linux. I will be using dcmtk's movescu to pull data. Is there a way to establish a rule depending on calling AET to filter out raw data or to include raw data when sending those images from PACS. For example, when modalities pull a study, both image and raw data sets should get pulled. But when a different application query and pull the same study, I want just the image data pulled. Would it be possible at PACS?

Getting everything and deleting raw data sets when applicable is another way, but is very inefficient.

What options exist and how to implement them? Pointers are fine.

Thanks.