forwarding problems

    hi,
    I'm using conquest 1.4.13 with mySQL 5. I configured conquest to forward the images to several destinations. It seems to work fine, but sometimes I found an error message in the log files:




    All Dicom Nodes are registered in the acrnema.map. Now my questions:


    1. What does

    Quote

    14.05.2008 15:50:19 [DROUTER] Server Command := 0001
    14.05.2008 15:50:19 [DROUTER] Message ID := 0063


    mean?


    2. What ist going on when the message



    appears? Exactly


    Quote

    14.05.2008 15:53:08 [DROUTER] ***Client Error: Unknown Command: 0001**
    14.05.2008 15:53:08 [DROUTER] ***Connection Terminated


    The hd space is 50GB. Currently used 10GB => enough space, I mean.


    dicom.ini configuration:


    Hi,


    FAILED STORAGE is rarely seen: it probably means that the incoming DICOM message is corrupt. This has no relation to export converters, I believe. The ***Client Error: Unknown Command: 0001** message is a fault in the error handling. Command 0001 is C-STORE and is correct. Looking at the log it seems that the data to be stored is missing. There also seems to be a 46 seconds delay before this message appears. Could be related to some timeout in the network. Any clue why the stored image is special. Is it very big?


    Marcel

    Quote from marcelvanherk

    Hi,


    FAILED STORAGE is rarely seen: it probably means that the incoming DICOM message is corrupt. This has no relation to export converters, I believe. The ***Client Error: Unknown Command: 0001** message is a fault in the error handling. Command 0001 is C-STORE and is correct. Looking at the log it seems that the data to be stored is missing. There also seems to be a 46 seconds delay before this message appears. Could be related to some timeout in the network. Any clue why the stored image is special. Is it very big?


    Marcel



    Hi,


    the images are MG images. One takes uncompressed 20GB. Yes, the network connection between PACS and the sender is a 2Mbit/s VPN connection SDSL. Our equipment has errors transmitting images via 2MBit/s VPN connection. The reason for using conquest was, that conquest has implemented some error handling like MaximumExportRetries. Do I get better results, if I extend e. g. the timeout?


    greetings

    Ah,


    conquest assumes that the image can be stored in memory. So 20 GB is really a problem: objects larger than about 512 MB are not supported.


    Having said that, it may be possible to keep the image compressed at all time. In version 1.4.14beta we have added compression UJ: "uncompressed or jpeg" that might do the job.


    It also might be worthwhile to extend the TCPIP timeout. The default is 300 s.


    Marcel

    Marcel,


    sorry, one image takes 20MB (file size) not 20GB!!


    Quote

    Having said that, it may be possible to keep the image compressed at all time. In version 1.4.14beta we have added compression UJ: "uncompressed or jpeg" that might do the job.


    what does it mean? Should I configure conquest to store images e. g. as jpeg lossless images?


    Version 1.4.14beta is a beta version and I think that the test cycle is not finished?


    Stefan

    Hi,


    1.4.14beta seems very stable (see bug reports). The mode UJ will allow the data to be communicated compressed - I am not sure how they are stored on your host. The only other option I see is to increase the TCPIP timeout. Any idea where the 46 minutes delay came from?


    Marcel

    Marcel,


    conquest stores our images uncompressed (*.dcm) on the harddisk. I have no idea where the 46 seconds delay come from.


    I would like to test to a higher network timeout setting. Where will I found the Version 1.14b?


    Stefan

    Marcel,


    it seems that I have another problem. I expect the the images are forwarded at first before they are deleted from disc, because the space limit is reached. Remember: I have configured two destinations for one source:


    ExportModality0 = *
    ExportCalledAE0 = DROUTER
    ExportCallingAE0 = MLCKWMWL
    ExportConverter0 = forward to FirststorageSCP
    ExportModality1 = *
    ExportCalledAE1 = DROUTER
    ExportCallingAE1 = MLCKWMWL
    ExportConverter1 = forward to SecondstorageSCP


    Now I expect that the exports are executed at first before the images are deleted by conquest. The log file shows me that the first export converter is executed very well. Then it could happen the images are deleted before the second export converter is executed.
    How do I handle that? I'm using conquest as a dicom router only. Is it a good idea to configure the export converter like


    ExportModality0 = *
    ExportCalledAE0 = DROUTER
    ExportCallingAE0 = MLCKWMWL
    ExportConverter0 = forward to FirststorageSCP; forward to SecondstorageSCP


    instead of


    ExportModality0 = *
    ExportCalledAE0 = DROUTER
    ExportCallingAE0 = MLCKWMWL
    ExportConverter0 = forward to FirststorageSCP
    ExportModality1 = *
    ExportCalledAE1 = DROUTER
    ExportCallingAE1 = MLCKWMWL
    ExportConverter1 = forward to SecondstorageSCP




    Stefan

    It is not anticipated that the patient being forwarded is simulaneously deleted. This problem should not occur when there is room on your server for 2 patients, as the delete order is based on the date/time of last entry. So, maybe you should change the threshold.


    Marcel

Participate now!

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

Register Yourself Login