Can anyone shed some light on this strange problem with setting up a Dicom Server?

Im sorry, I have tried to do a verbose log, but couldn’t get it to work for some reason so hope the attached is usable to identify where i might be going wrong…

My intention is to set up a personal pacs server that is Q/R’able from an ipad application, ( i have experimented with Medfilm. Ipaxera and ido viewer but for the purpose of this fault finding i am using medfilm)

Set up

Intel NUC PC Running Orthanc connected to router by LAN
Radiant on the same client successfully makes a pacs connection and downloads dicoms folders (succesful AET)

Separate Windows connected to network via wifi, succesfuly makes a pacs connection with radiant and downloads dicom folder (successful AET)

Ipad connected to the same wireless network shows in the log as not not matching AET, however they do match perfectly and I have even turned off AET matching!!!

I have checked 100 times and ports match an I.P’s match, Can anyone see anything I am missing or suggest any steps to further find my fault?

Thank You

orthanc.json (12.7 KB)

Orthanc.log.20170316-192420.4904 (8.05 KB)

I see you're naming all modalities "Orthanc". I'm thinking this name is
used as a key and so subsequent entries might override previous ones
(or something along those lines). This could explain why it works with
the two other modalities since they use the same AET and appear at the
end of the list.

Try using unique names:

"DicomModalities" : {
"sample" : [ "STORESCP", "", 2000 ],
"filmmed" : [ "Filmmed", "", 104 ],
"radiant1" : [ "RADIANT", "localhost", 11112 ],
"radiant2" : [ "RADIANT", "", 11112 ]

Ive managed to work out the problem with verbose log (If interested, the FAQ guide references “configuration.json” whereas the file name is now different and so needs renaming to work)

So having done that ive uploaded the verbose log, is anything any clearer from this?

The log shows me attempting a connection using 2 different apps, and although they report back different errors, it would seem to to suggest a problem highlighted a couple of years ago where Orthanc fails to reestablish a connection, (See time 13:41pm in the verbose log attached)

Is it possible that some code to deal with this issue has been lost/rolled back?

Verbose Log.log (360 KB)

Agreed, I have had issues with installations of Radiant on different workstations across my Hospital all using the same AE, even though the IP Was different. Once I gave them unique names "Names" and [AE Titles] my problems disappeared.