Marcel
Where are these QUEUES stored? I have a system that went through the above issue due to a reading station being off. And the queue seems to have survived a stop and start of the conquest service? Is that possible? I recall that the Queues used to be stored in a bin file but that doesn't seem to be the case anymore. Can you shed light. Sorry to hijack an old thread.
Mr Johnathan Bravo.
Marcel
Yes I had downloaded the 1.5.0b recently from the ingenium link . Running on Debian 11 bullseye.
Mr Johnathan Bravo
Marcel
I was able to perform a few tests this weekend . Below is what I've found.
dgate J2 compressed UltraSounds had the Green overlay on an older versions of OHIF , Remote Eye, and the dcm4chee Individual image view. I did try to simply rewrite the 0028,0004 tag to RGB from YBR_FULL without changing the j2 compression . This didn't change those viewers decompression, still had the green overlay. However If I take a Dgate compressed J2 ultrasounds and have dgate decompress them then the green overlay goes away. Also decompressing and re-compressing to JS works as well. With the JS compression the 0028,0004 tag remains RGB as in the original uncompressed files. Hope this helps and if you need me to do any other testing please let me know.
Mr Johnathan Bravo
Marcel
Sorry for the slow reply. Been a bit hectic here today.
Anyway, I was able to solve the immediate issue by forwarding the affected j2 compressed studies through another dgate that decompressed them and then forwarding to the Reading that has the viewers having the issue. I know there's a better way but I haven't had time to test one and this was a quick and dirty hacksolution that worked for the time being until I get more time to write and test proper import/export converters. I will take some time this weekend and test just changing 0028,0004 back to RGB on one of the j2 compressed studies and take a look at it in the viewers that are having a hard time . Thanks for your quick response and great product as always.
Mr Johnathan Bravo
Marcel
Sorry to bump an old thread but I have a client that is seeing this issue at the moment and we are using j2 to compress. However it seems to only be on US studies and is only showing up on some viewers. For example a US comes in as uncompressed and is compressed by dgate to j2, this changes 0028,0004 from RGB to YBR_FULL. In our main viewers , ohif, weasis, and clearcanvas, this doesn't seem to be presenting an issue. However the rad that is reading is using an older version of OHIF that does present with the green overlay.
So my main question would be, would jpeg-ls be a better compression option as it seems not to convert the RGB to YBR_FULL on compression. Or is there a newer executable or code I could implement that wouldn't cause this issue?
Another option I thought of was to put an importconverter in checking for those devices that send US and store them as js instead of j2 . My problem with that solution is that I cannot figure out how to forward those js studies to the rad as js and leave the rest being sent to him as j2.
Hope this post makes sense.
Mr Johnathan Bravo
P.S. forgot to say using 1.50b on debian 11
Marcel
Happy new year. Hope this year is great for you.
My question today regards a file that is created when I have some communication issues between Dgate and another SCP. I get a file generated in the the dgate home directory called DelayedFetchForwardFailures#### . Do the studies listed in there get re-tried at some point or is this just a housekeeping file for administration. Also it looks to be binary text file. Can you point me to the location in the code that generates it so I could write a quick reader for it. Thanks in advance.
Mr Johnathan Bravo
Marcel
Did the exit codes for commands submitted to dgate change between 1.4.19c and 1.5.0.b ? I know this is kind of an odd question but here's what I'm seeing
when doing something like the below from the command line
$> ./dgate --get_amaps:%s,%s,%s,%s
(the above command returns somthing like the following)
ANAETITLE,127.0.0.1,8181,un
$> echo $?
on a centos 7.6 system with 1.4.19c I'm receiving an exit code of 0 from bash... which indicates success.
Doing the same command on a debian buster system with 1.5.0.b results in an exit code of 255.
Just wondering if you knew why this was happening between the systems
Thanks in advance
Mr Johnathan Bravo
P.S. trying to do some bash scripting with dgate and was hoping to use the exit codes to determine success or failure of the command
Marcel
Thank you
Mr Johnathan Bravo
Marcel
Thanks for the info. I've tried deleting the study from database and filesystem with the same results.
Something you said however I do not understand. What is .v2 format? And my google fu isn't very good this morning apparently because I'm coming up empty searching for it. All I seem to find references for regarding v2 are some docker format an old microsoft chat log file format. If you could point me in the correct direction I would appreciate it.
Thanks
Mr Johnathan Bravo
Marcel
I've been starting to work with some rather large breast tomo's recently and ran across the following error message while trying to import some images after dropping them into /data/incoming
On this system I'm running 1.4.19b on a centos 7.8 . Incoming and Dropped data are set to store as J2.
Have you seen this an could you give some insight as to the source of the issue. Plenty of space on MAG0 and it doesn't look like I'm running out of ram . File sizes that are generating the error are roughly 1.1gb
Thanks in advance for any assistance
Mr Johnathan Bravo
Marcel
is there a way within dgate to get a list of studies waiting to be sent based on an exportconverter? Like a listing of the queue. Perhaps in lua somehow?
Thanks in advance
Mr Johnathan Bravo
Marcel
I was able to do as you asked yesterday and built the 1.5.0 version with the 1.4.19b pdu.cxx, buffer.cxx, and pdata.cxx files. The environment that I built for this testing was a completely updated 7.8.2003 . I wanted to give dgate the best possible environment which is why I went ahead and got that system completely up to date. And here's the interesting part. I have been unable to re-create the issue using that environment. Even with an original unchanged build of 1.5.0. So I'm going to build a VM that's a copy of the environment that I was having the issues in to see if the underlying OS has anything to do with it. Might take me a day or so to get any information back to you.
MrJohnBravo
P.S. Just to be clear Neither of the builds, exhibited the behavior I was seeing .
Marcel
I'll roll back those files later today and rebuild and run some tests. I will let you know the outcome.
MrJohnBravo
marcel
Ok. Let me know what I can do to assist and I'll be happy to do so.
MrJohnBravo
Marcel
I am seeing displaced lines in the images. It kind of looks like in some spots that the pixels have been shifted. I'm using Centos 7.6.1810.
MrJohnBravo
Marcel
I'm seeing an issue tranmitting DX images , whereby a DX has corrupted data after being transmitted from 1.5.0 . Not a lot of corruption , but definite and absolutely traceable to 1.5.0 . I've reverted back to 1.14.19b and the issue is not present there. I can provide more information and potentially a debuglog if you would like to track this down. It seems very specific in 1.5.0 to only affect DX transmissions. I had seen this type of corruption after transmission in 1.14.19c , d, d2 but it was more prevalent in those versions affecting more modalities. Please let me know what I can do to assist tracking this down.
MrJohnBravo
Marcel
Running Cent 7.6 and I've managed to compile dgate by changing some of the lines in the maklinux script regarding mysql/mariadb. Locations of headers and .so mostly . But now that I've compiled and run I'm getting a couple of errors that are confusing.
First is that the server is telling me that I don't have enough rights to MAG0 when I I'm using the same user to start dgate as created that directory and also I have rwx set for ugo on that directory as well.
error is :
Wed May 13 17:03:39 2020 *** Not enough rights to write in MAG0
directory config:
drwxrwxrwx. 2 root root 21 May 13 16:55 data
MAG0=/usr/local/dicomgate/data
I started dgate as follows:
./dgate -v
Second is the following error ... which i assume is telling me that somehow dgate hasn't been able to connect to the mysql / maridb driver?
Database type: NULL driver (black hole)
Any hints or suggestions would be appreciated .
Thanks in advance
MrJohnathan Bravo
Marcel
Ok. good to know. I'll either move it to an export converter and test or resolve it in another way. Thanks again.
Mr Johnathan Bravo
Marcel
I'm running I'm on 1.4.19b . I'm wondering if this is the same as bug 64 for version 1.5 alpha .
I've added a simple ImportConverter as follows:
ifequal "%u","CALLINGAE";system php /var/scripts/ConversionJob.php %f %VStudyInstanceUID
This import converter does work but not completely properly. The value sent to my script by %f is different than the actual filename written to the filesystem. It seems to differ by a single incremental value . As an example here are 2 image files that I received to my dgate instance recently and the %f value sent to my script, followed by the actual filename written to the filesystem.
IMAGE #1--------------
%f received by script = /usr/local/dicomgate/data/722006-1752-2019/1.3.46.670589.28.26690171469773220191010230221192396.11112_0000_000001_1571001576002e.dcm
Actual filename written = /usr/local/dicomgate/data/722006-1752-2019/1.3.46.670589.28.26690171469773220191010230221192396.11112_0000_000001_1571001576002f.dcm
IMAGE #2-------------
%f received by script =/usr/local/dicomgate/data/722006-1752-2019/1.3.46.670589.28.26690171469773220191010230154995010.2.2_0002_000002_1571001574002b.dcm
Actual filename written = /usr/local/dicomgate/data/722006-1752-2019/1.3.46.670589.28.26690171469773220191010230154995010.2.2_0002_000002_1571001574002c.dcm
As you can see it looks like the last value is incremented by 1 on each filename. Is this is a known issue in 1.4.19b I can provide more examples if needed as the behavior is very consistent.
Mr Johnathan Bravo
In WindowsManual.pdf I found:
[after NN] collect delay in seconds from last image
Cool. Thanks. It all works well
Mr John Bravo
