[mythtv] Re: [mythtv-commits] Re: Ticket #594: MPEG-4 recording
broken as on [7721]
Kevin Kuphal
kuphal at dls.net
Sat Nov 5 18:13:20 EST 2005
Bruce Markey wrote:
> MythTV wrote:
>
>> #594: MPEG-4 recording broken as on [7721]
>> --------------------------------+-------------------------------------------
>>
>> Reporter: bjm <bjm at lvcm.com> | Owner: danielk
>> Type: defect | Status: new Priority:
>> critical | Milestone: Component:
>> mythtv | Version: head Severity:
>> high | Resolution:
>> --------------------------------+-------------------------------------------
>>
>> Comment (by kkuphal):
>>
>> I can confirm this. After updating to SVN last night all my MPEG-4
>> recordings are exhibiting this behavior. Time to set my PVR-150 to
>> high
>> priority I guess...
>
>
> You can just reverse this patch as it doesn't have any dependencies:
> http://cvs.mythtv.org/trac/changeset/7721?format=diff
>
> This sort of "update" doesn't need to take up space in the bug
> database =).
>
> BTW, input preference is almost like a bool, either the inputs are
> equal or they are not. There could a situation where an odd channel
> priority could out score an input preference but other than that,
> anything more than +1 or -1 wouldn't make any difference.
You're right. After I added that I simply did as you suggested and
backed out the change. Recordings look good again. I have 2 WinTV in
my master and 1 PVR-150 in a slave. I've been meaning to make the
PVR-150 the highest input preference because it generates the best
looking recordings and then when I have 1 recording, the PVR goes (no
load), with 2, the PVR and 1 WinTV go (half load on backend) and only
when I have 3 going do I reach full load on the backend machine. I
up-ed the pref and my upcoming recordings work out that way. I left the
two WinTV cards with 0 preference as they then seem to simply be used in
numeric order as expected.
Kevin
--
Looking for affordable webhosting? http://www.sitecity.net
More information about the mythtv-dev
mailing list