Posts by marcelvanherk

Hoi Maarten,

aan de buglijst toegevoegd.

Marcek

Hi,

Conquest is free! It runs OHIF as an option. There is also a zip file with a more recent version of OHIF. Check that out.

Marcel

Hit enable web server button on server status page, and then right click it to open possible viewers.

In the dicom.ini in the folder where the conquestdicomserver.exe file is.

Marcel

I think it queries all images to be deleted, so that may run out of memory.

Marcel

Maybe you can set

LRUSort =

in dicom.ini. This selects another algorithm to cleanup that might be lighter on memory. It may be you have so complex patients in the last 1000 that it runs out of memory.

Marcel

Hi, I think you are maybe deleting too much at once. Let me check the ff option a bit later

Yes,

something like

dgate64 -aeFROM,TO

where FROM is MAG1 and TO is MAG0

Alternatively:

dgate64 -amMAG1,MAG0

copies and verifies the data and changes the database.

This would run a long time but runs while the server is active and all data is accessible.

To do it step by step (e.g. for 1GB) you can use a set of commands:

dgate64 -as1000000,1

dgate64 -amMAG1.Archiving,MAG0

Marcel

If its the patientid the behavior (reject) is right, but the errormessage is incorrect

Hi, thanks for testing.

Can you tell me what they changed? In your log you see that conquest reports "removefiles 0 images" i.e., it tries to remove the existing image and fails.

Marcel

Hi,

this must be a bug, it is not supposed to try and write the same data twice. Can you redo this with debug log on for me and post the full log?

Marcel

Thanks and good idea, but not a very high priority.

Marcel

Great!

Marcel

Never got around to deciding it.

No,

it is hardcoded to retry 10 times and wait a second inbetween.

cheers

Marcel

Hi, just been testing. This webpage works:

<FORM ACTION="/api/dicom/rs/attach" METHOD=POST ENCTYPE="multipart/form-data">
<INPUT NAME=script  TYPE=HIDDEN VALUE=reject>
Upload file to enter into server (dcm/v2/HL7/zip/7z/gz/tar): <INPUT NAME=filetoupload SIZE=40 TYPE=file VALUE=>
<INPUT TYPE=SUBMIT VALUE=Go>
</FORM>
<FORM ACTION="/api/dicom/rs/attachdicom" METHOD=POST ENCTYPE="multipart/form-data">
<INPUT NAME=script  TYPE=HIDDEN VALUE=Data:AddImage();return(1)>
Upload dicom file to enter into server (dcm): <INPUT NAME=filetoupload SIZE=40 TYPE=file VALUE=>
<INPUT TYPE=SUBMIT VALUE=Go>
</FORM>

So, I guess there is something wrong with your upload code. You can have a look in a browser to see what my example sends.

Put the tests into test.html on github, and catch empty servercommand() in posters.lua

Marcel

And I put the retrying version on github ;->>>

Marcel

I meant option 2!

A stopgap solution is to script a delay e.g. by defining dgate64.lua (if your binary is dgate64.exe) as follows:

print('delay')
t=os.time()
while(os.time()-t<5) do end
print('starting')

This will wait 5s before the monitor thread is activated.

Marcel

Hm,

it would not be an easy change to do this at all. The disk storage is for failed forward attempts. You could use lua code to keep track of all studies that are received or use AccessTime in the database to know which studies have just been added so that these can be retried. I.e. by sending these to itself.

Marcel

Hi,

The incoming folder thread (function monitorthread) opens a database. I guess that can retry e.g. 10s.

Marcel