dear Ed,
thank you very much for your assistance. This really helps me with getting OpenREM operational.
I have tried the two things,
on 1: the guide does not let me start orthanc in a verbose logging mode that writes to a log file. somehow the script needs some tweaking. I managed to start it in verbose mode, writing output to the terminal screen.
on 2: ICT department fixed memory on 16Gb and in the more or less 48 hours after that I've ben querying two times an hour on all modalities without any errors. I'm very happy with that.
for now I conclude that adaptable memory was not compatible with my installation on Windows Server and that this was fixed by fixing the memory.
You remember I was in the impression that I'm dealing with a few different type of errors.
Now today I'm querying on DX, for all studies on a given day. Say there are 130 studies.
Then in about 50% of the cases (days) the import_dx goes fine, until somewhere halfway during the "move" process, where I get the following error:
[09/Jun/2023 15:25:31] ERROR [remapp.netdicom.qrscu:2101] Move of study 106, series 2: Warning (0xb000) - Sub-operations completed, one or more failures. Sub-ops completed: 0, failed: 1, warning: 0.
there is no orthanc log/error.
Because I send the command through the terminal I get the traceback in the terminal;
Traceback (most recent call last):
File "E:\venv\Lib\site-packages\openrem\scripts\openrem_qr.py", line 12, in <module>
qrscu_script()
File "E:\venv\lib\site-packages\openrem\remapp\netdicom\qrscu.py", line 2646, in qrscu_script
wait_task(b)
File "E:\venv\lib\site-packages\openrem\remapp\tools\background.py", line 245, in wait_task
return task(blocking=True)
File "E:\venv\lib\site-packages\huey\api.py", line 932, in __call__
return self.get(*args, **kwargs)
File "E:\venv\lib\site-packages\huey\api.py", line 974, in get
raise TaskException(result.metadata)
huey.exceptions.TaskException: InterfaceError('connection already closed')
which seems to be related to a port issue?
after this error the openrem log keeps looping;
every 2 or 3 seconds: [09/Jun/2023 15:26:41] INFO [remapp.netdicom.qrscu:91] Returning Success response from echo to localhost 104 ORTHANC
now this loop stops with a fresh terminal query, and after that I remove the error task from the system through the web interface.
then with a lower frequency I get a similar error;
[09/Jun/2023 15:52:46] ERROR [remapp.netdicom.qrscu:2101] Move of study 79, series 3: Warning (0xb000) - Sub-operations completed, one or more failures. Sub-ops completed: 0, failed: 1, warning: 0.
with no traceback in the command prompt.
however with an orthanc error log
E0609 15:52:52.749825 OrthancException.cpp:61] The TCP port of the DICOM server is privileged or already in use: (port = 104) cannot create network: TCP Initialization Error: Only one usage of each socket address (protocol/network address/port) is normally permitted.
E0609 15:52:59.155926 main.cpp:2075] Uncaught exception, stopping now: [The TCP port of the DICOM server is privileged or already in use] (code 2004)
new query:
[09/Jun/2023 15:57:59] ERROR [remapp.netdicom.qrscu:2588] Query-retrieve aborted: DICOM nodes not ready. QR SCP echo is Success, Store SCP echo is Association aborted or never connected
W0609 15:52:59.155926 main.cpp:2106] Orthanc has stopped
then on the web interface:
Orthanc PACS
Error: Server is down - see status
and after windows server reboot all is fine again.
Now somehow this does not happen (as far as i understand now) with the short queries of 1 hour or such. And then only when querying on DX for a whole day, which is usually a large number of files and hence a relatively long process (couple of minutes).
It would be nice for our hospital to be able to query all studies from a past week or couple of days without error, hence I'm interested in tweaking settings or such thing to prevent above errors.
best regards
Han
Op woensdag 7 juni 2023 om 12:03:02 UTC+2 schreef Ed McDonagh: