Posts by blub_smile

Quote from joelspangler

You might need to use forward series instead of just forward, however I'm not sure that "forward series compressed as jk to DESTINATION" is valid syntax (manual is unclear - I didn't actually try). You might need to just "forward series to DESTINATION" and set up the destination's preferred syntax as jk (in the ACRNEMA.MAP file). If you want different compression levels, you might have to build multiple destinations in ACRNEMA.MAP.

I thought that the "package selection" for forwarding is "ForwardAssociationLevel = SERIES" - meaning that only whole/complete series will be transfered. Mhh might be wrong assumption

Hi

I want a simple routing:

Everything that comes from AET: SOURCE, is send to AET: PACS and is modality CT should be forwarded to AET: DESTINATION.

My export converter works, however images are forwarded instantly instead of "by series" as specified in DICOM ini and I want a delay of at least 60s.

So what did I miss with my setup?

Here is the export converter:

ExportConverters                  = 1ExportModality0                   = CTExportCalledAE0                   = PACSExportCallingAE0                  = SOURCEExportConverter0                  = forward compressed as jk to DESTINATION

DICOM ini:

# This file contains configuration information for the DICOM server
# Do not edit unless you know what you are doing


[sscscp]
MicroPACS                = sscscp
Edition                  = Personal


# Network configuration: server name and TCP/IP port#
MyACRNema                = PACS
TCPPort                  = 5678


# Reference to other files: known dicom servers; database layout; sops
ACRNemaMap               = acrnema.map
kFactorFile              = dicom.sql
SOPClassList             = dgatesop.lst


# Host(ignored), name, username and password for ODBC data source
SQLHost                  = localhost
SQLServer                = C:\0-PACSTest\PACS-2\Data\dbase\conquest.db3
Username                 = 
Password                 = 
SqLite                   = 1
BrowseThroughDBF         = 1
DoubleBackSlashToDB      = 0
UseEscapeStringConstants = 0


# Configure database
TruncateFieldNames       = 10
MaxFieldLength           = 254
MaxFileNameLength        = 255
FixPhilips               = 0
FixKodak                 = 0
KeepAlive                = 0
LargeFileSizeKB          = 4096
PrintSquareLandscape     = 0
UseKpacsDecompression    = 1
ZipTime                  = 05:
UIDPrefix                = 1.2.826.0.1.3680043.2.135.735646.51186055
EnableReadAheadThread    = 1
PatientQuerySortOrder    = 
StudyQuerySortOrder      = 
SeriesQuerySortOrder     = 
ImageQuerySortOrder      = 
EnableComputedFields     = 1
IndexDBF                 = 1
PackDBF                  = 0
LongQueryDBF             = 1000
TCPIPTimeOut             = 300
FailHoldOff              = 60
RetryDelay               = 100
RetryForwardFailed       = 0
ImportExportDragAndDrop  = 1
QueueSize                = 128
WorkListMode             = 0
WorkListReturnsISO_IR_100 = 1
DebugLevel               = 0
Prefetcher               = 0
LRUSort                  = 
AllowTruncate            = 
DecompressNon16BitsJpeg  = 1
UseBuiltInJPEG           = 1
LossyQuality             = 95
IgnoreOutOfMemoryErrors  = 0
NoDICOMCheck             = 0
PadAEWithZeros           = 0
AllowEmptyPatientID      = 0
FileNameSyntax           = 4


# Configuration of compression for incoming images and archival
DroppedFileCompression   = jk
IncomingCompression      = jk
ArchiveCompression       = as


# Names of the database tables
PatientTableName         = DICOMPatients
StudyTableName           = DICOMStudies
SeriesTableName          = DICOMSeries
ImageTableName           = DICOMImages
WorkListTableName        = DICOMWorkList
DMarkTableName           = DICOMAccessUpdates
RegisteredMOPDeviceTable = RegisteredMOPIDs
UIDToMOPIDTable          = UIDToMOPID
UIDToCDRIDTable          = UIDToCDRID


# Banner and host for debug information
PACSName                 = PACS
OperatorConsole          = 127.0.0.1


# Configure email of error messages
MailHost                 = 
MailPort                 = smtp
MailSignon               = 
MailFromName             = 
MailRcptName1            = 
MailCollectTime          = 1
MailWaitTime             = 10


