Move-SCU fails even after succesful Store-SCP of same study

[Jonathan salas]

I have generated --verbose logs and attached them above along with the configuration file.

I am using Orthanc to interface with Biosense Webster CARTO3 software and they are connected to each other via a network switch. All communication happens with the default port.

I am having isolated instances where restoring a study from the Orthanc server to the PACS workstation fails even after a successful storage onto the server. I have generated 4 --verbose logs which each represent an attempt and is explained in the README.txt file. In the first attempt, I tried to restore a study from the server and received the following error on the Orthanc side:

E0315 12:05:47.882938 OrthancException.h:85] The specified path does not point to a regular file: The path does not point to a regular file: C:\Active Study Data\TRANSEPPACS-A\0e\7e\0e7eb045-4e65-492f-a40b-f03f1ff4fef1

E0315 12:05:47.882938 MoveScp.cpp:237] IMoveRequestHandler Failed: The specified path does not point to a regular file

On the PACS side my output is:

[RestoreService] - Dicom Status Code = 'C000' - Biosense Status = DicomUnknownResponse. Restore read response: Unmapped error

C_MOVE operation did not complete successfully (error = 49152). Aborting Storage SCP connection

Error handling C-MOVE operation

I am having similar errors with other studies but this is inconsistent. Any advice on how to proceed would be GREATLY appreciated.

[Jonathan salas]

In attempt 2, I succesfully stored the study to the server. In attempt 3 I attempted to restore that file and got the same error as in attempt 1. In attempt 4, I reboot the CARTO3 workstation and try to restore again from scratch only to land back at the outputs from instance 1.

[Alain Mazy]

Since you have that error: 

The path does not point to a regular file: C:\Active Study Data\TRANSEPPACS-A\0e\7e\0e7eb045-4e65-492f-a40b-f03f1ff4fef1

could you tell us if the given file is there ? Is it accessible ?

If the file is not there, and the instance still exists in the database, I would say that "someone/something" deleted the file...

FYI, it might be interesting to read this section of the doc: http://book.orthanc-server.com/faq/orthanc-storage.html

--

Alain Mazy / Software Developer
a...@osimis.io / +32 494 31 67 27

	OSIMIS S.A.  Quai Banning 6BE-4000 Liège  www.osimis.io

[Jonathan salas]

The file is not there nor is it created when I store to the server but nonetheless asks for it when I go to restore.

The only interaction I have with the storage folder is that using "FreeFileSync" I have it set so that the contents of the storage folder are mirrored over to an archive on a different disk. Going through the sync logs and FreeFileSync's garbage can I can confirm that files are only being pushed one way (see attached screenshot) and that the only thing being "deleted" and then replaced is 3 files:

- index

- index-shm

- index-wal

Here is what a standard log looks like:

Enter code here___________________________________________________
|3/15/2019  TRANSEPPACS-A One-Way Update to Archive
|
|    Completed successfully
|    Items processed: 7 (45.3 MB)
|    Total time: 00:04:03
|__________________________________________________

[1:02:11 PM]  Info:  Comparison finished: 5,342 items found
[1:06:14 PM]  Info:  Synchronizing folder pair: Update>

                         C:\Active Study Data\TRANSEPPACS-

A
                         E:\PACS Backups\TRANSEPPACS-A Raw Data
[1:06:14 PM]  Info:  Updating file "E:\PACS Backups\TRANSEPPACS-A Raw Data\index"
[1:06:14 PM]  Info:  Updating file "E:\PACS Backups\TRANSEPPACS-A Raw Data\index-shm"
[1:06:14 PM]  Info:  Updating file "E:\PACS Backups\TRANSEPPACS-A Raw Data\index-wal"
[1:06:14 PM]  Info:  Creating folder "E:\PACS Backups\TRANSEPPACS-A Raw Data\bd\0b"
[1:06:14 PM]  Info:  Creating folder "E:\PACS Backups\TRANSEPPACS-A Raw Data\fa\6d"
[1:06:14 PM]  Info:  Creating file "E:\PACS Backups\TRANSEPPACS-A Raw Data\bd\0b\bd0b234b-831d-48b3-a87e-3dd15ebb8c6f"
[1:06:14 PM]  Info:  Creating file "E:\PACS Backups\TRANSEPPACS-A Raw Data\fa\6d\fa6db637-79b0-4f17-81b4-251598d3066b"
...

[Jonathan salas]

Here is the screenshot with my "FreeFileSync" settings as well

[Sébastien Jodogne]

Your database is visibly corrupted because you have not stopped Orthanc before running the backup, as documented in the Orthanc Book:

http://book.orthanc-server.com/users/backup.html

[Jonathan salas]

