Posts by ltcolfury

Hi Marcel,

Well, I just got it to work sort of. I used my laptop as a test on Wednesday, it worked and it's still running. (Not as a Service, but this isn't long term) Since then...

Short story today: I installed new SSD drive on the workstation, reinstalled W7, no updates, still didn't work. Uninstalled as a Service what you mentioned and it started working. Logged off, tried another send, Error Writing File to \\Diskstation\......

I installed Service, reboot. Didn't work. Uninstalled Service, reboot. Working again. I'm Re-initializing the database on the Workstation over the weekend so they can retrieve images again. But if I logoff or reboot, it won't work again. (Rinse/Repeat it seems since I figured this out)

Why would it do that? I'm so confused as why suddenly it started doing this after four years. Sorry for the edits.

Thanks for any suggestions.

C: is not full, just can't write to NAS when it did for over 3 years. When it attempts, error writing disk...

Hi Marcel,

Yes, I can access the files on the NAS, I can even write to it manually. (Right Click, create folder, etc.) When idle, ConQuest tries to write the files from C: to the NAS but same error, Error Writing File...to \\diskstation\archive\dbase\images\ So at night I've been turning off Conquest service, and manually moving them to the NAS. To pull back I've been copying them to a local PC and then importing them into KPACS and then send to PACS server.

The backup is much worse, I still can't receive any studies since that one writes directly to the NAS for some reason, but it was always setup that way. (I Attached that file on the backup Conquest.) Been doing the same as above, turning off CQ, copy/paste into NAS.

Would you have any ideas on how to correct this? It only happened when the NAS's firmware was updated and Synology tells me that it's an issue with the CQ and the permissions are correct on the NAS. (I checked as well, I cannot see anything abnormal and I didn't change anything.)

Thanks as always!

Marcel,

I think I may have spoke too soon. The images are being saved to C:\ and I'm unable to pull back any studies from remote locations. I can Query/Move and view them within Conquest though. Would you mind looking at the Dicom.ini file I attached? It's the same one I've been using all along.

Also, when you query the Conquest, it'll find the patient/study but it won't send and delete the study! The exact mention is this:

Deleting database entry for image....

***missing file: MAG1 MRN-45469\....

Thanks so much for any assistance. This has be so confused now.

Marcel...Just fixed the main one. Changed port 5678 to 104....boom it worked.

Crazy, I checked that port first thing, firewall wasn't blocking it either.

The backup is still running the re initialization database so I'll change that to port 104 when complete.

Just wanted to update!

Thanks.

Marcel,

Thank you so much for the reply. All that was done was an update to the Synology DS1813+. Both NAS's were affected by it. So that leads me to believe that's what caused it. They told me nothing they can do because they can write a file manually to the NAS's and pointed me back to ConQuest. (They aren't helpful at all.) I have it setup to run as Local User and not a service. Remote login is only me via Logmein. I have Conquest to run on startup is all.

I checked all permissions about 100x, seems as if all is correct. Conquest just won't write to the NAS and unable to pull anything back. You can query but Conquest reports "unable to find MRN-....etc, etc.

I thought of reinstalling but afraid to. Can I install the newest version on top of the current? I'm not sure of the process to do so. Same directory, run it this time as NT service? I truly cannot lose 4TB worth of data on both.

Thanks again for any assistance Marcel!

I just noticed something interesting. When I try to Query/Move to any date, I get "Unable to Connect." To me it seems as if the Conquest doesn't see the NAS. That's really odd. I did check the dicom.ini file and it's pointing correctly. This is also my backup NAS. I'm running re-initialization on the backup.

On the Main NAS, I can Query/Move and view the studies done on that date. (ex: 20180831 Study/Study Root) I still get the same error,

I'm at a loss, I don't where else to turn to get this working again on either of them. Still says, Error writing file /destination and the dicom information.

Hello,

Thanks for any assistance in advance.

