|
Hylafax Mailing List Archives
|
[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
Re: [hylafax-users] Transmission problems: info and questions
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*