# Configuration of disk(s) to store images
MAGDeviceThreshhold      = 0
MAGDeviceFullThreshHold  = 30
IgnoreMAGDeviceThreshold = 0
MAGDevices               = 1
MAGDevice0               = C:\0-pacstest\pacs-2\data\
NightlyCleanThreshhold   = 0


# Configuration of forwarding and/or converter programs to export DICOM slices
ForwardAssociationLevel           = SERIES
ForwardAssociationCloseDelay      = 5
ForwardAssociationRefreshDelay    = 300
ForwardAssociationRelease         = 1


ExportConverters                  = 1
ExportModality0                   = CT
ExportCalledAE0                   = PACS
ExportCallingAE0                  = SOURCE
ExportConverter0                  = forward compressed as jk to DESTINATION




ForwardCollectDelay               = 10
MaximumExportRetries              = 10
MaximumDelayedFetchForwardRetries = 10

Hi

We are currently looking for DICOM Workstation Software that is not bound to a full blown PACS - so stand alone versions available and FDA/CE cleared.

Here is what I found so far:

Merge eFilm
ClearCanvas
Visus JiveX
IQ-View

What are you guys using?

Sorry

I have somehow 2 IDs here - my bad. I will delete on shortly.

Yep that did the trick on my test machine

thx marcel!

Hi

yeah that would be an great addition to save non compliant/ or corrupted images in a "failed to import correctly" folder.
I do find such entries in the logs once in a while but usually it happened weeks ago and the studies are no longer available on the source machines so the data is gone.

With such an option it would be possible ti fix those files manually.

I ended up making a network connection and dropping images vie Explorer to new server.

Sending more than 100-120k images in one push needed GBs of RAM on sending machine which resulted in crashes - however that was 1,5 years ago.

Hi

We are at roughly 30 million images stored in Jpeg2000 and DB size with MySQL is about 22-23GB

Hi

Another feedback.

It was the router. After adding port forwarding for the VPN connection everything worked as expected.
Maaaan home class routers blocking VPN traffic nowdays what a pain .. .. ... ... !

Okay

It gets more strange from here. At my place at home I have no trouble connecting and receiving data.
It must have something to do with the router at the person's home who discovered the problem. Somehow his router must be blocking the VPN tunnel or sometehing else.

weired

Quote from marcelvanherk

Hi,

I think the issue may be related to the order in which data is retrieved. Is there an osirix setting to enable multiple connections simultaneiously?

Marcel

Mhh I will check that.

However strange is that we have other Osirix client with no problems AND what is really confusion that the same Osirix clients which has that issues doesn't have the issue over LAN connection. It only happens via VPN / ADSL connection.

Therefore I will look into connection / user setting for VPN tonight

Hi

No nothing special. We tested it on a random study from the current day. On my personal laptop with windows there were no problems on either conquest versions.
The notebook with the retrieving problem is an older MacBook Pro with Osirix which is not used a lot.

I will first update Osirix and OS x and then check the VPNT router settings - however VPN and router haven't had any changes fro 24 months and if it would be vpn related the client-osirix would not get the patient list after the query because the router would block all traffic.

I will keep u posted

I did now just test it with version 1.4.17d and 1.4.16k - same problem.
What is weired is that we did not get that error before with the same receiving machine !?
mhhh I have too look into that

Hi

We suddenly get the following error message:

