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
> 




Project hosted by iFAX Solutions