Unable to Receive Images from Multiple Servers on KPACS 1.6

  • 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!

  • That doesn't sound like a general issue. You can only trouble-shoot this by checking the log information on both sides. Maybe the logs of the sending machines give any indication. Or you could activate the K-PACS server log to see if it captures any information.


    Might be that - at times - K-PACS receives too many associations at once to handle. Or there are difficulties with the network and images cannot be transmitted properly. Or maybe the K-PACS server component - responsible for receiving images - is not always running.


    Try to narrow down the circumstances under which the issues occur. Is it happening at particular times during the day? Does it happen only with specific kinds of images (e.g. larger multi-frame objects or images from a particular modality/station)?


    For a diagnostic reading station including Windows 7 and 64 bit support as well as advanced DICOM handling and logging, we recommend trying out iQ-VIEW. It comes with medical device certification, which allows its use for diagnostic purposes, and technical support from local resellers and the manufacturer.

  • 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?

  • A socket error occurs when you try to connect from one station to another but it is inaccessible over the network. It sounds like a network issue. Make sure that the network/internet connection is stable. Maybe there are instances where the internet connection gets too slow. A system will close the sockets if nothing happens for a specific amount of time. It will time out. Use static IP addresses or use the hostnames instead. However, in the latter case, you must ensure that the hostnames can be resolved properly.


    And to answer your question, a multi-frame object is like a movie. You have one file, but it contains several/lots of images (=frames). It's like an MPEG or AVI, only in DICOM format.

  • 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.

  • 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!

  • Well, the issue with dynamic IP addresses is that they can change, as the name suggests. If you have configured your DICOM stations with the IP address, the communication will fail in case the IP has changed. If you use the hostname of the machine instead, changing IP addresses may take longer to resolve.


    Please note that we cannot troubleshoot your network or internet connection. The only thing I can say is that you should check the network status (IP addresses, speed, etc.) at such a time when the transfer issues occur. This should give you hints for further troubleshooting. Maybe you've got issues with the VPN connection.


    And, as I said in an earlier post, try activating the K-PACS server log in the server administration to see if there are indicators at K-PACS side (NOT the K-PACS process log).


    Good luck!

  • 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?

  • "Server is running" is just the status information. I was talking about activating the logging. Stop the server. Activate the "Verbose mode" checkbox and restart the server. A command line window will log the activity. It would be helpful to extend the number of lines that the command line box will display as logs can get rather long.


    Please note that we do not grant full technical support for any freeware products. We can only give you some pointers here to help you help yourself. Full technical support is granted for our professional software products. Feel free to check out our radiological workstation iQ-VIEW, including many more features, Windows 7 support, technical assistance even by a reseller in your region.

  • 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!

  • Quote from ctao

    DIMSE receiveFileData: 16378 bytes read <last: NO>


    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.


    With regards to iQ-VIEW, we cannot promise you that you won't have issues initially, especially if the reasons for the faulty communication is not our application but the network, hardware, sending station, or something else. However, in iQ-VIEW we have lots more options for trouble-shooting as well as much better logging options. A local reseller may be able to help you trouble-shoot in case of a purchase. As a manufacturer, we would support our local partner, if the necessity arises.

  • 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! :)

  • I don't really see a software bug at this point. You have socket errors pointing towards the network. And if image files actually arrive successfully (did you really check this?) but are not displayed in the study list, then this can have a variety of reasons, such as:


    - you have set search filters that limit the number of studies displayed in the list => deactivate all filters and try again
    - you have too many studies in your imagebox so that they can't all be displayed anymore => K-PACS will not show more than 10.000 studies => either use the search filters to look for the study in question or clean out your imagebox
    - your database is corrupted => compare the number of study folders in the "Database" folder on the computer's file system with the number of studies declared in the study browser's status bar when NO filter is active


    But yes, check out other applications to see whether they fit your needs better.

  • 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

  • It means that you are receiving data. But is the log entry "DIMSE receiveFileData: 16378 bytes read <last: NO>" the last one that you see in the log? Nothing after that? No "DIMSE receiveFileData: 16378 bytes read <last: YES>" or an association termination or anything?


    If the images do not physically arrive on the system, i.e. are not stored on the hard disk, they probably won't be registered in the K-PACS database either. And we are back to the network/connection issue. Check the logs of the sending stations (and crank up those logs to the highest level for getting the most details) and, if necessary, involve their vendor(s). It could also be a hardware issue on your computer, e.g. a defective memory or hard disk. You may run checks to ensure that the hardware is okay.


    And yes, you have a corrupted database. The number of studies listed in the study table and the number of study folders in the "Database" folder does not match. Not sure how that happened, because yes, usually a study selected and deleted within K-PACS will also be physically removed from the system.


    You could try to resolve the database corruption. My suggestion would be to start a completely new database and check with that. Create a folder directly under C:\ and point to it in the server administration tool (both paths ending with "\"). Don't forget to restart the server afterwards.


    Two other ideas pop up in my mind:


    - In case you do not receive ANY images anymore => maybe the hard disk is full
    - If only some images do not arrive => maybe their storage path would be too long for a Windows system to handle as Windows limits the number of characters allowed for a file path. This could happen if your "Database" is already several levels deep in the Windows folder structure.

  • 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!

  • Of course, the log bits make sense to me. That's part of my job. :wink:


    This is the beginning of a C-ECHO command ... a DICOM connection verification. A station with the AE title "ONEPACSPOLLER" sends a C-FIND command to the IP address and port on which your K-PACS is listening. According to the log, your K-PACS should have the AE title "ONIS22" configured. However, if that's all you had in your log file, then the C-ECHO was not successful but stopped before the necessary information could be exchanged.


    I am actually wondering now whether your K-PACS really has the AE title "ONIS22" or if you have the Onis viewer installed on the same system and have its DICOM receiver running at the same time as the KPServer. This could lead to confusion of the communication and explain why the images do not show up in K-PACS. Maybe they are stored in the Onis database instead?


    You should familiarize yourself with your network. Which stations exist, where they are located (IP) and which ports they use, what the AE titles are for each station and who communicates with who. Also check that the DICOM settings of each station are properly set up. That the correct AE titles, IP addresses and ports are configured for all stations that a particular station is supposed to communicate with. That those ports are not blocked by a firewall or something and that there are not several programs trying to use the same port on one machine.


    Database vs. Imagebox ... K-PACS actually has both. As you (may) know, K-PACS does not have a "real" database, such as MySQL or Postgres. It has a file-based database structure with the KPStudy.dir being the study level "database". The imagebox, however, is the location where the actual images are stored ... where you find the study folders. By default, the database file(s) are located in the same folder as the images. That makes the most sense. This is why the server administration tool gives two paths, though ... one to the database KPStudy.dir and one to the imagebox.

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!