[RFC] Fix interrupted recording with Hauppauge HD-PVR

[RFC] Fix interrupted recording with Hauppauge HD-PVR

[Ryley Angus]

[-- Attachment #1: Type: text/plain, Size: 3809 bytes --]

(Sorry in advance for probably breaking a few conventions of the mailing lists. First time using one so please let me know what I’m doing wrong)

I’m writing this because of an issue I had with my Hauppauge HD-PVR. I record from my satellite set top box using component video and optical audio input. I basically use "cat /dev/video0 > ~/video.ts” or use dd. The box is set to output audio as AC-3 over optical, but most channels are actually output as stereo PCM. When the channel is changed between a PCM channel and (typically to a movie channel) to a channel utilising AC-3, the HD-PVR stops the recording as the set top box momentarily outputs no audio. Changing between PCM channels doesn’t cause any issues.

My main problem was that when this happens, cat/dd doesn’t actually exit. When going through the hdpvr driver source and the dmesg output, I found the hdpvr driver wasn’t actually shutting down the device properly until I manually killed cat/dd.

I’ve seen references to this issue being a hardware issue from as far back as 2010: http://forums.gbpvr.com/showthread.php?46429-HD-PVR-drops-recording-on-channel-change-Hauppauge-says-too-bad .

I tracked my issue to the file “hdpvr-video.c”. Specifically, “if (wait_event_interruptible(dev->wait_data, buf->status = BUFSTAT_READY)) {“ (line ~450). The device seems to get stuck waiting for the buffer to become ready. But as far as I can tell, when the channel is changed between a PCM and AC-3 broadcast the buffer status will never actually become ready. 

I haven’t really ever done much coding, but I wrote a really nasty patch for this which tracks the devices buffer status and stops/starts the devices recording when the buffer is not ready for a period of time. In my limited testing it has worked perfectly, no output is overwritten, the output is in sync and the recording changes perfectly between stereo AC-3 (PCM input is encoded to AC-3 by the hardware) and 5.1 AC-3 no matter how frequently I change the channels back and forth. All changes are transparent to cat/dd and neither exit prematurely. Manually killing cat/dd seems to properly shut down the device. There is a half-second glitch in the resultant where the recording restarts, but this amounts to less than a second of lost footage during the change and compared to having the device hang, I can live with it. I haven’t had the device restart recording when it shouldn’t have.

So considering my code is really messy, I’d love it if someone could make some suggestions to make the code better and make sure I don’t have too many logic errors. I don’t really know too much about kernel coding practices either. And if anyone who’s experienced my issue could try out my change and let me know that’d be great. You will have to run "v4l2-ctl --verbose -d /dev/video0 -c audio_encoding=4” to ensure the 5.1 AC-3 is captured properly (AAC capture of 5.1 sources doesn’t seem possible) and "v4l2-ctl --verbose -d $MPEG4_IN --set-audio-input=2” to capture from the optical input.

Thanks in advance,

ryley


--- a/hdpvr-video.c	2014-04-07 09:34:31.000000000 +1000
+++ b/hdpvr-video.c	2014-04-07 09:37:44.000000000 +1000
@@ -453,11 +453,17 @@
 					ret = -EAGAIN;
 				goto err;
 			}
-
-			if (wait_event_interruptible(dev->wait_data,
-					      buf->status == BUFSTAT_READY)) {
-				ret = -ERESTARTSYS;
-				goto err;
+			int counter=0;
+			while (buf->status != BUFSTAT_READY) {
+				counter++;
+				msleep(20);
+				if (counter == 30) {
+					v4l2_dbg(MSG_INFO, hdpvr_debug, &dev->v4l2_dev,
+                                                "limit hit, counter is %d, buf status is %d\n", counter, buf->status);
+					counter=0;
+					ret = hdpvr_stop_streaming(dev);
+					ret = hdpvr_start_streaming(dev);
+				}
 			}
 		}


[-- Attachment #2: resume-recording-during-spdif-channel-change.patch --]
[-- Type: application/octet-stream, Size: 766 bytes --]

diff -Naur a/hdpvr-video.c b/hdpvr-video.c
--- a/hdpvr-video.c	2014-04-07 09:34:31.000000000 +1000
+++ b/hdpvr-video.c	2014-04-07 09:37:44.000000000 +1000
@@ -453,11 +453,17 @@
 					ret = -EAGAIN;
 				goto err;
 			}
-
-			if (wait_event_interruptible(dev->wait_data,
-					      buf->status == BUFSTAT_READY)) {
-				ret = -ERESTARTSYS;
-				goto err;
+			int counter=0;
+			while (buf->status != BUFSTAT_READY) {
+				counter++;
+				msleep(20);
+				if (counter == 30) {
+					v4l2_dbg(MSG_INFO, hdpvr_debug, &dev->v4l2_dev,
+                                                "limit hit, counter is %d, buf status is %d\n", counter, buf->status);
+					counter=0;
+					ret = hdpvr_stop_streaming(dev);
+					ret = hdpvr_start_streaming(dev);
+				}
 			}
 		}
 

[-- Attachment #3: Type: text/plain, Size: 3 bytes --]

Re: [RFC] Fix interrupted recording with Hauppauge HD-PVR

[Hans Verkuil]

Hi Ryley,

Thank you for the patch. Your analysis seems sound. The patch is
actually not bad for a first attempt, but I did it a bit differently.

Can you test my patch?

Regards,

	Hans

Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>

diff --git a/drivers/media/usb/hdpvr/hdpvr-video.c b/drivers/media/usb/hdpvr/hdpvr-video.c
index 0500c417..a61373e 100644
--- a/drivers/media/usb/hdpvr/hdpvr-video.c
+++ b/drivers/media/usb/hdpvr/hdpvr-video.c
@@ -454,6 +454,8 @@ static ssize_t hdpvr_read(struct file *file, char __user *buffer, size_t count,
 
 		if (buf->status != BUFSTAT_READY &&
 		    dev->status != STATUS_DISCONNECTED) {
+			int err;
+
 			/* return nonblocking */
 			if (file->f_flags & O_NONBLOCK) {
 				if (!ret)
@@ -461,11 +463,23 @@ static ssize_t hdpvr_read(struct file *file, char __user *buffer, size_t count,
 				goto err;
 			}
 
-			if (wait_event_interruptible(dev->wait_data,
-					      buf->status == BUFSTAT_READY)) {
-				ret = -ERESTARTSYS;
+			err = wait_event_interruptible_timeout(dev->wait_data,
+					      buf->status == BUFSTAT_READY,
+					      msecs_to_jiffies(500));
+			if (err < 0) {
+				ret = err;
 				goto err;
 			}
+			if (!err) {
+				v4l2_dbg(MSG_INFO, hdpvr_debug, &dev->v4l2_dev,
+					"timeout: restart streaming\n");
+				hdpvr_stop_streaming(dev);
+				err = hdpvr_start_streaming(dev);
+				if (err) {
+					ret = err;
+					goto err;
+				}
+			}
 		}
 
 		if (buf->status != BUFSTAT_READY)


On 04/07/2014 02:04 AM, Ryley Angus wrote:
> (Sorry in advance for probably breaking a few conventions of the
> mailing lists. First time using one so please let me know what I’m
> doing wrong)
> 
> I’m writing this because of an issue I had with my Hauppauge HD-PVR.
> I record from my satellite set top box using component video and
> optical audio input. I basically use "cat /dev/video0 > ~/video.ts”
> or use dd. The box is set to output audio as AC-3 over optical, but
> most channels are actually output as stereo PCM. When the channel is
> changed between a PCM channel and (typically to a movie channel) to a
> channel utilising AC-3, the HD-PVR stops the recording as the set top
> box momentarily outputs no audio. Changing between PCM channels
> doesn’t cause any issues.
> 
> My main problem was that when this happens, cat/dd doesn’t actually
> exit. When going through the hdpvr driver source and the dmesg
> output, I found the hdpvr driver wasn’t actually shutting down the
> device properly until I manually killed cat/dd.
> 
> I’ve seen references to this issue being a hardware issue from as far
> back as 2010:
> http://forums.gbpvr.com/showthread.php?46429-HD-PVR-drops-recording-on-channel-change-Hauppauge-says-too-bad
> .
> 
> I tracked my issue to the file “hdpvr-video.c”. Specifically, “if
> (wait_event_interruptible(dev->wait_data, buf->status =
> BUFSTAT_READY)) {“ (line ~450). The device seems to get stuck waiting
> for the buffer to become ready. But as far as I can tell, when the
> channel is changed between a PCM and AC-3 broadcast the buffer status
> will never actually become ready.
> 
> I haven’t really ever done much coding, but I wrote a really nasty
> patch for this which tracks the devices buffer status and
> stops/starts the devices recording when the buffer is not ready for a
> period of time. In my limited testing it has worked perfectly, no
> output is overwritten, the output is in sync and the recording
> changes perfectly between stereo AC-3 (PCM input is encoded to AC-3
> by the hardware) and 5.1 AC-3 no matter how frequently I change the
> channels back and forth. All changes are transparent to cat/dd and
> neither exit prematurely. Manually killing cat/dd seems to properly
> shut down the device. There is a half-second glitch in the resultant
> where the recording restarts, but this amounts to less than a second
> of lost footage during the change and compared to having the device
> hang, I can live with it. I haven’t had the device restart recording
> when it shouldn’t have.
> 
> So considering my code is really messy, I’d love it if someone could
> make some suggestions to make the code better and make sure I don’t
> have too many logic errors. I don’t really know too much about kernel
> coding practices either. And if anyone who’s experienced my issue
> could try out my change and let me know that’d be great. You will
> have to run "v4l2-ctl --verbose -d /dev/video0 -c audio_encoding=4”
> to ensure the 5.1 AC-3 is captured properly (AAC capture of 5.1
> sources doesn’t seem possible) and "v4l2-ctl --verbose -d $MPEG4_IN
> --set-audio-input=2” to capture from the optical input.
> Thanks in advance,
> 
> ryley
> 
> 
> --- a/hdpvr-video.c	2014-04-07 09:34:31.000000000 +1000
> +++ b/hdpvr-video.c	2014-04-07 09:37:44.000000000 +1000
> @@ -453,11 +453,17 @@
>  					ret = -EAGAIN;
>  				goto err;
>  			}
> -
> -			if (wait_event_interruptible(dev->wait_data,
> -					      buf->status == BUFSTAT_READY)) {
> -				ret = -ERESTARTSYS;
> -				goto err;
> +			int counter=0;
> +			while (buf->status != BUFSTAT_READY) {
> +				counter++;
> +				msleep(20);
> +				if (counter == 30) {
> +					v4l2_dbg(MSG_INFO, hdpvr_debug, &dev->v4l2_dev,
> +                                                "limit hit, counter is %d, buf status is %d\n", counter, buf->status);
> +					counter=0;
> +					ret = hdpvr_stop_streaming(dev);
> +					ret = hdpvr_start_streaming(dev);
> +				}
>  			}
>  		}
> 
> 
> 
> 
> 
> 

RE: [RFC] Fix interrupted recording with Hauppauge HD-PVR

[Ryley Angus]

Thanks Hans for getting back to me.

I've been trying out your patch and I found the device wasn't actually
restarting the streaming/recording properly after a channel 
change. I changed "msecs_to_jiffies(500))" to "msecs_to_jiffies(1000))" and
had the same issue, but "msecs_to_jiffies(2000))" 
seems to be working well. I'll let it keep going for a few more hours, but
at the moment it seems to be working well. The recordings
can be ended without anything hanging, and turning off the device ends the
recording properly (mine neglected this occurrence).

I'll let you know if I have any more issues,

ryley

-----Original Message-----
From: Hans Verkuil [mailto:hverkuil@xs4all.nl] 
Sent: Tuesday, April 08, 2014 12:07 AM
To: Ryley Angus; linux-media@vger.kernel.org
Subject: Re: [RFC] Fix interrupted recording with Hauppauge HD-PVR

Hi Ryley,

Thank you for the patch. Your analysis seems sound. The patch is actually
not bad for a first attempt, but I did it a bit differently.

Can you test my patch?

Regards,

	Hans

Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>

diff --git a/drivers/media/usb/hdpvr/hdpvr-video.c
b/drivers/media/usb/hdpvr/hdpvr-video.c
index 0500c417..a61373e 100644
--- a/drivers/media/usb/hdpvr/hdpvr-video.c
+++ b/drivers/media/usb/hdpvr/hdpvr-video.c
@@ -454,6 +454,8 @@ static ssize_t hdpvr_read(struct file *file, char __user
*buffer, size_t count,
 
 		if (buf->status != BUFSTAT_READY &&
 		    dev->status != STATUS_DISCONNECTED) {
+			int err;
+
 			/* return nonblocking */
 			if (file->f_flags & O_NONBLOCK) {
 				if (!ret)
@@ -461,11 +463,23 @@ static ssize_t hdpvr_read(struct file *file, char
__user *buffer, size_t count,
 				goto err;
 			}
 
-			if (wait_event_interruptible(dev->wait_data,
-					      buf->status == BUFSTAT_READY))
{
-				ret = -ERESTARTSYS;
+			err =
wait_event_interruptible_timeout(dev->wait_data,
+					      buf->status == BUFSTAT_READY,
+					      msecs_to_jiffies(500));
+			if (err < 0) {
+				ret = err;
 				goto err;
 			}
+			if (!err) {
+				v4l2_dbg(MSG_INFO, hdpvr_debug,
&dev->v4l2_dev,
+					"timeout: restart streaming\n");
+				hdpvr_stop_streaming(dev);
+				err = hdpvr_start_streaming(dev);
+				if (err) {
+					ret = err;
+					goto err;
+				}
+			}
 		}
 
 		if (buf->status != BUFSTAT_READY)


On 04/07/2014 02:04 AM, Ryley Angus wrote:
> (Sorry in advance for probably breaking a few conventions of the 
> mailing lists. First time using one so please let me know what I'm 
> doing wrong)
> 
> I'm writing this because of an issue I had with my Hauppauge HD-PVR.
> I record from my satellite set top box using component video and 
> optical audio input. I basically use "cat /dev/video0 > ~/video.ts"
> or use dd. The box is set to output audio as AC-3 over optical, but 
> most channels are actually output as stereo PCM. When the channel is 
> changed between a PCM channel and (typically to a movie channel) to a 
> channel utilising AC-3, the HD-PVR stops the recording as the set top 
> box momentarily outputs no audio. Changing between PCM channels 
> doesn't cause any issues.
> 
> My main problem was that when this happens, cat/dd doesn't actually 
> exit. When going through the hdpvr driver source and the dmesg output, 
> I found the hdpvr driver wasn't actually shutting down the device 
> properly until I manually killed cat/dd.
> 
> I've seen references to this issue being a hardware issue from as far 
> back as 2010:
> http://forums.gbpvr.com/showthread.php?46429-HD-PVR-drops-recording-on
> -channel-change-Hauppauge-says-too-bad
> .
> 
> I tracked my issue to the file "hdpvr-video.c". Specifically, "if 
> (wait_event_interruptible(dev->wait_data, buf->status =
> BUFSTAT_READY)) {" (line ~450). The device seems to get stuck waiting 
> for the buffer to become ready. But as far as I can tell, when the 
> channel is changed between a PCM and AC-3 broadcast the buffer status 
> will never actually become ready.
> 
> I haven't really ever done much coding, but I wrote a really nasty 
> patch for this which tracks the devices buffer status and stops/starts 
> the devices recording when the buffer is not ready for a period of 
> time. In my limited testing it has worked perfectly, no output is 
> overwritten, the output is in sync and the recording changes perfectly 
> between stereo AC-3 (PCM input is encoded to AC-3 by the hardware) and 
> 5.1 AC-3 no matter how frequently I change the channels back and 
> forth. All changes are transparent to cat/dd and neither exit 
> prematurely. Manually killing cat/dd seems to properly shut down the 
> device. There is a half-second glitch in the resultant where the 
> recording restarts, but this amounts to less than a second of lost 
> footage during the change and compared to having the device hang, I 
> can live with it. I haven't had the device restart recording when it 
> shouldn't have.
> 
> So considering my code is really messy, I'd love it if someone could 
> make some suggestions to make the code better and make sure I don't 
> have too many logic errors. I don't really know too much about kernel 
> coding practices either. And if anyone who's experienced my issue 
> could try out my change and let me know that'd be great. You will have 
> to run "v4l2-ctl --verbose -d /dev/video0 -c audio_encoding=4"
> to ensure the 5.1 AC-3 is captured properly (AAC capture of 5.1 
> sources doesn't seem possible) and "v4l2-ctl --verbose -d $MPEG4_IN 
> --set-audio-input=2" to capture from the optical input.
> Thanks in advance,
> 
> ryley
> 
> 
> --- a/hdpvr-video.c	2014-04-07 09:34:31.000000000 +1000
> +++ b/hdpvr-video.c	2014-04-07 09:37:44.000000000 +1000
> @@ -453,11 +453,17 @@
>  					ret = -EAGAIN;
>  				goto err;
>  			}
> -
> -			if (wait_event_interruptible(dev->wait_data,
> -					      buf->status == BUFSTAT_READY))
{
> -				ret = -ERESTARTSYS;
> -				goto err;
> +			int counter=0;
> +			while (buf->status != BUFSTAT_READY) {
> +				counter++;
> +				msleep(20);
> +				if (counter == 30) {
> +					v4l2_dbg(MSG_INFO, hdpvr_debug,
&dev->v4l2_dev,
> +                                                "limit hit, counter is
%d, buf status is %d\n", counter, buf->status);
> +					counter=0;
> +					ret = hdpvr_stop_streaming(dev);
> +					ret = hdpvr_start_streaming(dev);
> +				}
>  			}
>  		}
> 
> 
> 
> 
> 
> 



---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com

Re: [RFC] Fix interrupted recording with Hauppauge HD-PVR

[Keith Pyle]

On 04/07/14 22:32, Ryley Angus wrote:
> Thanks Hans for getting back to me.
>
> I've been trying out your patch and I found the device wasn't actually
> restarting the streaming/recording properly after a channel
> change. I changed "msecs_to_jiffies(500))" to "msecs_to_jiffies(1000))" and
> had the same issue, but "msecs_to_jiffies(2000))"
> seems to be working well. I'll let it keep going for a few more hours, but
> at the moment it seems to be working well. The recordings
> can be ended without anything hanging, and turning off the device ends the
> recording properly (mine neglected this occurrence).
>
> I'll let you know if I have any more issues,
>
> ryley
>
> -----Original Message-----
> From: Hans Verkuil [mailto:hverkuil@xs4all.nl]
> Sent: Tuesday, April 08, 2014 12:07 AM
> To: Ryley Angus; linux-media@vger.kernel.org
> Subject: Re: [RFC] Fix interrupted recording with Hauppauge HD-PVR
>
> Hi Ryley,
>
> Thank you for the patch. Your analysis seems sound. The patch is actually
> not bad for a first attempt, but I did it a bit differently.
>
> Can you test my patch?
>
> Regards,
>
> 	Hans
>
> Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
>
> diff --git a/drivers/media/usb/hdpvr/hdpvr-video.c
> b/drivers/media/usb/hdpvr/hdpvr-video.c
> index 0500c417..a61373e 100644
> --- a/drivers/media/usb/hdpvr/hdpvr-video.c
> +++ b/drivers/media/usb/hdpvr/hdpvr-video.c
> @@ -454,6 +454,8 @@ static ssize_t hdpvr_read(struct file *file, char __user
> *buffer, size_t count,
>   
>   		if (buf->status != BUFSTAT_READY &&
>   		    dev->status != STATUS_DISCONNECTED) {
> +			int err;
> +
>   			/* return nonblocking */
>   			if (file->f_flags & O_NONBLOCK) {
>   				if (!ret)
> @@ -461,11 +463,23 @@ static ssize_t hdpvr_read(struct file *file, char
> __user *buffer, size_t count,
>   				goto err;
>   			}
>   
> -			if (wait_event_interruptible(dev->wait_data,
> -					      buf->status == BUFSTAT_READY))
> {
> -				ret = -ERESTARTSYS;
> +			err =
> wait_event_interruptible_timeout(dev->wait_data,
> +					      buf->status == BUFSTAT_READY,
> +					      msecs_to_jiffies(500));
> +			if (err < 0) {
> +				ret = err;
>   				goto err;
>   			}
> +			if (!err) {
> +				v4l2_dbg(MSG_INFO, hdpvr_debug,
> &dev->v4l2_dev,
> +					"timeout: restart streaming\n");
> +				hdpvr_stop_streaming(dev);
> +				err = hdpvr_start_streaming(dev);
> +				if (err) {
> +					ret = err;
> +					goto err;
> +				}
> +			}
>   		}
>   
>   		if (buf->status != BUFSTAT_READY)
>
>
> On 04/07/2014 02:04 AM, Ryley Angus wrote:
>> (Sorry in advance for probably breaking a few conventions of the
>> mailing lists. First time using one so please let me know what I'm
>> doing wrong)
>>
>> I'm writing this because of an issue I had with my Hauppauge HD-PVR.
>> I record from my satellite set top box using component video and
>> optical audio input. I basically use "cat /dev/video0 > ~/video.ts"
>> or use dd. The box is set to output audio as AC-3 over optical, but
>> most channels are actually output as stereo PCM. When the channel is
>> changed between a PCM channel and (typically to a movie channel) to a
>> channel utilising AC-3, the HD-PVR stops the recording as the set top
>> box momentarily outputs no audio. Changing between PCM channels
>> doesn't cause any issues.
>>
>> My main problem was that when this happens, cat/dd doesn't actually
>> exit. When going through the hdpvr driver source and the dmesg output,
>> I found the hdpvr driver wasn't actually shutting down the device
>> properly until I manually killed cat/dd.
>>
>> I've seen references to this issue being a hardware issue from as far
>> back as 2010:
>> http://forums.gbpvr.com/showthread.php?46429-HD-PVR-drops-recording-on
>> -channel-change-Hauppauge-says-too-bad
>> .
>>
>> I tracked my issue to the file "hdpvr-video.c". Specifically, "if
>> (wait_event_interruptible(dev->wait_data, buf->status =
>> BUFSTAT_READY)) {" (line ~450). The device seems to get stuck waiting
>> for the buffer to become ready. But as far as I can tell, when the
>> channel is changed between a PCM and AC-3 broadcast the buffer status
>> will never actually become ready.
>>
>> ...
I've seen the same problem Ryley describes and handled it in user space 
with a cat-like program that could detect stalls and re-open the hdpvr 
device.  This approach seems much better.  Kudos to both Ryley and Hans.

I concur that the 500 ms. timeout is too small.  When testing my 
program, I tried using a variety of timeout values when I found that the 
HD-PVR seems to require some delay following a close before it is ready 
to respond.  In my tests, anything of 2.5 seconds or less was not 
reliable.  I only reached 100% re-open reliability with a 3 second 
timeout.  It may be that 2 seconds will work with the code Hans posted, 
but you may want to do some additional testing.  It is also possible 
that my HD-PVR is more sensitive to the timeout (i.e., slower to become 
ready).

There is one other potential problem you may want to check.  With my 
user-space restart, the mpeg stream consists of two (or more) 
concatenated streams.  This causes some programs like vlc to have 
problems (e.g., doing forward jumps) since it only sees the length of 
the last of the streams.  I'm not clear if this can also occur with your 
patch.

Keith

RE: [RFC] Fix interrupted recording with Hauppauge HD-PVR

[Ryley Angus]

Hi Kyle.

It may be possible that the delay in acceptable grace periods is due to a
difference in our input AV sources more so than the Hauppauge units
themselves. I'm wondering if it would be useful to control the timeout
period via a module parameter that defaults to 3 seconds perhaps?

As far as the issues with concatenated output, I've just looked at the files
containing a channel change and realized that VLC does show the duration as
0:00. Seeking with a keyboard isn't functional. Seeking with the timeline
and a mouse is fine. Avidemux seems to have trouble editing the file. If I
cut a section from a file that is from a single recording "session" it's
duration is correct, sync is correct and audio properties are correct. I
cannot cut across segments. MPC-HC also has duration issues with the
recording.

If I run the recordings through "ffmpeg -fflags +genpts -I <INPUT> -c:v copy
-c:a copy <OUTPUT>", the resultant file duration is correct in VLC, I can
seek with the keyboard and mouse and editing is perfect with Avidemux. But
would it be better if the device just cleanly stopped recording instead of
automatically resuming? Or, continuing with the module parameters idea,
could we determine whether or not it will automatically restart based off a
module parameter?

I feel bad for not noticing the VLC issues earlier, but I mostly just use
VLC to broadcast the recordings through my home network to client instances
of VLC. This works well, but obviously seeking isn't relevant.

ryley

-----Original Message-----
From: Keith Pyle [mailto:kpyle@austin.rr.com] 
Sent: Wednesday, April 09, 2014 12:28 AM
To: Ryley Angus; 'Hans Verkuil'; linux-media@vger.kernel.org
Subject: Re: [RFC] Fix interrupted recording with Hauppauge HD-PVR

On 04/07/14 22:32, Ryley Angus wrote:
> Thanks Hans for getting back to me.
>
> I've been trying out your patch and I found the device wasn't actually 
> restarting the streaming/recording properly after a channel change. I 
> changed "msecs_to_jiffies(500))" to "msecs_to_jiffies(1000))" and had 
> the same issue, but "msecs_to_jiffies(2000))"
> seems to be working well. I'll let it keep going for a few more hours, 
> but at the moment it seems to be working well. The recordings can be 
> ended without anything hanging, and turning off the device ends the 
> recording properly (mine neglected this occurrence).
>
> I'll let you know if I have any more issues,
>
> ryley
>
> -----Original Message-----
> From: Hans Verkuil [mailto:hverkuil@xs4all.nl]
> Sent: Tuesday, April 08, 2014 12:07 AM
> To: Ryley Angus; linux-media@vger.kernel.org
> Subject: Re: [RFC] Fix interrupted recording with Hauppauge HD-PVR
>
> Hi Ryley,
>
> Thank you for the patch. Your analysis seems sound. The patch is 
> actually not bad for a first attempt, but I did it a bit differently.
>
> Can you test my patch?
>
> Regards,
>
> 	Hans
>
> Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
>
> diff --git a/drivers/media/usb/hdpvr/hdpvr-video.c
> b/drivers/media/usb/hdpvr/hdpvr-video.c
> index 0500c417..a61373e 100644
> --- a/drivers/media/usb/hdpvr/hdpvr-video.c
> +++ b/drivers/media/usb/hdpvr/hdpvr-video.c
> @@ -454,6 +454,8 @@ static ssize_t hdpvr_read(struct file *file, char 
> __user *buffer, size_t count,
>   
>   		if (buf->status != BUFSTAT_READY &&
>   		    dev->status != STATUS_DISCONNECTED) {
> +			int err;
> +
>   			/* return nonblocking */
>   			if (file->f_flags & O_NONBLOCK) {
>   				if (!ret)
> @@ -461,11 +463,23 @@ static ssize_t hdpvr_read(struct file *file, 
> char __user *buffer, size_t count,
>   				goto err;
>   			}
>   
> -			if (wait_event_interruptible(dev->wait_data,
> -					      buf->status == BUFSTAT_READY))
> {
> -				ret = -ERESTARTSYS;
> +			err =
> wait_event_interruptible_timeout(dev->wait_data,
> +					      buf->status == BUFSTAT_READY,
> +					      msecs_to_jiffies(500));
> +			if (err < 0) {
> +				ret = err;
>   				goto err;
>   			}
> +			if (!err) {
> +				v4l2_dbg(MSG_INFO, hdpvr_debug,
> &dev->v4l2_dev,
> +					"timeout: restart streaming\n");
> +				hdpvr_stop_streaming(dev);
> +				err = hdpvr_start_streaming(dev);
> +				if (err) {
> +					ret = err;
> +					goto err;
> +				}
> +			}
>   		}
>   
>   		if (buf->status != BUFSTAT_READY)
>
>
> On 04/07/2014 02:04 AM, Ryley Angus wrote:
>> (Sorry in advance for probably breaking a few conventions of the 
>> mailing lists. First time using one so please let me know what I'm 
>> doing wrong)
>>
>> I'm writing this because of an issue I had with my Hauppauge HD-PVR.
>> I record from my satellite set top box using component video and 
>> optical audio input. I basically use "cat /dev/video0 > ~/video.ts"
>> or use dd. The box is set to output audio as AC-3 over optical, but 
>> most channels are actually output as stereo PCM. When the channel is 
>> changed between a PCM channel and (typically to a movie channel) to a 
>> channel utilising AC-3, the HD-PVR stops the recording as the set top 
>> box momentarily outputs no audio. Changing between PCM channels 
>> doesn't cause any issues.
>>
>> My main problem was that when this happens, cat/dd doesn't actually 
>> exit. When going through the hdpvr driver source and the dmesg 
>> output, I found the hdpvr driver wasn't actually shutting down the 
>> device properly until I manually killed cat/dd.
>>
>> I've seen references to this issue being a hardware issue from as far 
>> back as 2010:
>> http://forums.gbpvr.com/showthread.php?46429-HD-PVR-drops-recording-o
>> n -channel-change-Hauppauge-says-too-bad
>> .
>>
>> I tracked my issue to the file "hdpvr-video.c". Specifically, "if 
>> (wait_event_interruptible(dev->wait_data, buf->status =
>> BUFSTAT_READY)) {" (line ~450). The device seems to get stuck waiting 
>> for the buffer to become ready. But as far as I can tell, when the 
>> channel is changed between a PCM and AC-3 broadcast the buffer status 
>> will never actually become ready.
>>
>> ...
I've seen the same problem Ryley describes and handled it in user space with
a cat-like program that could detect stalls and re-open the hdpvr device.
This approach seems much better.  Kudos to both Ryley and Hans.

I concur that the 500 ms. timeout is too small.  When testing my program, I
tried using a variety of timeout values when I found that the HD-PVR seems
to require some delay following a close before it is ready to respond.  In
my tests, anything of 2.5 seconds or less was not reliable.  I only reached
100% re-open reliability with a 3 second timeout.  It may be that 2 seconds
will work with the code Hans posted, but you may want to do some additional
testing.  It is also possible that my HD-PVR is more sensitive to the
timeout (i.e., slower to become ready).

There is one other potential problem you may want to check.  With my
user-space restart, the mpeg stream consists of two (or more) concatenated
streams.  This causes some programs like vlc to have problems (e.g., doing
forward jumps) since it only sees the length of the last of the streams.
I'm not clear if this can also occur with your patch.

Keith




---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com

Re: [RFC] Fix interrupted recording with Hauppauge HD-PVR

[Keith Pyle]

On 04/08/14 12:07, Ryley Angus wrote:
> Hi Kyle.
>
> It may be possible that the delay in acceptable grace periods is due to a
> difference in our input AV sources more so than the Hauppauge units
> themselves. I'm wondering if it would be useful to control the timeout
> period via a module parameter that defaults to 3 seconds perhaps?
>
> As far as the issues with concatenated output, I've just looked at the files
> containing a channel change and realized that VLC does show the duration as
> 0:00. Seeking with a keyboard isn't functional. Seeking with the timeline
> and a mouse is fine. Avidemux seems to have trouble editing the file. If I
> cut a section from a file that is from a single recording "session" it's
> duration is correct, sync is correct and audio properties are correct. I
> cannot cut across segments. MPC-HC also has duration issues with the
> recording.
>
> If I run the recordings through "ffmpeg -fflags +genpts -I <INPUT> -c:v copy
> -c:a copy <OUTPUT>", the resultant file duration is correct in VLC, I can
> seek with the keyboard and mouse and editing is perfect with Avidemux. But
> would it be better if the device just cleanly stopped recording instead of
> automatically resuming? Or, continuing with the module parameters idea,
> could we determine whether or not it will automatically restart based off a
> module parameter?
>
> I feel bad for not noticing the VLC issues earlier, but I mostly just use
> VLC to broadcast the recordings through my home network to client instances
> of VLC. This works well, but obviously seeking isn't relevant.
>
> ryley
>
> ...
I doubt that the multiple segment problem can be easily fixed in the 
hdpvr Linux driver.  With the caveat that I'm far away from being an 
expert on MPEG, TS, and the like, I believe that the HD-PVR encoder 
generates the timing data into the stream with its origin being defined 
when the encoder starts the stream.  So, if the capture is restarted, 
the encoder is re-initialized by the HD-PVR firmware and the result is a 
new origin for the following stream segment.

The only real fix would be in the HD-PVR firmware - which we can't get 
and is why we have this problem in the first place.

Regardless of this problem, I think the proposed driver patch is a 
distinct improvement over the current situation.  Without the patch, we 
get truncated recordings.  With the patch, we get nearly complete 
recordings which have skip issues.  As you noted, this problem may be 
fixed with ffmpeg.

Keith

Re: [RFC] Fix interrupted recording with Hauppauge HD-PVR

[Hans Verkuil]

On 04/08/2014 07:07 PM, Ryley Angus wrote:
> Hi Kyle.
> 
> It may be possible that the delay in acceptable grace periods is due to a
> difference in our input AV sources more so than the Hauppauge units
> themselves. I'm wondering if it would be useful to control the timeout
> period via a module parameter that defaults to 3 seconds perhaps?

It is OK for both of you if I set the timeout to 3 seconds in my patch? So it
will use "msecs_to_jiffies(3000));".

If you can both confirm that that works, then I'll merge the patch.

Sorry for being late with my reply, it's been busy lately :-)

Regards,

	Hans

> 
> As far as the issues with concatenated output, I've just looked at the files
> containing a channel change and realized that VLC does show the duration as
> 0:00. Seeking with a keyboard isn't functional. Seeking with the timeline
> and a mouse is fine. Avidemux seems to have trouble editing the file. If I
> cut a section from a file that is from a single recording "session" it's
> duration is correct, sync is correct and audio properties are correct. I
> cannot cut across segments. MPC-HC also has duration issues with the
> recording.
> 
> If I run the recordings through "ffmpeg -fflags +genpts -I <INPUT> -c:v copy
> -c:a copy <OUTPUT>", the resultant file duration is correct in VLC, I can
> seek with the keyboard and mouse and editing is perfect with Avidemux. But
> would it be better if the device just cleanly stopped recording instead of
> automatically resuming? Or, continuing with the module parameters idea,
> could we determine whether or not it will automatically restart based off a
> module parameter?
> 
> I feel bad for not noticing the VLC issues earlier, but I mostly just use
> VLC to broadcast the recordings through my home network to client instances
> of VLC. This works well, but obviously seeking isn't relevant.
> 
> ryley
> 
> -----Original Message-----
> From: Keith Pyle [mailto:kpyle@austin.rr.com] 
> Sent: Wednesday, April 09, 2014 12:28 AM
> To: Ryley Angus; 'Hans Verkuil'; linux-media@vger.kernel.org
> Subject: Re: [RFC] Fix interrupted recording with Hauppauge HD-PVR
> 
> On 04/07/14 22:32, Ryley Angus wrote:
>> Thanks Hans for getting back to me.
>>
>> I've been trying out your patch and I found the device wasn't actually 
>> restarting the streaming/recording properly after a channel change. I 
>> changed "msecs_to_jiffies(500))" to "msecs_to_jiffies(1000))" and had 
>> the same issue, but "msecs_to_jiffies(2000))"
>> seems to be working well. I'll let it keep going for a few more hours, 
>> but at the moment it seems to be working well. The recordings can be 
>> ended without anything hanging, and turning off the device ends the 
>> recording properly (mine neglected this occurrence).
>>
>> I'll let you know if I have any more issues,
>>
>> ryley
>>
>> -----Original Message-----
>> From: Hans Verkuil [mailto:hverkuil@xs4all.nl]
>> Sent: Tuesday, April 08, 2014 12:07 AM
>> To: Ryley Angus; linux-media@vger.kernel.org
>> Subject: Re: [RFC] Fix interrupted recording with Hauppauge HD-PVR
>>
>> Hi Ryley,
>>
>> Thank you for the patch. Your analysis seems sound. The patch is 
>> actually not bad for a first attempt, but I did it a bit differently.
>>
>> Can you test my patch?
>>
>> Regards,
>>
>> 	Hans
>>
>> Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
>>
>> diff --git a/drivers/media/usb/hdpvr/hdpvr-video.c
>> b/drivers/media/usb/hdpvr/hdpvr-video.c
>> index 0500c417..a61373e 100644
>> --- a/drivers/media/usb/hdpvr/hdpvr-video.c
>> +++ b/drivers/media/usb/hdpvr/hdpvr-video.c
>> @@ -454,6 +454,8 @@ static ssize_t hdpvr_read(struct file *file, char 
>> __user *buffer, size_t count,
>>   
>>   		if (buf->status != BUFSTAT_READY &&
>>   		    dev->status != STATUS_DISCONNECTED) {
>> +			int err;
>> +
>>   			/* return nonblocking */
>>   			if (file->f_flags & O_NONBLOCK) {
>>   				if (!ret)
>> @@ -461,11 +463,23 @@ static ssize_t hdpvr_read(struct file *file, 
>> char __user *buffer, size_t count,
>>   				goto err;
>>   			}
>>   
>> -			if (wait_event_interruptible(dev->wait_data,
>> -					      buf->status == BUFSTAT_READY))
>> {
>> -				ret = -ERESTARTSYS;
>> +			err =
>> wait_event_interruptible_timeout(dev->wait_data,
>> +					      buf->status == BUFSTAT_READY,
>> +					      msecs_to_jiffies(500));
>> +			if (err < 0) {
>> +				ret = err;
>>   				goto err;
>>   			}
>> +			if (!err) {
>> +				v4l2_dbg(MSG_INFO, hdpvr_debug,
>> &dev->v4l2_dev,
>> +					"timeout: restart streaming\n");
>> +				hdpvr_stop_streaming(dev);
>> +				err = hdpvr_start_streaming(dev);
>> +				if (err) {
>> +					ret = err;
>> +					goto err;
>> +				}
>> +			}
>>   		}
>>   
>>   		if (buf->status != BUFSTAT_READY)
>>
>>
>> On 04/07/2014 02:04 AM, Ryley Angus wrote:
>>> (Sorry in advance for probably breaking a few conventions of the 
>>> mailing lists. First time using one so please let me know what I'm 
>>> doing wrong)
>>>
>>> I'm writing this because of an issue I had with my Hauppauge HD-PVR.
>>> I record from my satellite set top box using component video and 
>>> optical audio input. I basically use "cat /dev/video0 > ~/video.ts"
>>> or use dd. The box is set to output audio as AC-3 over optical, but 
>>> most channels are actually output as stereo PCM. When the channel is 
>>> changed between a PCM channel and (typically to a movie channel) to a 
>>> channel utilising AC-3, the HD-PVR stops the recording as the set top 
>>> box momentarily outputs no audio. Changing between PCM channels 
>>> doesn't cause any issues.
>>>
>>> My main problem was that when this happens, cat/dd doesn't actually 
>>> exit. When going through the hdpvr driver source and the dmesg 
>>> output, I found the hdpvr driver wasn't actually shutting down the 
>>> device properly until I manually killed cat/dd.
>>>
>>> I've seen references to this issue being a hardware issue from as far 
>>> back as 2010:
>>> http://forums.gbpvr.com/showthread.php?46429-HD-PVR-drops-recording-o
>>> n -channel-change-Hauppauge-says-too-bad
>>> .
>>>
>>> I tracked my issue to the file "hdpvr-video.c". Specifically, "if 
>>> (wait_event_interruptible(dev->wait_data, buf->status =
>>> BUFSTAT_READY)) {" (line ~450). The device seems to get stuck waiting 
>>> for the buffer to become ready. But as far as I can tell, when the 
>>> channel is changed between a PCM and AC-3 broadcast the buffer status 
>>> will never actually become ready.
>>>
>>> ...
> I've seen the same problem Ryley describes and handled it in user space with
> a cat-like program that could detect stalls and re-open the hdpvr device.
> This approach seems much better.  Kudos to both Ryley and Hans.
> 
> I concur that the 500 ms. timeout is too small.  When testing my program, I
> tried using a variety of timeout values when I found that the HD-PVR seems
> to require some delay following a close before it is ready to respond.  In
> my tests, anything of 2.5 seconds or less was not reliable.  I only reached
> 100% re-open reliability with a 3 second timeout.  It may be that 2 seconds
> will work with the code Hans posted, but you may want to do some additional
> testing.  It is also possible that my HD-PVR is more sensitive to the
> timeout (i.e., slower to become ready).
> 
> There is one other potential problem you may want to check.  With my
> user-space restart, the mpeg stream consists of two (or more) concatenated
> streams.  This causes some programs like vlc to have problems (e.g., doing
> forward jumps) since it only sees the length of the last of the streams.
> I'm not clear if this can also occur with your patch.
> 
> Keith
> 
> 
> 
> 
> ---
> This email is free from viruses and malware because avast! Antivirus protection is active.
> http://www.avast.com
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: [RFC] Fix interrupted recording with Hauppauge HD-PVR

[Keith Pyle]

On 05/09/14 06:08, Hans Verkuil wrote:
> On 04/08/2014 07:07 PM, Ryley Angus wrote:
>> Hi Kyle.
>>
>> It may be possible that the delay in acceptable grace periods is due to a
>> difference in our input AV sources more so than the Hauppauge units
>> themselves. I'm wondering if it would be useful to control the timeout
>> period via a module parameter that defaults to 3 seconds perhaps?
> It is OK for both of you if I set the timeout to 3 seconds in my patch? So it
> will use "msecs_to_jiffies(3000));".
>
> If you can both confirm that that works, then I'll merge the patch.
>
> Sorry for being late with my reply, it's been busy lately :-)
>
> Regards,
>
> 	Hans
>
>> As far as the issues with concatenated output, I've just looked at the files
>> containing a channel change and realized that VLC does show the duration as
>> 0:00. Seeking with a keyboard isn't functional. Seeking with the timeline
>> and a mouse is fine. Avidemux seems to have trouble editing the file. If I
>> cut a section from a file that is from a single recording "session" it's
>> duration is correct, sync is correct and audio properties are correct. I
>> cannot cut across segments. MPC-HC also has duration issues with the
>> recording.
>>
>> If I run the recordings through "ffmpeg -fflags +genpts -I <INPUT> -c:v copy
>> -c:a copy <OUTPUT>", the resultant file duration is correct in VLC, I can
>> seek with the keyboard and mouse and editing is perfect with Avidemux. But
>> would it be better if the device just cleanly stopped recording instead of
>> automatically resuming? Or, continuing with the module parameters idea,
>> could we determine whether or not it will automatically restart based off a
>> module parameter?
>>
>> I feel bad for not noticing the VLC issues earlier, but I mostly just use
>> VLC to broadcast the recordings through my home network to client instances
>> of VLC. This works well, but obviously seeking isn't relevant.
>>
>> ryley
>>
>> -----Original Message-----
>> From: Keith Pyle [mailto:kpyle@austin.rr.com]
>> Sent: Wednesday, April 09, 2014 12:28 AM
>> To: Ryley Angus; 'Hans Verkuil'; linux-media@vger.kernel.org
>> Subject: Re: [RFC] Fix interrupted recording with Hauppauge HD-PVR
>>
>> On 04/07/14 22:32, Ryley Angus wrote:
>>> Thanks Hans for getting back to me.
>>>
>>> I've been trying out your patch and I found the device wasn't actually
>>> restarting the streaming/recording properly after a channel change. I
>>> changed "msecs_to_jiffies(500))" to "msecs_to_jiffies(1000))" and had
>>> the same issue, but "msecs_to_jiffies(2000))"
>>> seems to be working well. I'll let it keep going for a few more hours,
>>> but at the moment it seems to be working well. The recordings can be
>>> ended without anything hanging, and turning off the device ends the
>>> recording properly (mine neglected this occurrence).
>>>
>>> I'll let you know if I have any more issues,
>>>
>>> ryley
>>>
>>> -----Original Message-----
>>> From: Hans Verkuil [mailto:hverkuil@xs4all.nl]
>>> Sent: Tuesday, April 08, 2014 12:07 AM
>>> To: Ryley Angus; linux-media@vger.kernel.org
>>> Subject: Re: [RFC] Fix interrupted recording with Hauppauge HD-PVR
>>>
>>> Hi Ryley,
>>>
>>> Thank you for the patch. Your analysis seems sound. The patch is
>>> actually not bad for a first attempt, but I did it a bit differently.
>>>
>>> Can you test my patch?
>>>
>>> Regards,
>>>
>>> 	Hans
>>>
>>> Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
>>>
>>> diff --git a/drivers/media/usb/hdpvr/hdpvr-video.c
>>> b/drivers/media/usb/hdpvr/hdpvr-video.c
>>> index 0500c417..a61373e 100644
>>> --- a/drivers/media/usb/hdpvr/hdpvr-video.c
>>> +++ b/drivers/media/usb/hdpvr/hdpvr-video.c
>>> @@ -454,6 +454,8 @@ static ssize_t hdpvr_read(struct file *file, char
>>> __user *buffer, size_t count,
>>>    
>>>    		if (buf->status != BUFSTAT_READY &&
>>>    		    dev->status != STATUS_DISCONNECTED) {
>>> +			int err;
>>> +
>>>    			/* return nonblocking */
>>>    			if (file->f_flags & O_NONBLOCK) {
>>>    				if (!ret)
>>> @@ -461,11 +463,23 @@ static ssize_t hdpvr_read(struct file *file,
>>> char __user *buffer, size_t count,
>>>    				goto err;
>>>    			}
>>>    
>>> -			if (wait_event_interruptible(dev->wait_data,
>>> -					      buf->status == BUFSTAT_READY))
>>> {
>>> -				ret = -ERESTARTSYS;
>>> +			err =
>>> wait_event_interruptible_timeout(dev->wait_data,
>>> +					      buf->status == BUFSTAT_READY,
>>> +					      msecs_to_jiffies(500));
>>> +			if (err < 0) {
>>> +				ret = err;
>>>    				goto err;
>>>    			}
>>> +			if (!err) {
>>> +				v4l2_dbg(MSG_INFO, hdpvr_debug,
>>> &dev->v4l2_dev,
>>> +					"timeout: restart streaming\n");
>>> +				hdpvr_stop_streaming(dev);
>>> +				err = hdpvr_start_streaming(dev);
>>> +				if (err) {
>>> +					ret = err;
>>> +					goto err;
>>> +				}
>>> +			}
>>>    		}
>>>    
>>>    		if (buf->status != BUFSTAT_READY)
>>>
>>>
>>> On 04/07/2014 02:04 AM, Ryley Angus wrote:
>>>> (Sorry in advance for probably breaking a few conventions of the
>>>> mailing lists. First time using one so please let me know what I'm
>>>> doing wrong)
>>>>
>>>> I'm writing this because of an issue I had with my Hauppauge HD-PVR.
>>>> I record from my satellite set top box using component video and
>>>> optical audio input. I basically use "cat /dev/video0 > ~/video.ts"
>>>> or use dd. The box is set to output audio as AC-3 over optical, but
>>>> most channels are actually output as stereo PCM. When the channel is
>>>> changed between a PCM channel and (typically to a movie channel) to a
>>>> channel utilising AC-3, the HD-PVR stops the recording as the set top
>>>> box momentarily outputs no audio. Changing between PCM channels
>>>> doesn't cause any issues.
>>>>
>>>> My main problem was that when this happens, cat/dd doesn't actually
>>>> exit. When going through the hdpvr driver source and the dmesg
>>>> output, I found the hdpvr driver wasn't actually shutting down the
>>>> device properly until I manually killed cat/dd.
>>>>
>>>> I've seen references to this issue being a hardware issue from as far
>>>> back as 2010:
>>>> http://forums.gbpvr.com/showthread.php?46429-HD-PVR-drops-recording-o
>>>> n -channel-change-Hauppauge-says-too-bad
>>>> .
>>>>
>>>> I tracked my issue to the file "hdpvr-video.c". Specifically, "if
>>>> (wait_event_interruptible(dev->wait_data, buf->status =
>>>> BUFSTAT_READY)) {" (line ~450). The device seems to get stuck waiting
>>>> for the buffer to become ready. But as far as I can tell, when the
>>>> channel is changed between a PCM and AC-3 broadcast the buffer status
>>>> will never actually become ready.
>>>>
>>>> ...
>> I've seen the same problem Ryley describes and handled it in user space with
>> a cat-like program that could detect stalls and re-open the hdpvr device.
>> This approach seems much better.  Kudos to both Ryley and Hans.
>>
>> I concur that the 500 ms. timeout is too small.  When testing my program, I
>> tried using a variety of timeout values when I found that the HD-PVR seems
>> to require some delay following a close before it is ready to respond.  In
>> my tests, anything of 2.5 seconds or less was not reliable.  I only reached
>> 100% re-open reliability with a 3 second timeout.  It may be that 2 seconds
>> will work with the code Hans posted, but you may want to do some additional
>> testing.  It is also possible that my HD-PVR is more sensitive to the
>> timeout (i.e., slower to become ready).
>>
>> There is one other potential problem you may want to check.  With my
>> user-space restart, the mpeg stream consists of two (or more) concatenated
>> streams.  This causes some programs like vlc to have problems (e.g., doing
>> forward jumps) since it only sees the length of the last of the streams.
>> I'm not clear if this can also occur with your patch.
>>
>> Keith
>>
>>
>>
>>
>> ---
>> This email is free from viruses and malware because avast! Antivirus protection is active.
>> http://www.avast.com
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-media" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
>
Yes, a 3-second timeout should be fine.  I'll be happy to test the 
merged patch.

Keith