[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

20000906: pnga2area timeouts reading 4.7 MB compressed image (cont.)

>From: Pepo Juega <address@hidden>
>Organization: Instituto Nacional de Meteorologia
>Keywords: 200008311046.e7VAk3N24792 ldm-mcidas pnga2area


re: Aug 31 09:21:00 area2png[22532]: doPNG:: 105419756   4696473  0.0446
This is pretty good compression!

>No wonder, I think the file is empty. (See below)

That would account for the incredible compression!

re: You could try changing 'alarm_timeout' to something like 120, 180,

>I don't think that will be necessary, but nice to know. 


re: Another possibility is that pnga2area is not getting an EOF indication
from the LDM's pqact routine.

>I don't quite understand that. But let me explain first.

>While I was waiting for your answer,
>I found out that the Wisconsin GVAR SDI ingestor issues a mail 
>message to the ldm account as soon as it detects a new image is 
>arriving (At the very first line scanned!) in contrast with other
>SDI ingestors like meteosat for example, which e-mail when the
>last image line is already down. This means that my IMGCOPY command
>for GVAR is issued when only a few lines have been sent down. The AREA
>file is fully allocated, but mostly empty! I was only passing over a
>few lines all the time.

OK, this is makes some sense now.  The AREA directory would be created and
would most likely indicate a certain size even though there are only
a few lines.  My area2png compression routine uses the shape of the image
(lines and elements/line) to prep the PNG compression routines.  I do
not do extensive checks to make sure that the AREA file being compressed
is complete.  I will have to review this design decision in the light of
your problem.

>So, I changed the action on the feeder side to just cron the appropiate
>IMGCOPY command 25 minutes after I get mail, and it then passes
>a complete image to area2png. (25 minutes is about what a full disc
>image takes to get downloaded) PROBLEM SOLVED

You are saying that the IMGCOPY will transfer empty lines from the
ingestor?  If this is true, the resulting AREA file should be viable
(although empty) and area2png should work correctly.  pnga2area on
the receiving side should also work correctly even though the image
will not be of much good.

>Now on the requester side I get:
>pnga2area[27222]: unPNG:: 42758475  113927188  2.6644

This looks more like it.  The question remains whether or not the
process completes correctly.  I am assuming that it does since you did
not include lines indicating a timeout condition.

re: not having a -close on the PIPE action

>That was not it for sure. I do both, close and flush.

OK.  Please let me know if there is any residual problem with pnga2area.


You are welcome.


NOTE: All email exchanges with Unidata User Support are recorded in the Unidata inquiry tracking system and then made publicly available through the web. If you do not want to have your interactions made available in this way, you must let us know in each email you send to us.