Posts by Flyboy

    We are currently running without (known) issues on 1.4.19, so it is not urgent at this time

    Thanks for looking into this!

    We just migrated to new servers and the new conquest version.
    I'm on 1.4.19a and the green color still shows up.
    No matter the compression used for communication.
    When I grab the raw .dcm files from the server, they don't show the green, but once conquest transfers them, they do

    I currently have an instance of conquest set up to forward images to a review station and change the compression on the fly while doing so to uncompressed.
    This so all internal and vpn traffic can be done with the highest compression, but the review station that can't handle this will still get the uncompressed images presented to it.

    Since we already store the images in the main conquest system, there is no need for this routing instance to also keep them.
    So I just have the following in my dicom.ini:

    1. # Configuration of rules to modify, log or reject incoming DICOM slices
    2. ImportConverters = 1
    3. ImportConverter0 = forward to RWS3; destroy

    I'm running into some issues where that RWS3 sometimes is rejecting images or when it reboots that images get missed.
    Even when an error is thrown, the images are destroyed.
    Is there a way of to retry failing images on an importconverter?
    And if not and I need to convert this to an exportconverter, is there a way to delete the images on a successful forward so this database stays mostly empty and I don't keep any extra copies of these images?


    Found the command, it is dgate --display_status:

    The difference between the 2 servers is that one of them is on 1.4.17d and one is 1.4.17beta3
    Beta 3 never switches back to the J2 compression and is transferring the images correctly
    1.4.17d is sending them as J2 and they show up garbled

    I tested different transfer by replacing the dgatesop.lst files on 1 server with different versions, but could not get it to go and transfer images in j2, even though that is what is defined in the acrnemap
    So now I think it must be due to the version of dgate
    I have no idea which version of the dgate executables I'm running, and the properties don't really help.
    What is the best idea of finding out which version you are running?
    the interface and logs don't really show me, even when restarting the server

    is there something to run on the command line to show the version?

    We are having some issues with images arriving scrambled on some of our Hologic review stations
    I have spent quote a few hours troubleshooting the issue and I think I found what is causing it, but not sure what the best way forward is.
    Example of one of the scrambled images arriving: (all headers show up ok)

    The issue is only occurring from some of our conquest servers, and so far only seems to happen when we send compressed images. Compression does not seem to matter.
    If we set the compression to un the images arrive correctly.
    All servers are running 1.4.17e

    The review station is set up as:
    rws1 4006 j2

    the working conquest servers show the following in the log:
    10/4/2016 8:19:19 AM [CONQUEST1] UPACS THREAD 42951: STARTED AT: Tue Oct 04 08:19:19 2016
    10/4/2016 8:19:19 AM [CONQUEST1] Calling Application Title : "CONQUEST1 "
    10/4/2016 8:19:19 AM [CONQUEST1] Called Application Title : "CONQUEST1 "
    10/4/2016 8:19:19 AM [CONQUEST1] Application Context : "1.2.840.10008.", PDU length: 16384
    10/4/2016 8:19:19 AM [CONQUEST1] Presentation Context 0 "1.2.840.10008." 1
    10/4/2016 8:19:19 AM [CONQUEST1] Presentation Context 1 "1.2.840.10008." 1
    10/4/2016 8:19:19 AM [CONQUEST1] C-Move Destination: "rws1 "
    10/4/2016 8:19:19 AM [CONQUEST1] Number of Images to send: 23
    10/4/2016 8:19:20 AM [CONQUEST1] Accepted compression: ui
    10/4/2016 8:19:20 AM [CONQUEST1] Sending file : E:\shimages\xxxxxxxxx\1.2.840.113663.1500.1.168875912.2.1.20160303.94628.843_0001_000001_14570163012be2.v2
    10/4/2016 8:19:20 AM [CONQUEST1] [recompress]: recompressed with mode = ui (strip=1)
    10/4/2016 8:19:20 AM [CONQUEST1] Accepted compression: ui

    The compression for the transfer is changed to ui, which I can't seem to find any info on in the manual

    a server that does not work shows:
    10/4/2016 8:14:34 AM [CONQUEST] UPACS THREAD 11104: STARTED AT: Tue Oct 04 08:14:28 2016
    10/4/2016 8:14:34 AM [CONQUEST] Calling Application Title : "CONQUEST "
    10/4/2016 8:14:34 AM [CONQUEST] Called Application Title : "CONQUEST "
    10/4/2016 8:14:34 AM [CONQUEST] Application Context : "1.2.840.10008.", PDU length: 16384
    10/4/2016 8:14:34 AM [CONQUEST] Presentation Context 0 "1.2.840.10008." 1
    10/4/2016 8:14:34 AM [CONQUEST] Presentation Context 1 "1.2.840.10008." 1
    10/4/2016 8:14:34 AM [CONQUEST] Presentation Context 2 "1.2.840.10008." 1
    10/4/2016 8:14:34 AM [CONQUEST] C-Move Destination: "RWS1 "
    10/4/2016 8:14:34 AM [CONQUEST] Number of images to send: 28
    10/4/2016 8:14:34 AM [CONQUEST] Accepted compression: ui
    10/4/2016 8:14:34 AM [CONQUEST] Sending file : F:\pacsimages\xxxxxxxxxxx\1.2.840.113619.2.227.207919569228.7858110310083250.10005_0560_000004_14755832214a0f.dcm
    10/4/2016 8:14:34 AM [CONQUEST] [recompress]: recompressed with mode = j2 (strip=0)

    When going over all the differences between the pacs servers that work and the ones giving issues, the only difference I can find is 2 different dgatesop.lst files
    The one that works is at the top and seems to be older, the one scrambling the images, is below and is newer

    1. ## DICOM Application / sop / transfer UID list.## This list is used by the CheckedPDU_Service ( "filename" ) service# class. All incoming associations will be verified against this# file.## Revision 2: disabled GEMRStorage and GECTStorage# Revision 3: extended with new sops and with JPEG transfer syntaxes# Revision 4: added Modality Worklist query##None none RemoteAE#None none LocalAE#DICOM 1.2.840.10008. applicationVerification 1.2.840.10008.1.1 sopStoredPrintStorage 1.2.840.10008. sopHardcopyGrayscaleImageStorage 1.2.840.10008. sopHardcopyColorImageStorage 1.2.840.10008. sopCRStorage 1.2.840.10008. sopDXStorageForPresentation 1.2.840.10008. sopDXStorageForProcessing 1.2.840.10008. sopDMStorageForPresentation 1.2.840.10008. sopDMStorageForProcessing 1.2.840.10008. sopDOralStorageForPresentation 1.2.840.10008. sopDOralStorageForProcessing 1.2.840.10008. sopCTStorage 1.2.840.10008. sopRetiredUSMultiframeStorage 1.2.840.10008. sopUSMultiframeStorage 1.2.840.10008. sopMRStorage 1.2.840.10008. sopMRImageStorageEnhanced 1.2.840.10008. sopMRStorageSpectroscopy 1.2.840.10008. sopRetiredNMStorage 1.2.840.10008. sopRetiredUSStorage 1.2.840.10008. sopUSStorage 1.2.840.10008. sopSCStorage 1.2.840.10008. sopSCStorageSingleBitMF 1.2.840.10008. sopSCStorageGrayscaleByteMF 1.2.840.10008. sopSCStorageGrayscaleWordMF 1.2.840.10008. sopSCStorageTrueColorMF 1.2.840.10008. sopStandaloneOverlayStorage 1.2.840.10008. sopStandaloneCurveStorage 1.2.840.10008. sop#WFStorageTwelveLeadECG 1.2.840.10008. sop#WFStorageGeneralECG 1.2.840.10008. sop#WFStorageAmbulatoryECG 1.2.840.10008. sop#WFStorageHemodynamic 1.2.840.10008. sop#WFStorageCardiacElectrophysiology 1.2.840.10008. sop#WFStorageBasicVoiceAudio 1.2.840.10008. sopStandaloneModalityLUTStorage 1.2.840.10008. sopStandaloneVOILUTStorage 1.2.840.10008. sopGrayscaleSoftcopyPresentationStateStorage 1.2.840.10008. sopRetiredXASinglePlaneStorage 1.2.840.10008. sopXASinglePlaneStorage 1.2.840.10008. sopRFStorage 1.2.840.10008. sopXABiPlaneStorage 1.2.840.10008. sopNMStorage 1.2.840.10008. sopVLImageStorage 1.2.840.10008. sopVLMultiFrameImageStorage 1.2.840.10008. sopVLMicroscopicSlideStorage 1.2.840.10008. sopVLPhotographicStorage 1.2.840.10008. sopVLEndoscopicImageStorage 1.2.840.10008. sopVLMicroscopicImageStorage 1.2.840.10008. sopVLSlideCoordinatesMicroscopicImageStorage 1.2.840.10008. sopVLPhotographicImageStorage 1.2.840.10008. sopBasicTextSR 1.2.840.10008. sopEnhancedSR 1.2.840.10008. sopComprehensiveSR 1.2.840.10008. sopMammographyCADSR 1.2.840.10008. sopKeyObjectSelectionDocument 1.2.840.10008. sopPETStorage 1.2.840.10008. sopStandalonePETCurveStorage 1.2.840.10008. sopRTImageStorage 1.2.840.10008. sopRTDoseStorage 1.2.840.10008. sopRTStructureStorage 1.2.840.10008. sopRTTreatmentRecordStorage 1.2.840.10008. sopRTPlanStorage 1.2.840.10008. sopRTBrachyTreatmentRecordStorage 1.2.840.10008. sopRTTreatmentSummaryRecordStorage 1.2.840.10008. sop#GEMRStorage 1.2.840.113619.4.2 sop#GECTStorage 1.2.840.113619.4.3 sopGE3DModelObjectStorage 1.2.840.113619.4.26 sopGERTPlanStorage 1.2.840.113619.5.249 sopGERTPlanStorage2 1.2.840.113619.4.5.249 sopGESaturnTDSObjectStorage 1.2.840.113619.5.253 sopPhilips3DVolumeStorage sopPhilips3DObjectStorage sopPhilipsSurfaceStorage sopPhilipsCompositeObjectStorage sopPhilipsMRCardioProfileStorage sopPhilipsMRCardioImageStorage sopPatientRootQuery 1.2.840.10008. sopPatientRootRetrieve 1.2.840.10008. sopStudyRootQuery 1.2.840.10008. sopStudyRootRetrieve 1.2.840.10008. sopPatientStudyOnlyQuery 1.2.840.10008. sopPatientStudyOnlyRetrieve 1.2.840.10008. sopFindModalityWorkList 1.2.840.10008. sopPatientRootRetrieveNKI 1.2.826.0.1.3680043.2.135.1066. sopStudyRootRetrieveNKI 1.2.826.0.1.3680043.2.135.1066. sopPatientStudyOnlyRetrieveNKI 1.2.826.0.1.3680043.2.135.1066. sopBasicGrayscalePrintManagementMeta 1.2.840.10008. sopBasicColorPrintManagementMeta 1.2.840.10008. sopBasicFilmSession 1.2.840.10008. sopBasicFilmBox 1.2.840.10008. sopBasicGrayscaleImageBox 1.2.840.10008. sopBasicColorImageBox 1.2.840.10008. sopBasicPrinter 1.2.840.10008. sopLittleEndianImplicit 1.2.840.10008.1.2 transferLittleEndianExplicit 1.2.840.10008.1.2.1 transfer#BigEndianExplicit 1.2.840.10008.1.2.2 transferJPEGBaseLine1 1.2.840.10008. transfer LittleEndianExplicitJPEGExtended2and4 1.2.840.10008. transfer LittleEndianExplicit#JPEGExtended3and5 1.2.840.10008. transfer LittleEndianExplicitJPEGSpectralNH6and8 1.2.840.10008. transfer LittleEndianExplicit#JPEGSpectralNH7and9 1.2.840.10008. transfer LittleEndianExplicitJPEGFulllNH10and12 1.2.840.10008. transfer LittleEndianExplicit#JPEGFulllNH11and13 1.2.840.10008. transfer LittleEndianExplicitJPEGLosslessNH14 1.2.840.10008. transfer LittleEndianExplicit#JPEGLosslessNH15 1.2.840.10008. transfer LittleEndianExplicit#JPEGExtended16and18 1.2.840.10008. transfer LittleEndianExplicit#JPEGExtended17and19 1.2.840.10008. transfer LittleEndianExplicit#JPEGSpectral20and22 1.2.840.10008. transfer LittleEndianExplicit#JPEGSpectral21and23 1.2.840.10008. transfer LittleEndianExplicit#JPEGFull24and26 1.2.840.10008. transfer LittleEndianExplicit#JPEGFull25and27 1.2.840.10008. transfer LittleEndianExplicit#JPEGLossless28 1.2.840.10008. transfer LittleEndianExplicit#JPEGLossless29 1.2.840.10008. transfer LittleEndianExplicitJPEGLossless 1.2.840.10008. transfer LittleEndianExplicit#JPEGLS_Lossless 1.2.840.10008. transfer LittleEndianExplicit#JPEGLS_Lossy 1.2.840.10008. transfer LittleEndianExplicit#RLELossless 1.2.840.10008.1.2.5 transfer LittleEndianExplicit#LittleEndianExplicitDeflated 1.2.840.10008. transfer LittleEndianExplicitJPEG2000LosslessOnly 1.2.840.10008. transfer LittleEndianExplicitJPEG2000 1.2.840.10008. transfer LittleEndianExplicit

    I'm not really sure what in here might be breaking the transfers, but if someone could help out that would be great.
    Or point me to a possible other cause for this issue.

    And we would need the later version of the file to support BTO images I think, so reverting all servers to the older file might not be an option.


    Correction to the above post:
    Images are not saving correctly on the live system either.
    - I had a patient saved as 1111-111 with 4 images under 1 study
    - I right click on the patient and did Change PatientID
    - for the first 3 images:
    -- conquest deleted the image from the database
    -- conquest tried to resave it in the database, but refused to, due to an inconsistent link patientID
    -- conquest left the image with original patientID, in the original folder, but it is not present in the database any more
    - the last image:
    -- conquest delete the image from the database
    -- conquest modified the image to reflect the new patientID
    -- conquest saved the image with new details in the database

    So the end result is:
    1 image saved with the new ID
    3 images still present on disk with the old ID, but no longer to be found in the database

    That was on a test server, which might have had multiple copies of the same images under different names and ID's
    I tested it on a semi-production server with only decent images on it, and it is working correctly there.

    Although I have 2 questions about it:
    I just upgraded this one (not a clean install) and now I notice the following in my Server Status:

    1. [CONQUEST] ***SQLITEExec error: no such column: Stage[CONQUEST] ***SQLITEExec error: 5 values for 4 columns[CONQUEST] ***[NewUIDsInDICOMObject] FAILED to change 0002,0003 (MediaStorageSOPInstanceUID)[CONQUEST] ***SQLITEExec error: no such column: Stage[CONQUEST] ***SQLITEExec error: 5 values for 4 columns[CONQUEST] ***[NewUIDsInDICOMObject] FAILED to change 0008,0018 (SOPInstanceUID)[CONQUEST] ***SQLITEExec error: no such column: Stage[CONQUEST] ***SQLITEExec error: 5 values for 4 columns[CONQUEST] ***[NewUIDsInDICOMObject] FAILED to change 0020,000d (StudyInstanceUID)[CONQUEST] ***SQLITEExec error: no such column: Stage[CONQUEST] ***SQLITEExec error: 5 values for 4 columns[CONQUEST] ***[NewUIDsInDICOMObject] FAILED to change 0020,000e (SeriesInstanceUID)

    I didn't see any requirement for a database regen with this version, or changes to the layout.
    Do we need to make database modifications for this version?

    And when changing a patient is, I always seem to get a message that it is refusing to save something, even though when verifying functionality later, everything seems to be there

    1. [CONQUEST] Importconverter-1.0 executes: newuids
    2. [CONQUEST] Deleting database entry for image: E:\pacsimages\1111-111\1.2.840.113619.2.227.2079247177132.2133131125200851.10005_53163_000001_14182421940018.dcm
    3. [CONQUEST] ***Refused to enter inconsistent link PatientID into DICOMStudies: PatientID = '2222-222' StudyInsta = '1.2.840.113619.2.227.2079247177132.17909131125194554.20000', Old='1111-111', Refused='2222-222'
    4. [CONQUEST] ***Error saving to SQL: 2222-222\1.2.840.113619.2.227.2079247177132.2133131125200851.10005_53163_000001_14737831610005.dcm
    5. [CONQUEST] ***Error entering object into server: E:\pacsimages\1111-111\1.2.840.113619.2.227.2079247177132.2133131125200851.10005_53163_000001_14182421940018.dcm

    I tested renaming some patient-id's (on a test server this time) and most of the patients I tried setting up with a new ID number were deleted from the database and my hard drive.
    The following showed in the logs:

    I went in the Browse Database, searched for a patient, right clicked, changed the ID, and all data was gone

    I haven't had it running for 7 days yet.
    But I increased the queue size in dicom.ini to 128000
    So I should be good there.

    But I wanted to make sure the queue survives a restart, otherwise I need to come up with a different way of clearing out those images

    I have an exportconvertor set up to delete images 7 days after being received
    ExportConverter2 = delete series after 604800

    I can't see where this gets saved to a file anywhere, so I presume this is a queue in memory that is being used?
    Is there a maximum number of images or series it can contain?
    And will this survive a reboot or a service restart?

    Just to keep other interested parties here updated in this issue:
    We set up a VPN to a new medical facility we are dealing with.
    When they were sending test images to confirm everything is working correctly, they were sending us images at their max. throughput speed, 200MB/sec
    This over a 50ms latency line, about the same as I have been testing with internally here.
    VPN setup and everything is the same as before.

    So this proved to me that Conquest is able to achieve higher speeds at that latency.

    Seeing that, I wanted to do some more testing here to see if I could figure out our slowness when sending
    I tested sending images from different other programs.
    K-PACS, same speed issue
    SendToPACS (Java based), was able to send to Conquest at maximum speed.

    When checking some logs I found they are sending the files in different packet sizes, but I don't know if that might be causing this or not:

    Tested more by tweaking network settings, network cards, vpn tunnels, ...
    But I could not get Conquest to go at the correct speeds.
    3Mbps seems to be what I get stuck at.

    Next I hooked up a new test-lab by vpn to my live environment and sent images across.
    Was I surprised when I got all of a sudden the maximum speed out of my connection.
    The only difference being the test-servers running windows 2012R2 and my live ones are 2008R2
    All settings, hardware, conquest versions and settings are all the same.

    I spun up another 2012R2 server in a different location and was able to replicate the way improved speeds. (way improved, being: going from 3Mbps to maximum connection throughput)

    Unless this finding makes a lightbulb go off with someone, my next recommendation to my customer is going to be to migrate all their image servers from windows 2008R2 to windows 2012R2


    They basically mean, you opened Conquest and browsed the database and patients through the "Browse database" tab

    [HPACS] db extract full patientlist for GUI

    "HPACS" - is your pacs server name
    "db extract full patientlist for GUI" - the first time you open the browse database tab it will pull in a full list of patients

    [HPACS] db extract studies for GUI of patient: A 2688042-6
    [HPACS] db extract series for GUI of patient: A 2688042-6
    [HPACS] db extract series for GUI of patient: A 2688042-6
    [HPACS] db extract studies for GUI of patient: A 2502854-1
    [HPACS] db extract series for GUI of patient: A 2502854-1
    [HPACS] db extract series for GUI of patient: A 2502854-1

    After pulling in the patient list, it will start getting the details for all patients, to put them on the grid.
    "db extract studies for GUI of patient" - Starting with the studies for that particular patient
    "db extract series for GUI of patient" - then going more granular for each of the studies, to see how many and which series were taken for them

    Re-reading from GUI
    This is most likely because you made a change to the known DICOM providers and pressed on Save. It will re-read all providers into memory again.