Okay so I have stopped running the backup software and will ensure to stop Orthanc before I try that again.

How should I proceed so that I can successfully restore these files?

-JS

[Alain Mazy]

If the files are not there anymore, you should re-import them by uploading them through the web interface or pushing them through DICOM protocol.

[Jonathan salas]

Importing the files through the DICOM protocol doesn't create the file that is being requested upon retrieval.

I also can not import the files through the web interface because when CARTO3 software exports files to USB, it doesn't export them as .DCM files but rather a format that can only be retrieved by interfacing with another CARTO workstation.

I should have a copy of all of the files that were uploaded to Orthanc, I just wonder how the best way to rebuild my corrupted database at this point?

[Jonathan salas]

If you look at attachment 2 and attachment 3 above you'll see the verbose logs for re-importing (2) and then failed subsequent retrieval (3) of the files.

[Alain Mazy]

Since your DB/Storage is corrupted, you can 

- either restore a working backup of the full DB and all files (OrthancStorage directory) 

- or you can erase the OrthancStorage directory and then re-import everything the same way as you imported it the first time.

[Alain Mazy]

Checking the subject of your request, settings this flag to true in the config file might solve your particular problem but there's really no guarantee ... and your DB/Storage might still be corrupted at other places

  // Specifies how Orthanc reacts when it receives a DICOM instance
  // whose SOPInstanceUID is already stored. If set to "true", the new
  // instance replaces the old one. If set to "false", the new
  // instance is discarded and the old one is kept. Up to Orthanc
  // 1.4.1, the implicit behavior corresponded to "false".
  "OverwriteInstances" : false,

from https://bitbucket.org/sjodogne/orthanc/raw/Orthanc-1.5.6/Resources/Configuration.json

[Jonathan salas]

I have decided to rebuild the database from scratch so as to avoid any other corruption issues. Thank you for all the support.

My question now is whether Windows 7 "Backup and Restore" will corrupt the DB as well if the storage directory is flagged as a part of the folders included in the backup?

[Jonathan salas]

Also, can you please explain why I would want the overwrite flag set to "false" by default?

[Alain Mazy]

I guess "Backup and Restore" might corrupt the SQLite DB as well.

If you want to perform "live backup", you might want to switch to a PostgreSQL DB.

Another option might be to have another Orthanc running on another PC and implement autorouting to copy every instance received on the main Orthanc to the backup one.

[Alain Mazy]

Actually, when handling valid DICOM files, you're not supposed to need that overwrite flag set to "true".  Since DICOM files are supposed to be immutable, if you upload a DICOM file a second time, Orthanc will check that it already has this file (mainly based on the SOPInstanceUID).  

And, files are not supposed to disappear so no need to overwrite...

However, having this configuration set to "true" is always a good choice (we just set the default value to "false" to keep the backward compatibility).

Enabling overwrite was mainly introduced for guys who are changing the compression inside DICOM files to minimize disk usage.  In this case, they will upload the same instance a second time and they want the recompressed instance to replace the previous file.

[Jonathan salas]

Now that I think of it, are there any other windows features that should be turned off with respect to the storage folder?

What would happen if for example the storage folder inherits archiving, encryption, or indexing from it's parent?

Get Outlook for Android

---

From: Alain Mazy <a...@osimis.io>
Sent: Thursday, March 21, 2019 4:14:10 AM
To: Jonathan salas
Cc: Orthanc Users
Subject: Re: Move-SCU fails even after succesful Store-SCP of same study

 

[Jonathan salas]

With respect to the Overwrite flag:

In my situation we may restore the DICOM images to another CARTO workstations where we may edit it such as manually cleaning up the electroanatomical map generated and excluding data points. If we re-uploaded the same study with these modifications, what should our Overwrite flag be?

---

From: Alain Mazy <a...@osimis.io>
Sent: Thursday, March 21, 2019 4:14:10 AM
To: Jonathan salas
Cc: Orthanc Users
Subject: Re: Move-SCU fails even after succesful Store-SCP of same study

 

[Alain Mazy]

then you would need Overwrite = true

[Jonathan salas]

Thank you again for the continued support, our department has historically not had success gaining access to the hospital DICOM network and I'll be the first to attempt to host their own.

With regards to the original issue, are there any other windows features that should be turned off with respect to the storage folder?

What would happen if for example the storage folder inherits archiving, encryption, or indexing from it's parent?

[Sébastien Jodogne]

With regards to the original issue, are there any other windows features that should be turned off with respect to the storage folder? 

What would happen if for example the storage folder inherits archiving, encryption, or indexing from it's parent?

Just give a try, then contribute to the Orthanc project by sharing your insights on this forum.