Hi,
cleanup works on date of entry into the server. See http://www.image-systems.biz/p…p?t=688&highlight=cleanup
Marcel
Hi,
cleanup works on date of entry into the server. See http://www.image-systems.biz/p…p?t=688&highlight=cleanup
Marcel
The sample I gave had the filtering.
Both the MIRROR copying and forwarding go through a queue that has a small size (512 images). One the queue is full the server gets delayed.
To solve the speed difference problem you might use defer to delay forwarding until night-time. The forward queue is then written to disk.
Marcel
Hi,
there is no need for 64 bit yet: the server software is just plain 32 bits.
There is an known issue however of some 2003 machines with MS sql server 2005 giving a secure socket layer error: the delphi GUI application then cannot connect to the sql server.
The MYSQL issue you mentioned may be related to the registry settings reported earlier. The version 1.4.13beta automatically sets the right registry setting.
Marcel
Hi
We use MIRRORDEVICE (one server's MAG0 is the other's MIRROR0 and vice-versa) for this task, but that will copy as soon as files are recieved and not wait until later.
I think other rules will quickly cause a loop. However, it may be possible to filter on CallingAE and stop the converter from shuttling files back directly like so:
on server1: ifnotequal "%u","SERVER2"; forward to SERVER2
on server2: ifnotequal "%u","SERVER1"; forward to SERVER1
Marcel
Hi LJJ,
Printer_files is used for printing, but also for temporary files passed to the decompressor and for conversion to GIF that should have been deleted after use. So yes you can delete any files in there.
But I do not understand why they are there. Are they dicom files, gif images for the web viewer or text files?
Maybe the server can create the images there but not delete them due to insufficient rights?
What version and OS do you use?
Marcel
Hi,
The 16 bit jpeg 'bug' is a protection since in an early version of conquest there were problems using Offis tools on DICOM files created by conquest. If you want I can take this test out and you could see if it then works correctly.
The NAS problem with conquest running as a service has not been solved to my knowledge. I have no clue why this still should happen when the service login equals the user that normally logs in.
Marcel
Hi,
The largest systems (like ours) run windows and MS-SQL which is very stable - but mind backing up the database to protect against disk loss. However, Mysql runs fine too on windows. The linux version has no complete mysql support yet, although I think some users got it to work. Also the lack of a GUI on linux makes it more work. PostgresSQL is too slow to my liking.
Marcel
Seems like a very smart way to transfer large amounts of DICOM data to me.
Marcel
Not yet,
objects larger than 500 MB partially crash the server. On the list for the next release, but mey be very hard to fix other than that the object is totally rejected. A 64 bit version would help here....
Marcel
Hi,
I think Syngo declines such a move. You can try to enter multiple patient IDs separated by just a comma (,) into the patient ID box. Best use a text editor to make the list.
Marcel
There may be an issue with a - dash in the patientID. Which version are you running? Does this occur for all patients?
Marcel
Hi,
This is intended behavior: it only sends a command to the server and sending the command succeeds. I will see if I can add your wished behavior.
Marcel
Try dgate --debuglevel:4 and see what query is executed. That might solve the mystery.
Marcel
For the manual: dgate -?
I ran the commands on a windows/linux machine where they worked. By the way, the server (dgate -v) needs to run (in the background) for dgate -- commands to work.
Marcel
Hi,
the calledAE issue is probably a bug where the spaces are not correctly handled. As for reading in the new dicom.ini, kill and restart server should do the job. However, once a DICOM image is recieved a filename is generated and stored in the database - that will be reused for the same object. Only deleting the image/series/study/patient will force generation of a new filename.
Marcel
Hi,
The date format in DICOM images must be YYYYMMDD. Any other format will not be correctly handled (as you have shown) and lead to a rejected database insert when the resulting string is too long (more than 8 chars).
The too long date string should have been truncated by our server and give a warning message. That this does not happen is a known bug.
Marcel
Hi, some command line tools exist but they are not so well documented nor user friendly.
Try:
dgate "--studyfinder:conquestsrv1|t|%s %s %s"
where t is a part of name or patient ID.
Or:
dgate "--query:dicomstudies|PatientID||%s"
Marcel
Does the crash occur when the object is dropped onto conquest? If so, a copy of the offending would be appreciated to see if I need to fix something.
Marcel
Hi,
They can be on the same machine but need to be set up on different ports: not both 104.
Marcel
Hi,
conquest accepts Hl& files (via drag and drop or a batch file) to fill its own worklist database. That can be queries through DICOM. I am not aware of a DICOM option to forward or recieve modality worklist entries (they can only be queried). So, it is not clear how your pacs loads its modality worklist table. I guess conquest cannot help there.
Marcel