Dear Orthanc community,
I recently installed Orthanc 1.9.3 on debian
with the parameters of the config file (for more details see the attached file orthanc.json):
“DefaultEncoding” : “Utf8”,
“AcceptedTransferSyntaxes” : [ “1.2.840.10008.1.*” ],
“DicomAlwaysAllowEcho” : true,
“DicomAlwaysAllowStore” : true,
“DicomAlwaysAllowFind” : true,
“DicomAlwaysAllowGet” : true,
“DicomCheckModalityHost” : false,
“DicomScuPreferredTransferSyntax” : “1.2.840.10008.1.2”,
plugins:
postgresql-index 4.0
serve-folders 1.9.3
worklists 1.9.3
and clients use to download images: horos, radiant
so, the log file accumulates records with the value (for more details see the attached file orthanc.log.png):
W0525 12: 15: 21.752451 OrthancGetRequestHandler.cpp: 163] C-GET: Unknown transfer syntax received: 1.2.840.10008.1.2
What could be the problem and how to solve it?
besides, requests (c-find) are very slow, maybe this is due to the large accumulation of records in the log file?
orthanc.json (34.4 KB)
Detailed log file with --trace-dicom parameter
see attached file trace-dicom.log
вторник, 25 мая 2021 г. в 13:24:04 UTC+6, nur nur:
trace-dicom.log (69 KB)
if i download by Radiant client, there not errors
in attached file log
вторник, 25 мая 2021 г. в 15:44:14 UTC+6, nur nur:
Can anybody help me solve the problem?
вторник, 25 мая 2021 г. в 15:55:32 UTC+6, nur nur:
Hello,
The log “C-GET: Unknown transfer syntax received: 1.2.840.10008.1.2” is a warning message that can be ignored (this is not an error message).
This warning is indeed misleading (as it is generated for the rejected presentation contexts, and not because of an unknown transfer syntax). It has just been removed by the following changeset that is pending in the mainline:
https://hg.orthanc-server.com/orthanc/rev/b14989f9ff8b
In the “trace-dicom.log” file you sent, all the C-STORE responses are marked as successful, so your DICOM client claims to have properly received the DICOM instances from Orthanc.
In either case, I don’t personally have access to an Apple/Windows computer with Horos/Radiant, so I cannot reproduce your issue and provide further support without a minimal working example using free and open-source tools:
https://book.orthanc-server.com/users/support.html#discussing-a-minimal-working-example
https://book.orthanc-server.com/faq/proprietary.html
Sébastien-
Thank you
My main problem is that the query results are very slow and periodically not shown to Orthank clients.
Query (c-find) results are shown in approximately 30 seconds 109 studies
and therefore thought that it was due to the accumulation of the message “Unknown transfer syntax received”
Can you tell me in which direction to look for a solution so that the result of requests is executed without delays and emptys?
I used scaling considering the recommendation https://book.orthanc-server.com/faq/scalability.html
one base and several orthangs,
in the attached file scheme.png is scheme
пятница, 28 мая 2021 г. в 15:50:37 UTC+6, s.jo...@gmail.com:
If you have a 100Mbps network, it is totally normal that transferring 500MB (the size of a typical CT-scan) takes about 1 minute. This is just a matter of network bandwidth, and has nothing to do with Orthanc.
Logging messages are faster than network transfers by order of magnitudes, and cannot impact the performance of transfers.
In either case, you should hire a professional who could do an audit the quality of your Orthanc setup on site:
https://book.orthanc-server.com/users/support.html#finding-professional-assistance
Sébastien-
one of the best query result, in attach file
суббота, 29 мая 2021 г. в 15:57:29 UTC+6, s.jo...@gmail.com:
now the query result was completed in 15 seconds, mostly 20-30 seconds, and sometimes the results is empty
суббота, 29 мая 2021 г. в 16:01:02 UTC+6, nur nur:
This timing indicates that you have not set the configuration option “StorageAccessOnFind” to “Never”, contrarily to what is recommended in the Orthanc Book:
https://book.orthanc-server.com/faq/scalability.html#recommended-setup-for-best-performance
Consequently, Orthanc has to download 118 DICOM files from your storage area (the “number of candidate resources after fast DB filtering”), which requires NFS transfers.
Check out the description of this option in the configuration file:
https://hg.orthanc-server.com/orthanc/file/Orthanc-1.9.3/OrthancServer/Resources/Configuration.json#l670
// Performance setting to specify how Orthanc accesses the storage
// area during C-FIND. Three modes are available: (1) “Always”
// allows Orthanc to read the storage area as soon as it needs an
// information that is not present in its database (slowest mode),
// (2) “Never” prevents Orthanc from accessing the storage area, and
// makes it uses exclusively its database (fastest mode), and (3)
// “Answers” allows Orthanc to read the storage area to generate its
// answers, but not to filter the DICOM resources (balance between
// the two modes). By default, the mode is “Always”, which
// corresponds to the behavior of Orthanc <= 1.5.0.
the fact of the matter is that this parameter is specified as “never”
in attach file my config
and I’m more worried about the fact that the result periodically does not give anything, doctors complain
суббота, 29 мая 2021 г. в 16:10:38 UTC+6, s.jo...@gmail.com:
orthanc.json (34.5 KB)
Triple-check your configuration files, especially the value of the “StorageAccessOnFind” option on all your Orthanc servers (Orthanc0 and Orthanc1 on your previous “scheme.png”).
In either case, this is a problem with your deployment, with your QNAP server, or with your network infrastructure, for which I cannot do anything remotely. As written above, get in touch with professional assistance:
https://book.orthanc-server.com/users/support.html#finding-professional-assistance
If this is an issue without Orthanc, propose a minimal working example to reproduce your timing issue:
https://book.orthanc-server.com/users/support.html#discussing-a-minimal-working-example