HylaFAX The world's
most advanced open source fax server
|
|
[
Date Prev][
Date Next][
Thread Prev][
Thread Next]
[
Date Index]
[
Thread Index]
Re: Q: Retrain Negative -- Giving up after 3 tries?
Hi David,
Been looking at faxd/TagLine.c++ around lines 270-299 in imageTagLine()
function. There's some suspicious looking stuff particularly a rather
obvious comment around line 290 that might be the source.
I am still trying to figure out what is going on. Talk to you soon.
- Robert
At 14:21 11/08/98 +1000, David Weiss wrote:
>Hi Robert,
>
>> You could hand edit the info file to force 2400. A reducing requirement on
>> each retrain would presumably do the same thing.
>
>Yup, tried that. Even locked it down (with an &). This did cause the
>transmission to occur at 2400, however the RTNs and retransmissions
>were still there. It seems therefore that the encoding error is
>introduced into the data stream regardless of the info file setting. I
>am still puzzled why the "sendfax -B 2400" should not also cause the
>encoding error. If anyone knows how all the multiple levels of
>configuration (info files, command line parms, destctrls,
>user-specific configs etc) all work together and what takes precedence
>over what and when, I would be very grateful for a detailed
>explanation. Wading through the source is very un-enlightening.
>
>Also fiddled around with Class2Modem::sendPhaseB() to make HylaFAX
>actually train down, on receipt of an RTN (something like how it
>currently handles RTP -- why they are handled differently is beyond me).
>Specifically lowering the speed with info.setMaxSignallingRate( BR_2400 )
>had no affect. Perhaps HylaFAX can't alter the speed once a connection
>is established?
>
>> Very much thanks David!! - the protocol analyzer really helped to sort out
>> the problem. i might even go buy some Telstra shares ;-)
>>
>> Now i guess the main problem is to find tag line bug.
>
>It would be great if you could fix that bug -- good luck.
>
>David
>