I'm using Conquest Server 1.4.17. Never had an issue until today for years. (I use two of them actually for redundancy, different locations, both with the same issue.) I attached the log file from today.

The error I receive is Error Writing File...and then the MRN#, etc. I checked all the permissions and they are all fine, nothing changed. I just find it odd that this happened.

Would anyone know what the problem could be?

Thank You very much for any assistance.

Hi Marcel,

Oddly, the nightly move no longer runs at night, for about a week now. I no longer see the maintenance log listed in the daily log file. The configuration is still listed and the local HDD space is filling up again. Most studies go to MAG1 but some will continue to go to the local HDD. Very strange.

I'll paste the config for it below that I just copied. I triple checked and settings seem fine.

# Configuration of disk(s) to store images
MAGDeviceThreshhold = 0
MAGDeviceFullThreshHold = 30
IgnoreMAGDeviceThreshold = 0
MAGDevices = 2
MAGDevice0 = C:\users\archive\downloads\dicomserver1417\data\
MAGDevice1 = \\diskstation\archive\dbase\images\
ImportExportDragandDrop = 1

ImportConverter0 = storage MAG1
NightlyCleanThreshhold = 0
NightlyMoveThreshhold = 500000
NightlyMoveTarget = MAG1

I did investigate the patient from the error that listed but I don't see anything abnormal. I could try moving it manually?

Thanks again Marcel.

Hi Marcel,

I wanted to post back on my findings after monitoring for a few days.

The Nightlymove is working since I see them in the logs. But I did notice the HDD size drop again since certain studies still are placed onto the workstation.

I do see this message below (All different .dcm files of course) in the Maintenance log file each day which runs halfway down the .txt file. Is this anything to be concerned about?

10/30/2014 2:00:23 AM [CONQUESTSRV1] ***Unable to determine size of file: 'C:\users\archive\downloads\dicomserver1417\data\dbase\1.2.392.200036.9116.4.1.6288.13906\1.2.392.200036.9116.4.1.6288.13906.10002\1.2.392.200036.9116.4.1.6288.13906.10.2001.18.554566365.dcm'

Thanks again Marcel,

Chaz

Thank you as always Marcel, I appreciate the assistance.

I don't see more than one ImportExportDragDrop line. I'll copy/paste below the dicon.ini file again below, I just copied/paste from the dicom.ini file from the directory.

Something that I found strange is that between 2014/09/17 to 2014/10/18 all of the studies went into the workstation directory. I deleted them (as a test) and resent a few randomly today and they went back into that directory. But, all new studies went directly to the NAS. I did find one new study go to the workstation directory though.

In the morning I will check the workstation directory to see if the images are moved over automatically. If they do, then I won't be concerned.

# Configuration of disk(s) to store images
MAGDeviceThreshhold = 0
MAGDeviceFullThreshHold = 30
IgnoreMAGDeviceThreshold = 0
MAGDevices = 2
MAGDevice0 = C:\users\archive\downloads\dicomserver1417\data\
MAGDevice1 = \\diskstation\archive\dbase\images\
ImportExportDragandDrop = 1
ImportConverter0 = storage MAG1
NightlyCleanThreshhold = 0
NightlyMoveThreshhold = 500000
NightlyMoveTarget = MAG1

Thanks again Marcel.

Thank you for the reply Marcel! I make sure to stop the service when I make a change to the ini file.

I will do what you suggested but I will post what the configuration I have in the dicom.ini file after changing in the GUI.

Another question: I'm sort of confused why certain studies are sent to MAG0 when it's configured for MAG1. Is there some sort of setting I'm missing?

Is this correct for the threshhold?

