HylaFAX The world's most advanced open source fax server
[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [hylafax-users] Faxes cut in half

This is what I did..


#!/bin/sh
. etc/setup.cache
. bin/common-functions
QFILE=sendq/q$1
parseQfile
case "$number" in
       0171959463)
       echo "ModemSoftRTFCC: no"
       echo "DesiredDF: 0";;
esac
exit 0



..and this is what i get. What am I doing wrong?

dic 01 11:27:59.04: [28058]: SESSION BEGIN 000005950 390110171959463
dic 01 11:27:59.04: [28058]: HylaFAX (tm) Version 4.3.0
dic 01 11:27:59.04: [28058]: SEND FAX: JOB 1142 DEST 0171959463 COMMID 000005950 DEVICE '/dev/modem2' FROM 'Cora <*****************' USER fax
dic 01 11:27:59.04: [28058]: <-- [12:AT+FCLASS=1\r]
dic 01 11:27:59.06: [28058]: --> [2:OK]
dic 01 11:27:59.06: [28058]: DIAL 0171959463
dic 01 11:27:59.06: [28058]: <-- [15:ATDT0171959463\r]
dic 01 11:28:15.71: [28058]: --> [7:CONNECT]
dic 01 11:28:17.21: [28058]: --> [2:OK]
dic 01 11:28:17.21: [28058]: REMOTE NSF "00 00 56 55 55 00 8C 90 80 AF 06"
dic 01 11:28:17.21: [28058]: NSF remote fax equipment: Brother MFC-3100C/MFC-8600
dic 01 11:28:17.21: [28058]: <-- [9:AT+FRH=3\r]
dic 01 11:28:17.23: [28058]: --> [7:CONNECT]
dic 01 11:28:17.92: [28058]: --> [2:OK]
dic 01 11:28:17.92: [28058]: REMOTE CSI "0171959463"
dic 01 11:28:17.92: [28058]: <-- [9:AT+FRH=3\r]
dic 01 11:28:17.94: [28058]: --> [7:CONNECT]
dic 01 11:28:18.35: [28058]: --> [2:OK]
dic 01 11:28:18.35: [28058]: REMOTE best rate 33600 bit/s
dic 01 11:28:18.35: [28058]: REMOTE max A4 page width (215 mm)
dic 01 11:28:18.35: [28058]: REMOTE max unlimited page length
dic 01 11:28:18.35: [28058]: REMOTE best vres 15.4 line/mm
dic 01 11:28:18.35: [28058]: REMOTE format support: MH, MR, MMR, JBIG
dic 01 11:28:18.35: [28058]: REMOTE supports T.30 Annex A, 256-byte ECM
dic 01 11:28:18.35: [28058]: REMOTE best 10 ms/scanline
dic 01 11:28:18.35: [28058]: USE 14400 bit/s
dic 01 11:28:18.35: [28058]: USE error correction mode
dic 01 11:28:18.35: [28058]: SEND file "docq/doc1143.ps;c0"
dic 01 11:28:18.35: [28058]: USE A4 page width (215 mm)
dic 01 11:28:18.35: [28058]: USE unlimited page length
dic 01 11:28:18.35: [28058]: USE 3.85 line/mm
dic 01 11:28:18.35: [28058]: USE 2-D MMR
dic 01 11:28:18.35: [28058]: USE 0 ms/scanline
dic 01 11:28:18.35: [28058]: SEND training at v.17 14400 bit/s
dic 01 11:28:18.35: [28058]: <-- [9:AT+FRS=7\r]
dic 01 11:28:18.49: [28058]: --> [2:OK]
dic 01 11:28:18.49: [28058]: <-- [9:AT+FTH=3\r]
dic 01 11:28:19.47: [28058]: --> [7:CONNECT]
dic 01 11:28:19.47: [28058]: <-- data [23]
dic 01 11:28:19.47: [28058]: <-- data [2]
dic 01 11:28:19.50: [28058]: --> [7:CONNECT]
dic 01 11:28:19.50: [28058]: <-- data [7]
dic 01 11:28:19.50: [28058]: <-- data [2]
dic 01 11:28:20.69: [28058]: --> [2:OK]
dic 01 11:28:20.69: [28058]: <-- [9:AT+FTS=7\r]
dic 01 11:28:20.76: [28058]: --> [2:OK]
dic 01 11:28:20.76: [28058]: <-- [11:AT+FTM=145\r]
dic 01 11:28:20.78: [28058]: --> [7:CONNECT]
dic 01 11:28:20.78: [28058]: DELAY 400 ms
dic 01 11:28:21.18: [28058]: <-- data [1024]
dic 01 11:28:21.18: [28058]: <-- data [1024]
dic 01 11:28:21.18: [28058]: <-- data [652]
dic 01 11:28:21.18: [28058]: <-- data [2]
dic 01 11:28:28.59: [28058]: --> [5:ERROR]
dic 01 11:28:28.59: [28058]: MODEM Command error
dic 01 11:29:28.59: [28058]: MODEM <Timeout>
dic 01 11:30:28.60: [28058]: MODEM <Empty line>
dic 01 11:30:28.60: [28058]: Problem sending TCF data
dic 01 11:30:28.60: [28058]: <-- [9:AT+FRH=3\r]
dic 01 11:30:31.70: [28058]: --> [0:]
dic 01 11:30:31.70: [28058]: MODEM <Empty line>
dic 01 11:30:31.70: [28058]: <-- data [1]
dic 01 11:30:31.91: [28058]: MODEM <Timeout>
dic 01 11:30:31.91: [28058]: DELAY 1500 ms
dic 01 11:30:33.41: [28058]: SEND training at v.17 12000 bit/s
dic 01 11:30:33.41: [28058]: <-- [9:AT+FRS=7\r]
dic 01 11:31:03.42: [28058]: MODEM <Timeout>
dic 01 11:31:03.42: [28058]: Failure to receive silence.
dic 01 11:31:03.42: [28058]: Error sending T.30 prologue frames
dic 01 11:31:03.42: [28058]: SEND training at v.17 9600 bit/s
dic 01 11:31:03.42: [28058]: <-- [9:AT+FRS=7\r]
dic 01 11:31:33.42: [28058]: MODEM <Timeout>
dic 01 11:31:33.42: [28058]: Failure to receive silence.
dic 01 11:31:33.42: [28058]: Error sending T.30 prologue frames
dic 01 11:31:33.42: [28058]: SEND training at v.29 9600 bit/s
dic 01 11:31:33.42: [28058]: <-- [9:AT+FRS=7\r]
dic 01 11:32:03.43: [28058]: MODEM <Timeout>
dic 01 11:32:03.43: [28058]: Failure to receive silence.
dic 01 11:32:03.43: [28058]: Error sending T.30 prologue frames
dic 01 11:32:03.43: [28058]: SEND training at v.29 7200 bit/s
dic 01 11:32:03.43: [28058]: <-- [9:AT+FRS=7\r]
dic 01 11:32:33.44: [28058]: MODEM <Timeout>
dic 01 11:32:33.44: [28058]: Failure to receive silence.
dic 01 11:32:33.44: [28058]: Error sending T.30 prologue frames
dic 01 11:32:33.44: [28058]: SEND training at v.27ter 4800 bit/s
dic 01 11:32:33.44: [28058]: <-- [9:AT+FRS=7\r]
dic 01 11:33:03.45: [28058]: MODEM <Timeout>
dic 01 11:33:03.45: [28058]: Failure to receive silence.
dic 01 11:33:03.45: [28058]: Error sending T.30 prologue frames
dic 01 11:33:03.45: [28058]: SEND training at v.27ter fallback mode 2400 bit/s
dic 01 11:33:03.45: [28058]: <-- [9:AT+FRS=7\r]
dic 01 11:33:33.45: [28058]: MODEM <Timeout>
dic 01 11:33:33.45: [28058]: Failure to receive silence.
dic 01 11:33:33.45: [28058]: Error sending T.30 prologue frames
dic 01 11:33:33.45: [28058]: TRAINING failed
dic 01 11:33:33.45: [28058]: <-- [9:AT+FTH=3\r]
dic 01 11:33:41.01: [28058]: --> [0:]
dic 01 11:33:41.01: [28058]: <-- [5:ATH0\r]
dic 01 11:33:46.02: [28058]: MODEM <Timeout>
dic 01 11:34:16.03: [28058]: SESSION END



