Issues with Export Converter in dicom.ini

    Dear Marcel,
    I'm trying to start a home-made conversion tool using an exportconverter in dicom.ini
    In my development environment I'm sending patients from another conquest installation. I have a couple of issues with exportconverters (last version, 19b).


    -we want to start our tool once the series transmission is ended. We are using a command like:


    ExportConverter0 = process series after N by cmd /C echo %%time%% >> c:\log.txt


    Apparently, the command is not triggered N seconds after series has been transmitted, but every N seconds during the whole transmission. Ie, if N=1 and transmission lasts 20 seconds, we find 20 lines in log.txt, each one 1 second apart from the previous. Our understanding is that an internal timeout (possibly ForwardCollectDelay) would determine if the transmission is finished, then N seconds are waited and the "process" statement is executed. Isn't that the logic?



    - the second issue is even more puzzling, because it is apparently random. We increased N in the above exportconverter to 600, that is far higher than transmission time of a series, and we found that apparently only some series are forwarded to the "process" program (in our case, we find 10 or 12 lines in c:\log.txt, while a patient with 16 series has been correctly transmitted). The patient is correctly received, ie all 16 series are stored and included in db. The expoortconverter lines are all present in the conquest log. Then, we went back to N=1 s and we found that the problem is present also in that case, ie some series are forwarded to process every N seconds, while some other are never forwarded. Thus, it appears that some series get "lost". Finally, increasing QueueSize from 128 to 256 or even 2560 does not improve (or even mare worst) the issues.


    Thank you in advance for your help

    Hi,


    since there is no DICOM way to know when transmission is ended, N should be set such that trandmission is certainly completed. So the behavior with N=1 is normal. ForwardCollectDelay is the default N if no 'after' clause is provided.


    The second report is strange. The mechanism is that every incoming image puts a unique command into a queue that looks like


    process (command) patientID seriesuid


    The method assumes that this command is the same for all imaged to be processed. If any of the text is variable, multiple processes would be triggered. I have no idea why commands are lost. Can you try to run it in an ImportConverter instead to see if that makes any difference?


    Marcel

    Hi Marcel and thank you for your support.


    Starting from the second issue:


    we tried to use an ImportConverter, but the behaviour is the same: ie the process line is sent to the log, but it is not always executded, in ana apprently random way. Any suggestion about how to debug this issue?


    Regarding the first issue, I would have a further report and a suggestion


    -the report is that if the 'after' clause is not provided, the command is not triggered at all, irrespectively of the "ForwardCollectDelay" value


    -the suggestion is to change the "after" timeout logic. If I understood correctly, the timeout is triggered by the first image, and then commands are queued serially every "timeout" seconds if timeout is shorter than transmission time. In my opinion, it would be more useful if the timeout is started by the first image, but then it is reset by each incoming image that does not change the text in


    process (command) patientID seriesuid


    This way, the command would be issued only if the timeout expires, ie it is not reset. This occur logically only if time between successive images is longer than timeout, or after the last image.


    On my oipinion this logic is safer, because "timeout" would be compared to the transmission time of a single image, that is generally much more predictable of the transmission time of a whole series. In our environment, we have seies made by thousand of images, so with the current logic we would be forced to set a very long timeout, that would unnecessarily slow the forwarding process for short series (including 3-50 images)


    Thank you again, Federico

    Hi,


    I will put the change into 1.4.19c. I have been testing as follows:


    ImportConverter0 = process series after 5 by test.lua %VSeriesDescription; destroy


    with test.lua containing:


    print('@@@@@@@@@@', version, command_line)


    There seem to be no series dropped as far as I can see. What does happen is the log often drops lines. Can this be your issue? If you use 'Only log to file', the log file is guaranteed to contain all log lines.


    The log looks like (supressing all destroy lines):



    All series trigger a print.


    regards,


    Marcel

    Hi Marcel, thank you for your help.


    We'll do our test with lua (until now we directly invoked cmd)


    to reply to your questions:
    -no, it is not a log issue. Indeed, the command lines are all logged, what happens is that they are not actually executed
    -the series are dropped at random, ie transferring again the same patient, dropped series are different.


    We'll let you know the result of our tests.


    Best, Federico

Participate now!

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

Register Yourself Login