Posts by retsil

  • StudyModal value too long

    Hi,


    I am running conquest versions 1.4.17d and 1.4.15 and I have started getting the following error when receiving images. We use postgres version 9 with Redhat 7.




    I have confirmed that the problem is with the StudyModal field and I have tried to alter the column width to accomodate, but I still get the same type of error, but with the larger field size.


    Code
    ALTER TABLE DICOMStudies ALTER COLUMN StudyModal TYPE varchar(128);



    Code
    ALTER TABLE DICOMStudies ALTER COLUMN StudyModal TYPE varchar(256);


    The only reason I can think of why there might be a problem is that we recently upgraded to Redhat 7

  • DICOMReader_AE

    Quote

    This post is a bit off topic. Just describes a problem I've been having with the Siemens Syngo/E.Soft workstations. I guess it just demonstrates that it pays to read the conquest logs carefully.


    Conquest has been built for 64 bit Fedora with PostgreSQL support. There are some minor tweaks necessary for a successful compile on Fedora described in another post (search for Fedora).


    Thought I might share an experience of being reminded about a particular vendors feature.


    In this case if you leave a checked tick box called "Retrieve through DICOM scripts" you get interesting behaviour. This changes the AE title for the C-Move command. I think it is for the purposes of debugging on a separate port and running a DICOM converter script. The default AE title for this configuration appears to be called DICOMReader_AE.


    Output from dgate is shown below:


  • /usr/include/stropts.h

    I am pleased to report that I managed to successfully rebuild using the following config:



    DICOM data is stored over two NAS devices using "FileNameSyntax = 8". The NAS is mounted using the cifs filesystem driver
    There are about 1700000 images in 2TB and the rebuild took about 3 days.


    Code
    ./dgate --debuglog_in:debug.log

    ./dgate --debuglevel:4

    ./dgate --log_on:normal.log

    find . -maxdepth 1 -mindepth 1 -type d -exec /usr/loca/src/conquest/dgate --regendir:MAG0,{} \;

  • /usr/include/stropts.h

    I've been tracking the memory usage of dgate and it seems to have a stable low-water mark at 7Mb. It does spike up to 200Mb when regenerating some files.


    It may be that the computer doesn't have enough RAM. It is an old laptop with 256Mb RAM and 256Mb Swapspace. I installed FC9 without Gnome or KDE.


    I tried the following script


    Code
    ./dgate --debuglog_in:debug.log

    ./dgate --debuglevel:4

    ./dgate --log_on:normal.log

    find . -maxdepth 1 -mindepth 1 -type d -exec /usr/loca/src/conquest/dgate --regendir:MAG0,{} \;


    I've also figured out a way to get the dgate server process to restart if it dies.


    I managed to rebuild 600,000 images before postgres reported out of memory errors. Will need to investigate expanding swapspace.

  • /usr/include/stropts.h

    I seem to be only able to rebuild 200,000 images before I get the following error.


    Quote


    Thu Nov 6 19:38:20 2008 [Regen] /storage/NMUS_Data/dicom/1367206_AE_IT/1.2.840.113663.1500.1.12335.1.99.20040922.162032.203/1.2.528.1.1001.100.3.645.1577.21021204110.20041017024916578/1.2.528.1.1001.100.4.645.1577.20021204110.20043017024916625.dcm -SUCCESS
    Thu Nov 6 19:39:18 2008 ***VR:ReAlloc out of memory allocating 242380800 bytes
    Thu Nov 6 19:39:18 2008 ***A fatal error occurred (out of memory) - closing server


    I try

    Quote


    ./dgate --regendir:MAG0,1367206_AE_IT


    and it seems to be ok.


    Is there a way to get around what looks to be a memory leak problem?


    Thanks

  • /usr/include/stropts.h

    I made the following changes to npipe.cpp and it seemed to compile (conquestlinux1414)

  • Unable to determine size of file

    Thank you Marcel, I apologise if these questions are getting too tedious. I wasn't sure whether to take the error quite so literally.


    This seems to be a problem specific to storing images on an external NAS.

  • /usr/include/stropts.h

    It appears that in FC9 and above that stropts.h has been removed


    My previous attempts in FC7 have successed but I do receive warnings like

    Quote


    fattach is not implemented and will always fail


    What kind of changes should I make to npipe.cpp to safely remove dependancies on stropts.h?


    Interestingly, I found the same problem arising in the Ingres Database project.


    Thanks


    Robbie

  • Unable to determine size of file

    I have a problem with trying to select and move studies for achiving.


    I run the following code (I never get a chance to run the 3rd line)

    Code
    dgate --restoremagflags:

    dgate --selectlruforarchival:50000000,MAG0

    dgate --movedatatodevice:MAG1,MAG0.Archiving


    It previously worked, but now I am getting the following errors when I attempt to select studies for archival.


    Quote


    20081104 09:11:59 ***Unable to determine size of file: 'K:\nmus_data\dicom\0605153_GA\1.2.840.113663.1100.16239782.1.1140428460.120060220.1094415\1.2.840.113663.1100.16229782.2.1.120060220.1094415\1.2.840.113663.1100.16329782.3.6.120060220.1094732.dcm'


    Use dir from the command line to verify that the file is there, and everything appears to be ok.


    I've tried to rebuild the database too, but it only rebuild 1M images when it originally had 1.7M images.


    Quote


    DICOM server version 1.4.14. Date of this release: 20080902.
    Windows XP SP2.


    Quote


    Mysql 5.0.51a on Fedora Core 9

  • Cannot compute total size

    Thanks for that,
    I managed to start moving image data to the archive device


    Quote


    dgate --restoremagflags:
    dgate --selectlruforarchival:100000,MAG0
    dgate --movedatatodevice:MAG1,MAG0.Archiving


    Note that I used --selectlruforarchival:100000,MAG0 because --selectlruforarchival:100000,0 doesn't work and repsonds with the answer Nothing to do.

  • Cannot compute total size

    The DICOM files were originally added to conquest using "dgate.exe --addimagefile"
    It appears that the Patient ID had the initials of the operator included.



    I used dcmdump on the file and got

    Quote


    (0010,0020) LO [2440681 AF\] # 12, 2 PatientID


    It also appears that conquest can't find these patients when using DICOM remote query, however the entries do exist when I access via mysqladmin.


    It appears to only be affecting about 600 images so I'll just move them out and re-initialise (0.04% of all images)

  • Cannot compute total size

    Thanks,


    The archive appears to partially work now. However some records seem to have problems. I'm guessing that it is an escape caharcter problem with mysql.

    Quote


    mysql Ver 14.7 Distrib 4.1.20, for redhat-linux-gnu (i386) using readline 4.3


  • Linux hardware - NAS combination

    There are a few reasons why I'm considering a separating the NAS and DICOM server. It seems to be a model which my boss in favour of. We particularly like being able to store image in part 10 format on a 3rd party device. It is slower, but it is also pretty hard to stuff up. If the conquest server and the NAS are on the same device, then the whole thing becomes a black box. For example we may not be able to upgrade the NAS software without recompiling conquest. We may also want to migrate to a larger storage device without having to reconfigure conquest.


    Interestingly we've *tried* other commercial DICOM servers, and many of them do not support having images on a NAS.


    I think conquest is great. I've just had a few teething problems, that's all. I'm also getting used to the issues which come along with storing large amounts of data.

  • Linux hardware - NAS combination

    I'm looking at using a diskless x86 client to install the linux version of conquest. We've had problems with transfer speeds using Samba NAS devices. It can take days just to delete a directory tree with a million entries. I'm hoping to find using a NFS NAS in combination with linux conquest a lot more manageable. I was quite surprised that very few NAS devices offer NFS, even though most of them run linux (I presume that it would just be a security risk, particularly when they are marketed for home users)


    Any recommendations for a good combination? I would prefer an x86 client so that I can install a standard (and familiar) linux distro.


    x86 client
    http://www.norhtec.com/products/mcjr/index.html


    NAS device
    http://www.qnap.com/pro_detail_software.asp?p_id=85

  • Re-initialise while live

    In my case I've created two installations using mysql as a database backend


    C:\dicomserver (SQLServer=conquest)


    C:\alt_dicomserver (SQLServer=alt_conquest)


    I'm rebuilding the "alt" server and then I should just be able to copy the mysql tables, overwriting the original dicomserver.


    As you have shown, I can even re-import individual directories if new files have been added in the meantime.


    Rebuild is about 59 hours for 1.8M instances on 2Tb.


    Thanks

  • Cannot compute total size

    I have hit the limit of my NAS device (2Tb) and I'm looking to archive data to a secondary NAS device.
    I added the new device as MAG1 and ran the following


    dgate -as1000,0
    dgate -v -amMAG0,MAG1


    The dgate starts printing the size of each dicom file to the console (Note I have added x in some places to protect patient identity).

    Quote

    K:\nmus_data\dicom\0x1x0x7\1.2.124.285.1.657524.816007.2x0x0x0x13x0x4\1.2.528.1.
    1001.100.3.1673.1781.20021204110.200x0x0x2x5x5x5x2\1.2.528.1.1001.100.4.1673.178
    1.20021204110.200x0x0x2x5x5x5x3.dcm = 225 KB


    and then after a few minutes I got the following error

    Quote


    ***Unable to query for image records to compute total size
    MoveDataToDevice: *** could not compute KB used for patient: x3x9x8x AF\


    DGATE (1.4.14, build Tue Sep 02 22:39:12 2008) is running as threaded server