Unable to Receive Images from Multiple Servers on KPACS 1.6

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.

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.

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!

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

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.

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.

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.

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

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.