Re: Failure to transmit clean ECM image data

On 04/10/2017 04:29 PM, Ross Boylan wrote:
> On Mon, Apr 10, 2017 at 2:20 PM, Lee Howard <[email protected]> wrote:
>> After four attempts to send the same 27 frames of image data the receiver
>> had accepted a total of zero. Consequently, HylaFAX's faxsend decided that
>> there was no hope of getting it through with SuperG3 (V.34-Fax) and gave up.
>>
>> On the next attempt it should automatically try it again without V.34
>> speeds.  Hopefully it would work, then.
> It looks to me as if all 3 attempts used the same speed.  They all say
> USE 28800 bit/s
> and then at the end
> The destination appears to have trouble with V.34-Fax.
>
> So I don't think it's backing off.  Is there a way to do so manually,
> i.e., as a configuration option for the modem, or maybe the
> destination number?

Because you're using v6.0.6 I'm not sure if there was a problem in that 
branch of releases that caused hasV34Trouble to not work as I'm used to 
seeing.  You could see if HylaFAX+ v5.5.9 resolves it automatically.  
(No, v6.0.6 is not newer than v5.5.9.)

The "info" file for the destination number in /var/spool/hylafax/info/ 
should have "hasV34Trouble:yes" in it.  The info files are routinely 
purged by faxcron after disuse, and unless you "lock" that setting it 
will get unset through that purge.  So, you can "lock" it by adding an 
ampersand, "&hasV34Trouble:yes".

See: http://hylafax.sourceforge.net/man/hylafax-info.php

Thanks,

Lee.


____________________ HylaFAX(tm) Users Mailing List _______________________
  To subscribe/unsubscribe, click http://lists.hylafax.org/cgi-bin/lsg2.cgi
 On UNIX: mail -s unsubscribe [email protected] < /dev/null
  *To learn about commercial HylaFAX(tm) support, mail [email protected].*