Posts by ctao

thank you Sabine - the entry "DIMSE receiveFileData: 16378 bytes read <last: NO>" is the last one that I have seen. It has not been followed by a "YES".

Although - I have not seen the "DIMSE receiveFileData: 16378 bytes read <last: NO>" at all the past couple times I ran verbose mode, including now after I created a new imagebox in C:\

Now the log entry reads:

PDU Type: Associate Request, PDU Length: 202 + 6 bytes PDU header
01 00 00 00 00 ca 00 01 00 00 4f 4e 49 53 32 32
20 20 20 20 20 20 20 20 20 20 4f 4e 45 50 41 43
53 50 4f 4c 4c 45 52 20 20 20 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 10 00 00 15 31 2e
32 2e 38 34 30 2e 31 30 30 30 38 2e 33 2e 31 2e
31 2e 31 20 00 00 2e 01 00 00 00 30 00 00 11 31
2e 32 2e 38 34 30 2e 31 30 30 30 38 2e 31 2e 31
40 00 00 11 31 2e 32 2e 38 34 30 2e 31 30 30 30
38 2e 31 2e 32 50 00 00 37 51 00 00 04 00 02 00
00 52 00 00 11 31 2e 32 2e 34 30 2e 30 2e 31 33
2e 31 2e 31 2e 31 53 00 00 04 00 00 00 00 55 00
00 0e 64 63 6d 34 63 68 65 2d 31 2e 34 2e 33 31

Parameters:
Our Implementation Class UID: 1.2.826.0.1.3680043.2.360.0.3.5.4
Our Implementation Version Name: IIS_354
Their Implementation Class UID: 1.2.40.0.13.1.1.1
Their Implementation Version Name: dcm4che-1.4.31
Application Context Name: 1.2.840.10008.3.1.1.1
Calling Application Name: ONEPACSPOLLER
Called Application Name: ONIS22
Responding Application Name:
Our Max PDU Receive Size: 16384
Their Max PDU Receive Size: 131072
Presentation Contexts:
Context ID: 1 (Proposed)
Abstract Syntax: =VerificationSOPClass
Proposed SCP/SCU Role: Default
Accepted SCP/SCU Role: Default
Proposed Transfer Syntax(es):
=LittleEndianImplicit
Requested Extended Negotiation: none
Accepted Extended Negotiation: none
called AE: ONIS22
calling AE: ONEPACSPOLLER
Constructing Associate AC PDU
DIMSE receiveCommand

---------------------------------------------------------------------

does any of that make sense to you? it does not to me, except that I think one of my sending stations is called "ONIS22" and/or "ONEPACSPOLLER" - although I do not actually know who they are!

I will be checking with my sending station's vendor later today to hopefully get a more detailed log.

I think my hard disk still has room, 347 GB used, 233 GB free. My database (imagebox, right?) is, or was: C:\KPacs\Imagebox\
now the database is C:\KPACSImagebox\

I'll have to get someone to send me something and see what happens and will keep you posted. Thank you again for your help and expertise, Sabine!

Quote from Sabine Stridde

This means that K-PACS is currently receiving data. The images are sent over the network in individual data packages of 16378 Bytes per package (= PDU size). The information "<last: NO>" means that the just received package is not the last one and that more data will follow. It will keep the association open.

Ah great, I thought I was getting somewhere sorry I assumed that this meant that I was receiving images. I guess I am receiving data, but not enough, so the studies are incomplete? So I am in fact not receiving the images.

To make matters more complicated, one of my sending stations reported the error message was in the AET. I have never changed mine, and neither has the sending station, but we checked anyway and of course they were the same.

I do not have any filters on, and I have 1066 studies in my worklist, and 1097 folders in the KPacs/Imagebox. I am not sure why there is a difference, but I did just delete a bunch of older studies. I assume when I delete them from KPACS that they are deleted from the computer file folder...?

If I sort the computer files by date, I do not find any of the "missing" studies, at least within the past week or so when this started happening

thank you for all your help, Sabine. It seems like KPACS is receiving the data, but there is something internal to KPACS that is not allowing the images to appear in the worklist. When I run verbose mode,I get other info in the log but mostly it's that line, "DIMSE receiveFileData: 16378 bytes read <last: NO>" that I see, and there are no new images that appear in the worklist...so, a software bug is how I see it. I will look into other programs including iQ-VIEW. thank you again!

ok, I was wondering how to activate verbose mode - didn't know you had to stop the server. you are right the log is pretty long and I cannot even scroll up to see the full log anymore...but right now there are probably hundreds of lines saying the same thing:

DIMSE receiveFileData: 16378 bytes read <last: NO>

what does that mean?

if I get iQ-VIEW I want to make sure these issues do not occur again.

thank you for your help Sabine!

ok thanks Sabine. my dynamic IP has not changed in about a year, and every time I have problems receiving images, I check the IP and it is the same. I also check my download/upload speeds and they are normal.

I have also checked the Server Admin Tool (under Local Settings), and the KPACS server status always says: "Server is running" Is there something else I should be looking for?

thanks Sabine. sorry if this is a duplicate post - not sure where the other one went. anyway, I do NOT have a static IP. I used to, but then discovered the dynamic IP accounts were much less expensive and the address never changes anyway...but it sounds like there may be some other issues as well? do you know if having a dynamic IP address (that stays the same) may be an issue?

the cost to have a similar down/upload speeds (similar to my current residential account) with addition of a static IP over here requires a business account which is about 3X the cost!

thanks Sabine! I do not have a static IP. I have a regular "dynamic IP" internet connection, but the IP address has yet to change. Are there issues with using a non-static IP? the cost to upgrade to static is significant, I believe about 2x the cost.

thank you, Sabine. I have not noticed any particular time of day that is prone to this problem. I am receiving plain x-rays only from several different sources/stations. Some just send a few images at a time, some may send 50 at a time, but the problem exists regardless of incoming volume. I'm not sure what multi-frame images are - are they multiple images that can be scrolled thru? - I do not usually receive those types.

the log or error message on the sending machine side says, "communication error", or on another source it will say:

Device Error Occurred
[PACS]
[Socket Connection Error]

my process log (in process manager) doesn't seem to show any errors - it always says it's listening on port 104

I have adequate download speed (80 Mbps), but I my sending machines have DSL and so their upload speed should be ok (?), but at about 1.5 Mbps.

Any other ideas? could it be that the slower connection on the sending side is a problem?

Hello, I am new to this forum!

I have been using KPACS 1.6 to receive images from multiple servers (they are actively sent from multiple servers). KPACS will intermittently not be able to receive the images - servers will report an error message - sometimes this is resolved with a re-boot, but not always. I have Win 7 64. I don't see anything showing in Process Log, and my status is always "listening".

Is this a common problem (I have not seen any other posts about this specifically)?

Please help! I am not that tech-savvy. Thank you in advance!