- # This file contains configuration information for the DICOM server
- # Do not edit unless you know what you are doing
- MicroPACS = sscscp
- # Network configuration: server name and TCP/IP port#
- MyACRNema = DICOMARCH
- TCPPort = 5566
- # Host, database, username and password for database
- SQLHost = 127.0.0.1:5432
- SQLServer = conquest
- Username = redacted
- Password = redacted
- Postgres = 1
- DoubleBackSlashToDB = 1
- UseEscapeStringConstants = 1
- # Configure server
- ImportExportDragAndDrop = 1
- KeepAlive = 60
- ZipTime = 05:
- UIDPrefix = 1.2.8184.108.40.20680043.2.135.736520.62657947
- EnableComputedFields = 1
- WatchFolder = F:\dicom_arch\data\incoming\
- FileNameSyntax = %studydate[0,3]\%studydate[4,5]\%studydate[6,7]\%id\%modality_%studyuid\%seriesid_%sopuid.dcm
- # Configuration of compression for incoming images and archival
- DroppedFileCompression = j2
- IncomingCompression = j2
- ArchiveCompression = j2
- # For debug information
- PACSName = DICOMARCH
- OperatorConsole = 127.0.0.1
- DebugLevel = 0
- # Configuration of disk(s) to store images
- MAGDeviceFullThreshHold = 30
- MAGDevices = 1
- #MAGDevice0 = D:\dicom_arch\data\
- MAGDevice0 = \\ARCHIWUM\pacs_archive\arch_studies\
- ImportConverters = 1
- # it's not working or dgate crashes before it gets to this point
- ImportConverter0 = ifequal "%m", "SEG"; destroy;
I made a quick vid showing how it reacts to 'safe' and 'crash' dcm
sorry for low quality but I wanted to keep the recording small.
It's the whole process from starting the service, then dropping safe.dcm into incoming (shown in the log) and then dropping crash.dcm... service just stops and wont start until I remove the crash.dcm from the incoming folder.
I forgot to mention (not sure if relevant) but this is being run as a service.
Crash is totally silent. No mention of it in the dgate log. The service just dies and the only mention of this is in the system log
I just tested this using debug 4 in the gui and this is what I get:Code
- [DICOMARCH] 9999,0300 24 LO ConquestConsoleText "set debug level from GUI"
- [DICOMARCH] 9999,0400 12 LO ConquestConsoleComma "debuglevel:4"
- [DICOMARCH] set debug level from GUI
- [DICOMARCH] JPEG compress started.
- [DICOMARCH] Debug[CompressJPEG]: H = 512, W = 512, Bits = 1 in 1, Components = 1, Frames = 275
- [DICOMARCH] JPEG Lossless
- [DICOMARCH] , H = 512, W = 512, Bits = 8 in 8, Frames = 275
- *** Restarted dead server after error 7
- [DICOMARCH] Stopped zip and cleanup thread
- [DICOMARCH] User interface test: local server is running!
setting debug to 4, then dropping file in the 'incoming' then 3 lines and it dies and restarts after few sec
(I have to remove the file from incoming otherwise the service won't even start - throws 'access denied' and dies)
7 848 448 bytes
 it's dgate64.exe just to be clear. (there is no dgate.exe.. not sure why. I might have skipped it)
[edit2] I think I found the original file - it's from 3.V.2019 00:05
Here is the original file. It crashes my dgate64 1.5.0.
and here is the same file after it was received by dgate 1.4.17d. It was somehow 'repaired' and is no longer crashing 1.5
I have a problem with dgate crashing upon receiving a 'SEG' type modality files. Typical study processed by Syngo contains few 'CT' series, few 'SR', and few 'SEG'.
From what I understand those 'SEG' files are some internal Syngovia files - I'm not even sure they are a proper dicom files to be honest.
Normally doctors are sending only 'ct' series to pacs, leaving out all others. However sometimes they miss-click or forget to uncheck those extra series so Syngo is trying to send all of them to pacs.
The problem is that this is totally crashing dgate64. There is nothing is the log but I looked only into standard log, I may try to set debug to 4 and force a crash again if you'd like.
System log however shows app crash as:
Strange.. cause dgate is running just fine otherwise so I have no idea what is it talking about.. access to what?
oh and also maybe this will help you:
I also tried to send the same 'SEG' file to older dgate server (this one is still running on 1.4.17d) and this one did not crash probably because it was caught by importconverter:Code
- 20190528 20:33:18 UPACS THREAD 16248: STARTED AT: Tue May 28 20:33:17 2019
- 20190528 20:33:18 Calling Application Title : "SYNGOVIA "
- 20190528 20:33:18 Called Application Title : "ARPACS1 "
- 20190528 20:33:18 Application Context : "1.2.840.10008.3.1.1.1", PDU length: 32768
- 20190528 20:33:18 Presentation Context 0 "1.2.840.10008.5.1.4.220.127.116.11" 0
- 20190528 20:33:18 Presentation Context 1 "1.2.840.10008.5.1.4.18.104.22.168" 0
- 20190528 20:33:18 Presentation Context 2 "1.2.840.10008.5.1.4.22.214.171.124" 0
- 20190528 20:33:18 Presentation Context 3 "1.2.840.10008.5.1.4.126.96.36.199" 0
- 20190528 20:33:18 Presentation Context 4 "1.2.840.10008.5.1.4.188.8.131.52" 0
- 20190528 20:33:18 Presentation Context 5 "1.2.840.10008.5.1.4.184.108.40.206" 0
- 20190528 20:33:18 Presentation Context 6 "1.2.840.10008.5.1.4.220.127.116.11" 0
- 20190528 20:33:18 Presentation Context 7 "1.2.840.10008.5.1.4.18.104.22.168" 0
- 20190528 20:33:18 Presentation Context 8 "1.2.840.10008.5.1.4.22.214.171.124" 0
- 20190528 20:33:18 Presentation Context 9 "1.2.840.10008.5.1.4.126.96.36.199" 1
- 20190528 20:33:18 Presentation Context 10 "1.2.840.10008.5.1.4.188.8.131.52" 1
- 20190528 20:33:18 Presentation Context 11 "1.2.840.10008.5.1.4.184.108.40.206" 1
- 20190528 20:33:18 Presentation Context 12 "1.2.840.10008.5.1.4.220.127.116.11" 1
- 20190528 20:33:18 Presentation Context 13 "1.2.840.10008.5.1.4.18.104.22.168" 1
- 20190528 20:33:18 Presentation Context 14 "1.2.840.10008.5.1.4.22.214.171.124" 1
- 20190528 20:33:18 Presentation Context 15 "1.2.840.10008.5.1.4.126.96.36.199" 1
- 20190528 20:33:18 Presentation Context 16 "1.2.840.10008.5.1.4.188.8.131.52" 1
- 20190528 20:33:18 Presentation Context 17 "1.2.840.10008.5.1.4.184.108.40.206" 1
- 20190528 20:33:18 [CompressJPEGImage]: JPEG compression not allowed for PR/SR/RT
- 20190528 20:33:18 Importconverter0.1: destroyed received image
- 20190528 20:33:19 UPACS THREAD 16248: ENDED AT: Tue May 28 20:33:19 2019
- 20190528 20:33:19 UPACS THREAD 16248: TOTAL RUNNING TIME: 2 SECONDS
No idea why it was caught by 'SR' filter ... I'm pretty sure it's 'SEG' not 'SR' (at least Syngo shows it as 'SEG' not 'SR')
I tried to add same filter to my 1.5.0 but with no effect.. it crashed.
I'd like to send you a sample of this SEG file but I have no idea how to extract it from Syngo.. Efilm is not accepting it. I may try to remove the SR filter from the old server and see what will happen. Maybe it'll be able write it to hdd.
After much googling yesterday I came up with exactly same answer - this seems to be an OS problem and most popular fix is to set/change those registry values:Code
- Get-Item 'HKLM:\System\CurrentControlSet\Services\Tcpip\Parameters' | New-ItemProperty -Name MaxUserPort -Value 65534 -Force | Out-Null
- Get-Item 'HKLM:\System\CurrentControlSet\Services\Tcpip\Parameters' | New-ItemProperty -Name TcpTimedWaitDelay -Value 30 -Force | Out-Null
- Get-Item 'HKLM:\System\CurrentControlSet\Services\Tcpip\Parameters' | New-ItemProperty -Name TcpNumConnections -Value 16777214 -Force | Out-Null
- Get-Item 'HKLM:\System\CurrentControlSet\Services\Tcpip\Parameters' | New-ItemProperty -Name TcpMaxDataRetransmissions -Value 5 -Force | Out-Null
This was my goto solution. Right now I'm waiting for to problem to occur - I want to catch this while it's happening and see which application is causing this (I expect few thousands open ports or sth like that). After that I'll implement those registry changes and see if it helps.
I will let you know.
 unfortunately issue hasn't appeared in past few days so I'm unable to confirm the cause nor test the solution. I'll update this post again if it'll happen again in the future.
It looks like this is just a coincidence and has nothing to do with the 1.4.x -> 1.5.0 migration.
From what I understand this is an error related to the OS running out (hitting the user limit?) of ports (sockets?).
This would explain why the error is showing up and disappearing 'randomly' without my intervention.
Probably one of the applications going crazy.. hard to say. I'll try to catch it while it's happening and try to confirm this.
So the bottom line is that it's probably not your fault
 I wonder why it's not happening when receiving images. Just on incoming queries. I guess the receiver is always bound to one static port while incoming queries try to open new port to send the response? Does it make sense? It would explain everything...
I recently updated to 1.5.0-alpha-test2, build Fri May 10 20:42:19 2019, bits 64
This messages started to show up (2 variants).
Problems seems to come and go away on it's own (I guess we are hovering around some kind of limit)
Server is receiving images with no error but is not responding to queries while this is happening.
There are no errors in the postgres log
Is this 1.5.0 specific ? I've never ever seen this error beforeCode
- 20190521 09:51:20
- 20190521 09:51:20 UPACS THREAD 24770: STARTED AT: Tue May 21 09:51:20 2019
- 20190521 09:51:20 Calling Application Title : "efilm "
- 20190521 09:51:20 Called Application Title : "dicomarch "
- 20190521 09:51:20 Application Context : "1.2.840.10008.3.1.1.1", PDU length: 64234
- 20190521 09:51:20 Presentation Context 0 "1.2.840.10008.5.1.4.220.127.116.11" 1
- 20190521 09:51:20 Presentation Context 1 "1.2.840.10008.5.1.4.18.104.22.168" 1
- 20190521 09:51:20 Presentation Context 2 "1.2.840.10008.5.1.4.22.214.171.124" 1
- 20190521 09:51:20 Presentation Context 3 "1.2.840.10008.5.1.4.126.96.36.199" 1
- 20190521 09:51:20 Presentation Context 4 "1.2.840.10008.5.1.4.188.8.131.52" 1
- 20190521 09:51:20 Presentation Context 5 "1.2.840.10008.5.1.4.184.108.40.206" 1
- 20190521 09:51:20 Presentation Context 6 "1.2.840.10008.5.1.4.220.127.116.11" 0
- 20190521 09:51:20 (StudyRootQuery) search level: STUDY
- 20190521 09:51:20 *** could not connect to server: No buffer space available (0x00002747/10055)
- Is the server running on host "127.0.0.1" and accepting
- TCP/IP connections on port 5432?
- 20190521 09:51:20 C-Find (StudyRoot) located 0 records
- 20190521 09:51:20 UPACS THREAD 24770: ENDED AT: Tue May 21 09:51:20 2019
- 20190521 09:51:20 UPACS THREAD 24770: TOTAL RUNNING TIME: 0 SECONDS
Thank you for all the help.
I'll start with second server on the remote location - 32k PDU should help ( I hope ).
As for the lua I do understand what you are trying to do here but I'm not sure I'm brave enough to do it this way.
I was hoping that this would a bit easier (like an option in dicom.ini ) but oh well.. if first solution won't work then I might still try the lua parallelization.
Unfortunately I can't see any difference using 1.5.0 (unless I should do sth more than the usual .exe/dll replacements)Quote
you could also instruct conquest to send data in parallel, using multiple moves at once.
This sounds interesting... Could you please elaborate a bit about this? Would it be possible to respond to a clients query with parallel move?? like, for example, send each series simultaneously?
I'm not sure how would it work... can this be done using lua? If possible this would speed up sending considerably (not so long ago I was experimenting with this a bit and found out that speed gain from using 4 parallel 'lines' gave me close to 4x the speed. I expected to hit some diminishing returns at this point but no - the gain was almost linear.
Thx for quick answer
Pretty much all the clients report 16k PDU except for Efilm which uses 64k PDU size.
Is it possible to force larger blocks? or is this one of those things which has to be negotiated and accepted by both sides (server and client)?
This is becoming a real issue because with each passing year more and more doctors prefer to work from remote locations.
Right now it's sometimes (if a client has about 50ms latency) faster to zip whole study, download it via shared folder and then unpack it than send it via dicom protocol.
I'll try 1.5.0 and compare the results.
We have a doctor in a remote location connected via vpn. He has a decent net - speed test showing around 40/8Mbit connection with ping oscillating in 15-25ms range (stable, no packet drops).
The problem is the speed - it's nowhere near the network cap. From what I can see it's about 2-3 images per second (700-800kb/s)
At the same time I can download the same study at a rate of 20+ images per second (5-6Mb/s).
Same vpn, same client (radiant), same server (1.4.19d1). The only real difference is that I'm much closer so much better ping to the server (100/100Mbit with 2ms ping).
The interesting thing is that he can do a little trick using Horus/Osirix - they have an option to download a single series - so basically he can order the download of each series separately >at the same time< making whole process parallel and thus MUCH faster.
So clearly it IS possible to download the study faster (I can do it, and he can do it using this trick) so the network bandwidth is not the problem. Nor the server, nor the client..
The only thing left is latency and network overhead.
Now the 100$ question - is there a way to speed up sending? Some setting maybe? Some way to make it parallel? Is dicom standard really this sensitive to latency or am I missing sth here?
Lately I had to add 2 new exporters and since then strange things started to happen.
Until now I was using this set of 7 exporterconverters:Code
- ExportConverters =7ExportModality0 =CTExportConverter0 =xx.exeExportModality1 =MRExportConverter1 =xx.exeExportModality2 =CRExportConverter2 =xx.exeExportModality3 =USExportConverter3 =xx.exeExportModality4 =MGExportConverter4 =xx.exe; forward compressed as j2 to AIO;ExportConverter5 = ifequal "%V0032,1033", "CZM"; forward compressed as j2 to FWD;ExportModality6 =PXExportConverter6 =xx.exe
and everything was working as expected.. for years, but as soon as I changed ExportConverters to 9 and added this:
strange hang ups started to happen. It works for some time and then suddenly I get a call from CT technicians telling me that they can't send images to pacs... so I restarted service and it works again for few hours.. then again it suddenly stops accepting images.
Am I missing some obvious mistake in config here or..?
dgate ver 1.4.17d
I'm not sure I understand. I just tested this on both viewers and outcome is still the same.
Query from Radiant:
1) smith generates -> LIKE E'%smith%'
2) *smith* generates the same -> LIKE E'%smith%'
Query from Efilm:
1) smith generates -> LIKE E'SMITH%'
2) *smith* generates -> LIKE E'%SMITH%%'
In both cases resulting db queries are case sensitive, so I'm not sure what you meant by this.
The only way this could work is by using ILIKE instead of LIKE, but ILIKE has it's own problems - if I remember correctly it has trouble using index scans and seq scans on big db can be painful
I'd like to ask how do you deal with case sensitive name queries from different dicom clients. For example:
Patient name in my pg database looks like this: "John Smith"
Let's say doctor typed in "smith" and hit search button.
Now, depending on the viewer, there are few cases:
1) some dicom viewers ( like Efilm for example) ask for "SMITH" (to be more precise: ...WHERE DICOMStudies.PatientNam LIKE E'SMITH%'...)
2) other viewers (like Radiant) leave everything as it was so it'll ask for "smith"
so.. they both return 0 results.
For now I can't even be sure if the name format in my db is always consistent/correct - 99% of the time study is made based on worklist entry so it'll be like 'John Smith' but sometimes sth goes wrong and study is made manually.. so I can not guarantee that someone didn't type in "John SMITH' for example.
This can be easily fixed by ImportConverter using '^' ... so let's say I'll use it to guarantee that ALL entries in db will be in upper cases.
Case 1 fixed.. but what about case 2?
Can I force Conquest to always ask db for upper('smith')? as in ...WHERE DICOMStudies.PatientNam LIKE upper(E'smith%')\
can I modify incoming c-find and replace 'smith' with 'SMITH' on the fly?
maybe there is another easy solution I can't see?