On 08/07/19 04:58, Hans Verkuil wrote:
> On 8/4/19 12:09 AM, Keith Pyle wrote:
>> The hdpvr firmware reacts poorly to a fast close/open sequence. Delaying
>> a few seconds between the close and next open produces generally reliable
>> results. Rather than requiring user
Pyle
Tested-by: Keith Pyle
---
Changes since v2:
- Rewrapped comments again, per request from Hans.
- Per advice from checkpatch.pl --strict (suggested by Hans), added
spacing around `|` for mode permissions. This satisfies checkpatch,
but reduces consistency in hdpvr-core.c, which had
ors may set the limit to 0 to request that `hdpvr_read` never
attempt to restart streaming. Previously, there was no way for
administrators to opt out of an attempted restart.
Signed-off-by: Keith Pyle
Tested-by: Keith Pyle
---
Changes since v2:
- Rewrapped comments again, per request from Hans.
-
On 07/25/19 02:10, Hans Verkuil wrote:
> On 7/7/19 11:15 PM, Keith Pyle wrote:
>> The hdpvr firmware reacts poorly to a fast close/open sequence. Delaying
>> a few seconds between the close and next open produces generally reliable
>> results. Rather than requiring user
Pyle
Tested-by: Keith Pyle
---
Changes since v1:
- Rewrapped output at 80 columns, per request from Hans. Literal strings
still exceed 80 columns where necessary to keep an entire string together,
since this makes it easier for grep to find the file and line that
generates a given message
ors may set the limit to 0 to request that `hdpvr_read` never
attempt to restart streaming. Previously, there was no way for
administrators to opt out of an attempted restart.
Signed-off-by: Keith Pyle
Tested-by: Keith Pyle
---
Changes since v1:
- Rewrapped output at 80 columns, per request from H
On 06/20/19 06:33, Hans Verkuil wrote:
On 6/19/19 4:29 AM, Keith Pyle wrote:
On 06/18/19 02:16, Hans Verkuil wrote:
Hi Keith,
On 6/18/19 6:17 AM, Keith Pyle wrote:
We made the suggested change, compiled, installed, and rebooted. There was some
progress - test 2 (turning the HD-PVR off) no
On 06/20/19 06:33, Hans Verkuil wrote:
On 6/19/19 4:29 AM, Keith Pyle wrote:
On 06/18/19 02:16, Hans Verkuil wrote:
Hi Keith,
On 6/18/19 6:17 AM, Keith Pyle wrote:
We made the suggested change, compiled, installed, and rebooted. There was some
progress - test 2 (turning the HD-PVR off) no
tex.
There are also two other changes (suggested by Keith):
- msecs_to_jiffies(4000); (a NOP) should have been msleep(4000).
- Change v4l2_dbg to v4l2_info to always log if streaming had to be restarted.
Reported-by: Keith Pyle
Suggested-by: Keith Pyle
Signed-off-by: Hans Verkuil
This patch
On 06/18/19 02:16, Hans Verkuil wrote:
Hi Keith,
On 6/18/19 6:17 AM, Keith Pyle wrote:
We made the suggested change, compiled, installed, and rebooted. There was some
progress - test 2 (turning the HD-PVR off) no longer produces a splat. Test 1
(start capture) and test 3 (run capture
and
On 06/17/19 05:22, Hans Verkuil wrote:
On 6/15/19 10:06 PM, Keith Pyle wrote:
We have observed a hard mutex deadlock in the hdpvr driver on both 5.1.8
and 5.1.10. The problem occurs while reading from the HD-PVR device
and results in an unkillable user process. It is readily reproducible
We have observed a hard mutex deadlock in the hdpvr driver on both 5.1.8
and 5.1.10. The problem occurs while reading from the HD-PVR device
and results in an unkillable user process. It is readily reproducible.
The problem has been reproduced on two different systems and with two
different HD-
On 02/14/17 19:18, Jonathan Sims wrote:
> This is a code cleanup after recent changes introduced by commit
> a503ff812430e104f591287b512aa4e3a83f20b1.
>
> Signed-off-by: Jonathan Sims
> ---
>
> drivers/media/usb/hdpvr/hdpvr-video.c | 18 +++---
> 1 file changed, 7 insertions(+), 11 d
On 05/12/14 07:41, Hans Verkuil wrote:
Ryley, Keith, can you test this one more time and if it works reply with
a 'Tested-by' tag that I can add to the patch?
Thanks!
Hans
This issue was reported by Ryley Angus:
I record from my satellite set top box using component video and opti
rough my home network to client instances
of VLC. This works well, but obviously seeking isn't relevant.
ryley
-Original Message-
From: Keith Pyle [mailto:kp...@austin.rr.com]
Sent: Wednesday, April 09, 2014 12:28 AM
To: Ryley Angus; 'Hans Verkuil'; linux-media@vger.kernel
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 d
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 is
On 09/26/12 21:42, Keith Pyle wrote:
I recently purchased a Hauppauge HD-PVR (the 1212 version, label on
bottom 49001LF, Rev F2). I have consistent capture failures on Linux
where data from the device simply stops, generally within a few
minutes of starting a capture. Yet, the device works
On 10/13/12 14:17, David Röthlisberger wrote:
On Wed, 26 Sep 2012 21:42:32 -0500
Keith Pyle wrote:
I recently purchased a Hauppauge HD-PVR (the 1212 version, label on
bottom 49001LF, Rev F2). I have consistent capture failures on Linux
where data from the device simply stops, generally within
I recently purchased a Hauppauge HD-PVR (the 1212 version, label on
bottom 49001LF, Rev F2). I have consistent capture failures on Linux
where data from the device simply stops, generally within a few minutes
of starting a capture. Yet, the device works flawlessly on Windows with
the same USB
20 matches
Mail list logo
