Hylafax Mailing List Archives

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

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



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*



Home
Report any problems to webmaster@hylafax.org

HylaFAX is a trademark of Silicon Graphics Corporation.
Internet connectivity for hylafax.org is provided by:
VirtuALL Private Host Services