When you write "I tried with 127.0.0.1 and I get the exact same problem":
Have you tried the other part of the FAQ (disable IPv6)?Which problem are you referring to? Doing C-FIND from Orthanc to GE modalities, or doing C-FIND from GE modalities to Orthanc? Is it a slowness problem in Orthanc Explorer (your logs indicate 10 minutes to display the 3742 answers), or is it a general communication problem? You are mixing several issues, and I cannot follow you anymore. Please clearly separate the concerns, and structure your posts.
As mentionned in its DICOM conformance statement, Orthanc supports both Patient Root and Study Root models, both as SCU and as SCP, so this is totally unrelated:
https://bitbucket.org/sjodogne/orthanc/src/default/Resources/DicomConformanceStatement.txt
From my point of view, the fact that you don't see results when querying GE from Orthanc results from the fact that your commercial modality does not support the wildcards introduced by Orthanc in its C-FIND query in the ("Study Date" fields). This is exactly the purpose of the fourth argument in the "DicomModalities" configuration of options: Have you played with the latter argument?
http://book.orthanc-server.com/users/configuration.html
Once again, get in touch with your commercial support. Only they can help you identifying what is wrong with your setup (notably in the wildcards mentioned above). I cannot do reverse engineering in their behalf, especially from a remote location.
Final word: Don't forget you are not the only Orthanc user, and that my bandwidth is limited. The time I spent with you debugging something that you commercial suppliers could debug (and for which you pay maintenance fees), is time I cannot spent on the core of Orthanc, which freezes new features and penalizes the entire Orthanc community.
Regards,
Sébastien-
On Monday, January 23, 2017 at 9:59:46 AM UTC+1, salim....@gmail.com wrote:Dear Sebastien,
I'm a bit lucky because in my departement I found a station for which the Query is OK (with filter, fully OK).
I attached the conformance statement of both workstations :
- GE Xeleris 3.1 with the Query OK
- GE AWServer 3.2 with the Query broken (except if no conditions is used).
I might picked up something interesting :
Xeleris 3.1 support both Patient Root and Study Root query model while AWServer 3.2 only support the Study root query model.
May I found something interesting here ?
Best regards,
Salim
> Dear Sebastien,
>
> I tried with 127.0.0.1 and I get the exact same problem.
>
> I made several testing, the only Query that correctly retrieve results is in case of zero filtering (all name/ID/Accession/Studies, all data, all modalities).
> If I use any filter (name or ID or Accession or studies, or date or modalities) I get empty result list even for very large request (all patients from 1 year which is almost the entire set of studies in AWserver).
>
> It seems that Orthanc do not speak the same language as AWserver and this is the same behavior with the most recent Philips (EBW) workstations.
>
> I have one questions, when I use no filter I got 3742 answers/content in the log. When I use a filter in only get one line /answers without any number.
>
> Does it mean that Orthanc received an empty result from AWserver ? What is the answer "unit", a matching series ? patient ? or maybe a group of n patients ?
>
> Could it be helpful I can find and show you the DICOM conformance statement of each failing workstation ?
>
> If you have any other idea for testing let me know.
>
> Best regards,
>
> Salim
>
>
>
> > Dear Salim,
> >
> >
> > That's very interesting: Your last log indicates that the communication between the Orthanc core and your "KANOUNIX" server takes about one second, but that it takes about 100ms to make one query from Orthanc Explorer to the REST API of the Orthanc core (which should be almost immediate). So I feel that you actually face an user interface problem, not a DICOM communication problem.
> >
> >
> > Have you read the "Orthanc Explorer is slow under Windows on the localhost" item in the FAQ?
> > Troubleshooting — Orthanc Book documentation
> >
> >
> > Regards,
> > Sébastien-
> >
> >
> >
> > Dear Sebastien,
> >
> >
> >
> > I wanted to post a new log, I made my very large query in --verbose mode.
> >
> >
> >
> > You will see that Orthanc is reciving A LOT of answers from AWServer, it recieve 3727 answer messages which is consistent with my number of series in AWserver.
> >
> > At the end of this very long query : I got my query result in the webpage !
> >
> >
> >
> > I tried with a smallest request calling one specific ID or a small group of patients (Patient from Today) but here I got nothing and the log only display one answer log
> >
> >
> >
> > I0120 19:38:29.255957 MongooseServer.cpp:726] GET /queries/2cda873d-12dd-447d-881e-d50b1256d839/answers
> >
> >
> >
> > So now I know that the communication is OK because I got my very long query (without any conditions) in the result page.
> >
> > What is broken is specific query, sad because for sure I can't wait to download +3700 results to find my patients.
> >
> >
> >
> > Anyway, next monday I will try to investigate in GE admin interface to see if I can find more logs but my chance of success are pretty low.
> >
> >
> >
> > Tell me if this new log give you a new idea about something in your side.
> >
> >
> >
> > Thanks for your support I really appreciate that.
> >
> >
> >
> > Best regards,
> >
> >
> >
> > Salim
> >
> >
> >
> >
> >
> >
> >
> >
> > > Dear Sebastien,
> >
> > >
> >
> > > For sure we won't debug the commercial software.
> >
> > > In Dijon they have a good connection with their Philips employee and I will ask to see if he can look at Philips log, but the last time we tried to used Philips log it was so messy that it was unusable.
> >
> > >
> >
> > > However, I think that we won't find anything in the log of the commercial software because I obviously see that Orthanc is reciving message.
> >
> > > When I start a very large query (all patients, all date) I see a significant LAN activity and the web page of Orthanc hangs for a long time.
> >
> > > When I run a small query (one patient specific ID) I don't have this huge hang.
> >
> > >
> >
> > > I'm pretty sure that Orthanc is receiving something, the LAN activity should come from somewhere and I strongly suspect that data are arriving to Orthanc and maybe the problem is in their processing.
> >
> > >
> >
> > > Do you have a deeper log than --verbose to get all messages Orthanc receive from the network ?
> >
> > >
> >
> > > Best regards,
> >
> > >
> >
> > > Salim
> >
> > >
> >
> >
> > > > No, this does not explain your issue.
> >
> > > >
> >
> > > >
> >
> > > > We cannot provide any further guidance, as your problem is visibly linked either to your network topology, or to the behavior of your proprietary workstations. We would need to be on site to assist you, which is not the case.
> >
> > > >
> >
> > > >
> >
> > > > Get in touch with your PACS administrator, and with the commercial support of your DICOM modalities. Always remember that you pay your suppliers to assist you in such situations.
> >
> > > >
> >
> > > >
> >
> > > > As Orthanc is FOSS, your suppliers are able to help you debug its code (we would of course happily fix the issue if they identify a bug within the source code of Orthanc). The converse is not possible: A community project cannot debug a closed-source product.
> >
> > > >
> >
> > > >
> >
> > > >
> >
> > > > Sorry,
> >
> > > > Sébastien-
> >
> > > >
> >
> > > >
> >
> > > >
> >
> > > >
> >
> > > >
> >
> > > > On Friday, January 20, 2017 at 2:52:28 PM UTC+1, salim....@gmail.com wrote:Correct I don't find
> >
> > > >
> >
> > > >
> >
> > > >
> >
> > > > (0008,0052) QueryRetrieveLevel = STUDY => but I guess this one is query specific
> >
> > > >
> >
> > > > (0008,0061) ModalitiesInStudy
> >
> > > >
> >
> > > > (0010,0032) PatientBirthTime
> >
> > > >
> >
> > > >
> >
> > > >
> >
> > > > I will try to look at your script but I fear that it may be over my possibilities (i'm a physician, I like the computing side but not so familiar with code writing).
> >
> > > >
> >
> > > >
> >
> > > >
> >
> > > > Could these missing tags break the bidirectional query ? Is that something you can fix in a future release ?
> >
> > > >
> >
> > > >
> >
> > > >
> >
> > > > Best regards,
> >
> > > >
> >
> > > >
> >
> > > >
> >
> > > > Salim
> >
> > > >
> >
> > > >
> >
> > > >
> >
> > > >
> >
> > > >
> >
> >
> > > >
> >
> > > > > OK, so I suspect that your DICOM file does not contain some of the DICOM tags as queried by your commercial workstation (they are reproduced in my previous post), which prevents the matching from succeeding.
> >
> > > >
> >
> > > > >
> >
> > > >
> >
> > > > >
> >
> > > >
> >
> > > > > Use Orthanc Explorer to identify these missing tags.
> >
> > > >
> >
> > > > >
> >
> > > >
> >
> > > > >
> >
> > > >
> >
> > > > > Afterwards, you can dynamically patch incoming C-FIND requests by providing a Lua script implementing the "IncomingFindRequestFilter()" callback. In your case, your callback would remove all the tags that are missing from your DICOM file. This is explained in the Orthanc Book, with a sample script:
> >
> > > >
> >
> > > > > Server-side scripting with Lua — Orthanc Book documentation
> >
> > > >
> >
> > > > >
> >
> > > >
> >
> > > > >
> >
> > > >
> >
> > > > > Sébastien-
> >
> > > >
> >
> > > > >
> >
> > > >
> >
> > > > >
> >
> > > >
> >
> > > > >
> >
> > > >
> >
> > > > >
> >
> > > >
> >
> > > > > On Friday, January 20, 2017 at 2:30:33 PM UTC+1, salim....@gmail.com wrote:Yes, i'm certain to run 1.2.0 (It the first and only version I have installed in this computer).
> >
> > > >
> >
> > > > >
> >
> > > >
> >
> > > > >
> >
> > > >
> >
> > > > >
> >
> > > >
> >
> > > > > Here my system API :
> >
> > > >
> >
> > > > >
> >
> > > >
> >
> > > > > {
> >
> > > >
> >
> > > > >
> >
> > > >
> >
> > > > > "DatabaseBackendPlugin" : null,
> >
> > > >
> >
> > > > >
> >
> > > >
> >
> > > > > "DatabaseVersion" : 6,
> >
> > > >
> >
> > > > >
> >
> > > >
> >
> > > > > "DicomAet" : "KANOUNIX",
> >
> > > >
> >
> > > > >
> >
> > > >
> >
> > > > > "DicomPort" : 4006,
> >
> > > >
> >
> > > > >
> >
> > > >
> >
> > > > > "HttpPort" : 8042,
> >
> > > >
> >
> > > > >
> >
> > > >
> >
> > > > > "Name" : "MyOrthanc",
> >
> > > >
> >
> > > > >
> >
> > > >
> >
> > > > > "PluginsEnabled" : true,
> >
> > > >
> >
> > > > >
> >
> > > >
> >
> > > > > "StorageAreaPlugin" : null,
> >
> > > >
> >
> > > > >
> >
> > > >
> >
> > > > > "Version" : "1.2.0"
> >
> > > >
> >
> > > > >
> >
> > > >
> >
> > > > > }
> >
> > > >
> >
> > > > >
> >
> > > >
> >
> > > > >
> >
> > > >
> >
> > > > >
> >
> > > >
> >
> >
> > > >
> >
> > > > >
> >
> > > >
> >
> > > > > > Hello,
> >
> > > >
> >
> > > > >
> >
> > > >
> >
> > > > > >
> >
> > > >
> >
> > > > >
> >
> > > >
> >
> > > > > >
> >
> > > >
> >
> > > > >
> >
> > > >
> >
> > > > > > If I look at your logs, I indeed see that the following query is received by Orthanc:
> >
> > > >
> >
> > > > >
> >
> > > >
> >
> > > > > >
> >
> > > >
> >
> > > > >
> >
> > > >
> >
> > > > > >
> >
> > > >
> >
> > > > >
> >
> > > >
> >
> > > > > >
> >
> > > >
> >
> > > > >
> >
> > > >
> >
> > > > > > (0008,0000) GenericGroupLength = 80
> >
> > > >
> >
> > > > >
> >
> > > >
> >
> > > > > > (0008,0005) SpecificCharacterSet = ISO_IR 192
> >
> > > >
> >
> > > > >
> >
> > > >
> >
> > > > > > (0008,0020) StudyDate =
> >
> > > >
> >
> > > > >
> >
> > > >
> >
> > > > > > (0008,0030) StudyTime =
> >
> > > >
> >
> > > > >
> >
> > > >
> >
> > > > > > (0008,0050) AccessionNumber =
> >
> > > >
> >
> > > > >
> >
> > > >
> >
> > > > > > (0008,0052) QueryRetrieveLevel = STUDY
> >
> > > >
> >
> > > > >
> >
> > > >
> >
> > > > > > (0008,0061) ModalitiesInStudy =
> >
> > > >
> >
> > > > >
> >
> > > >
> >
> > > > > > (0008,1010) StationName =
> >
> > > >
> >
> > > > >
> >
> > > >
> >
> > > > > > (0008,1030) StudyDescription =
> >
> > > >
> >
> > > > >
> >
> > > >
> >
> > > > > > (0010,0000) GenericGroupLength = 52
> >
> > > >
> >
> > > > >
> >
> > > >
> >
> > > > > > (0010,0010) PatientName =
> >
> > > >
> >
> > > > >
> >
> > > >
> >
> > > > > > (0010,0020) PatientID = *XXXXXXXXX*
> >
> > > >
> >
> > > > >
> >
> > > >
> >
> > > > > > (0010,0030) PatientBirthDate =
> >
> > > >
> >
> > > > >
> >
> > > >
> >
> > > > > > (0010,0032) PatientBirthTime =
> >
> > > >
> >
> > > > >
> >
> > > >
> >
> > > > > > (0010,0040) PatientSex =
> >
> > > >
> >
> > > > >
> >
> > > >
> >
> > > > > > (0020,0000) GenericGroupLength = 24
> >
> > > >
> >
> > > > >
> >
> > > >
> >
> > > > > > (0020,000d) StudyInstanceUID =
> >
> > > >
> >
> > > > >
> >
> > > >
> >
> > > > > > (0020,0010) StudyID =
> >
> > > >
> >
> > > > >
> >
> > > >
> >
> > > > > > (0020,1208) NumberOfStudyRelatedInstances =
> >
> > > >
> >
> > > > >
> >
> > > >
> >
> > > > > >
> >
> > > >
> >
> > > > >
> >
> > > >
> >
> > > > > >
> >
> > > >
> >
> > > > >
> >
> > > >
> >
> > > > > > Several DICOM "GenericGroupLength" tags are included in the C-FIND query issued by your commercial workstation, but Orthanc <= 1.1.0 didn't support such tags correctly. This has been fixed in Orthanc 1.2.0 by the following changeset:
> >
> > > >
> >
> > > > >
> >
> > > >
> >
> > > > > >
> >
> > > >
> >
> > > > >
> >
> > > >
> >
> > > > > > https://bitbucket.org/sjodogne/orthanc/commits/af60b784d2b8c5143d9e96acae48975a1f32bcf3
> >
> > > >
> >
> > > > >
> >
> > > >
> >
> > > > > >
> >
> > > >
> >
> > > > >
> >
> > > >
> >
> > > > > >
> >
> > > >
> >
> > > > >
> >
> > > >
> >
> > > > > >
> >
> > > >
> >
> > > > >
> >
> > > >
> >
> > > > > > As a consequence, which version of Orthanc are you using? Are you certain of using the most recent version (1.2.0)? This can be check by querying the URI "/system".
> >
> > > >
> >
> > > > >
> >
> > > >
> >
> > > > > >
> >
> > > >
> >
> > > > >
> >
> > > >
> >
> > > > > >
> >
> > > >
> >
> > > > >
> >
> > > >
> >
> > > > > > HTH,
> >
> > > >
> >
> > > > >
> >
> > > >
> >
> > > > > > Sébastien-
> >
> > > >
> >
> > > > >
> >
> > > >
> >
> > > > > >
> >
> > > >
> >
> > > > >
> >
> > > >
> >
> > > > > >
> >
> > > >
> >
> > > > >
> >
> > > >
> >
> > > > > >
> >
> > > >
> >
> > > > >
> >
> > > >
> >
> > > > > > On Friday, January 20, 2017 at 12:39:06 PM UTC+1, salim....@gmail.com wrote:Hi all,
> >
> > > >
> >
> > > > >
> >
> > > >
> >
> > > > > > I have a problem with the Query function of Orthanc.
> >
> > > >
> >
> > > > >
> >
> > > >
> >
> > > > > > It happens in 2 different institution with some commercial nuclear medicine workstations.
> >
> > > >
> >
> > > > >
> >
> > > >
> >
> > > > > > The problem is that the Query gives empty results in bi-directional way :
> >
> > > >
> >
> > > > >
> >
> > > >
> >
> > > > > > If I query the commercial workstation (AW) from orthanc I get empty results.
> >
> > > >
> >
> > > > >
> >
> > > >
> >
> > > > > > If I query Orthanc from the commercial workstation I get empty results too.
> >
> > > >
> >
> > > > >
> >
> > > >
> >
> > > > > > I tested the query with different workstations and I get some of them with this query problem while others are OK
> >
> > > >
> >
> > > > >
> >
> > > >
> >
> > > > > > - For GE : The Xeleris workstation (15 y old version) is OK for Query but the new AWSever failed to Query
> >
> > > >
> >
> > > > >
> >
> > > >
> >
> > > > > > - For Philips : The fist version of EBW workstation is OK for query but the next version starting 2010 give also empty query list.
> >
> > > >
> >
> > > > >
> >
> > > >
> >
> > > > > > I put in attachment the log results of the both direction query.
> >
> > > >
> >
> > > > >
> >
> > > >
> >
> > > > > > I don't see real error message but the list stay empty while I should get patient that met the criteria in both way.
> >
> > > >
> >
> > > > >
> >
> > > >
> >
> > > > > > Thanks for your help,
> >
> > > >
> >
> > > > >
> >
> > > >
> >
> > > > > > Best regards,
> >
> > > >
Yes i'm only using IPv4, IPv6 has been always disabled.
The problem i'm talking about is doing a C-Find from Orthanc To GE AWSever. It is not a slowness problem, it is a "empty result" problem. I get answer only if I use none filter, that is why I got 3742 results but if I use any filter I always get an empty result page (while I know that AWServer contains study that should match the filter).
The reverse problem about doing C-Find from AwServer to Orthanc also exist and gives me empty results for each query but I stay focus on the first direction (Orthanc to AWServer).
I have tried all the manufacturer patches in the fourth argument none of them allowed me to get my query results.
I will try to see if I can get support from either GE in Toulouse or Philips in Dijon.