Posts by qcor

  • problem with adding files via 'incoming' folder and drag&drop

    I figured it out... took me a while cause I was focused on the error "-FAILED: file does not contain correct UIDs".

    Turns out it had nothing to do with UIDs - it's much simpler than that.


    I had 3 instances of dgate using the same MAG0... and that's fine BUT it also means that they are using the same 'incoming' folder. I should have specified an unique WatchFolder for each of them... but I didn't... cause I'm a genius :/

    So yeah... there is nothing wrong with files/UIDs. It's just me being stupid and having 3 process fighting over files for who gets it first.


    One "mystery" solved. But I still have no idea why drag&drop is not working... no errors, no log entries (even on debug 4), nothing. Zero reaction.

    My gut is telling me it could also be OS related(win2012r2), but drag&drop is working fine everywhere else. It looks like gui is not getting (or ignoring) the drop event but that's just a wild guess.

    Worst part is I have no idea how to test/debug this further. I'm pretty sure it was working on the same system back when I had 1.4.19

  • problem with adding files via 'incoming' folder and drag&drop

    Hi


    I'm having problems with image importing. Dragging files onto the GUI does nothing at all, so I tried to use 'incoming' folder. Here is what I got:


    Code
    [DICOMARCH] ***[AddImageFile] \\ARCHIWUM\pacs_archive\arch_studies\incoming\1_1.2.392.200039.113.2.110014750.10.20210728.191544.31.dcm -FAILED: file does not contain correct UIDs

    [DICOMARCH] ***[AddImageFile] \\ARCHIWUM\pacs_archive\arch_studies\incoming\1_1.2.392.200039.113.2.110014750.10.20210728.191544.31.dcm -FAILED: file does not contain correct UIDs

    [DICOMARCH] ***[AddImageFile] \\ARCHIWUM\pacs_archive\arch_studies\incoming\1_1.2.392.200039.113.2.110014750.10.20210728.191544.31.dcm -FAILED: file does not contain correct UIDs

    [DICOMARCH] ***[AddImageFile] \\ARCHIWUM\pacs_archive\arch_studies\incoming\1_1.2.392.200039.113.2.110014750.10.20210728.191544.31.dcm -FAILED: Error on Load

    [DICOMARCH] ***[AddImageFile] \\ARCHIWUM\pacs_archive\arch_studies\incoming\1_1.2.392.200039.113.2.110014750.10.20210728.191558.421.dcm -FAILED: file does not contain correct UIDs

    [DICOMARCH] ***[AddImageFile] \\ARCHIWUM\pacs_archive\arch_studies\incoming\1_1.2.392.200039.113.2.110014750.10.20210728.191558.421.dcm -FAILED: file does not contain correct UIDs

    [DICOMARCH] ***[AddImageFile] \\ARCHIWUM\pacs_archive\arch_studies\incoming\1_1.2.392.200039.113.2.110014750.10.20210728.191558.421.dcm -FAILED: file does not contain correct UIDs

    [DICOMARCH] ***[AddImageFile] \\ARCHIWUM\pacs_archive\arch_studies\incoming\1_1.2.392.200039.113.2.110014750.10.20210728.191558.421.dcm -FAILED: Error on Load


    The funny thing about it is that those files were taken from the MAG0. Modality sent them to PACS with no problems. Then I copied some images from the study to the tmp folder, then deleted whole study via web interface and then tried to import the files again.

    Some files were imported with no problems, but about half of them produced this kind of errors.


    Any ideas?

  • bunch of random questions/problems

    Another 'random' question, I hope you don't mind. :)


    How does the processing queue work? I realize this is a complex question so let me narrow it down a bit to a specific case which I don't understand.


    I'm forwarding all MG studies to a specific workstation, like this:

    ExportModality0 = MG

    ExportConverter0 = forward compressed as j2 to MGWORKSTATION;


    Unfortunately this machine (MGWORKSTATION) was turned OFF for almost 2 weeks. I saw the 'export failed' and queue retries in the log and I thought everything will just queue up and will be send as soon as the workstation is be back ON.


    Then I got reports from the staff about studies ( other than MG ) not "coming through" so I began investigating and found a bunch of 'holding processing of ...' messages on studies like CT, MR etc..

    Then I turned on the MGWORSTATION as a test and now I'm seeing bunch of "Queue: retrying processing of file ... CT"


    So it looks to me like a growing backlog of MG studies was somehow able to stop the processing of other unrelated studies. I didn't expect this... so my question is - why is this happening? how to prevent it? How are autorouting failures disrupting other stuff?

  • Conquest 1.5.0b with MS SQL issue

    Using 1.5.0c (b + few hotfixes by Marcel) I can confirm that dgate64.exe uses about 200Mb while idle and can EASILY use up to 4Gb of ram (or even more) while 'working' but I've >never< seen it crash. Also the memory usage goes down after a while so it doesn't look like a memory leak.

    Back when I had 1.5.0b it was running 24/7 literally for months with zero issues (under moderate load - 150ish MR/CT per day)


    The difference is I'm using PostgresSQL. Maybe it's a db specific issue?

  • bunch of random questions/problems

    Interesting.. It's quite the opposite for me.

    I'm seeing mostly socketupdates.

    While the log is idle it always stops on a socketupdate. (for example after echo it stays at socketupdate)

    Under heavy log load I sometimes see scrollupdate flickering here and there so it looks like this one is working.


    I've never seen a timer update.

  • bunch of random questions/problems

    yes - it's the ‎8 II ‎2021, ‏‎22:03:36 version


    umm.. honestly I'm not sure. We do have one in the network but I'm not sure if it's being used any more. If yes then it would be on veeeery rare cases.

  • bunch of random questions/problems

    no no, it is NOT permanently missing. Just not shown until next trigger.

    In fact it's easy to reproduce - I used 2 dicomechos in a row (via the console.bat) and got this (attached)

    As you can see there are 2 echo responses in the serverstatus.log (on the left) and only one in the GUI window on the right.

    It WILL show up in the GUI eventually, so it's not totally missing for sure... it's more like it's still waiting in the buffer waiting for next trigger.

  • bunch of random questions/problems

    this version was much better. refresh rate is much smoother and no gui freezing.

    However I'm still missing few last lines (usually 1-3 lines). In the previous version I've seen much bigger chunks missing so I think there is an improvement (or maybe I'm just luck today :) )

  • bunch of random questions/problems

    I've been testing this version for a while under a 'normal load' (which for me means 0-2 people downloading/uploading a study simultaneously) and honestly it's behavior is hard to describe.

    The updates are happening at a semi-random intervals.. I'd say somewhere between 1 - 3sec (with 1 being very common, 3 being very rare). That's far from being 'smooth' but that's not the worst part.

    The worst part is that sometimes there is stuff missing in the window. Sometimes it's just last 1-2lines, but sometimes it's a LOT of lines.

    (see attached screenshot) In this particular case you can see that there is plenty of stuff in the log (on the left) but everything below the red line is missing in the conquest window.

    And it stays like that until something will trigger the next update.

    Maybe it's still waiting in the buffer?... but then it should be flushed after 0.1s, shouldn't it?


    and bonus question:

    What does the 'ui' compression mean? Can't find it the manual. I'd expect a 'j2' (as defined in the arcnema) but I'm getting 'ui' instead. (transfer between 2 dgates 1.5)

  • bunch of random questions/problems

    This is not at all what I'm observing here. I see this:


    - when the buffer is full - yes

    - when data comes in - no

    - it has not been refreshed for 0.1 s - no

    - on a timer, 0.1 s after last data came - no


    I've tried giving it a nudge with the console and by dropping in single file. It looks like the "buffer is full" is the ONLY one working.

  • bunch of random questions/problems

    yeah.. I just noticed it too. I must have been lucky the first few times.

    Now the serverstatus window is just empty.


    edit1: umm.. wait a sec.. I alt-tabbed back there and it was working again.. o.O testing further.. I'll be back


    edit2: ok so it looks/acts as if you are using some kind of a log buffer (of fixed size?) and waiting for it to get full before flushing it into the status window.

    This would cause 2 exact problems I'm observing now:

    1) if nothing is happening (aka nothing new is being logged) when the gui opens then you are stuck with an empty status window.

    2) you are always missing last X lines which are currently in the buffer (and haven't been flushed yet cause of low log activity)

    If that's the case the solution should be simple - wait till buffer full OR time_passed>X. The real question is: are YOU causing this or the OS?

  • bunch of random questions/problems

    I think you fixed it. No more freezing.

    I didn't test it *extensively* but in 300 seconds of serverstatus scrolling non-stop (sending images with debug lvl 1 so it was a LOT of text) - 0 freezes. :thumbup:


    While testing I've noticed another thing - the progress bar, nor the text updates are not happening while transferring studies.

    After I click "copy to destination" I get this (attached) and it stays like that forever. It IS WORKING.. just not updating. It should do the "copied X out of Y images", right? Green progress bar is frozen like that too.

    It stopped working around the time I turned off the EnableComputedFields because of some Agfa dicom clients butchering my database with stupid/unnecessary queries about image count so I thought maybe it was related to that...

    ... but I also updated to 1.5.0 pre-release at about the same time... so maybe it's just a bug?