Posts by jmd

  • Wrong storage using dgate --movestudies and custom FileNameSyntax

    Hi Marcel,


    While using "dgate --movestudies" between 2 servers (on 150c) with a custom FileNameSyntax on the destination server, I'm questionning why I do have such wrong behavior while transferring different images:

    Thu Dec 15 08:33:23 2022 Rewritten file: /home/z/images/empty/empt/y//undefined_0000_000000_1670541699b283.dcm

    Thu Dec 15 08:33:25 2022 Rewritten file: /home/z/images/empty/empt/y//undefined_0000_000000_1670541699b283.dcm

    Thu Dec 15 08:33:27 2022 Rewritten file: /home/z/images/empty/empt/y//undefined_0000_000000_1670541699b283.dcm

    Thu Dec 15 08:33:28 2022 Rewritten file: /home/z/images/empty/empt/y//undefined_0000_000000_1670541699b283.dcm

    (...)

    instead of

    Thu Dec 15 08:33:22 2022 Written file: /home/z/images/DX/2022/12/13/1.3.51.0.7.4206535190.25030.44867.34842.57055.3588.37361_0001_000001_1671089602008b.dcm


    dicom.ini setting:

    FileNameSyntax = %modality%/%studydate[0,3]/%studydate[4,5]/%studydate[6,7]/%seriesuid_%series_%image_%time%counter.dcm


    This does not occur on all files ??!! but hopefully a regular C-store transfer works fine

    As a result many different images are saved into the same unique file, it smells bad...


    Any idea how to fix this ?


    Best regards
    Jean-Marc

  • Error SQL Add with DB regen

    Hello Marcel,
    Thank you, the file.txt was populated accordingly. It seems there are too many fields into our custom dicom.sql (58 columns for dicomimages instead of 21 by default) and the where clause looks like corrupted.

    Mon Oct 7 21:57:55 2019 Query Tables: DICOMImages

    Mon Oct 7 21:57:55 2019 Columns : SOPInstanc,... ... ...,SeriesInst

    Mon Oct 7 21:57:55 2019 Where : esInst

    Mon Oct 7 21:57:55 2019 Order : (null)

    Mon Oct 7 21:57:55 2019 ***[Regen] ./data/0009703828/1.3.46.670589.5.2.10.2156913941.892665339.860724_0001_002000_14579035620000.dcm -FAILED: Error SQL Add


    compared to the output of default dicom.sql

    Mon Oct 7 22:05:18 2019 Query Tables: DICOMImages

    Mon Oct 7 22:05:18 2019 Columns : SOPInstanc,SOPClassUI,ImageNumbe,ImageDate,ImageTime,EchoNumber,NumberOfFr,AcqDate,AcqTime,ReceivingC,AcqNumber,SliceLocat,SamplesPer,PhotoMetri,QRows,QColums,BitsStored,ImageType,ImageID,ImagePat,SeriesInst

    Mon Oct 7 22:05:18 2019 Where : SOPInstanc = '1.3.46.670589.5.2.10.2156913941.892665340.475317' AND ImagePat = '0009703828'

    Mon Oct 7 22:05:18 2019 Order : (null)

    Mon Oct 7 22:05:18 2019 Update Table: DICOMImages

    Mon Oct 7 22:05:18 2019 Updates : SOPInstanc = '1.3.46.6.....


    What is the max length for the columns statement ? Is there a way to increase it ?

  • Error SQL Add with DB regen

    Hi,


    I have a small issue after MariaDB upgrade from 10.1 to 10.3 on Linux. As already stated in the forum, the 'Rows' keyword within dicom.sql has to be modified first, otherwise we cannot create the DICOMImages table or insert data.

    Then I wanted to regen the database with dgate -v -r but it completely fails for every image on recent Conquest versions 1.4.19d1 (and also 1.500alpha), throwing the following errors:

    Step 1: Re-intialize SQL Tables

    Dropping Existing tables (if-any)

    Worklist is empty

    Dropping worklist

    Dropping other tables

    WorkList Database

    Patient Database

    Study Database

    Series Database

    Image Database

    Step 2: Load / Add DICOM Object files

    Regen Device 'MAG0'

    ***[Regen] /home/images/PAT0000000363/1.2.826.0.1.3680043.2.120.83.150831.5235.668.83_0022_000002_15086798670013.dcm -FAILED: Error SQL Add

    ***[Regen] /home/images/PAT0000000363/1.2.826.0.1.3680043.2.120.421.150788.3877.668.255_0019_000002_15081412250021.dcm -FAILED: Error SQL Add

    ... ...


    Strange things:
    - incoming c-store images are saved, meaning the 'Rows' keyword issue passed fine. (otherwise it shows before step 2: ***Failed MYSQLExec : CREATE TABLE DICOMImages )

    - older conquest version 1.4.17d *is* able to regenerate without trouble !


    Any advice ?
    Is there a way to display the SQL output with a debug switch working with -r ?


    Thanks

  • New web interface and viewers

    Hi,
    Maybe a typo error in the cgi-bin/dicom.ini ? anyway I restarted from a default install and I only get this:


    Conquest 1.4.17d WADO viewer
    Wado viewer error, cannot query server at series level: PACS
    *** lua run error viewers/wadoseriesviewer.lua:137: attempt to index local 'seriesinfo' (a nil value) in 'dofile('viewers/wadoseriesviewer.lua')'


    This is the source url:
    http://192.168.10.65:5679/dgat…78188422.8088219&size=560


    Please let me know what did I miss...

  • exportconverter does not create directory !

    Hello,


    I have quite a strange situation on a linux server where I'm not able anymore to create directories and sub-directories with the exportconverter. I simply use the mkdir --parents function and it was working in the past (long time ago). I noticed it is always failing now after two conquest upgrades to 16f last year then 17d.


    ExportConverters = 2
    ExportConverter0 = mkdir -p "/home/images/%V0010,0010/%V0008,0020"
    ExportConverter1 = dcmj2pnm +oj +Sxv 1024 %f "/home/images/%V0010,0010/%V0008,0020/%b.jpg"


    I can see the following directly in the console (but not in the log ??) :
    F: cannot create file /home/images/QUICK/20150202/1.2.392.200036.9125.3.1962171351018510.64769277586.645614_1006_001006_14228676630005.jpg


    And in serverstatus.log, I never have anything related to this error or to Exportconverter0.0
    Mon Feb 2 10:00:59 2015 Exportconverter1.0 executes: dcmj2pnm +o blablabla


    So I'm a bit lost, I tried also to put everything on the same line with only one exportconverter, tried to mkdir only one directory at a time, checked at least 1 space character around the equal sign, always the same issue, it seems the mkdir function is not called... Of course, within the shell I can use the mkdir command manually and it works. Also the folder rights have been put to 777, no way !


    Any advice ?? I don't know anymore if this is related to conquest or to the linux OS....

  • Cannot compile on Debian 8.0 pre-release

    Hello Marcel,


    hum hum, I got the same output for the two Debian versions...
    objdump -T /lib/x86_64-linux-gnu/libdl.so.2 | grep dlclose
    00000000000010f0 g DF .text 0000000000000034 GLIBC_2.2.5 dlclose


    I will check further but did not found any valuable information until now, that's why I posted..

  • Cannot compile on Debian 8.0 pre-release

    Dear,


    I tried but failed to compile conquest (17d) on a fresh Debian 8.0 technical preview (also after upgrade from 7.7 to 8.0), although there was no problem on previous Debian releases...


    # sudo sh maklinux_mysql


    //usr/local/lib/libjasper.a(jas_stream.o): within function « jas_stream_tmpfile »:
    /etc/conquest/jasper-1.900.1-6ct/src/libjasper/base/jas_stream.c:368: WARNING: the use of `tmpnam' is dangerous, better use `mkstemp'
    /usr/bin/ld: lua.o: undefined symbolic reference «dlclose@@GLIBC_2.2.5»
    //lib/x86_64-linux-gnu/libdl.so.2: error adding symbols: DSO missing from command line
    collect2: error: ld returned 1 exit status
    cp: cannot evaluate « dgate »: No such file or directory


    Can you please help ?

  • Restrict incoming objects

    Hello Marcel,


    Thanks once again for your quick reply. I did try dgatesop.lst in the past, but this was without lua scripting, so the result was not so good... It seems to be easy to set up, I will give it a try soon.


    Have a nice day !

  • Restrict incoming objects

    Dear Marcel,


    I'm annoyed with unauthorized or unsupported C-Store connections to conquest when a new modality is set up too quickly. I would like to be able to validate such things to avoid troubles, misconfiguration, even server crash.


    I tried to search on the forum but did not get not one single relevant input (!?)


    So, is there a way to setup a kind of acrnema.map with available modalities, and reject unrecognized C-Store requests ?


    Thanks !

  • Conquest sending tons of images instead of one

    Dear Marcel,


    Many thanks for your great support. I think I found out the root cause: Within the MAG device there was a strange link to the root directory, with a kind of endless loop, I believe this was populating the db in a very bad way, sometimes it was working, sometimes not...


    After checking and cleaning the filesystem, I was able to regenerate the db in a good shape. The Q/R's are correct now, but I will continue to monitor.


    It was a bit difficult !


    Have a nice day
    Jim

  • Conquest sending tons of images instead of one

    Hum, you're right, through phpmyadmin the sql query returns exactly the same number ! So it seems my database migration is fully inconsistent. I was digging in the wrong way... Thanks !


    I don't understand why it works fine during the next 24 hours after I recompile ?! very strange


    Here is how I proceed:
    - old server is running 1.4.14: all the dcm files have been copied to the new server
    - new server = 1.4.17c, dicom.ini and dicom.sql adapted
    - dgate -r


    This should populate the db accordingly, right ? Could this be related to the dicom.sql (small) changes, I'll try not to touch it...

  • Conquest sending tons of images instead of one

    Ahah, ok, I missed this way to catch the debug, here it is.
    I just ran dgate -r just to be sure.
    So, the query should return only 2 studies with a couple of images, not 30k...
    Any advice ?


  • Conquest sending tons of images instead of one

    Hi,


    I got exactly the same symptom and errors today, bad time... :o( This time we use the std build 17c and I only changed the following:
    - archivecompression = un
    - filenamesyntax = 4
    (it was requested to keep the .dcm filenaming instead of .v2)


    I tried to set up the debug level to 4 but I was not succesful... I tried

    Code
    ./dgate -^serverstatus.log --debuglog_on:debug.log --debuglevel:4

    and

    Code
    ./dgate -v --debuglog_on:debug.log --debuglevel:4

    but it does not seem to populate any files. Sorry, I made a lot of search on the forum but failed to find the correct way...


    What do you recommend ? Should I try an older conquest version?


    Bye

  • Conquest sending tons of images instead of one

    Hello Marcel,


    I was using a new dicom.sql I'm sure. So I just recompiled with the 'standard' 1.4.17c, regenerated db and wait so long... and it worked, we are back to a running state...


    I assume something was wrong in the configuration (as dicom.xxx files are replaced when I compile, and I have edited these files) or the patch to increase PDUsize to 65536 was not accepted... But for sure I will not debug this server anymore, I prefer to set up a similar config.


    I'll write down the enhanced debug level to provide more information...


    Jim

  • Conquest sending tons of images instead of one

    Hello,


    I put a server in production environment with conquest 1.4.17c (with only one change: a small fix regarding PDU size you gave me some weeks ago).
    There are around 60.000 images in the system.


    From the dicom viewer side, we are able to query but each time we try to start the C-move, conquest returns tons of images to send !!!??
    example below: send query, return 4 studies, select one study with one serie, then conquest is sending 3800 images but there are related to the wrong patient !!


    I checked several times the configuration but cannot find any trouble. I was using 1.4.14 in the past, so maybe my previous dicom.ini was not correct. Anyway after starting with the default dicom.ini included I got the same results...


    I believe this is a config issue... What do you recommend ?
    Should I revert to the standard 1.4.17c ?


    Thank you for your help!


    my serverstatus.log

    Code
    Tue Dec 10 07:18:45 2013 Started zip and cleanup threadTue Dec 10 07:18:45 2013 DGATE (1.4.17c, build Tue Dec  3 18:18:06 2013, bits 64) is running as threaded serverTue Dec 10 07:18:45 2013 Database type: native MySQL connectionTue Dec 10 07:42:30 2013 Tue Dec 10 07:42:30 2013 UPACS THREAD 0: STARTED AT: Tue Dec 10 07:42:30 2013Tue Dec 10 07:42:30 2013 	Calling Application Title : "IQVIEW2         "Tue Dec 10 07:42:30 2013 	Called Application Title : "SERV         "Tue Dec 10 07:42:30 2013 	Application Context : "1.2.840.10008.3.1.1.1", PDU length: 16384Tue Dec 10 07:42:30 2013 	Presentation Context 0 "1.2.840.10008.5.1.4.1.2.2.1" 1Tue Dec 10 07:42:30 2013 (StudyRootQuery) search level: STUDY Tue Dec 10 07:42:30 2013 C-Find (StudyRoot) located 4 recordsTue Dec 10 07:42:31 2013 UPACS THREAD 0: ENDED AT: Tue Dec 10 07:42:31 2013Tue Dec 10 07:42:31 2013 UPACS THREAD 0: TOTAL RUNNING TIME: 1 SECONDSTue Dec 10 07:42:34 2013 Tue Dec 10 07:42:34 2013 UPACS THREAD 1: STARTED AT: Tue Dec 10 07:42:34 2013Tue Dec 10 07:42:34 2013 	Calling Application Title : "IQVIEW2         "Tue Dec 10 07:42:34 2013 	Called Application Title : "SERV         "Tue Dec 10 07:42:34 2013 	Application Context : "1.2.840.10008.3.1.1.1", PDU length: 16384Tue Dec 10 07:42:34 2013 	Presentation Context 0 "1.2.840.10008.5.1.4.1.2.2.1" 1Tue Dec 10 07:42:34 2013 (StudyRootQuery) search level: SERIESTue Dec 10 07:42:34 2013 C-Find (StudyRoot) located 1 recordsTue Dec 10 07:42:35 2013 UPACS THREAD 1: ENDED AT: Tue Dec 10 07:42:35 2013Tue Dec 10 07:42:35 2013 UPACS THREAD 1: TOTAL RUNNING TIME: 1 SECONDSTue Dec 10 07:42:35 2013 Tue Dec 10 07:42:35 2013 UPACS THREAD 2: STARTED AT: Tue Dec 10 07:42:35 2013Tue Dec 10 07:42:35 2013 	Calling Application Title : "IQVIEW2         "Tue Dec 10 07:42:35 2013 	Called Application Title : "SERV         "Tue Dec 10 07:42:35 2013 	Application Context : "1.2.840.10008.3.1.1.1", PDU length: 16384Tue Dec 10 07:42:35 2013 	Presentation Context 0 "1.2.840.10008.5.1.4.1.2.2.1" 1Tue Dec 10 07:42:35 2013 	Presentation Context 1 "1.2.840.10008.5.1.4.1.2.2.2" 1Tue Dec 10 07:42:35 2013 	C-Move Destination: "IQVIEW2 "Tue Dec 10 07:42:35 2013 Number of Images to send: 3800Tue Dec 10 07:42:35 2013 Sending file : /home/images/data/FUJIA07112210290/1.2.392.200036.9125.3.481918453137.64537986775.1632146_1001_001009_12555497271726.dcmTue Dec 10 07:42:35 2013 Sending file : /home/images/data/FUJIA07112210290/1.2.392.200036.9125.3.481918453137.64537986775.1632146_1001_001010_12555497281727.dcmTue Dec 10 07:42:36 2013 Sending file : /home/images/data/FUJIA08011815480.....


    my dicom.ini