Posts by lselvon

    Have contacted the vendor, and this is a possible explanation from them for this issue. "Achieva" is the MR modality source.



    As far as I know Conquest does not stip off any header information.


    How can I check if studies are being received as pure dicom images in Conquest ? What header attributes distinguishes that ?


    Louis

    This issue is also apparent if I use K-PACS to retrieve the studies. A packet sniffer shows checksum errors. I am trying DCMTK C-MOVE to see if it reveals any useful information. Prior to a certain date this was not an issue for us. I also see no networking issues on the port, AE allocated as other modalities works fine for retrieval using efilm. At this stage I am suspecting a change that the modality may have done that is causing this grief.


    It does not appear to be a Conquest problem, at this stage anyway.


    Louis

    I have done a clean install of Conquest and use the Create MYSQL database option of conquest so that the necessary settings are added in dicom.ini. I then manually edited the dicom.ini and updated the following :


    SQLHost = IP of Linux server
    SQLServer = name of database on Linux server
    Username = username given access on Linux server
    Password = set accordingly


    I also changed the path of the data directory to point to where I have the images stored for the Linux setups, and saved configuration.


    The two below were left
    MySql = 1
    DoubleBackSlashToDB = 1


    I re-started server with no issues. However when I head on to the Browse Database tab, I get this error


    Quote


    There was a problem loading libmysql.dll - mysql not functional


    Louis

    Hi Steini


    I am on E-FILM Version 2.0. Thank you for the solution. Unfortunately if appears that this is not my issue, I did a check on the study UID for all the MR studies and none of them are null. So my issue is something else. It would help if E-FILM logs gave a bit more information when Conquest is trying to send the data to it.


    I have encountered this issue before with E-FILM, but in this particular case E-FILM was not accepting any data because the water mark levels was too high, and when the PC was close to disk full, E-FILM would not accept any studies, and Conquest kept giving the above error. The fix was to lower the water marks levels to a reasonable level.


    If others have other ideas, by all means let me know.


    Will keep debugging this.


    Louis

    Hello


    This is an odd issue that I get from time to time between E-FILM and Conquest for MRI studies. At odd times E-FILM cannot retrieve the MRI studies. Conquest reports that the e-FILM did not accept the connection. If I try and forward the MR study from Conquest -> e-FILM the same happens.


    At other times it works fine.


    Any clues why this happens ?


    Louis

    Hello


    We are experiencing some issues between Conquest and a vendor PACS system. Conquest is set to forward studies to the PACS.


    The issue is some studies, although Conquest has forwarded the studies to the PACS, cannot be seen in PACS.


    The PACS vendor is stating that they are receiving Modality Performed Procedure Step (MPPS) on the sent studies that are not visible in their PACS.


    My question is does Conquest forwarder send any form of MPPS to any DICOM node ?


    Thank You


    Louis

    Below is a temp file generated when the crash occured again. I have also attached an image. I cannot capture the detailed microsoft report.



    I am yet to change DB and see what happens. FYI I am not using the native mysql odbc driver. Am using the one from MySQL "MyODBC-3.51.11-2-win" . I have the same driver being used on the other Conquest machine that does not crash like this one.


    Louis

    Files

    • crash.JPG

      (60.14 kB, downloaded 928 times, last: )

    Hello


    I have installed on a brand new machine with the following specifications


    Microsoft Windows XP
    Service Pack 2
    HP xw6600 Workstation
    Inter (R) Xeon (R) CPU
    E5205 @ 1.86 GHz
    1.59 GHz, 3.25 GB of RAM


    I am however experiencing frequent crashes with Conquest running. I keep getting the famous "dgate.exe has ecountered a problem and needs to close" by Windows OS. Before the crash all Conquest was doing was writing images to the MySQL database.


    I have to keep re-starting server, but then at some other point it crashes again. If I install Conquest as a service, the issue also occurs.


    The version is 1.4.13.


    I also have a seperate > 3 year old Windows box running the 4 instances of 1.4.13 Conquest and I do not get this crash occuring at all.


    Would using the "Keep server alive" option be recommended for such frequent crashes ?


    Any clues to help debug this is appreciated.


    Louis

    With the manual update issue, I had Conquest installed as a service. Needed to stop Conquest from there to see manual changes.


    But why does each "Save Configuration" from the Configuration tab keeps updating the SQLSERVER settings back to the default dbase location and not keep the MySQL one ?


    What does a Save Configuration actually do ?

    Hello


    On the 30-May-2008 at 15:30 Pm our main imaging storage server had a RAIF failure and was down for 4 days. Support from a paid vendor was ridiculous. Will keep the vendor's name out of this.


    We actually have the Conquest server as a redundancy server in between our modalities, and the main archive, forwarding the data across to the archiving system.


    Thanks to Conquest departmental activites was midly affected by this failure. Had we just connected directly to the main archive from all modalities, god knows the mess the department would have been in.


    Keep up the great work on Conquest.


    Louis

    Hi


    I noticed that when if I update anything from the Configuration tab of Conquest Windows, the parameter SQLSERVER in the dicom.ini file keeps pointing back to the default DBASE directory.


    Our system is configured to use MySQL, and this parameter was changed to point to the MySQL ODBC during initial install. But any updates done from the Configuration tab, like the size for nightly deletes and a save is done, appars to update this parameter, and I lose sync with the MySQL database.


    We eventually encountered an association error whenever images were being sent to the Conquest server. I had to manually re-update the SQLSERVER setting, and do a clean regen to fix the association issue with received studies.


    If I manually updated the nightly setting direct in the .ini file, and bring up server, I do not see the change from the Configuration tab display as well. Had to change it from the Configuration display tab, save, but that updates the SQLSERVER back to default.


    Are these bugs ?


    Louis

    I have tried the following and ExportConvertor1 is not working, only ExportConvertor0 is happening. Any clues :?:


    It is not just an issue with Philips. I also get the dicom move error, when sending to E-FILM. Once it gets to the PR image slice, Conquest just stops.


    This is a dump of the logs when sending one with PR at slice 2. No error is given from the logs. The dicom move error is from the Query tab.



    I've commented the SOP in dgatesop.lst, and re-started server. Tried sending again to e-film and I still get a Dicom move error after slice 1.


    It only seems to send it, if I remove the PR from the database.


    There is a script I collected from this forum from a work colleague to remove modalities off Conquest. I will use it to remove all PR UIDs series in the database.


    Philips have now turned off the sending of the PR SOP as we don't need it.


    Louis