Hylafax Mailing List Archives
|
[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
Re: [hylafax-users] [Fwd: facsimile not received]
The copy quality checking mechanism is rejecting the page due to 6
consecutive rows of corrupt image data. Those are probably just RTC,
and it may be slightly messed up and so the decoder is counting the
EOLs that make up RTC as scanline EOLs instead, and thus coming up
with 6 lines of corrupt image data. If you turn SessionTracing up to
0xFFF I could tell you more. If it is what I think it is, then
HylaFAX CVS HEAD will not have this problem. Otherwise you can just
turn your MaxConsecutiveBadLines up to 6 (from 5).
Unfortunately I can't get them to send again, so I doubt I could get you
a log set at 0xFFF.
I'll up the bad lines count.
... this means that the sender interpreted our RTN signal (which means
that we reject the last page sent and want the sender to retransmit)
as MCF or they are simply ignoring it. The "fault" here lies with the
sender failing to follow T.30 fax protocol. However, most fax
machines will still print out the rejected page in this scenario
anyway, and so the developer/manufacturer of the sending fax machine
could be fooled into thinking that it does work "correctly" if they
didn't actually pay close enough attention.
A change has been made to HylaFAX CVS HEAD called
SaveUnconfirmedPages. It will cause HylaFAX to save this page (even
though we rejected it) rather than deleting it.
I'll look forward to CVS being released.
Your quick response is greatly appreciated. Thanks.
--
Steven Kurylo
____________________ 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*