From patchwork Tue Apr 8 03:32:12 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Ryley Angus X-Patchwork-Id: 23462 X-Patchwork-Delegate: hverkuil@xs4all.nl Received: from mail.tu-berlin.de ([130.149.7.33]) by www.linuxtv.org with esmtp (Exim 4.72) (envelope-from ) id 1WXMlz-0003Sf-4M; Tue, 08 Apr 2014 05:32:31 +0200 X-tubIT-Incoming-IP: 209.132.180.67 Received: from vger.kernel.org ([209.132.180.67]) by mail.tu-berlin.de (exim-4.72/mailfrontend-6) with esmtp id 1WXMlw-0001m8-5O; Tue, 08 Apr 2014 05:32:31 +0200 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755308AbaDHDcZ (ORCPT + 1 other); Mon, 7 Apr 2014 23:32:25 -0400 Received: from mail-ee0-f43.google.com ([74.125.83.43]:38357 "EHLO mail-ee0-f43.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754665AbaDHDcX (ORCPT ); Mon, 7 Apr 2014 23:32:23 -0400 Received: by mail-ee0-f43.google.com with SMTP id e53so145823eek.2 for ; Mon, 07 Apr 2014 20:32:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:thread-index :content-language; bh=cqhcfBiLDefqAyV2nIvG6kiT7N3o99uBOZRB2oJHnSU=; b=pRy2QorNxYI7OsQnpFpgweTrbzRJrFzT5974GV9YIn5FZPIiZIS9ZIvdLXwapVolAX zcm8JlksYq08C2FVFUkpEPC2Z+SA9S587oDr3Ncf3qwURCD9CKHvKG5zVvLUbffft2gl HUjAT8gn0x2kS0wsFv8FSa25PXC3Em5j6ZxVvDlPXVcpgt/1rQi/Je6yhUKbc2vfCkTF eiw8ofEuQxkFJNySS9Yz0NkgiyX/dgy4pSa7GUvoB8+Xxu2uvNwu+DYUC2Umlvwc0DyU mNC2dEoqWxD3xAxNpsVcFs2Tu1oDiM17CzX/KrPaDED2t0R5K2QFmSHAohj0vnyLP+hl lGnQ== X-Received: by 10.15.32.206 with SMTP id a54mr1193966eev.51.1396927942725; Mon, 07 Apr 2014 20:32:22 -0700 (PDT) Received: from RYLEYANGUS (58-6-238-170.dyn.iinet.net.au. [58.6.238.170]) by mx.google.com with ESMTPSA id g3sm1598606eet.35.2014.04.07.20.32.19 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 07 Apr 2014 20:32:21 -0700 (PDT) From: "Ryley Angus" To: "'Hans Verkuil'" , References: <5342B115.2070909@xs4all.nl> In-Reply-To: <5342B115.2070909@xs4all.nl> Subject: RE: [RFC] Fix interrupted recording with Hauppauge HD-PVR Date: Tue, 8 Apr 2014 13:32:12 +1000 Message-ID: <007a01cf52db$253a7fe0$6faf7fa0$@gmail.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQMuAYyogaKSZUdSzvJhZDf0kE416QEqeTzomEBd7dA= Content-Language: en-us X-Antivirus: avast! (VPS 140407-0, 04/07/2014), Outbound message X-Antivirus-Status: Clean Sender: linux-media-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-media@vger.kernel.org X-PMX-Version: 6.0.0.2142326, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.4.8.32419 X-PMX-Spam: Gauge=IIIIIIII, Probability=8%, Report=' FORGED_FROM_GMAIL 0.1, HTML_00_01 0.05, HTML_00_10 0.05, BODY_SIZE_6000_6999 0, BODY_SIZE_7000_LESS 0, DKIM_SIGNATURE 0, FORGED_MUA_OUTLOOK 0, URI_ENDS_IN_HTML 0, __ANY_URI 0, __BOUNCE_CHALLENGE_SUBJ 0, __BOUNCE_NDR_SUBJ_EXEMPT 0, __CP_MEDIA_BODY 0, __CP_URI_IN_BODY 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __FORWARDED_MSG 0, __FRAUD_BADTHINGS 0, __FRAUD_WEBMAIL 0, __FRAUD_WEBMAIL_FROM 0, __FROM_GMAIL 0, __HAS_FROM 0, __HAS_MSGID 0, __HAS_X_MAILER 0, __HAS_X_MAILING_LIST 0, __IN_REP_TO 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __OUTLOOK_MUA 0, __OUTLOOK_MUA_1 0, __PHISH_SPEAR_STRUCTURE_1 0, __SANE_MSGID 0, __SUBJ_ALPHA_END 0, __SUBJ_ALPHA_NEGATE 0, __SXL_RIP_ERROR_SERVFAIL , __SXL_SIG_ERROR_SERVFAIL , __SXL_URI_ERROR_SERVFAIL , __TO_MALFORMED_2 0, __URI_NS , __USER_AGENT_MS_GENERIC 0, __YOUTUBE_RCVD 0' 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 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 -- 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 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) {