Posts by manzing

Hi Marcel,

I use SQLite Dbase with BrowseThroughDBF activated.

dicom.ini extract :

SqLite                   = 1
BrowseThroughDBF         = 1

The folder Dbase exists (well 2 folders exists and are used : one in conquest server folder / data, on in data folder which is located on another partition). One test server, i use the default folder and the issue is present.
I made a test server with DBASE III and the same error occured.
As i said before, your test image HEAD_EXP_00097038 always display fine in every case. This is obiously something related to the images we produce since some times (old studies are not affected) and the last version of Conquest GUI, as the 1.4.15 GUI works flawlessly with all studies / images, using the last dgate.exe 1.4.17d.

If you want to dig, i can send you one image which fail with the last GUI.

About worklist and MirthConnect, you're right : i added a step which removes problematic caracters and replace them with standard ones.
Now the hl7 files are being processed normally.

Thanks for your answer anyway,

Emmanuel

Marcel,
After another test, the issue does not occur when using conquest 1.4.15.
The bad news is that i updated to 1.4.17 in order to use a lua script which allow dynamic IP for some client (if you remember), so i can hardly revert to 1.4.15.

EDIT : well, i can use this as a workaround as the issue is caused by the GUI only. I pasted the 1.4.15 GUI in my 1.4.17d Conquest folder, and i now can delete my studies again !

It seems something has changed between the 2 versions.

Hi Marcel, Hi everybody

I have 2 issues and the first one is critical and i can't figure out how to fix it.

Firstly since a few months (i think, maybe since i migrated Conquest on a Windows 2012 server ?) when i select a patient in the GUI, instead of displaying image i can read "image file not found". The series and the images are not displayed either.
All i can see is the study name in the top field (capture as attachment).
That said, if i use a Dicom client and query the PACS, i can retrieive the study, display images, everything works fine.

The problem is that clinicians usually make some mistakes in patient informations, markers or some other things.
I use to delete the study or the serie in Conquest, and then ask the clinicians to send again the study to the PACS.
I am now unable to delete anything on most cases.
The same issue occur on a test server i made this morning. The only study which work fine is the default one provided in conquest.
Reindexing the database, and even change database type does not have any effect.
I've also tried many options in dicom.ini without any success.

The second issue is not so annoying, but maybe there is a way to make it work : I use Mirth Connect to send a HL7 file to conquest in order to feed the worklist..
Sometimes, some patients have some accent mark or apostrophe in their names and it makes Conquest to fail to add them to the worklist.
Is there any workaround ?

Many thanks in advance for any help !

Hi Marcel,

I migrated on a windows 2012 server 64 Bits, updated Conquest to last version and it runs flawlessly since a month.
Some old clients like Kpacs are not able to retrieve large series but the server is not affected at all.

So, Marcel, i really want to thank you (again !) for the help you provide to all of us !

I'm already using uj compression, but it's still the same :

Quote

20141210 11:35:26 ***[DecompressJPEGL]: Could not allocate decompressed image memory.
20141210 11:35:26 ***[DecompressImage]: JPEG library decompression error

The good thing is that the server does not seem to crash now.

That said, migrate on a 64bits OS appears to be a good option, as Microsoft will also stop support for Windows 2003 server soon.

Hi Marcel,

I've just made a test on a Windows 2012 server (64bits):
The server can handle big files without crashing but the transfer fails because of the client (i think KPACS made a kind of timeout on large file transfer) on a study which contains a 1.5 GB file (!)
We can send such files to Conquest whitout any problem (even with dgate 32bits), but client can not retrieive without make Conquest to crash.
Since the 64 bits dgate does not crash i will consider to migrate my server to a 64 bits Windows server, and recommend the users not to send such files to the PACS.
I'll post here to keep you inform.

Again, thank you for your help Marcel.

Hi Marcel,

