Posts by dimitris_skordias

    Hi Marcel,

    How can I get the number of images in a series with a Lua script, such as the following example ?




    a.SeriesInstanceUID = '1.2.34534.4564564668.467897544574.3345345345'

    b=dicomquery('STORESCP', 'SERIES', a)



    (NumberOfInstances is fake just for the example..)

    Best regards.

    Hi Marcel,

    Bit difficult to run the ping as firewalls block it and I am not sure that I can disable it.

    However, if a forward fails then the sending CQ server shouldn't retry it as per the export retry settings ?

    If i am not wrong, I have configure 30 retries for every failed export... however this seems not to work as expected ... or the configuration is not correct.

    Best regards,


    Hello Marcel,

    I have a setup with two CQ servers (1.4.19b and 1.4.19c respectively) where the 1st one, via an export converter, forwards series to the 2nd one (I have attached both config files and log snapshots)

    The problem we face is that, randomly and rarely (let's say in 1 or 2 cases per day) the forward fails and the Sender logs the message "***preretrieve/forward xxx to: remote DICOM error" while the Receiver logs "connection terminated..."

    FYI, the Sender runs on an "on premise" DELL T320 server running WinSrv2012 while the Receiver runs on a an Microsoft Azure VM running WinSrv2012 too.

    Any idea of what causes the problem ?

    Best regards,


    Sender Log.txt

    Receiver Log.txt



    Hi Marcel,

    Unfortunately the problem remains in a different form...

    It does not exhaust virtual memory, however dgate32 peaks CPU utilization (50%) and RAM (50%) and does not respond in Q/R you ask for today studies and get 0 as a response which is not the case

    If you see the attached log there are still "bad heap nodes"...

    Any suggestions what to do ? Should I switch back to 64 mode with daily restarts ?


    Hi Marcel,

    You are absolutely right !

    I checked today log and the leak occurs each time EFILM rejects an image ... so most likely this is indeed a consistent relationship.

    Could you please advise how to handle this ? I am afraid that stop using EFILM, even temporarily, could not be an acceptable option...

    Best regards.

    Hi Marcel,

    The setup is the same in all servers as it is the same VM imported (OVF files).

    I used ODBC as I was familiar with MSSQL setup which is also ODBC.

    I will try to check the activity on the peaks and let you know...

    Worth to mention that there is a user who fetches 10-20 studies (MRI,CT) on EFILM which first get uncompressed... could this generate the leakage ?

    By the way, can you please elaborate on of the heapinfo() message meaning ? what is small med and large and the respective numbers?


    Hello Marcel,

    Yesterday afternoon at 18:01 we had the last crash..

    Specifically, at 17:00 Windows Event Viewer started to log Virtual Memory shortage events ... at 18:01 Postgres crashed with error "Out of memory" and auto restarted with auto recovery... finally the system became unusable this morning at 8:00 am and we had to restart the whole server (VM) ...

    During the incident evolution, the user operations (c-Moves, C-stores, C-Finds) were usual and not extraordinary...

    I have attached the Conquest log for that period as well as Postgres log, hoping that this may help to locate the problem.

    FYI... in our setup Conquest connects to Postgres via ODBC and not native ... Could this be the cause of the problem ?

    Best regards

    Hi Marcel

    I added the print(heapinfo()) as you suggested and while I was doing some C-MOVEs the following events were posted to pacstrouble.log


    20210320 11:45:44 7844 small (466311); 95 medium (61521) 9 large (539998) *** ERROR - bad heap node

    20210320 12:00:56 34972 small (1516944); 210 medium (134631) 73 large (8084432) *** ERROR - bad heap node


    Can you please explain what that errors mean and suggest handling ?


    Hi Marcel,

    I check the logs and did not notice any remarkable C-Store or C-Move activity during the jump up...

    Also I checked the hardware via DELLs IDRAC dashboard and found the host system healthy...

    Next step is to perform the necessary updates on Windows Server 2019 (which updates Defender as well) and see if any progress occurs...

    Final step is to switch off Defender and replace it with another Antivirus...

    What do you think ?