Re: [hylafax-users] Faxes cut in half

["SCIN - Danilo Bottino" <info@xxxxxxx>]

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*