Posts by garlicknots

Hi Marcel

We have this method in place because we wanted to ensure the UID generation was unique per exam and not per send. With newuids, someone could send the same dataset repeatedly and duplicate it, couldn't they?

When you mention inconsistent dataset, where would the inconsistency be? The filesystem / the database?

The edit occurs on a single object, creating a new series. I am not clear on how an inconsistency with the UIDs can exist. This runs on an ImportConverter, so it should all be pre-filesystem & db, right?

Yeah an Echo would do the trick.

As for Luas - I've got limited scripting/development experience but do my best. I can't seem to make a good Lua delivery script with retries though I probably should give it another shot.

Forgot to post resolution about this. This was resolved by removing a trailing & from the stats script.

export reporter:

curl -i -XPOST 'http://0.0.0.0:8086/write?db=conquest_stats' --data-binary "conquest_exports,hostname=`hostname -s`,destinationae=$1,modality=$2,calledae=$3,state=$4 callingae=\"$5\",sopuid=\"$6\",mrn=\"$7\",accession=\"$8\""

import reporter
curl -i -XPOST 'http://0.0.0.0:8086/write?db=conquest_stats' --data-binary "conquest_imports,hostname=`hostname -s`,modality=$1,calledae=$2 callingae=\"$3\",sopuid=\"$4\",mrn=\"$5\",accession=\"$6\""

We have an issue with our diagnostic viewer which causes cine clips to sometimes to blend in the stack of stills when we'd like to have them easily identifiable as cine clips.

To split these clips, we built a lua which generates a new (and consistent) series instanceuid and changes the series description to CINE. This fires properly, but at times it writes an object which will not successfully export. This is not consistent. I do not know how to make it fail and I do not have access to a study which will cause this issue. We see it several times a month.

I noticed yesterday that when this file is written, it's a DCM file instead of a v2.

We use FileNameSyntax=3 so I'd expect to see a v2 object.

Here is the lua:

--Separate and create unique Series with US Cines
--If called "CQUS" and SOPClassUID equals the SOPClass for US Cines, then Obtain the last 7 characters from the SOP Instance UID(SOPSubs) and remove 10 characters from SeriesInstanceUID.
--If new SeriesInstanceUID ends in a period, remove 11 characters from the original SeriesInstanceUID.
--Concatenates the values from the new SeriesInstanceUID and new SOPSubs to make a unique US Cine SeriesInstanceUID.
--Rename SeriesDescription to "CINE"
if Association.Called == 'CQUS' then
    if Data.SOPClassUID == '1.2.840.10008.5.1.4.1.1.3.1' then 
    SOPSubs = string.sub(Data.SOPInstanceUID, -7)
    SeriesInstanceUID = string.sub(Data.SeriesInstanceUID, 1, -10)
        if string.byte(SeriesInstanceUID, -1) == 46 then 
            SeriesInstanceUID = string.sub(Data.SeriesInstanceUID, 1, -11) 
        end
    Data.SeriesInstanceUID = SeriesInstanceUID..SOPSubs..'.24'
    Data.SeriesDescription = 'CINE'
    print('ic-cqus.lua  UPACS THREAD ' .. Association.Thread .. ': received an US Cine on AETitle CQUS and has modified SeriesInstanceUID to ', Data.SeriesInstanceUID, 'and updated the SeriesDescription to', Data.SeriesDescription) 
    end
    if Data.SOPClassUID == '1.2.840.10008.5.1.4.1.1.88.33' then
        print('ic-cqus.lua  UPACS THREAD ' .. Association.Thread .. ': has destroyed SR object ' .. Data.SOPInstanceUID)
        script('destroy')
    end
end

This would be a really great. When our primary archive has process restarts, which we need to do roughly once a week to preserve performance, we have potential for these errors to be seen. We'd like a way to handle the 'failed to connects' differently than other forms of DCM failure.

Got it, thanks.

