Duplicate found in DICOMStudies

tmalina · September 4, 2024 at 2:10 PM

Hello,

we have Conquest v 1.5.0d working and we recive from onother radiology lab DICOM pictures. Sometimes I have following problem. After receeiving first pictures for a new patient, the patient shown twices or more in database. For Example from SQL-Table dicomstudies (I anonymized the patientdata) :


1.2.840.113619.6.95.31.0.3.4.1.5030.13.37289214	20240904	100439	0	MR_**	37289214	EP-12	0**Y	**	MR	^^^^	YYYYMMDD	F	123456	1725443936	NULL	NULL	NULL
1.2.840.113619.6.95.31.0.3.4.1.5030.13.37289214	20240904	100439	0	MR_**	37289214	EP-12	0**Y	**	MR	^^^^	YYYYMMDD	F	123456	1725443936	NULL	NULL	NUL

and after this we get following messages in logfile for each receeived picture in the study:

04.09.2024 11:59:12 [EPI_UKE] ***Duplicate found in DICOMStudies WHERE StudyInsta='1.2.840.113619.6.95.31.0.3.4.1.5030.13.37289214'

04.09.2024 11:59:12 [EPI_UKE] ***Error saving to SQL: 123456\1.3.12.2.1107.5.2.19.45024.2024090410052056083462517.0.0.0_0004_000001_17254439526f64.dcm

Is there some Race-Condition withe the SQL-Commands? Do You have an ideea what can wo do?

Thanks,

Thomas

marcelvanherk · September 4, 2024 at 2:46 PM

Hi Thomas,

I have never seen this. What database are you using?

Marcel

marcelvanherk · September 4, 2024 at 2:55 PM

Is your partner lab sending pictures over many associations at once?

You can see this is the server log. It may be useful to share the server log before the issue appears.

Marcel

tmalina · September 4, 2024 at 4:10 PM

Hi,

start of logfile für this case:

04.09.2024 11:59:11 [SERVER]

04.09.2024 11:59:11 [SERVER] UPACS THREAD 4184: STARTED AT: Wed Sep 04 11:59:11 2024

04.09.2024 11:59:11 [SERVER] *** connection terminated

04.09.2024 11:59:11 [SERVER] UPACS THREAD 4184: ENDED AT: Wed Sep 04 11:59:11 2024

04.09.2024 11:59:11 [SERVER] UPACS THREAD 4184: TOTAL RUNNING TIME: 0 SECONDS

04.09.2024 11:59:11 [SERVER]

04.09.2024 11:59:11 [SERVER] UPACS THREAD 4185: STARTED AT: Wed Sep 04 11:59:11 2024

04.09.2024 11:59:11 [SERVER] *** connection terminated

04.09.2024 11:59:11 [SERVER] UPACS THREAD 4185: ENDED AT: Wed Sep 04 11:59:11 2024

04.09.2024 11:59:11 [SERVER] UPACS THREAD 4185: TOTAL RUNNING TIME: 0 SECONDS

04.09.2024 11:59:11 [SERVER]

04.09.2024 11:59:11 [SERVER] UPACS THREAD 4186: STARTED AT: Wed Sep 04 11:59:11 2024

04.09.2024 11:59:11 [SERVER] *** connection terminated

04.09.2024 11:59:11 [SERVER] UPACS THREAD 4186: ENDED AT: Wed Sep 04 11:59:11 2024

04.09.2024 11:59:11 [SERVER] UPACS THREAD 4186: TOTAL RUNNING TIME: 0 SECONDS

04.09.2024 11:59:11 [SERVER]

04.09.2024 11:59:11 [SERVER] UPACS THREAD 4187: STARTED AT: Wed Sep 04 11:59:11 2024

04.09.2024 11:59:11 [SERVER] Calling Application Title : "AE_SEND "

04.09.2024 11:59:11 [SERVER] Called Application Title : "SERVER "

04.09.2024 11:59:11 [SERVER] Application Context : "1.2.840.10008.3.1.1.1", PDU length: 28672

04.09.2024 11:59:11 [SERVER] Presentation Context 0 "1.2.840.10008.5.1.4.1.1.4" 1

04.09.2024 11:59:11 [SERVER]

04.09.2024 11:59:11 [SERVER] UPACS THREAD 4188: STARTED AT: Wed Sep 04 11:59:11 2024

04.09.2024 11:59:11 [SERVER] Calling Application Title : "AE_SEND "