----- Original Message ----- From: "SCIN - Danilo Bottino" <info@xxxxxxx>
To: "Lee Howard" <faxguy@xxxxxxxxxxxxxxxx>
Cc: <hylafax-users@xxxxxxxxxxx>
Sent: Friday, December 01, 2006 3:13 AM
Subject: Re: [hylafax-users] Faxes cut in half


Thanks for the long explanation!

I did a search through the logs and found that

1) it happens with only one receiver who owns this BrotherMFC-8600 model (also mentioned in the session log I sent some days ago), and this is good.

http://www.superwarehouse.com/images/products/printers/multifunction/brother/brother_mfc_8600.gif

2) there are no other receivers with that model, so we can't compare the session logs, and this is bad.

Anyway, we reached ~50 outgoing faxes a day and this is the only one receiver who sometimes reports a badly received fax. So, you're probably right in thinking there's a problem on his end.. ok, I'll try that JobControl thing to see what I get! I'll keep you updated.

Danilo

SCIN - Danilo Bottino wrote:

I've managed to store a few of those badly received tiffs and as far as I can see the conversion looks good. Huh.. now what?


Let me give you a run-down of the image proces - maybe it will help you understand what we're after.

You submit some document to the server for transmission. The server then looks at that document and "prepares it" for transmission... meaning the server has an "info" file describing the known capabilites of the remote device, and so it will then prepare the image according to what it anticipates will work best and closest to the request of the user. If the submitted document just happens to be in the proper format then the server will not do anything to the image for preparation.

