it wasn't updating in the early version of 1.5.0.
it wasn't updating in 1.5.0b.
Now I'm using dgate64.exe 1.5.0b with your 1.5.0c gui you gave me and it's the same.
it wasn't updating in the early version of 1.5.0.
it wasn't updating in 1.5.0b.
Now I'm using dgate64.exe 1.5.0b with your 1.5.0c gui you gave me and it's the same.
Annoying. Sometimes it works and sometimes it doesn't.
Marcel
yeah.. I just noticed it too. I must have been lucky the first few times.
Now the serverstatus window is just empty.
edit1: umm.. wait a sec.. I alt-tabbed back there and it was working again.. testing further.. I'll be back
edit2: ok so it looks/acts as if you are using some kind of a log buffer (of fixed size?) and waiting for it to get full before flushing it into the status window.
This would cause 2 exact problems I'm observing now:
1) if nothing is happening (aka nothing new is being logged) when the gui opens then you are stuck with an empty status window.
2) you are always missing last X lines which are currently in the buffer (and haven't been flushed yet cause of low log activity)
If that's the case the solution should be simple - wait till buffer full OR time_passed>X. The real question is: are YOU causing this or the OS?
Hi,
I use a delphi memo which is not very fast. It refreshes when the buffer is full, when data comes in and it has not been refrehed for 0.1 s and/or on a timer, 0.1 s after last data came in. As long as the timer fires (which may be not too often when the gui is very busy) the page should be updated.
Marcel
Hi,
In my system I am also not impressed by the update speed. To test nudge it you can use console.bat and type e.g.: dicomecho('CONQUESTSRV1')
Marcel
This is not at all what I'm observing here. I see this:
- when the buffer is full - yes
- when data comes in - no
- it has not been refreshed for 0.1 s - no
- on a timer, 0.1 s after last data came - no
I've tried giving it a nudge with the console and by dropping in single file. It looks like the "buffer is full" is the ONLY one working.
This is the 4 feb, 10:16pm version?
It use the printer timer that always runs.
Marcel
yes. this one:
Weird,
it works fine for me on windows 7. I have made one more small change in the logging. Build date shows as today. Also fix updown control for debuglevel and create better indices as side effect of verify database.
Try this one: ConquestDICOMServer.zip
Marcel
I've been testing this version for a while under a 'normal load' (which for me means 0-2 people downloading/uploading a study simultaneously) and honestly it's behavior is hard to describe.
The updates are happening at a semi-random intervals.. I'd say somewhere between 1 - 3sec (with 1 being very common, 3 being very rare). That's far from being 'smooth' but that's not the worst part.
The worst part is that sometimes there is stuff missing in the window. Sometimes it's just last 1-2lines, but sometimes it's a LOT of lines.
(see attached screenshot) In this particular case you can see that there is plenty of stuff in the log (on the left) but everything below the red line is missing in the conquest window.
And it stays like that until something will trigger the next update.
Maybe it's still waiting in the buffer?... but then it should be flushed after 0.1s, shouldn't it?
and bonus question:
What does the 'ui' compression mean? Can't find it the manual. I'd expect a 'j2' (as defined in the arcnema) but I'm getting 'ui' instead. (transfer between 2 dgates 1.5)
Hi,
I will read the code again.
UI is littleendianexplicit.
regards,
Marcel
Now it works better - just a thinking error on my side.
Thanks for testing.
Marcel
this version was much better. refresh rate is much smoother and no gui freezing.
However I'm still missing few last lines (usually 1-3 lines). In the previous version I've seen much bigger chunks missing so I think there is an improvement (or maybe I'm just luck today )
Hi,
can you check that the same lines are in the log. Dgate used UDP to talk to the server, so it may drop lines coming in faster than ~1 ms apart. If they are not in the log file it is an UDP issue.
Marcel
no no, it is NOT permanently missing. Just not shown until next trigger.
In fact it's easy to reproduce - I used 2 dicomechos in a row (via the console.bat) and got this (attached)
As you can see there are 2 echo responses in the serverstatus.log (on the left) and only one in the GUI window on the right.
It WILL show up in the GUI eventually, so it's not totally missing for sure... it's more like it's still waiting in the buffer waiting for next trigger.
Weird - as if your timer based updates do not happen.
The same works fine for me (win7 and win8)
Marcel
Weird - as if your timer based updates do not happen.
Exactly.
I'm on win server 2012 r2. It's a bit like win 8.1 (but server ver.) so my guess would be 'if it works on 8.1 then it should work on 2012r2... but apparently not.
If you have any ideas I will gladly help you test/debug this.
Just to make sure: it is the 8 Feb version!
Do you use the DICOM printer?
yes - it's the 8 II 2021, 22:03:36 version
umm.. honestly I'm not sure. We do have one in the network but I'm not sure if it's being used any more. If yes then it would be on veeeery rare cases.
Don’t have an account yet? Register yourself now and be a part of our community!