zip download error

105 views
Skip to first unread message

Alison

unread,
May 7, 2019, 6:03:21 PM5/7/19
to Orthanc Users
Hello,

Has anyone had trouble downloading zip files from the Orthanc Explorer? When I try to download the zip file it takes a few minutes and then says it has successfully completed but when I view the zip file its too small to contain any files or says "invalid zip". I'm wondering if its because we have a lot of large multi-band sequences in our protocol? 

I have had it successfully work twice. I have not done anything differently when it doesn't work and the scan files are about the same size. 

Thank you!

Alison

Sébastien Jodogne

unread,
May 8, 2019, 4:26:01 AM5/8/19
to Orthanc Users
Hello,

If your DICOM study is so large that it takes a few minutes to generate a ZIP file, this leads to a timeout in the HTTP protocol.

You should use the asynchronous mode to generate the ZIP file (which is not implemented in the Orthanc Explorer):
http://book.orthanc-server.com/faq/improving-interface.html

Here is a sample interactive session of such an asynchronous operation:

{
   "ID" : "24c22a0f-0ec1-468e-a4e8-73ac2ec8a741",
   "Path" : "/jobs/24c22a0f-0ec1-468e-a4e8-73ac2ec8a741"
}
{
   "CompletionTime" : "20190508T082249.985684",
   "Content" : {
      "Description" : "REST API",
      "InstancesCount" : 46,
      "UncompressedSizeMB" : 5
   },
   "CreationTime" : "20190508T082249.727206",
   "EffectiveRuntime" : 0.255,
   "ErrorCode" : 0,
   "ErrorDescription" : "Success",
   "ID" : "24c22a0f-0ec1-468e-a4e8-73ac2ec8a741",
   "Priority" : 0,
   "Progress" : 100,
   "State" : "Success",
   "Timestamp" : "20190508T082257.001143",
   "Type" : "Archive"
}

HTH,
Sébastien-
Message has been deleted

Alison

unread,
May 9, 2019, 5:27:52 PM5/9/19
to Orthanc Users
Hi Sebastien,

Thank you for your response. We're having some trouble with this: 

