<div class="gmail_quote">On Mon, Aug 29, 2011 at 11:34 AM, Tom Lichti <span dir="ltr"><<a href="mailto:redpepperracing@gmail.com">redpepperracing@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On Mon, Aug 29, 2011 at 11:26 AM, Jerry Rubinow <<a href="mailto:jerrymr@gmail.com">jerrymr@gmail.com</a>> wrote:<br>
> On Mon, Aug 29, 2011 at 8:43 AM, Andrew Stadt <<a href="mailto:acstadt@stadt.ca">acstadt@stadt.ca</a>> wrote:<br>
</div><div class="im">>> > -Jerry<br>
>> ><br>
>> An ugly gludge I used once for a PVR150 with audio issues simply<br>
>> involved spawning another script from inside the channel change script.<br>
>> The 2nd script would sleep for a couple secs, while myth did its post<br>
>> channel change processing, then reset the audio channel via v4l2-ctl.<br>
>> Might work here, YMMV.<br>
><br>
> That's an excellent kludge, thanks for the idea. I'll try that out tonight<br>
> and hopefully that'll last until I'm able to find older firmware or<br>
> otherwise figure out why this started happening.<br>
> Janne, Jarod, or anyone who's familiar with the driver, any ideas? Is there<br>
> a potential kernel incompatibility with the firmware? I wanted to save<br>
> doing a full system update as a last resort since things are otherwise<br>
> pretty stable.<br>
> -Jerry<br>
<br>
</div>I am using a similar kludge for my PVR-x50 cards, but I am using the<br>
System Events mechanism, so when a 'Recording Start' event occurs, I<br>
fire off a script to normalize the volume on the PVR cards.<br>
<br>
I might have the actual names wrong, but that's basically what I did.<br>
I can get better details later when I am home, if needed.</blockquote><div><br></div><div>Very nice, that's even better. No need for further details, I just looked it up and it should be easy. I'm not up on my myth features, obviously. Thanks.</div>
<div><br></div><div>-Jerry</div></div>