Wow,
thats appreciated!
Marcel
Wow,
thats appreciated!
Marcel
Not yet, is on the list for the release.
Marcel
Hi,
Exportconverter "forward patient to XXXX" in 1.4.13beta would do the job. However, it would forward all studies to the viewing client when one is recieved. Your specific option is not there. Also note a bug in 1.4.13beta causing a high CPU load during the 10 minute timeout when using this option. So it is ok to test but please wait until release for production use.
Marcel
Try "forward study to XXXX" in 1.4.13beta. However, note that there is a bug causing high CPU load while it waits for the timeout of 10 mins. For real use you have to wait for a release version.
Marcel
Hi,
try:
between "7", "20"; defer; forward to TEP_ESOFT
The defer message should then repeat until 20 hours.
Marcel
Can you specify way how you would like to see finer control through dicom.ini? By the way, part of the bogging down is due to the bug in the 1o minutes delay.
Marcel
Can you query VITREA from conquest or store from CONQUEST into VITREA?
Marcel
Hi,
Can you query VITREA from conquest, or C-STORE from conquest to VITREA? Maybe that gives some more information. It is the C-STORE that is started as result of the C-MOVE that failes. I.e., VITREA queries PACS OK and asks it to store 361 images in VITREA. Then PACS starts a C-STORE and that fails.
Options:
Maybe the VITREA does not accept the kind of images being asked for
Maybe VITREA does not accept any command from PACS
Maybe the port for VITREA is configured wrong in PACS
Marcel
PCAS VITREA?
I do not think conquest allows spaces in an AE.
Marcel
Can you give a headerdump from an object that succesfully saved (i.e. 200 frames).
Marcel
I assume that the header corruption only occur for files stored with .v2 extension? Maybe some of these v2 files (NKI) compressed - this is not done using a transfer syntax, but by moving the pixel data to another VR. Also, older versions may not have handled jpeg completely correctly.
It may be possible to fix the files by replacing dgate.exe by a recent version, switching of NKI compression, and use a c-move to copy the images from the conquest server to the same conquest server. This will load and store the images. However, this will not generate a meta-header: only files stored with dcm extension recieve a metaheader. Such a copy operation will NOT change file extensions.
Add metaheaders (creating regular .dcm files) is possible by transmitting the the images from one server (using .v2 filenames, often with filenamesyntax 3) to another server (using .dcm filenames), where filenamesyntax is e.g. set to 4.
Marcel
There is no automatic way: you could query on the studies; make a list and then use dgate --deletestudy:studyuid in a batch file to clean the system.
Marcel
Are you using compression, forwarding, etc?
Marcel
Hi,
We have not run into this issue before. You are talking about one single dicom object (one large single file)? If so, can you let use download a sample file somewhere?
Since the entire object is loaded into memory (and maybe twice) prior to transfer I assume there is a limit due to avaible RAM.
If the software makes a copy of a dicom object than that would stop working indeed around such a size (the memory limit of a windows process is about 1.5 GB in practice).
Marcel
Hi,
conquest does not compute the DICOM elements for these counts irrespective of the dbf used.
Marcel
This is a bug with quotes in the patient ID. Is fixed in latest versions.
Marcel
Hi,
the move reply is correct I thick. Since conquest cannot initiate the move it replies that is is done.
The problem is in the reverse connection that conquest wants to make to vitrea to C-STORE the images. This is a separate association.
Is conquest listed in vitrea? Conquest itself accepts messages from anybody, but vitrea maybe only from those that are known to it. The check on AE in vitrea may also be case sensitive.
Marcel
This must be some bug: know issues are with e.g. "exportconverter0 = forward study to" and mysql registry settings. Please find these on the forum and see if they apply
Marcel
Hi,
It means what is says: the server (dgate.exe) does not have sufficient rights to write to the directory corresponding with MAG0, e.g. c:\dicomserver\data.
When does this happen?
Marcel