04.09.2024 11:59:11 [SERVER] Called Application Title : "SERVER "

04.09.2024 11:59:11 [SERVER] Application Context : "1.2.840.10008.3.1.1.1", PDU length: 28672

04.09.2024 11:59:11 [SERVER] Presentation Context 0 "1.2.840.10008.5.1.4.1.1.4" 1

04.09.2024 11:59:12 [SERVER] Importconverter0.0: sets preferred storage to MAG0

04.09.2024 11:59:12 [SERVER]

04.09.2024 11:59:12 [SERVER] UPACS THREAD 4189: STARTED AT: Wed Sep 04 11:59:11 2024

04.09.2024 11:59:12 [SERVER] Calling Application Title : "AE_SEND "

04.09.2024 11:59:12 [SERVER] Called Application Title : "SERVER "

04.09.2024 11:59:12 [SERVER] Application Context : "1.2.840.10008.3.1.1.1", PDU length: 28672

04.09.2024 11:59:12 [SERVER] Presentation Context 0 "1.2.840.10008.5.1.4.1.1.4" 1

04.09.2024 11:59:12 [SERVER] Written file: H:\conquest\123456\1.3.12.2.1107.5.2.19.45024.2024090410052055999662507.0.0.0_0002_000001_17254439526f63.dcm

04.09.2024 11:59:12 [SERVER] Written file: H:\conquest\123456\1.3.12.2.1107.5.2.19.45024.2024090410052056054262513.0.0.0_0003_000001_17254439526f62.dcm

04.09.2024 11:59:12 [SERVER] ExportConverter6.1: forward H:\conquest\123456\1.3.12.2.1107.5.2.19.45024.2024090410052055999662507.0.0.0_0002_000001_17254439526f63.dcm to AE_DEST

04.09.2024 11:59:12 [SERVER] Importconverter0.0: sets preferred storage to MAG0

04.09.2024 11:59:12 [SERVER] ***Duplicate found in DICOMStudies WHERE StudyInsta = '1.2.840.113619.6.95.31.0.3.4.1.5030.13.37289214'

04.09.2024 11:59:12 [SERVER] ***Error saving to SQL: 123456\1.3.12.2.1107.5.2.19.45024.2024090410052056083462517.0.0.0_0004_000001_17254439526f64.dcm

04.09.2024 11:59:12 [SERVER] Importconverter0.0: sets preferred storage to MAG0

04.09.2024 11:59:12 [SERVER] ***Duplicate found in DICOMStudies WHERE StudyInsta = '1.2.840.113619.6.95.31.0.3.4.1.5030.13.37289214'

04.09.2024 11:59:12 [SERVER] Exportconverter6.2: queued delete imag - (single object 20240904-20240904 of 123456) to

04.09.2024 11:59:12 [SERVER] ExportConverter6.1: forward H:\conquest\123456\1.3.12.2.1107.5.2.19.45024.2024090410052056054262513.0.0.0_0003_000001_17254439526f62.dcm to AE_DEST

04.09.2024 11:59:12 [SERVER] ***Error saving to SQL: 123456\1.3.12.2.1107.5.2.19.45024.2024090410052056054262513.0.0.0_0003_000002_17254439526f65.dcm

04.09.2024 11:59:12 [SERVER] UPACS THREAD 4189: ENDED AT: Wed Sep 04 11:59:12 2024

04.09.2024 11:59:12 [SERVER] UPACS THREAD 4189: TOTAL RUNNING TIME: 1 SECONDS

04.09.2024 11:59:12 [SERVER] Importconverter0.0: sets preferred storage to MAG0

04.09.2024 11:59:12 [SERVER] ***Duplicate found in DICOMStudies WHERE StudyInsta = '1.2.840.113619.6.95.31.0.3.4.1.5030.13.37289214'

04.09.2024 11:59:12 [SERVER] UPACS THREAD 4188: ENDED AT: Wed Sep 04 11:59:12 2024

04.09.2024 11:59:12 [SERVER] UPACS THREAD 4188: TOTAL RUNNING TIME: 1 SECONDS

04.09.2024 11:59:12 [SERVER] ***Error saving to SQL: 123456\1.3.12.2.1107.5.2.19.45024.2024090410052055999662507.0.0.0_0002_000002_17254439526f66.dcm

04.09.2024 11:59:12 [SERVER] UPACS THREAD 4187: ENDED AT: Wed Sep 04 11:59:12 2024