Then the call is placed and the remote device is contacted. The remote's feature support is examined, and if we can communicate the fax image that we prepared then protocol moves ahead. If it is not in an acceptable format for the receiver then we hang up, prepare the image correctly, and then dial again. Then faxsend reads-in (to RAM) each page of image data as it is needed in the protocol, and the tagline is put onto it (again, in RAM). When dealing with an MMR source document this requires us to regenerate the entire page of data. When dealing with MH or MR source documents we can snip and cut-n-paste the scanlines into place without modifying the rest of the page. And then, if ModemSoftRTFCC is enabled (and it is by default) faxsend with convert the image compression between MH, MR, and MMR (and JBIG where available) on-the-fly and then transmit that data to the receiver.

In the transmission process it can be done with or without ECM. With ECM there is a virtual guarantee that the data will be correct before the receiver attempts to decode it. Without ECM there is no guarantee at all.

The receiver then does whatever it does, but in the process it will decode the image data to print it onto paper.

So hopefully you can see all of the points where the image can get fouled up from the point where you have the original document on file and submit it to the server and the point where the receiver prints it out.

In your case you have shown me logs that indicate that the session used MMR source documents and transmitted MMR (thus no RTFCC employed) and that ECM is being used. Now you're confirming that the source documents are fine - at least to your TIFF viewer. The receiver's fax machine is confirming all of the ECM frames as received in good form. The fact that the receiver's print-out is being truncated means that at the point of truncation the MMR data it has is corrupted according to its T.6 (MMR) decoder. The fact that the corruption occurs inside of the page image and not immediately below the tagline indicates that the majority of the tagline imaging process is okay.

So, where does that leave us?

The options are these...

1) there still could be an error in the source TIFF image document - however, this is unlikely given that you've looked at it okay and that it's being further processed by the tagline imaging

2) there could be some flaw in HylaFAX's T.6 decoder or encoder as it decodes and then re-encodes the data during the imaging process. This is possible, but if it were the case I think that we'd see many more instances of this problem with other people

3) something could be wrong the ECM framing of the image data, but again, this would seem unlikely as we aren't getting these reports from elsewhere

4) the receiver could have a bug in its MMR decoder - I think that this is the most likely bet... but it's not guaranteed by any means.

I don't think that there are really any other possibilities.

Next thing to do, I would recommend that you use JobControl to limit your faxes to these destinations to MH and MR image data compression... no MMR. So you'll want to put this into your faxq configuration file (/var/spool/hylafax/etc/config):

JobControlCmd: etc/jobcontrol

Then restart faxq. And then you'll want to make a file (and mark it executable!) /var/spool/hylafax/etc/jobcontrol with this in it:

   #!/bin/sh
   . etc/setup.cache
   . bin/common-functions
   QFILE=sendq/q$1
   parseQfile
   case "$number" in
       5551212|7772323)
           echo "ModemSoftRTFCC: no"
           echo "DesiredDF: 0";;
   esac
   exit 0


Instead of "5551212" and "7772323" put your destinations' phone numbers. That will limit faxes to be MH to those destinations. ECM will still be used. So any errors will be limited to one single scanline.

Then send faxes and see how things go.

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*




____________________ 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*

Project hosted by iFAX Solutions