Posts by manzing

    Hi


    OK, it was due to missing quotes for the new modality.


    Syntax is
    if Data.Modality~='CR' then Data.Modality = 'CR' end


    Tested the LUA importconverter as well -> perfect.


    Many thanks Marcel, and merry Christmas !

    Thanks Marcel.


    I added the lua line in dicom.ini but i haven't checked if it works yet.


    When i try to use the code in the lua box, if i hit the "test syntax" button an error occured (lua syntax error... unfinished line...). If i click "start modify", no error but no change in modality.


    Any other suggestion ?

    Hi Marcel,


    For some reason i have some Rx images that arrive to conquest with bad modality.
    I want to rewrite modality in every incoming dicom if modality is not CR.


    Do you think my import converter is OK ?


    Code
    1. ImportConverter1 = ifnotequal "%m", "CR"; set "%m", "CR";


    Besides, i want to change past errors and now it asks for a lua script...


    Could you show me how to change modality of a serie using lua box in the "browse database" tab ?


    Thanks,

    Hi Marcel,


    That's kinda weird, i use the same database, SQlite.
    As i said before, i also tried with DBASE III on a test server and had the same issue.


    I can use the old GUI as a workaround, but i can't understand what happen...
    I was thinking to a user right problem but couldn't find anything that could explain.


    Could it be related to the OS version ? I can't remember but it is possible that the issue appeared after i migrated on my Windows 2012 server.


    I keep in touch if i can find any explanation.


    Thanks for your help Marcel.

    Hi Marcel,


    I use SQLite Dbase with BrowseThroughDBF activated.


    dicom.ini extract :

    Code
    1. SqLite = 1
    2. BrowseThroughDBF = 1


    The folder Dbase exists (well 2 folders exists and are used : one in conquest server folder / data, on in data folder which is located on another partition). One test server, i use the default folder and the issue is present.
    I made a test server with DBASE III and the same error occured.
    As i said before, your test image HEAD_EXP_00097038 always display fine in every case. This is obiously something related to the images we produce since some times (old studies are not affected) and the last version of Conquest GUI, as the 1.4.15 GUI works flawlessly with all studies / images, using the last dgate.exe 1.4.17d.


    If you want to dig, i can send you one image which fail with the last GUI.


    About worklist and MirthConnect, you're right : i added a step which removes problematic caracters and replace them with standard ones.
    Now the hl7 files are being processed normally. :)


    Thanks for your answer anyway,


    Emmanuel

    Marcel,
    After another test, the issue does not occur when using conquest 1.4.15.
    The bad news is that i updated to 1.4.17 in order to use a lua script which allow dynamic IP for some client (if you remember), so i can hardly revert to 1.4.15.


    EDIT : well, i can use this as a workaround as the issue is caused by the GUI only. I pasted the 1.4.15 GUI in my 1.4.17d Conquest folder, and i now can delete my studies again ! :D


    It seems something has changed between the 2 versions.

    Hi Marcel, Hi everybody


    I have 2 issues and the first one is critical and i can't figure out how to fix it.


    Firstly since a few months (i think, maybe since i migrated Conquest on a Windows 2012 server ?) when i select a patient in the GUI, instead of displaying image i can read "image file not found". The series and the images are not displayed either.
    All i can see is the study name in the top field (capture as attachment).
    That said, if i use a Dicom client and query the PACS, i can retrieive the study, display images, everything works fine.


    The problem is that clinicians usually make some mistakes in patient informations, markers or some other things.
    I use to delete the study or the serie in Conquest, and then ask the clinicians to send again the study to the PACS.
    I am now unable to delete anything on most cases.
    The same issue occur on a test server i made this morning. The only study which work fine is the default one provided in conquest.
    Reindexing the database, and even change database type does not have any effect.
    I've also tried many options in dicom.ini without any success.


    The second issue is not so annoying, but maybe there is a way to make it work : I use Mirth Connect to send a HL7 file to conquest in order to feed the worklist..
    Sometimes, some patients have some accent mark or apostrophe in their names and it makes Conquest to fail to add them to the worklist.
    Is there any workaround ?


    Many thanks in advance for any help !

    Files

    • error.jpg

      (90.66 kB, downloaded 344 times, last: )

    Hi Marcel,


    I migrated on a windows 2012 server 64 Bits, updated Conquest to last version and it runs flawlessly since a month.
    Some old clients like Kpacs are not able to retrieve large series but the server is not affected at all.


    So, Marcel, i really want to thank you (again !) for the help you provide to all of us ! :)

    I'm already using uj compression, but it's still the same :

    Quote

    20141210 11:35:26 ***[DecompressJPEGL]: Could not allocate decompressed image memory.
    20141210 11:35:26 ***[DecompressImage]: JPEG library decompression error


    The good thing is that the server does not seem to crash now.


    That said, migrate on a 64bits OS appears to be a good option, as Microsoft will also stop support for Windows 2003 server soon.

    Hi Marcel,


    I've just made a test on a Windows 2012 server (64bits):
    The server can handle big files without crashing but the transfer fails because of the client (i think KPACS made a kind of timeout on large file transfer) on a study which contains a 1.5 GB file (!)
    We can send such files to Conquest whitout any problem (even with dgate 32bits), but client can not retrieive without make Conquest to crash.
    Since the 64 bits dgate does not crash i will consider to migrate my server to a 64 bits Windows server, and recommend the users not to send such files to the PACS.
    I'll post here to keep you inform.


    Again, thank you for your help Marcel.

    Hi Marcel,


    Indeed, users send some video since a month, so the cause is clearly identified now.
    Do you think it will be fine if i upgrade my server with dgate64, and keep the same hardware, 8 GB of RAM ?
    Or should i prevent users to send such sized video ?


    Many thanks,

    Thank you for your answer Marcel.
    I use a Windows 2003 Server R2, 32bits indeed.
    Guess i have to plan to migrate on a newer x64 system.


    Just to be sure : Which size is very big according to your mind ?

    Hello,


    One of my Conquest server keeps crashing with the following lines in pacstrouble.log :


    Quote

    20141205 15:29:14 ***VR:ReAlloc out of memory allocating 429716448 bytes


    20141205 15:29:14 ***A fatal error occurred (out of memory) - closing server


    It happened during transfer :

    Quote

    [ECHOCQ] 20141205 15:29:14 Sending file : E:\echo\base\L11-11742^CN^KEZIA^CHEMIN\1.2.392.200039.105.2.682.10.20141205.113956.93_1417775937.dcm
    [ECHOCQ] 20141205 15:29:14 ***VR:ReAlloc out of memory allocating 429716448 bytes


    [ECHOCQ] 20141205 15:29:14 ***A fatal error occurred (out of memory) - closing server
    20141208 10:13:16 Started zip and cleanup thread


    The server can operate perfectly during several days and then crash. It restarts but after several times it remains down, despite i set the "keep alive" option and the service set to "always restart" in Windows settings.


    I updated to 1.4.17d but no change, i also tried to rebuild database, same result.
    My server has 8 GB RAM installed and it should be enough i think. The pagefile is dynamically sized.
    Any idea ?


    Many thanks.

    Here it is Marcel.


    [removed link, trouble downloading; asked for data on a pm]


    I edited my previous post to specify that the worklist does not work anymore after trying to send an HL7 file which contains a ZDS section.
    Thanks.

    Marcel,


    I found Fuji system refuse to process because off a missing study instance UID.
    It seems that i had to put in as a field in ZDS section in my HL7 file.
    But when using a ZDS section in HL7, worklist query does not work anymore. Conquest refuse HL7 file if this section is present, and it make the worklist to be unusable.


    Do you have any explanation about that ?


    Thanks !

    Hi Marcel,


    I don't want to make you waste your time, so i'm going to do some testing today, and if the WL still not work i will try to call again the Fuji support team.
    I already spent some time with them trying to solve this issue whitout success and i'm afraid this is dead end, but i'd rather waste their time than yours.
    They have to give their customers some support, and they have to respect DICOM standard.
    Please, don't start to do major fix in your code, i will try to have it solved on Fujis side, ans if i really can't manange with their help, i will keep you informed and might ask for your help.


    Many thanks.


    Emmanuel

    Marcel,


    I use a Windows 2003 / win32 server.
    Of course, i'm ready to test some code if necessary.
    I thought a workaround would have been possible using lua or with some change in dicom.sql but i'm sorry this is not that simple. :?


    Many thanks for your answer.

    Hi,


    I face exactly the same issue using conquest with a fuji CR and i can't start a study on the Fuji, although the worklist query works fine.
    Is there any workaround to make the worklist works with a fuji CR device ?


    Thanks.