Restrict the usage of sending EOR, even when using MH and MR

From Lee:
|  commit 5047c9552d77be6d1ab22e0bb72f08d93a180c04
|  Author: Lee Howard <faxguy@howardsilvan.com>
|  Date:   Sat Aug 26 16:57:51 2006 +0000
|
|    We really shouldn't send EOR if the receiver hasn't gotten enough data frames
|    in MH or MR.  If, for example, they haven't received any frames properly then
|    it's not a good idea to be EORing.  So for now we say half.

diff --git a/CHANGES b/CHANGES
index cbc11bdea652dda8212397bf1e152da6ee95ce1d..dc2233001d055c754868d4f391fac105bb757d1b 100644 (file)
--- a/CHANGES
+++ b/CHANGES
@@ -2,6 +2,7 @@
 
 Changelog since HylaFAX 4.3.3
 
+* Restrict the usage of sending EOR, even when using MH and MR (13 Mar 2007)
 * Fix send buffer when transmitting non-ECM data with a non-zero
   scanline-time value (13 Mar 2007)
 * Flush modem input after NO CARRIER result in Class 1 Phase C send (13 Mar 2007)

diff --git a/faxd/Class1Send.c++ b/faxd/Class1Send.c++
index 28dd4505819ad82e299c40157c7d89303ab55d3b..181dcda9497d94cd0485ba82ca105e89f90bff9a 100644 (file)
--- a/faxd/Class1Send.c++
+++ b/faxd/Class1Send.c++
@@ -1433,17 +1433,19 @@ Class1Modem::blockFrame(const u_char* bitrev, bool lastframe, u_int ppmcmd, fxSt
                            } else {
                                /*
                                 * At this point data corruption is inevitable if all data
-                                * frames have not been received correctly.  This is tolerable
-                                * with MH and MR data, as the effect of the corruption
-                                * will be limited, but with MMR data all data following the
-                                * corrupt frame will be meaningless: the page image will be
-                                * truncated on the receiver's end.  So if this is the case
-                                * we disconnect, and hopefully we try again successfully.  If
-                                * this happens repeatedly to the same destination, then
-                                * disabling MMR to this destination would be advisable.
+                                * frames have not been received correctly.  With MH and MR 
+                                * data formats this may be tolerable if the bad frames are 
+                                * few and not in an unfortunate sequence.  With MMR data the
+                                * receiving decoder should truncate the image at the point
+                                * of the corruption.  The effect of corruption in JBIG or JPEG
+                                * data is quite unpredictable.  So if all frames have not been
+                                * received correctly and we're looking at an unacceptable
+                                * imaging situation on the receiver's end, then we disconnect,
+                                * and hopefully we try again successfully.
                                 */
-                               if (blockgood == false && params.df == DF_2DMMR) {
-                                   emsg = "Failure to transmit clean MMR image data.";
+                               if (blockgood == false && (params.df >= DF_2DMMR ||
+                                   (params.df <= DF_2DMR && badframes > frameNumber/2))) {
+                                   emsg = "Failure to transmit clean ECM image data.";
                                    protoTrace(emsg);
                                    return (false);
                                }