Re: [hylafax-users] Phase D error only on certain Tiffs

[Lee Howard <faxguy@xxxxxxxxxxxxxxxx>]

On 2004.02.19 18:14 Frank @ Impact wrote:
> Sending certain tiffs (actually those generated from the sendfax
> client
> or from a WHFC) from one of the digi modems to another digi modem on
> the
> same card always produces a phase D error.  The send and receive logs
> below.

sendfax doesn't usually generate TIFF unless the original document is 
TIFF (in which case it still didn't generate it)... usually it delivers 
PostScript to documents to hfaxd.  Likewise, I believe that the 
traditional WHFC setup uses a PostScript printer driver.

In the end, HylaFAX's faxq examines the documents, be they TIFF, 
PostScript/PDF, or PCL, and then uses tiff2fax, pcl2fax, ps2fax, and 
pdf2fax to generate and reformat the TIFF data that faxsend will 
transmit during a send session.  Yes, even TIFF data will most likely 
be reformatted (using an ugly tiff2ps -> ps2fax step) if tiffcheck 
doesn't sign off on the file.

> But sending a tiff that was generated by a client like ifax's HylaFSP
> is
> transmitted just fine between the same two modems.

I'm not sure what the FSP drivers deliver to hfaxd - I suspect that it, 
like Cypheus, is TIFF, but I'm not exactly sure.

> Any ideas?  Why just these types of generated tiffs squawk with this
> error?  BTW, the first page does come through ok.  But not any other
> pages as you can see the hangup.
>
> I did send this same tiff from an old practical peripherals modem in
> class 1 to one of these digi modems with no problems at all.

This would tend to indicate a Class 2.0 firmware sending error based on 
the image data content.  I doubt the error is client-oriented.

To test better, get this file...

> Feb 19 20:30:49.42: [17874]: SEND file "docq/doc2719.tif;70"

Yes, that's "doc/doc2719.tif;70" - (usually has a semi-colon in the 
filename) the one prepared by faxq.  This isn't the one submitted to 
hfaxd by the client.  Now, this file isn't likely to still exist on 
your system.  So, what you need to do is recreate the error (or the 
success) - and then, before the job is complete and before the job is 
removed, copy this file out of the docq directory.  It's a short-lived 
isotope of the original - it only exists from the time faxq prepares it 
for sending to the time the job is completed.  That's the TIFF data 
that is actually transmitted.

Then send that file using 'sendfax -n -s a4 -l -2 -d some_number 
doc2719.tif\;70', it should pass through tiffcheck unscathed, and you 
should be able to test successes and failures with it.

Then you take the successful TIFF and the painful TIFF and you compare 
them.   First use the easy tools like diff, tiffcmp, tiffinfo, 
tiffdump, and then if that doesn't result in anything, use a binary 
file hex-dumping/editing program to compare the actual data.  You 
should be able to find the culprit that way.

> Feb 19 20:31:11.95: [17856]: <-- [7:AT+FDR\r]
> Feb 19 20:31:13.28: [17856]: --> [14:+FHT: FF 13 8C]
> Feb 19 20:31:21.76: [17856]: --> [7:+FHS:A0]
> Feb 19 20:31:21.76: [17856]: REMOTE HANGUP: Unspecified Phase D error 
> (code A0)

The remote hangup occurred nearly 8.5 seconds after MCF was sent.  
Here's the last bit of the send log:

> Feb 19 20:30:59.25: [17874]: SEND send MPS (more pages, same document)
> Feb 19 20:31:11.75: [17874]: --> [26:+FHT: FF 13 BF 4F 00 00 56]
> Feb 19 20:31:13.46: [17874]: --> [14:+FHR: FF 13 8C]
> Feb 19 20:31:13.46: [17874]: --> [2:OK]
> Feb 19 20:31:13.46: [17874]: <-- [8:AT+FPS?\r]
> Feb 19 20:31:13.72: [17874]: --> [1:1]
> Feb 19 20:31:13.72: [17874]: --> [2:OK]
> Feb 19 20:31:13.72: [17874]: SEND recv MCF (message confirmation)

It all looks good to here, but your posted send log ends before page 2, 
so it's hard to get a good idea of what happened at 20:31:21.76.  The 
receiver seems to think that the sender hung up at that point.  But 8.5 
seconds to send a single page seems too short.

I'd bet on an ECM problem.  Try testing that by putting "-E" into your 
sendfax command (for a normally failed submission).

Lee.

____________________ HylaFAX(tm) Users Mailing List _______________________
 To subscribe/unsubscribe, click http://lists.hylafax.org/cgi-bin/lsg2.cgi
On UNIX: mail -s unsubscribe hylafax-users-request@xxxxxxxxxxx < /dev/null
 *To learn about commercial HylaFAX(tm) support, mail sales@xxxxxxxxxxxx*