Posts by marcelvanherk

    Hi,


    Thanks for this info, it makes solving the problem easier. From the code I can see that the message occurs because "1.2.840.10008.1.2" is not included as transfer syntax. I would add more debug statements but I am travelling, so I cannot help you in more detail at this time.


    Marcel

    Hi,


    It is possible but probably not a good idea: only queries from the same called AE would work, since conquest would compare the called AE with the one in the database for every query. I believe someone tried this before. What does work is to add another (unused) tag to the database, and have an ImportConverter copy the called ae to this tag (e.g., ImportConverter0 = set 9999,9999 to "%c")


    Marcel

    Hi,


    Have a pogrammer download dgatelinux1415alpha.zip, extract files, edit routine dgatecgi in dgate.cpp, and compile file total.cxx (which includes all other source files). The command line to compile total.cxx is documented in the code. There is no difference between the linux and the windows source code.


    Marcel

    Hi,


    if you are on linux, this is relatively easy. On windows things are more difficult. The web page as it is now is hardcoded in C++ code, so you need someone with some development experience to pull this off.


    Marcel

    Hi,


    there is a scripting possibility that in principle should allow that (you should be able to create all existing pages from scratch). But it may be difficult to achieve. It may be easier - but not trivial - to modify the source code (routine dgatecgi in dgate.cpp) and recompile. The logo is just a jpg that can be replaced. Specific items could be made configurable (through dicom.ini) on request for the next release.


    Marcel

    Hi,


    Hi Steini, could you try to reproduce the same effect sending from a conquest server? If in the receiving server you add "StorageFailedErrorCode = 0" in dicom.ini, the sending server would not stop sending and the net effect should be the same. I have trouble reproducing the same effect.


    Edit: it would also be worthwhile to positively determine that the 100% CPU load does not occur with 1.4.13. I can then slowly downgrade parts of the code to see when it dissapears.


    Edit: the ***Error saving to SQL: message precedes a large memory leak. Does the 100% occur at the first instance or after a couple? Could shortage of memory be a factor?


    Marcel

    Hi,


    compression is done by resending data to the server itself. Images stored as .V2 files can be NKI compressed this way; when stored as .DCM files, you can compress then as JPG. There is no mechanism to do this based on MAG device, other than making a comma separated list of patient ID's on MAG1 and pasting this in the query/move page.


    Marcel

    Hi,


    I tried to reproduce this sending from another conquest, and the conquest query/move client hangs up after the first fail and no 100% cpu occurs. In your last sample it sends two images. So it seems the problem is also related to how the sending party responds to error messages. But I will keep looking.


    Edit: it also seems strange that the log says the thread ends, while in fact it starts using 100% CPU (you are positive it is at the same time?). As far as I can see in th code, after this message, ServerChild returns, ServerChildThread returns, DriverHelper returns, and the thread ends.


    Edit: also the very fast operation could be strange. The server recieves some large files (17 MB uncompressed), compresses it, and then fails to save to the database. All this in less than 1 second.


    Marcel

    Hi,


    Strange the the PDB does not give debug info in process explorer - it does for me. Maybe it depends on a part of visual studio 2008. The '*** connection terminated' message is interesting. Can you show a more complete log around this line?


    Marcel

    Hi,


    MySQL5.1.34 (with conquest1.4.14, efilm1.5.3) works as well.


    I do notice that if I enter nothing in the mysql query fields it will find data, while if I enter * there, it will expand to ** in the query, and that does not match empty strings in the database. This seems related to the problem reported by Steini. I will report a bug to map a ** query to a * query. In DBASEIII both types of queries are already the same.


    Marcel