Posts by ottoopik

Ofcourse by any means... you are doing such a great job offering us very good software and I will gladly test it or help you how ever I can!

Indeed when I retrieved only serie (76 images), there were no such mess.. just slice after slice like doing manual dicom copy.

Though speed was around 2-3 mbit/s vs. manual copy that can do about 7-10 mbit/s but ofcourse this maybe because remote pacs is undergoing maintenance because its almost midnight around here.

It seems to be bug.

Is there any workaround?

remote pacs admins are complaining over us also because every slice we recieve = 1 job for their server. If other clients retrieve like 2000 slice study they make only 1 job.. but because of this bug its like 2000 job sessions per study that causes massive queue in remote pacs and they are kinda mad

Result is identical

Hey,

Since virtual server is retrieving data from pacs soooo soo long...

8-10 seconds per 1 slice, lets say its 1800 slice study.. then it will take more than 2 hours.

If I retrieve studys manually using conquest interface, no problem... study comes at steady 8-10 mbit/s (11 up/down connection)

Is there a way to configure virtualserver to act same way?

problem:

12.02.2009 11:38:52 [KLIINIKTDK]

12.02.2009 11:38:52 [KLIINIKTDK] UPACS THREAD 541: STARTED AT: Thu Feb 12 11:38:51 2009

12.02.2009 11:38:52 [KLIINIKTDK] Calling Application Title : "WFM1TLN "

12.02.2009 11:38:52 [KLIINIKTDK] Called Application Title : "KLIINIKTDK "

12.02.2009 11:38:52 [KLIINIKTDK] Application Context : "1.2.840.10008.3.1.1.1", PDU length: 100000

12.02.2009 11:38:52 [KLIINIKTDK] Presentation Context 0 "1.2.840.10008.5.1.4.1.1.2" 1

12.02.2009 11:38:52 [KLIINIKTDK] Presentation Context 1 "1.2.840.10008.5.1.4.1.1.2" 1

12.02.2009 11:38:54 [KLIINIKTDK] Written file: D:\kliiniktdk\dicom\xxxxxxxxxxxx\1.2.840.113619.2.55.3.279719183.503.1224665112.674.3_0003_000070_12344279000218.dcm

12.02.2009 11:38:54 [KLIINIKTDK] UPACS THREAD 541: ENDED AT: Thu Feb 12 11:38:54 2009

12.02.2009 11:38:54 [KLIINIKTDK] UPACS THREAD 541: TOTAL RUNNING TIME: 3 SECONDS

12.02.2009 11:38:56 [KLIINIKTDK] Virtual server - Grabbed 1.2.840.113619.2.55.3.279719183.503.1224665112.962.70 from WFM1TLN

12.02.2009 11:38:57 [KLIINIKTDK]

12.02.2009 11:38:57 [KLIINIKTDK] UPACS THREAD 542: STARTED AT: Thu Feb 12 11:38:57 2009

12.02.2009 11:38:57 [KLIINIKTDK] Calling Application Title : "WFM1TLN "

12.02.2009 11:38:57 [KLIINIKTDK] Called Application Title : "KLIINIKTDK "

12.02.2009 11:38:57 [KLIINIKTDK] Application Context : "1.2.840.10008.3.1.1.1", PDU length: 100000

12.02.2009 11:38:57 [KLIINIKTDK] Presentation Context 0 "1.2.840.10008.5.1.4.1.1.2" 1

12.02.2009 11:38:57 [KLIINIKTDK] Presentation Context 1 "1.2.840.10008.5.1.4.1.1.2" 1

12.02.2009 11:39:00 [KLIINIKTDK] Written file: D:\kliiniktdk\dicom\xxxxxxxxxxxxx\1.2.840.113619.2.55.3.279719183.503.1224665112.674.3_0003_000071_12344279000219.dcm

12.02.2009 11:39:00 [KLIINIKTDK] UPACS THREAD 542: ENDED AT: Thu Feb 12 11:39:00 2009

12.02.2009 11:39:00 [KLIINIKTDK] UPACS THREAD 542: TOTAL RUNNING TIME: 3 SECONDS

12.02.2009 11:39:01 [KLIINIKTDK] Virtual server - Grabbed 1.2.840.113619.2.55.3.279719183.503.1224665112.962.71 from WFM1TLN

12.02.2009 11:39:02 [KLIINIKTDK]

whole this process takes too much time......

manual copy = 10-25 minutes per study

virtual server retrieve = 2.5+ hours.... same study

halp!

ty!

Afaik exportconverter is for image forwarding, but we need to retrieve some old archived images.

Study level aint working with virtualservers therefore we may overload host pacs.

That too.. from local disk, everything works just fine.

Hmmm ok.

I'll ask them what is the exact problem and why he wants us to retrieve images in study level.

Quote from marcelvanherk

I am afraid the NAS issue is still baffling me. The logs are normal. Have you looked at these posts?

http://www.image-systems.biz/f…28&p=2904&hilit=nas#p2904

Can you also open the GUI when the service is running, and test some maintenance options (show free space on device?) Can you query the server when it runs as a service.

Marcel

Display More

Will check the link.

Yep, I have opened GUI, maintenance options shows free space, I can query but I cannot write/read to/from device. In only GUI mode, all works fine

Hello,

This command works with export converters

but

Is there a way to get it working in study level with "Vritualserverfor*=" situation?

At the moment it is retrieving studys from virtual servers in association level = image , we need to change it to study level because our central PACS host admin says its a problem to them - I have no information why it is problem for them...

Yeap I have about same errors.

Oke.. I tried running service as user that has mapped drive etc.

Updated mysql to new version.

No results... if running "nt service mode" I still get "***error writing..." and such error messages.

It clearly has something to do with LACIE nas and Mysql (libmysql.dll?)

mysql tables are local yes.

If you mean that mysql is on the same machine as conquest service?

Tryed that one also, does not work! Error message is same.

And it occurs only with mysql

Hello,

Some background: Win2003srv, conquest 1.4.14, Lacie 1.5 TB (Ethernet 1Gbps BigDisk), Mysql 5.0.45.

Everything is fine in GUI mode but if I run conquest in "nt service mode" it no loger can write/read on/from storage device (Lacie)
(Windows share on device that has username and password, its mapped to specified drive)

When using local drives or Fibercat storage thats connected via optical cables and mapped to dynamic disk - no problems so far, everything works brilliant.

The problem seems to occur only with MYsql because when I use MS sql 2005, it all works fine again even w lacie.

Because of this lacie interface and all is so crap that I cannot chek out logs if conquest is accessing or at least trying to do it at all...

Any Ideas or help?

Ott
Tallinn Diagnostic Centre