Remove test for FE_CAN_MUTE_TS so that frontends will not leak stray data during tuning. This had to go because the previous solution involved blocking. The frontend might have been correctly locked previously, in which case it was possible for userspace apps to receive old data unexpectedly.

1 files changed, 2 insertions, 12 deletions

diff --git a/linux/drivers/media/dvb/dvb-core/dvb_frontend.c b/linux/drivers/media/dvb/dvb-core/dvb_frontend.c
index 6ea66adad..1d564cd95 100644
--- a/linux/drivers/media/dvb/dvb-core/dvb_frontend.c
+++ b/linux/drivers/media/dvb/dvb-core/dvb_frontend.c
@@ -237,9 +237,6 @@ static void dvb_call_frontend_notifiers (struct dvb_frontend_data *fe,
 
 	fe->status = s;
 
-	if (!(s & FE_HAS_LOCK) && (fe->info->caps & FE_CAN_MUTE_TS))
-		return;
-
 	/**
 	 *   now tell the Demux about the TS status changes...
 	 */
@@ -772,6 +769,7 @@ static int dvb_frontend_ioctl (struct inode *inode, struct file *file,
 		       fe->min_delay = (dvb_override_tune_delay * HZ) / 1000;
 		}
 
+		dvb_frontend_wakeup(fe);		
 		dvb_frontend_add_event (fe, 0);	    
 		break;
 
@@ -796,15 +794,7 @@ static int dvb_frontend_ioctl (struct inode *inode, struct file *file,
 		struct dvb_frontend_info* tmp = (struct dvb_frontend_info*) parg;
 		tmp->caps |= FE_CAN_INVERSION_AUTO;
 	}
-
-	// if the frontend has just been set, wait until the first tune has finished.
-	// This ensures the app doesn't start reading data too quickly, perhaps from the
-	// previous lock, which is REALLY CONFUSING TO DEBUG!
-	if ((cmd == FE_SET_FRONTEND) && (err == 0)) {
-		dvb_frontend_wakeup(fe);
-		err = wait_event_interruptible(fe->wait_queue, fe->state & ~FESTATE_RETUNE);
-	}
-
+	
 	return err;
 }