Re: [hylafax-users] Transmission problems: info and questions

[Lee Howard <faxguy@xxxxxxxxxxxxxxxx>]

Ross Boylan wrote:

> Since it takes many minutes to process my inputs into tiff, this
> resubmission was a big win for me.
>  

I've added a resubmit feature to faxalter in hylafax+ 
(http://hylafax.sourceforge.net) for this very reason.

> If one runs faxalter for a job that is currently transmitting, what
> should the effect be?  It seemed to me it interrupted the job.
>  

It will interrupt the job if it's in send-process.

> 2) faxalter -a doesn't seem to work.  Not only did running it not
> reset the time to that desired, it caused a job to attempt
> transmission immediately.

I wonder if the Debian maintainer applied a timezone patch to 4.2.5 that 
was developed in the 4.3.0 development process.  Ultimately the initial 
changes there were incomplete or faulty, and these were eventually 
remedied in 4.3.0.

> There seem to be a number of conditions that cause the job to fail
> before the indicated number of retries.
>  

Be careful not to confuse the faxalter -t meaning of "tries" with the 
sendfax -t meaning of "tries".  In faxalter -t "tries" refers to the 
number of calls that will be placed.  In sendfax -t "tries" refers to 
the number of attempts that will be made to send the entire fax job 
after a connection is made to the remote receiver.  In sendfax -T 
"maxdials" refers to faxalter -t "tries".  So you're running into the 
max number of protocol attempts (meaning as sendfax gives -t) as set 
forth by the client program and not the max number of dials (meaning as 
set by faxalter -t).

> May 28 21:57:02.05: [21888]: SEND send frame number 35
> May 28 21:57:02.05: [21888]: SEND send frame number 36
> May 28 21:57:02.05: [21888]: SEND send frame number 37
> May 28 21:57:02.05: [21888]: DELAY 200 ms
> May 28 21:57:02.24: [21888]: <-- [11:AT+FTM=146\r]
> May 28 21:57:32.24: [21888]: MODEM TIMEOUT: reading line from modem
> May 28 21:57:32.24: [21888]: MODEM <Timeout>
> May 28 21:57:32.24: [21888]: SEND end page
> May 28 21:57:32.24: [21888]: Unspecified Transmit Phase C error
> May 28 21:57:32.24: [21888]: <-- [9:AT+FTH=3\r]
> May 28 21:57:32.37: [21888]: --> [8:AT+FTH=3]

USR modems stink this way.  Using AT+FRS seems to give them grief.  The 
new (4.3.0) prototypes for USR modems have this in them:

#
# When using AT+FRS=n we see USR modems reset themselves in the middle 
of sessions
# this is not good.  So, we seem to work-around that problem by not 
using the
# command.  Unfortunately, this isn't an ideal thing.
#
Class1SwitchingCmd:     "<delay\0727>"


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@xxxxxxxxx*