# Configuration of disk(s) to store images
MAGDeviceThreshhold = 0
MAGDeviceFullThreshHold = 30
IgnoreMAGDeviceThreshold = 0
MAGDevices = 2
MAGDevice0 = C:\users\archive\downloads\dicomserver1417\data\
MAGDevice1 = \\diskstation\archive\dbase\images\
ImportExportDragandDrop = 1
ImportConverter0 = storage MAG1
NightlyCleanThreshhold = 0
NightlyMoveThreshhold = 500000
NightlyMoveTarget = MAG1

Thank you very much Marcel.

Hi Marcel,

I was having some issues with my workstation that has the Conquest on it. (It sends to the NAS) I didn't notice it until today but the dicom.ini file changed on its own

It was missing this below so I added it back and it's working fine again:
ImportExportDragandDrop = 1
ImportConverter0 = storage MAG1

All of the data was being saved locally. So, this caused an issue with so much data on the workstation. (275GB used out of 500GB now)

I want to make sure that I do this correctly to move these files back onto the NAS where the images are stored: (I can query the information of course but if the workstation HDD fails so do these images.)

Stop the Conquest services, Copy all studies from the "data folder" (except dbase and Printer...) place it into the NAS directory to where the rest of the data is saved? If I restart the services, Conquest should recognize them?

Also, I noticed inside the "dbase folder" there are about 10 dicom strings listed from a particular date, can I move them out as well into the NAS directory?

Thank you for your time Marcel.

Marcel,

Just dropping a note that I was able to figure the issue out that I had yesterday. I didn't know how else to let you know other than attempting to post.

As always, thank you for your assistance.

Hi Marcel, Hope all is well!

I think you may know this right away so I thought I'd ask you. I did do a search on it but nothing came up. There's two things but I believe they are somehow related.

I'm setting up a backup to the other back up I created previously for redundancy. I added below my config

# Configuration of disk(s) to store images
MAGDeviceThreshhold = 0
MAGDeviceFullThreshHold = 30
IgnoreMAGDeviceThreshold = 0
MAGDevices = 2
MAGDevice0 = C:\users\archive2\downloads\dicomserver1417\data\
MAGDevice1 = \\diskstation2\archive\images\
NightlyCleanThreshhold = 0
NightlyMoveThreshhold = 0
NightlyMoveTarget =

When I try to add below to above in the ini file, it's removed after I try and send. (See below)
ImportExportDragandDrop = 1
ImportConverter0 = storage MAG1

Once I installed Conquest and configured the NAS I did a test send from my gateway. I can ping/echo, no problems. This is what I receive in server status via Conquest: I do see the gateway AE and the study trying to initialize with this Conquest setup but it fails.

CONQUESTSRV2] Calling Application Title : "AE_PACS "
[CONQUESTSRV2] Called Application Title : "CONQUESTSRV2 "
[CONQUESTSRV2] Application Context : "1.2.840.10008.3.1.1.1", PDU length: 16384
[CONQUESTSRV2] Presentation Context 0 "1.2.840.10008.5.1.4.1.1.1" 1
[CONQUESTSRV2] ***SQLITEExec error: no such table: DICOMImages
[CONQUESTSRV2] ***SQLITEExec error: no such table: DICOMImages
[CONQUESTSRV2] ***Error saving to SQL: MRN-36204\1.2.392.200036.9125.3.307921924553.64751133183.27283_1001_001001_14049387770000.dcm
[CONQUESTSRV2] UPACS THREAD 4: ENDED AT: Wed Jul 09 16:46:17 2014
[CONQUESTSRV2] UPACS THREAD 4: TOTAL RUNNING TIME: 7 SECONDS
[CONQUESTSRV2] User interface test: local server is running!
[CONQUESTSRV2] db extract for GUI of patient dbf
[CONQUESTSRV2] ***SQLITEExec error: no such table: DICOMPatients
[CONQUESTSRV2] db extract for GUI of patient: xxx none xxx
[CONQUESTSRV2] ***SQLITEExec error: no such table: DICOMPatients
[CONQUESTSRV2] ***SQLITEExec error: no such table: DICOMPatients
[CONQUESTSRV2] ***SQLITEExec error: no such table: DICOMStudies
[CONQUESTSRV2] ***SQLITEExec error: no such table: DICOMSeries
[CONQUESTSRV2] ***SQLITEExec error: no such table: DICOMImages

