Conquest sending tons of images instead of one

    Hello,


    I put a server in production environment with conquest 1.4.17c (with only one change: a small fix regarding PDU size you gave me some weeks ago).
    There are around 60.000 images in the system.


    From the dicom viewer side, we are able to query but each time we try to start the C-move, conquest returns tons of images to send !!!??
    example below: send query, return 4 studies, select one study with one serie, then conquest is sending 3800 images but there are related to the wrong patient !!


    I checked several times the configuration but cannot find any trouble. I was using 1.4.14 in the past, so maybe my previous dicom.ini was not correct. Anyway after starting with the default dicom.ini included I got the same results...


    I believe this is a config issue... What do you recommend ?
    Should I revert to the standard 1.4.17c ?


    Thank you for your help!


    my serverstatus.log

    Code
    Tue Dec 10 07:18:45 2013 Started zip and cleanup threadTue Dec 10 07:18:45 2013 DGATE (1.4.17c, build Tue Dec  3 18:18:06 2013, bits 64) is running as threaded serverTue Dec 10 07:18:45 2013 Database type: native MySQL connectionTue Dec 10 07:42:30 2013 Tue Dec 10 07:42:30 2013 UPACS THREAD 0: STARTED AT: Tue Dec 10 07:42:30 2013Tue Dec 10 07:42:30 2013 	Calling Application Title : "IQVIEW2         "Tue Dec 10 07:42:30 2013 	Called Application Title : "SERV         "Tue Dec 10 07:42:30 2013 	Application Context : "1.2.840.10008.3.1.1.1", PDU length: 16384Tue Dec 10 07:42:30 2013 	Presentation Context 0 "1.2.840.10008.5.1.4.1.2.2.1" 1Tue Dec 10 07:42:30 2013 (StudyRootQuery) search level: STUDY Tue Dec 10 07:42:30 2013 C-Find (StudyRoot) located 4 recordsTue Dec 10 07:42:31 2013 UPACS THREAD 0: ENDED AT: Tue Dec 10 07:42:31 2013Tue Dec 10 07:42:31 2013 UPACS THREAD 0: TOTAL RUNNING TIME: 1 SECONDSTue Dec 10 07:42:34 2013 Tue Dec 10 07:42:34 2013 UPACS THREAD 1: STARTED AT: Tue Dec 10 07:42:34 2013Tue Dec 10 07:42:34 2013 	Calling Application Title : "IQVIEW2         "Tue Dec 10 07:42:34 2013 	Called Application Title : "SERV         "Tue Dec 10 07:42:34 2013 	Application Context : "1.2.840.10008.3.1.1.1", PDU length: 16384Tue Dec 10 07:42:34 2013 	Presentation Context 0 "1.2.840.10008.5.1.4.1.2.2.1" 1Tue Dec 10 07:42:34 2013 (StudyRootQuery) search level: SERIESTue Dec 10 07:42:34 2013 C-Find (StudyRoot) located 1 recordsTue Dec 10 07:42:35 2013 UPACS THREAD 1: ENDED AT: Tue Dec 10 07:42:35 2013Tue Dec 10 07:42:35 2013 UPACS THREAD 1: TOTAL RUNNING TIME: 1 SECONDSTue Dec 10 07:42:35 2013 Tue Dec 10 07:42:35 2013 UPACS THREAD 2: STARTED AT: Tue Dec 10 07:42:35 2013Tue Dec 10 07:42:35 2013 	Calling Application Title : "IQVIEW2         "Tue Dec 10 07:42:35 2013 	Called Application Title : "SERV         "Tue Dec 10 07:42:35 2013 	Application Context : "1.2.840.10008.3.1.1.1", PDU length: 16384Tue Dec 10 07:42:35 2013 	Presentation Context 0 "1.2.840.10008.5.1.4.1.2.2.1" 1Tue Dec 10 07:42:35 2013 	Presentation Context 1 "1.2.840.10008.5.1.4.1.2.2.2" 1Tue Dec 10 07:42:35 2013 	C-Move Destination: "IQVIEW2 "Tue Dec 10 07:42:35 2013 Number of Images to send: 3800Tue Dec 10 07:42:35 2013 Sending file : /home/images/data/FUJIA07112210290/1.2.392.200036.9125.3.481918453137.64537986775.1632146_1001_001009_12555497271726.dcmTue Dec 10 07:42:35 2013 Sending file : /home/images/data/FUJIA07112210290/1.2.392.200036.9125.3.481918453137.64537986775.1632146_1001_001010_12555497281727.dcmTue Dec 10 07:42:36 2013 Sending file : /home/images/data/FUJIA08011815480.....


    my dicom.ini

    Hi,


    if you increase the debug level (dgate --debuglevel:4) the actual query will be shown.


    You also say you updated. Did you keep the old dicom.sql? If that one is out of sync with the database anything could happen. I.e., you need to use the OLD dicom.sql or regenerate the database.


    Marcel

    Hello Marcel,


    I was using a new dicom.sql I'm sure. So I just recompiled with the 'standard' 1.4.17c, regenerated db and wait so long... and it worked, we are back to a running state...


    I assume something was wrong in the configuration (as dicom.xxx files are replaced when I compile, and I have edited these files) or the patch to increase PDUsize to 65536 was not accepted... But for sure I will not debug this server anymore, I prefer to set up a similar config.


    I'll write down the enhanced debug level to provide more information...


    Jim

    Hi,


    I got exactly the same symptom and errors today, bad time... :o( This time we use the std build 17c and I only changed the following:
    - archivecompression = un
    - filenamesyntax = 4
    (it was requested to keep the .dcm filenaming instead of .v2)


    I tried to set up the debug level to 4 but I was not succesful... I tried

    Code
    ./dgate -^serverstatus.log --debuglog_on:debug.log --debuglevel:4

    and

    Code
    ./dgate -v --debuglog_on:debug.log --debuglevel:4

    but it does not seem to populate any files. Sorry, I made a lot of search on the forum but failed to find the correct way...


    What do you recommend ? Should I try an older conquest version?


    Bye

    Ahah, ok, I missed this way to catch the debug, here it is.
    I just ran dgate -r just to be sure.
    So, the query should return only 2 studies with a couple of images, not 30k...
    Any advice ?


    Hi,


    This is the query. It looks all right to me, but is responds with 30489 records.


    Code
    Query On ImageWed Dec 11 21:54:45 2013 Issue Query on Columns: DICOMImages.SOPClassUI, DICOMImages.SOPInstanc, DICOMSeries.SeriesInst, DICOMStudies.StudyInsta,DICOMImages.ObjectFile,DICOMImages.DeviceNameWed Dec 11 21:54:45 2013 Values: DICOMSeries.SeriesInst = '1.2.392.200036.9125.3.481918453137.64732576297.11922557' and DICOMStudies.StudyInsta = '1.2.392.200036.9125.2.481918453137.64732576297.11922556' and DICOMSeries.StudyInsta = DICOMStudies.StudyInsta and DICOMImages.Manufactur = DICOMSeries.ManufacturWed Dec 11 21:54:45 2013 Tables: DICOMImages, DICOMSeries, DICOMStudiesWed Dec 11 21:54:45 2013 Records = 30489Wed Dec 11 21:54:45 2013 Number of Images to send: 30489


    To me it seems that image table in the SQL server is confused. Can you use e.g., mysqladmin to perform this query?


    SQL
    SELECT * FROM DICOMImages, DICOMSeries, DICOMStudies WHERE DICOMSeries.SeriesInst = '1.2.392.200036.9125.3.481918453137.64732576297.11922557' and DICOMStudies.StudyInsta = '1.2.392.200036.9125.2.481918453137.64732576297.11922556' and DICOMSeries.StudyInsta = DICOMStudies.StudyInsta and DICOMImages.Manufactur = DICOMSeries.Manufactur


    and see the result?


    Marcel

    Hum, you're right, through phpmyadmin the sql query returns exactly the same number ! So it seems my database migration is fully inconsistent. I was digging in the wrong way... Thanks !


    I don't understand why it works fine during the next 24 hours after I recompile ?! very strange


    Here is how I proceed:
    - old server is running 1.4.14: all the dcm files have been copied to the new server
    - new server = 1.4.17c, dicom.ini and dicom.sql adapted
    - dgate -r


    This should populate the db accordingly, right ? Could this be related to the dicom.sql (small) changes, I'll try not to touch it...

    Hi,


    I guess that something has gone wrong during the "dgate -r" phase. If you have a backup of the old database you can use it with the old dicom.sql. Or MySQL is in a bad state for some reason. You could try SQLite for bit, it should work fine for such a small number of images.


    Marcel

    Dear Marcel,


    Many thanks for your great support. I think I found out the root cause: Within the MAG device there was a strange link to the root directory, with a kind of endless loop, I believe this was populating the db in a very bad way, sometimes it was working, sometimes not...


    After checking and cleaning the filesystem, I was able to regenerate the db in a good shape. The Q/R's are correct now, but I will continue to monitor.


    It was a bit difficult !


    Have a nice day
    Jim

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!

Register Yourself Login