Indeed, users send some video since a month, so the cause is clearly identified now.
Do you think it will be fine if i upgrade my server with dgate64, and keep the same hardware, 8 GB of RAM ?
Or should i prevent users to send such sized video ?

Many thanks,

Thank you for your answer Marcel.
I use a Windows 2003 Server R2, 32bits indeed.
Guess i have to plan to migrate on a newer x64 system.

Just to be sure : Which size is very big according to your mind ?

Hello,

One of my Conquest server keeps crashing with the following lines in pacstrouble.log :

Quote

20141205 15:29:14 ***VR:ReAlloc out of memory allocating 429716448 bytes

20141205 15:29:14 ***A fatal error occurred (out of memory) - closing server

It happened during transfer :

Quote

[ECHOCQ] 20141205 15:29:14 Sending file : E:\echo\base\L11-11742^CN^KEZIA^CHEMIN\1.2.392.200039.105.2.682.10.20141205.113956.93_1417775937.dcm
[ECHOCQ] 20141205 15:29:14 ***VR:ReAlloc out of memory allocating 429716448 bytes

[ECHOCQ] 20141205 15:29:14 ***A fatal error occurred (out of memory) - closing server
20141208 10:13:16 Started zip and cleanup thread

The server can operate perfectly during several days and then crash. It restarts but after several times it remains down, despite i set the "keep alive" option and the service set to "always restart" in Windows settings.

I updated to 1.4.17d but no change, i also tried to rebuild database, same result.
My server has 8 GB RAM installed and it should be enough i think. The pagefile is dynamically sized.
Any idea ?

Many thanks.

It's OK, my issue has been solved by using a generated UID in dicom.sql.

Thanks again Marcel.

Here it is Marcel.

[removed link, trouble downloading; asked for data on a pm]

I edited my previous post to specify that the worklist does not work anymore after trying to send an HL7 file which contains a ZDS section.
Thanks.

Marcel,

I found Fuji system refuse to process because off a missing study instance UID.
It seems that i had to put in as a field in ZDS section in my HL7 file.
But when using a ZDS section in HL7, worklist query does not work anymore. Conquest refuse HL7 file if this section is present, and it make the worklist to be unusable.

Do you have any explanation about that ?

Thanks !

Hi Marcel,

I don't want to make you waste your time, so i'm going to do some testing today, and if the WL still not work i will try to call again the Fuji support team.
I already spent some time with them trying to solve this issue whitout success and i'm afraid this is dead end, but i'd rather waste their time than yours.
They have to give their customers some support, and they have to respect DICOM standard.
Please, don't start to do major fix in your code, i will try to have it solved on Fujis side, ans if i really can't manange with their help, i will keep you informed and might ask for your help.

Many thanks.

Emmanuel

Marcel,

I use a Windows 2003 / win32 server.
Of course, i'm ready to test some code if necessary.
I thought a workaround would have been possible using lua or with some change in dicom.sql but i'm sorry this is not that simple.

Many thanks for your answer.

Hi,

I face exactly the same issue using conquest with a fuji CR and i can't start a study on the Fuji, although the worklist query works fine.
Is there any workaround to make the worklist works with a fuji CR device ?

Thanks.

Hi Marcel,

For now, it seems to work fine !

Many thanks.

Hi Marcel,
The issue is here again this morning.
I tested the server by querying it, it worked. Then i launched the GUI, it hung, and the dgate server is not responding anymore now.
I have to restart service.
I can't find any explanation...

EDIT :

After a log reading, i think this is an issue due to the lua script i use for changing IP on demand, if you remember : http://forum.image-systems.biz/viewtopic.php?f=33&t=15613

Here is a log extract which match the time i tried to launch the GUI.
http://d-h.st/WVf
It seems that the IP test is making an infinite loop and then crash the server.

Do you believe i'm thinking the right way ?

Thanks

Everything is OK now, i will post here if it occurs again.

Now the GUI is working, the first command does not make the server to hang anymore.
Weird things...

The first one.