04.09.2024 11:59:12 [SERVER] UPACS THREAD 4187: TOTAL RUNNING TIME: 1 SECONDS

I'm using an older DB

Server-Typ: MariaDB
Server-Version: 10.1.19-MariaDB - mariadb.org binary distribution

marcelvanherk · September 4, 2024 at 6:16 PM

Well the client is sending over 3 connections at once. This should not be a problem but apparently it is. How reproducible it this issue?

tmalina · September 5, 2024 at 9:13 AM

Hi,

external lab is sending the data since monday this week, and till now I noticed about 3 from 10 cases.

Will it be a possible sollution if I define StudyInsta field unique in the table dicomstudies ?

marcelvanherk · September 5, 2024 at 11:21 AM

Ok,

this is clearly a bug. Can you instruct them to use only one channel to send the data for now, this is likely a setting in the PACS? If you add unique the saving will likely fail as well. I will try to fix this with some priority, but it still may take a few weeks.

Marcel

tmalina · September 6, 2024 at 9:41 AM

Hi,

I will pass the information to the lab.

I made changes in the DB:

Code

ALTER TABLE `dicompatients` ADD UNIQUE KEY `PatientID` (`PatientID`);
ALTER TABLE `dicomstudies` ADD UNIQUE KEY `StudyInsta` (`StudyInsta`);

I will monitor this and I give rosponse to the behavior.

Thanks,

Thomas

marcelvanherk · September 11, 2024 at 9:33 AM

Hi,

StudyInsta etc is used as PRIMARY KEY. That should make it UNIQUE, doesn't it?

Marcel

tribb · October 21, 2025 at 9:28 AM

Hey Marcel,

I work in the team of tmalina and have been asked to look into this problem and the Conquest server.
Unfortunately, the issue still persists and is becoming increasingly noticeable, with more cases coming from the other lab. About 10–15% of the transfers are being dropped with the same “Duplicate found” error.

I’m in contact with the other lab, but for now, there is no useful information. They will investigate further.

Is there a way to fix or contain this issue on our side in the meantime? Maybe by limiting the threads/channels for a while, or forcing the DB to merge instead of dropping the packages?

Any help is appreciated.

marcelvanherk · October 21, 2025 at 9:50 AM

Hi,

I think to best way to avoid the issue for now is to ask the other lab to send on one connection only. Or if the role of this server is just a forwarder to run it without a database.

Would you in the meantime mind upgrading to the dgate64.exe of 1.5.0f? It can be dropped in without changing anything. This makes it easier to find the error.

Marcel

tribb · October 21, 2025 at 11:29 AM

Thanks for the quick response.

I updated the dgate64 to the 1.5.0.f version.

I'll also reached out to the other lab with the one connection only request.

tribb · October 27, 2025 at 9:11 AM

Good morning,

Unfortunately, the recent update of dgate64 caused some issues, so we had to revert to version 1.5.0d.

the idea of using a forwarder without a database would work well for this connection and server. The database on this server is temporary anyway, so we could easily operate without it. especially if it helps prevent files from being dropped from the other lab.

Is the “DICOM Routing without Database” section in the manual is still the best way to configure this setup for 1.5.0d?

marcelvanherk · October 27, 2025 at 9:46 AM

Sure the manual is up to date,

Curious as to what the issues are in 1.50f.

best regards,

Marcel

marcelvanherk · October 27, 2025 at 9:53 AM

Another solution may be to try sqlite.

tribb · November 5, 2025 at 9:41 AM

Hey,

The two crashes while running 1.50f:

20251007 13:37:37 ***Failed to Listen () - bind error
20251007 13:38:52 ***Failed to Listen () - bind error
20251007 13:42:03 ***preretrieve/forward xxx to: remote DICOM error

20251011 12:20:04 ***Error in Accept() function call

Nothing else was logged for hours before either crash.

It looks like there may have been a mistake during the manual update on this long-running server. Other instances of 1.50f are running fine, so I suspect a clean install (instead of the manual update) should resolve the issue.

On a positive note, adding an ImportConverter(forward + destroy) for data sent by the specific lab, while keeping the database active, has been working great so far.

Thanks again for your help,

marcelvanherk · November 5, 2025 at 10:33 AM

Hi,

I expect there was a ghost dgate64.exe running that blocked the DICOM port.

Good to hear the issue has been circumvented. I will try to fix the issue anyway when I have a bit more time.

Marcel

Participate now!