Posts by marcelvanherk

    Hi Pat,


    Hm, a number of people have reported similar problems that appeared and dissapeared without apparent reason. Basically this message says that the sender hangs up right after connecting at the TCP/IP level, or that conquest does not accept the association. Most report, however, this problem when connecting from a single modality - i.e., it seems a specific host - host network problem.


    I suppose somewhere in your network an update was performed that caused this problem, but have no clue what it could be..sorry. Some (wild guess) suggestions: try to reboot routers in the network, and try to reboot the sending system.


    Just to make sure, you could also downgrade dgate.exe to the one from 1.4.13 (see ftp://ftp-rt.nki.nl/outbox/MarcelVanHerk/dicomserver), and see if the problems dissappear.


    Hope this helps,


    Marcel

    Hi,


    there is a reported problem with warning messages returned from a client hanging up the server. A small part of debug log pasted in a post here would suffice to get a feeling for what goes wrong.


    To change a tag for all incoming data (double check the group / element) :


    importconverter0 = set 0008,0080 to "BMG"


    you can also make this conditional; there are dozens of script commands.


    Marcel

    Hi,


    what is the nature of the DICOM error? I do not see why conquest is different. It just transmits whatever is set in the Institution VR. And you can instruct conquest to modify this field to your liking (for newer versions).


    Marcel

    Hi,


    I had to look carfully as well: it is in DicomConformance_FilesLST_Changes.pdf, on page 9 and 10.:


    Quote

    The CONQUEST user interface (Windows only) will queue incoming
    images and will asynchronously convert each DICOM file into a BMP file,
    load it in memory and assemble the pictures to be printed on a page.
    Processed DICOM files and BMP files are deleted. Note: the basic print
    support in the CONQUEST user interface will not handle multiple
    simultaneous print requests correctly!


    Marcel

    No,


    also dbaseIII can handle millions of images, although there is a 2 GB limit for the DICOMimages table in version 1.4.12. This limit is only reached at 1.5 million images. There was also patch for 1.4.12 for potential database corruption released (a modified ODBCI.CPP). Did you apply that patch? Note, modern versions don't have the limit or the bug.


    Or maybe you should just upgrade, and regenerate the database. That can be done in a separate folder pointing to the same data (i.e., side by side with a running 1.4.12), as long as you use a different port number for the server.


    Marcel

    Hi,


    sizes up to 50 million images have been used - so the size is not the problem. I still would like to see the debug log of queries from A and B:


    try


    kill the running dgate
    dgate -v &
    dgate --debuglevel:4


    now do a query from A and then a query from B and show me the query data.


    Marcel

    Hi,


    I was referring to this statement:


    Quote

    Also if I query from our GE Xeleris to both the Conquest database, both results are normal;


    So one system's queries works and the other one fails. This is strange, and therefore I asked logs of a query originating from both systems to the failing conquest dicom server.


    When data in unailable this means that maybe the index is lost? For dbase, this index is -in memory on patient ID. What do you see in the logs when you restart the server?


    Marcel

    Hi,


    The print server uses the GUI log, which is known to drop lines if the server is very busy. So, the printer option is not production grade. That one machine works and the other not maybe related to having a different number of cores?


    I will see what I can do to improve upon this problem for upcoming releases.


    Marcel

    Hi,


    as documented in the manual, the actual printing interface in the conquest GUI is unfortunaly not multi-user safe. Can you show me the Server status log of your overlapping operation? Maybe I can use the thread number to separate the jobs.


    Marcel

    Hi,


    Digging a little into debugging on vista64 bits: this download will allow you to give me more info from the 64 bit version:


    ftp://ftp-rt.nki.nl/outbox/Mar…er/dgate64withsymbols.zip


    Is the server core (64 bits), with debug information (pdb file). If you place both in the dicomserver directory, process explorer will show you symbols for the thread stack - that makes it much easier for me to find the culprit!


    And here is the same set for 32 bits:


    ftp://ftp-rt.nki.nl/outbox/Mar…rver/Dgate32withdebug.zip


    Stack traces with these versions would be highly appreciated.


    By the way, these server cores contain debug information but are identically optimized, so performance should be identical.


    Thanks,


    Marcel