The dicom.ini does have the proper directory chosen which is :

SQLHost = localhost
SQLServer = C:\Users\Archive2\Downloads\dicomserver1417\Data\dbase\conquest.db3
Username =
Password =
SqLite = 1
BrowseThroughDBF = 1
DoubleBackSlashToDB = 0
UseEscapeStringConstants = 0

Could you tell me what I've done wrong?

Thank you as always Marcel.

Marcel,

As I stated above, I mentioned I would post my findings if I found out what the issue was. (In case another user runs into this problem using the same configuration as I.)

I made a change in the NAS and it's been working for over an hour on its own.

Here is what I did…

I logged into the DS (Synology NAS), Control Panel / Shared Folder / Privileges / NFS Privileges. I noticed nothing was listed so I decided I would add something to the Network File System (NFS) area.

I created:

192.168.60.237 (<Workstation address accessing), Read/Write/Root Squash=No Mapping/Asynchronous = Yes/ Non-Privileged = Allowed/Security = Yes.

Rebooted the NAS to make sure the settings took and so far it's been working. I know that this isn't an actual part of Conquest but since I am using Conquest with this setup, I thought I'd at least post what just started working for me on this long post of mine.

Thank you very much Marcel for all your assistance!!!!! Cannot thank you enough for taking the time to answer me through this.

Ahhh yes, forgot the \ at the end of my new folder name.

Thanks again Marcel.

Hi Marcel,

Thank you for the advice. I have been in contact with the NAS forum and support, but so far they are lost on it as well. It does seem like the properties are changing on their own.

I just want to make sure I understand this correctly on what you suggested: And do this correctly

If my directory of where the images are stored (and saved in dicom.ini): \\diskstation\archive\images I would want to change the directory in the NAS (And dicom.ini) to \\diskstation\archive\images\studies (<For example... so it's one level deeper.)

Thank you again for all of your assistance! Once corrected, I will post what the issue is/was in case someone else comes across this problem.

Hi again Marcel...I was hoping perhaps you might know what this might be. The permissions issue still haunts me.

I did test it and used the local PC as the directory (MAG0) and it still did the same thing. After about 3-5 minutes of idle time, I get the error writing to the directory.

I found a way around it by doing this but I have to do it 2x a day and let it run. (Changed it back to MAG1 of course.)

In Windows, Network, explore to \diskstation\archive\images. I right click the images folder, properties, and I remove the blue "Read Only" (Only applies to files in this folder.) Attribute. Afterwards, it will run for about 6-8 hours and do not have an issue sending to the NAS. Once it ends, I have to do it all over again.

I know I cannot change this attribute since it's a Windows aspect but this tells me it has something to do with the permissions somehow. There has to be a way around this... Has anyone ever asked you about something like this? Any ideas I could try?

Thank you Marcel.

Marcel...

I think I'm good to go! I am able to query the database from my gateway (easier) but I was able to manipulate my search fields to separate the multiple studies per patient.

And, no issue with the permissions, all is working. I figured that the NAS configuration would allow the full permission to the directory but that only did the top level and not the entire directory which I did via in Windows. (It's still running but that's not a big deal)

Thank you very much again!

Thanks for the reply Marcel.

I think I figured it out, I believe it was a permissions issue with the directory of the NAS. In Windows to the path I gave all rights and removed the "Read Only" option. (Which is updating but started to work right away.)

Is there a way to properly list the "Browse the Database" by modality or name? If I search for MRN#, I see patient appear but says one (1) listed but there's multiple studies. How do I sort out which study I want to retrieve?

Thanks again Marcel, I surely hope this is the last time I bother you.