VL64 = {'0x0032,0x1030', '0x0010,0x1040', '0x0008,0x1030', '0x0008,0x103E'}
--64 Char Trunc Iteration
for i, TAG in pairs(VL64) do
    y1=string.sub(TAG, 1, 6)
    y2=string.sub(TAG, 8, 13)
    if Data:GetVR(y1,y2) and #Data:GetVR(y1,y2) > 64 then 
            Data:SetVR(y1,y2,string.sub(Data:GetVR(y1,y2,string), 1, 64))
        print ('ic-dicomnormalizer.lua UPACS THREAD ' .. Association.Thread .. ': has truncated: ' .. Data:GetVR(y1,y2,string) ..' to 64 characters')
        EXECFLAG = 1
    end
end

Hey marcelvanherk I've got a problem for ya.

We had an exam arrive today that had 1024 characters in ReasonForStudy (0032,1030) which choked our Exports. We've been slowly building a DICOM normalizer lua that we run against all images that come in to clean up VL mismatches that our long-term archive does not like and ReasonForStudy is one of the tags we fire against.

I spent a little while tonight trying to figure out if we had an issue in our lua and after some trial and error I've found that if a DICOM tag is greater than 255 characters, the comparison will not fire. What can be done to extend that char length limitation?

Here's a snip of the lua

for i, TAG in pairs(VL64) do
    if Data[TAG] and Data[TAG]:len() > 64 then 
            Data[TAG] = string.sub(Data[TAG], 1, 64)
            print ('ic-dicomnormalizer.lua UPACS THREAD ' .. Association.Thread .. ': has truncated: ' .. Data[TAG] ..' to 64 characters')
    end
end

Definitely can't go without retries. We've given that an attempt in the past but there are too many erroneous failures to rely on that. The retry firing on the entire converter is helpful for a few reasons, we have the converters notifying an influxdb database of attempts so we can monitor through grafana. Seeing in grafana when something is trying repeatedly is one of our countermeasures to manage 'clogs.'

Moving to 1.5.0 is something we could consider. We've not moved to 1.4.19d yet so an upgrade is somewhat due. When do you foresee 1.5.0 releasing?

We are using CQ for many workflows and enforce sending retries when transfers fail. The behavior we see displayed is that a failed send will retry indefinitely until success and will not allow any other objects to send through the EC until it is handled as the EC expects.

Due to this, we are separating workflows into different ECs so that they do not impact one-another when there is a transfer problem. We're getting closer and closer to the documented limit of 20 ECs. Can this be extended and/or is there a way to review the retry behavior so the ECs do not completely halt when there are transfer problems?

The problem is how the Viewing applications handle certain PMIs. The content itself is not damaged, but your source is your problem The US units you are receiving from should use a PMI which is handled more gracefully more commonly- maybe try YBR_RCT.

Does this do anything for you?

https://github.com/wolfSSL/wol…b/master/tls/client-tls.c

Hello,

My site is looking to try out DICOM TLS but we don't seem to have a software solution which supports it natively. marcelvanherk is this feature possibly coming in a future release?

Is there another way I could may this function without native support within dgate?

Looks like you're missing the g++ dependency. Check and install your deps. If you're not a Linux person, now may be the time to consider just running in Windows.

Mem increase has had no effect. We observed this issue again today.

What's so curious is this effects ExportConverters themselves. We have more than one ExportConverter sending to the same destination and one will fire successfully while the other does not. Stop/Start dgate and everything is fine again.

We have increased memory of the nodes from 2gb->3gb as of around noon yesterday.

whoever owns your httpd should own those files

Just cleaned up two instances of the issue today on two different nodes, one had only a single active connection and the other I uhhh sort of stopped and started without checking.

Hi frank, we've got a Centos7 cluster running CQ. We did not compile ourselves but do have a working (though rarely used) web portal and can probably help. Our webserver setup is a bit hacky from my point of view but then again that could be on me more than anything else.

Presuming you have dgate and supporting webserver config in your cgi-bin, is that true?

File permissions accurate?

File ownership accurate?

Newweb or classicweb?

This occurred again today on one node in the cluster. This time, it didn't appear to be driven by load as we have observed in the past.

The red line in the top-left of the graph is the rough window in time vlconquest01 was misbehaving (failing to send all studies which stored). Stopped and started dgate and the behavior returned to normal.

Hi Marcel - do you have a preference for how requests come to you? I can name a few right now, but I don't want to dump in the wrong location. One (seemingly) small enhancement that would be nice for us would be if timestamps in logfiles would include milliseconds.