ReadAheadThread: readahead > 0007
17.07.2014 21:11:03 [TELERAD] ReadAheadThread: readahead > 0008
17.07.2014 21:11:03 [TELERAD] ReadAheadThread: readahead > 0009
17.07.2014 21:11:03 [TELERAD] ReadAheadThread: readahead > 0010
17.07.2014 21:11:03 [TELERAD] ReadAheadThread: readahead > 0016
17.07.2014 21:11:03 [TELERAD] RetrieveOn: givenout < 0000
17.07.2014 21:11:03 [TELERAD] Sending file : D:\DICOM\CT\2014\07\393638\1.2.276.0.37.1.183.201007.5326132\1.2.392.200036.9116.2.6.1.48.1214859555.1405568923.960477\000001.dcm
17.07.2014 21:11:03 [TELERAD] ReadAheadThread: readahead > 0025
17.07.2014 21:11:03 [TELERAD] ReadAheadThread: warning - resolving deadlock due to erratic incoming order
17.07.2014 21:11:03 [TELERAD] ReadAheadThread: readahead > 0034
17.07.2014 21:11:03 [TELERAD] ReadAheadThread: warning - resolving deadlock due to erratic incoming order
17.07.2014 21:11:03 [TELERAD] ReadAheadThread: readahead > 0035
17.07.2014 21:11:04 [TELERAD] ReadAheadThread: warning - resolving deadlock due to erratic incoming order
17.07.2014 21:11:04 [TELERAD] ReadAheadThread: readahead > 0036
17.07.2014 21:11:06 [TELERAD] ReadAheadThread: warning - resolving deadlock due to erratic incoming order
17.07.2014 21:11:06 [TELERAD] ReadAheadThread: readahead > 0037
17.07.2014 21:11:08 [TELERAD] ReadAheadThread: warning - resolving deadlock due to erratic incoming order
17.07.2014 21:11:08 [TELERAD] ReadAheadThread: readahead > 0038
17.07.2014 21:11:09 [TELERAD] ReadAheadThread: warning - resolving deadlock due to erratic incoming order
17.07.2014 21:11:09 [TELERAD] ReadAheadThread: readahead > 0039
17.07.2014 21:11:11 [TELERAD] ReadAheadThread: warning - resolving deadlock due to erratic incoming order
17.07.2014 21:11:11 [TELERAD] ReadAheadThread: readahead > 0040
17.07.2014 21:11:12 [TELERAD] ReadAheadThread: warning - resolving deadlock due to erratic incoming order
17.07.2014 21:11:12 [TELERAD] ReadAheadThread: readahead > 0041
17.07.2014 21:11:14 [TELERAD] ReadAheadThread: warning - resolving deadlock due to erratic incoming order
17.07.2014 21:11:14 [TELERAD] ReadAheadThread: readahead > 0042
17.07.2014 21:11:16 [TELERAD] ReadAheadThread: warning - resolving deadlock due to erratic incoming order
17.07.2014 21:11:16 [TELERAD] ReadAheadThread: readahead > 0043
17.07.2014 21:11:17 [TELERAD] ReadAheadThread: warning - resolving deadlock due to erratic incoming order
17.07.2014 21:11:17 [TELERAD] ReadAheadThread: readahead > 0044
17.07.2014 21:11:19 [TELERAD] ReadAheadThread: warning - resolving deadlock due to erratic incoming order
17.07.2014 21:11:19 [TELERAD] ReadAheadThread: readahead > 0045
17.07.2014 21:11:19 [TELERAD] Retrieve: remote connection dropped after 0 images, 501 not sent

Receiving /initiating client is Osirix which had been working for years thats what's bothering me.

thx

Hi

does it only go so "deep" when re-indexing?

No it doesn't. I haven't come across a limit of "deep" it goes.

Hi

I can't help you with the specific problem bu I can rule out the maximum directory issue - I "re-gened" 26 million images recently all in one MAG-Device, with I don't know close to a or over a million subdirectories so there is no limit.

Aren't there any errors in the maintenance log if so many images where skipped?

Hi

Usually it is as simple as:
1. Make the disc/drive available within the OS
2. Add the path of your dicom data to Conquest as a mag device
3. re-index that specific device
4. done

I would copy a couple of hundred MBs for testing to another location first.

Speed of re-indexing varies on the disc-drive speeds and database enginge. With MySQL on a ssd and 7200rpm RAID 6 as data storage average speed is between 200-400 images/s (CT/MRI - CR is slower)- depending on defragmentation status.

You said putting files in the data-directory an re-index failed. That is kinda strange.
Therefore the following questions:
1. What is the file extension of your files?
2. Do ya have a log of the re-index (not the whole log - just some lines)

Thx for the hint with the 2nd network card however I have switched back to MySQL.
Now everything is back to normal. Much higher speed than with the Postgres Setup - there must have been something wrong.
I will stay at MySQL for now if we do not run into stability issues, if we do I have to figure out what caused the problem.

Yeah its on the same machine as well.
I cannot explain this behavior though Postgres seems to be fast when it comes to receiver and send studies, only searching seems slow!?
I will switch back to MySQL thoufh I don't have the time to keep troubleshooting this issue and I am better in managing MySQL that postgres anyway.
Rebuild just takes 2,5d or so, not too bad.

Hi Marcel,

Which database, Postgres oder MySQL? - I am currently investigating this and it looks like MySQL is somehow a lot faster (over 2mbit DSL VPN 780 record in 6s - postgres 28s or timeout).