Hey
After increasing queuesize, all seems to work fast now.
no more lag so far.
but when using "forward STUDY to" then ocasionally I still get asossiation lost so I went back to default system and everything is fine.
Ott
Hey
After increasing queuesize, all seems to work fast now.
no more lag so far.
but when using "forward STUDY to" then ocasionally I still get asossiation lost so I went back to default system and everything is fine.
Ott
I have noticed that sometiems portion of data comes fast and then it starts to slow down until 1 slice per sec
I changed queuesize to 1200, will see how it works now.
But now when I used "forward study to" instead of just forward to.. I'm getting alot of: ***preretrieve/forward xxx to: association lost
errors
sorry
ForwardAssociationLevel = STUDY
ForwardAssociationCloseDelay = 15
ForwardAssociationRefreshDelay = 3600
ForwardAssociationRelease = 1
ExportConverters = 2
ExportConverter0 = forward to WFM1TLN
ExportConverter1 = forward to itkpaksFIR
ForwardCollectDelay = 300
MaximumExportRetries = 0
MaximumDelayedFetchForwardRetries = 0
although ForwardCollectDelay = 300 does not seem to be working.
Changed
ExportConverter0 = forward study to WFM1TLN
ExportConverter1 = forward study to itkpaksFIR
now it is queuing 5 minutes before forwarding study
was the problem because i'm was missing forward "study" to ?
There is two forwarding rules.
Hello,
This is problably not conquest problem at all but I just thought that It wont do any harm to ask it here If anyone has similar experience with philips CT and conquest.
Somewhy CT is sending studyes into conquest pacs almost 1 slice in 1...2 seconds. So.. sending study that has 600 slices takes 600 seconds or more
its all 1Gb LAN and no network bottlenecks.
The most weird thing is that some studys arrive to conquest at full speed.
Any thoughts?
Ty!
one dgate and one gui only
my backup pacs finishes regenning soon then I'll check what happens if I try to move about same amount of data on mysql 5.1
it printed only "clearing..." and "starting archiving process"
it took maybe 1 minute max and then command screen returned to normal.
btw I've noticed that sometimes when using debug logging and switching different log levels, it may mess up whole debug logging and nothing appears until complete conquest client exit and start.
it does show activity about export converters and clients requesting info/data but doesnt show dgate --commands log
using these commands does not generate any log sadly :\
so I did "dgate -v -au" and see how it turns out tonight?
Making space at night by moving LRU patients to: MAG1
Amount of MB to move: 27218
[TDKPACS] ---------- Start archival operation -----------
failed selecting patients for nightly moving
[TDKPACS] ---------- Start archival operation -----------
failed nightly moving
hmmm...
about 6.2+ GB
5+ mln images
26k + studies
if thats the case then I understand.. dgate just timeouts before stuff gets done?
but is there any way of having somekinde of --movestudies:mag0,mag1(date range) in future?
at the moment im just manually moving oldest folders from one mag to another and then regenning single directoryes.
Hmm yes but I dont :\
I'm trying 14.15 version atm and see if it works.
EDIT: yes.. same happens with 1.4.15
problably its new mysql version thats causing this problem
I will try to going back to older mysql and newer conquest version and let you know how it goes.
the whole reason why I upgraded mysql was because database crashed and was not recoverable... so I thought that I might aswell upgrade mysql in process.
nah.. same thing. nothing happens
EDIT: I did notice now that my mysql innodb buffer pool was too small... maybe that was the whole reason, I upped it and testing again as we speak.
Maybe I was just trying to move too much at once and sql base got overhelmed by queries.
first
[TDKPACS] Connected by address: 0100007f
[TDKPACS] Testing transfer: '1.2.840.10008.1.2' against list #0 = '1.2.840.10008.1.2'
[TDKPACS] 0000,0002 18 UI AffectedSOPClassUID "1.2.840.10008.1.1"
[TDKPACS] 0000,0100 2 US CommandField 48
[TDKPACS] 0000,0110 2 US MessageID 1
[TDKPACS] 0000,0800 2 US DataSetType 257
[TDKPACS] 0002,0010 17 UI TransferSyntaxUID "1.2.840.10008.1.2"
[TDKPACS] 9999,0300 42 LO ConquestConsoleText "Server command sent using DGATE -- option"
[TDKPACS] 9999,0400 16 LO ConquestConsoleComma "restoremagflags:"
[TDKPACS] Server command sent using DGATE -- option
[TDKPACS] Resetting archive flag on device: MAG0
[TDKPACS] Update Table: DICOMImages
[TDKPACS] Updates : DeviceName = 'MAG0'
[TDKPACS] Where : DICOMImages.DeviceName LIKE 'MAG0.%'
[TDKPACS] Resetting archive flag on device: MAG1
[TDKPACS] Update Table: DICOMImages
[TDKPACS] Updates : DeviceName = 'MAG1'
[TDKPACS] Where : DICOMImages.DeviceName LIKE 'MAG1.%'
second
[TDKPACS] Connected by address: 0100007f
[TDKPACS] Testing transfer: '1.2.840.10008.1.2' against list #0 = '1.2.840.10008.1.2'
[TDKPACS] 0000,0002 18 UI AffectedSOPClassUID "1.2.840.10008.1.1"
[TDKPACS] 0000,0100 2 US CommandField 48
[TDKPACS] 0000,0110 2 US MessageID 1
[TDKPACS] 0000,0800 2 US DataSetType 257
[TDKPACS] 0002,0010 17 UI TransferSyntaxUID "1.2.840.10008.1.2"
[TDKPACS] 9999,0300 42 LO ConquestConsoleText "Server command sent using DGATE -- option"
[TDKPACS] 9999,0400 32 LO ConquestConsoleComma "selectlruforarchival:100000,MAG0"
[TDKPACS] Server command sent using DGATE -- option
[TDKPACS] Query Distinct Tables: DICOMImages, DICOMSeries, DICOMStudies, DICOMPatients
[TDKPACS] Columns : DICOMPatients.PatientID, DICOMPatients.AccessTime
[TDKPACS] Where : DICOMImages.DeviceName = 'MAG0.Archiving' and DICOMStudies.PatientID = DICOMPatients.PatientID and DICOMImages.SeriesInst = DICOMSeries.SeriesInst and DICOMSeries.StudyInsta = DICOMStudies.StudyInsta
[TDKPACS] Order : DICOMPatients.AccessTime
third
[TDKPACS] Connected by address: 0100007f
[TDKPACS] Testing transfer: '1.2.840.10008.1.2' against list #0 = '1.2.840.10008.1.2'
[TDKPACS] 0000,0002 18 UI AffectedSOPClassUID "1.2.840.10008.1.1"
[TDKPACS] 0000,0100 2 US CommandField 48
[TDKPACS] 0000,0110 2 US MessageID 1
[TDKPACS] 0000,0800 2 US DataSetType 257
[TDKPACS] 0002,0010 17 UI TransferSyntaxUID "1.2.840.10008.1.2"
[TDKPACS] 9999,0300 42 LO ConquestConsoleText "Server command sent using DGATE -- option"
[TDKPACS] 9999,0400 36 LO ConquestConsoleComma "movedatatodevice:MAG1,MAG0.Archiving"
[TDKPACS] Server command sent using DGATE -- option
[TDKPACS] Query Distinct Tables: DICOMImages, DICOMSeries, DICOMStudies, DICOMPatients
[TDKPACS] Columns : DICOMPatients.PatientID, DICOMPatients.AccessTime
[TDKPACS] Where : DICOMImages.DeviceName = 'MAG0.Archiving' and DICOMStudies.PatientID = DICOMPatients.PatientID and DICOMImages.SeriesInst = DICOMSeries.SeriesInst and DICOMSeries.StudyInsta = DICOMStudies.StudyInsta
[TDKPACS] Order : DICOMPatients.AccessTime
tryed debug lvl 4... it just doesnt show anything :\
mysql error log is clean.
I think I'll test 14.15 version and maybe downgrade to another mysql version in the evening and look how it works out since I have no idea how to debug or trace the problem at the moment.
Hey,
hmm.. yes 1.4.16rc4b and 32bit. Im using MySQL 5.5.8
I have not changed dicom.sql nor changed truncatedfieldnames in dicom.ini - it's all default.
This is all that serverstatus shows on these commands:
dgate --restoremagflags:
Server command sent using DGATE -- option
Resetting archive flag on device: MAG0
Resetting archive flag on device: MAG1
dgate --selectlruforarchival:100000,MAG0
Server command sent using DGATE -- option
dgate --movedatatodevice:MAG1,MAG0.Archiving
Server command sent using DGATE -- option
all those commands take long time to execute but what is server doing at that time, I have no information at all... but I do notice that free disk space on MAG0 is not getting bigger and MAG1 aint getting smaller.
dgate -as100000
dgate -amMAG0.Archiving,MAG1
nothing happens, server log does not show any activity... should it?
dgate --restoremagflags:
dgate --selectlruforarchival:10000,MAG0
dgate --movedatatodevice:MAG1,MAG0.Archiving
those commands just show in log "command sent using Dgate" or smth and thats it... nothing more happens.
yes im running dgate from dir where conquest pacs is.
also im having alot of failures in event log: Faulting application dgate.exe, version 0.0.0.0, faulting module dgate.exe, version 0.0.0.0, fault address 0x00061286.
windows 2003 R2 sp2
I think i'll roll back to 14.15 version and see if I still get these issues
Hey
Is there any way of moving studies from one mag to another?
I have tryed
dgate --restoremagflags:
dgate --selectlruforarchival:100000,MAG0
dgate --movedatatodevice:MAG1,MAG0.Archiving
commands but nothing happens... dgate.exe just doesnt do nothing. debug doesnt show anything.
also nightlymovetreshold does not work in latest conquest build.
it would be super awesome to have command --movestudies:MAG0,MAG1,(date range)
or is there any way of triggering nightlymove manually so i dont have to wait until 02:00 ?
Thanx!
sry, yep tables!
If I understand you correctly then yes.. other patients are missing.