The first call:
contains what I assume is the uuid (e.g., http://localhost:8042/app/explorer.html#study?uuid=8fb41d30-e6057100-f693d86f-b6819d72-4fc1a9b9 ) from the orthanc explorer, but I really have no clue as that string (8fb41...) disappears in the subsequent calls like:
So, I don't know where we would find that 8fb string, and when I try using the id (or uuid) from orthanc explorer, none of the steps work.  I'm also not sure I can make asynchronous calls as that syntax generates errors like:

Invoke-WebRequest : Parameter cannot be processed because the parameter name 'd' is ambiguous. Possibl
include: -DisableKeepAlive -Debug.
At line:1 char:97
+ ... rchive -X POST -d
+                    ~~
    + CategoryInfo          : InvalidArgument: (:) [Invoke-WebRequest], ParameterBindingException
    + FullyQualifiedErrorId : AmbiguousParameter,Microsoft.PowerShell.Commands.InvokeWebRequestCommand

I have attached a screenshot as well.

Thank you!
OrthancCommandLine.jpg

Sébastien Jodogne

unread,
May 10, 2019, 2:51:39 AM5/10/19
to Orthanc Users
The "8fb..." ID is indeed the Orthanc identifier of a DICOM study of mine:

The "24c..." ID is the random identifier of the asynchronous job that consists in creating an archive from the study:

As an unique, random identifier, the "24c..." will change for each call to the asynchronous API.

bieegl

unread,
May 13, 2019, 2:20:58 PM5/13/19
to Orthanc Users
Thanks for this information.  Unfortunately, I cannot get any of the calls with various combinations of POST syntax I've tried to work.  Are there any examples of asynchronous calls on a windows installation of orthanc?  If none of the syntax works, does this mean I don't have the rest API installed properly?  For example -X POST generates syntax errors, but -Method POST seems to be acceptable syntax, it just still fails to recognize/understand the '{"synchronous":false}' part.

For example, if I just run curl http://localhost:8042/jobs
---


StatusCode        : 200
StatusDescription : OK
Content           : [
                       "256e56b0-1c5f-4028-b234-0df5caf0422e",
                       "4d56d295-feca-493d-bdc2-99b25bd7e483",
                       "58f6df68-02f6-47ab-b193-a4f657d38592",
                       "65040f25-6b6b-4148-8021-3dfbbd37b38b",
                       "6fa10c96-20d6-4fe9-a9c...
RawContent        : HTTP/1.1 200 OK
                    Connection: keep-alive
                    Content-Length: 433
                    Content-Type: application/json; charset=utf-8

                    [
                       "256e56b0-1c5f-4028-b234-0df5caf0422e",
                       "4d56d295-feca-493d-bdc2-99b25bd7e483",
                     ...
Forms             : {}
Headers           : {[Connection, keep-alive], [Content-Length, 433], [Content-Type, application/json; charset=utf-8]}
Images            : {}
InputFields       : {}
Links             : {}
ParsedHtml        : System.__ComObject
RawContentLength  : 433
---

and I can make more detailed calls like



StatusCode        : 200
StatusDescription : OK
Content           : {
                       "CompletionTime" : "20190509T195858.384467",
                       "Content" : {
                          "Description" : "REST API",
                          "InstancesCount" : 9533,
                          "UncompressedSizeMB" : 2498
                       },
                       "CreationTime" : "2019050...
RawContent        : HTTP/1.1 200 OK
                    Connection: keep-alive
                    Content-Length: 498
                    Content-Type: application/json; charset=utf-8

                    {
                       "CompletionTime" : "20190509T195858.384467",
                       "Content" : {
                          "Description" : ...
Forms             : {}
Headers           : {[Connection, keep-alive], [Content-Length, 498], [Content-Type, application/json; charset=utf-8]}
Images            : {}
InputFields       : {}
Links             : {}
ParsedHtml        : System.__ComObject
RawContentLength  : 498


Is there something more basic that I need to check?
thanks,
Brian

Sébastien Jodogne

unread,
May 14, 2019, 4:54:15 AM5/14/19
to Orthanc Users
I can guarantee you that the calls from my previous post work properly on GNU/Linux platforms with bash:

This is a Windows-specific issue related to escaping characters in shells, for which I personally can't provide support:

Benjamin Golinvaux

unread,
May 14, 2019, 5:03:56 AM5/14/19
to Orthanc Users
Hello

When you type curl, it actually calls Invoke-WebRequest, that is *not* compatible with curl in terms of flags (The Powershell team admitted that hijacking the `curl` alias was a very bad idea)

To sole this, you can either choose to install and use curl or fix the Invoke-WebRequest flags.

- In order to use curl from Powershell, use curl.exe instead of curl : this will ensure the actual curl is used.

- If you prefer to use the Windows native tools, you can find an example of Invoke-WebRequest in the Orthanc book : 


Hope this helps! 

bieegl

unread,
May 20, 2019, 7:31:58 PM5/20/19
to Orthanc Users
Thanks for this info Benjamin.

I can now run:

PS C:\Users\VHASFCROACHB> Invoke-WebRequest -Uri http://localhost:8042/studies/608332e1-535e1e15-f97f323f-4560532e-be794
7f5/archive -Method POST -Body '{"Synchronous":false}'

and get:

StatusCode        : 200
StatusDescription : OK
Content           : {
                       "ID" : "768698d3-fc25-4f40-a5b8-7bf3714bcb37",
                       "Path" : "/jobs/768698d3-fc25-4f40-a5b8-7bf3714bcb37"
                    }

RawContent        : HTTP/1.1 200 OK
                    Connection: keep-alive
                    Content-Length: 111
                    Content-Type: application/json; charset=utf-8

                    {
                       "ID" : "768698d3-fc25-4f40-a5b8-7bf3714bcb37",
                       "Path" : "/jobs/768698d3-fc25-4f40...
Forms             : {}
Headers           : {[Connection, keep-alive], [Content-Length, 111], [Content-Type, application/json; charset=utf-8]}
Images            : {}
InputFields       : {}
Links             : {}
ParsedHtml        : System.__ComObject
RawContentLength  : 111


then I can run:
PS C:\Users\VHASFCROACHB> Invoke-WebRequest -Uri http://localhost:8042/jobs/768698d3-fc25-4f40-a5b8-7bf3714bcb37

and get:

StatusCode        : 200
StatusDescription : OK
Content           : {
                       "Content" : {
                          "Description" : "REST API",
                          "InstancesCount" : 9533,
                          "UncompressedSizeMB" : 2498
                       },
                       "CreationTime" : "20190520T204028.318424",
                       "EffectiveRuntime" : 142.75...
RawContent        : HTTP/1.1 200 OK
                    Connection: keep-alive
                    Content-Length: 504
                    Content-Type: application/json; charset=utf-8

                    {
                       "Content" : {
                          "Description" : "REST API",
                          "InstancesCount" : 9533,
                         ...
Forms             : {}
Headers           : {[Connection, keep-alive], [Content-Length, 504], [Content-Type, application/json; charset=utf-8]}
Images            : {}
InputFields       : {}
Links             : {}
ParsedHtml        : System.__ComObject
RawContentLength  : 504

If I just plug that url into a browser, I can keep getting the full json information, which eventually lists:

{
   "CompletionTime" : "20190520T205821.664025",
   "Content" : {
      "Description" : "REST API",
      "InstancesCount" : 9533,
      "UncompressedSizeMB" : 2498
   },
   "CreationTime" : "20190520T204028.318424",
   "EffectiveRuntime" : 1028.9929999999999,
   "ErrorCode" : 0,
   "ErrorDescription" : "Success",
   "ID" : "768698d3-fc25-4f40-a5b8-7bf3714bcb37",
   "Priority" : 0,
   "Progress" : 100,
   "State" : "Success",
   "Timestamp" : "20190520T214238.507178",
   "Type" : "Archive"
}

then I try:

PS C:\Users\VHASFCROACHB> Invoke-WebRequest -Uri http://localhost:8042/jobs/768698d3-fc25-4f40-a5b8-7bf3714bcb37/archive > D:\...\zipTest.zip

and this did not work - the zip file is corrupted, even though I saw a long-running dialogue in the power shell indicating that lots of bytes were being read.  Have I made an obvious syntax error at this last step or in some prior step?

thanks,
Brian

Benjamin Golinvaux

unread,
May 21, 2019, 2:02:17 AM5/21/19
to Orthanc Users
Hello Brian

Redirecting the binary output of Powershell commands using the > operator is unfortunately often unreliable (see https://brianreiter.org/2010/01/29/powershells-object-pipeline-corrupts-piped-binary-data/).   I think this was not part of their design goals to treat raw bytes as pipe-able data. This is often a problem when mixing unix-style command line programs with Powershell.

Could you please give it a try using the Invoke-WebRequest -OutFile parameter ?

Let me know how this goes!

bieegl

unread,
May 22, 2019, 1:31:15 PM5/22/19
to Orthanc Users
It worked!!! Thank you so much!

specifically, this:

PS C:\Users\VHASFCROACHB> Invoke-WebRequest -Uri http://localhost:8042/jobs/768698d3-fc25-4f40-a5b8-7bf3714bcb37/archive
 -OutFile 'D:\...\zipTestMay202019.zip'

The -OutFile argument must be a 'characterString' path to the destination OutFile, so single quote were required to make it work.  If you run it this way:

PS C:\Users\VHASFCROACHB> Invoke-WebRequest -Uri http://localhost:8042/jobs/768698d3-fc25-4f40-a5b8-7bf3714bcb37/archive
 -OutFile D:\...\zipTestMay202019.zip

It seems like it's working, generates a file, but the file is not the actual archive.

Benjamin Golinvaux

unread,
May 23, 2019, 2:40:51 AM5/23/19
to Orthanc Users
Hi Brian 

Thanks for the feedback!

I am puzzled as to why the single quotes are required in this case.

Were there maybe spaces or backticks (`) in the D:\....  file path?  Being given what happens without quotes, it seems to be something else but my imagination fails on me on that one!

Cheers.
Reply all
Reply to author
Forward
0 new messages