[mythtv-users] Unable to edit more than one channel at a time after channel scan

jr jraymyth at gmail.com
Sat Apr 24 22:21:35 UTC 2010


On Thu, Apr 22, 2010 at 1:20 AM, Michael T. Dean
<mtdean at thirdcontact.com> wrote:
> On 04/21/2010 11:31 PM, jr wrote:
>>
>> On Wed, Apr 21, 2010 at 10:49 PM, Michael T. Dean wrote:
>>
>>>
>>> On 04/21/2010 09:45 PM, jr wrote:
>>>
>>>>
>>>> Running 0.22 and 0.23 on two machines side by side. (Ubuntu 9.10; AMD
>>>> X4&    Intel Atom 230) Having the same issues on both.
>>>>
>>>> I have gone through the drills I have read about on these pages:
>>>>
>>>> 1) Set up tuner
>>>> 2) Set up Video Source
>>>> 3) Set up input connection
>>>>     a. Choose a source
>>>>     b. Scan for channels
>>>>         i. Accept the non-conflicting channels
>>>>         ii. manually assign arbitrary numbers to the conflicting
>>>> channels
>>>> 4) Leave mythtv-setup
>>>> 5) Run mythfilldatabase
>>>>
>>>>
>>>> At this point I have some channels that are filled in with the good
>>>> values (incl XMLTVID), and some with no XMTVID, so,
>>>>
>>>> 6) Start mythbackend
>>>> 7) Start mythfrontend
>>>> 8) Go to Watch TV and walk thru the channels
>>>>    a) Press E to EDIT
>>>>    b) identify the channel with my meat computer
>>>>    c) find the corresponding xmltvid in Schedules Direct
>>>>    d) enter the info
>>>>    e) advance to the next channel
>>>>
>>>> I can advance to the next channel, and the channel continues to play,
>>>> but mythfrontend will no longer respond to input.  I have to kill the
>>>> process, restart it, and edit the next channel.  Rinse. Repeat.
>>>>
>>>
>>> http://svn.mythtv.org/trac/ticket/7007
>>> http://svn.mythtv.org/trac/ticket/7767
>>> http://svn.mythtv.org/trac/ticket/8077
>>>
>>> We would appreciate your doing some testing to see if it only occurs with
>>> certain playback profile groups in use (see comments on #8077) and, if
>>> so,
>>> which ones.  If you find they have something in common, please try
>>> changing
>>> that something (such as deinterlacer) and see if you can figure out
>>> exactly
>>> what causes it.
>>>
>>> My guess: deinterlacer.
>>>
>>> No "me too's", please, though.  If you don't have any information on the
>>> cause or a suggested fix, no need to comment on the ticket.  Thanks.  :
>>>>
>>>> There has gotta be a better way.
>>>> Help?
>>>>
>>>
>>> Go to Live TV.  Do /not/ hit E.  Use a laptop or some other computer to
>>> bring up the MythWeb channel editor, and edit all the channel xmltvid's
>>> and
>>> submit in a single click..
>>>
>>> Of course, now that I've saved you a ton of time on editing your
>>> xmltvid's,
>>> you can repay me by using some of that saved time to do some testing, as
>>> above.  :
>>
>> good idea on the laptop thing.  I will try it.  As for payback, I am
>> in arrears, no doubt, to all of the myth devs.  I will be happy to do
>> some testing.  Though I will do so tomorrow night , if you do not
>> mind.  Its approaching midnight here.  Is there any particular logging
>> switch I should be sure to have on?
>>
>> Bonus data point: I found that it is not hitting E a second time that
>> causes the lock up, but hitting E after I have changed the channel.
>>
>
> Definitely don't need to do it tonight.  At least at this point, I don't
> think we really need logs as much as we need people who can reproduce the
> issue to flip switches to see what they can change to trigger/prevent the
> issue.  It most likely has something to do with either the chosen video or
> OSD renderer or (my guess) the chosen deinterlacer.
>
> I have a feeling that bobdeint, specifically, is causing it (and potentially
> other deinterlacers, such as the 2x ones).  And, since the playback profile
> group that's chosen by default (due to a bug in the settings UI code--code
> that's going to be thrown away, so isn't high on anyone's list to fix) is
> CPU+, and since CPU+ uses bobdeint, it's something that some people see when
> they first set up their systems.  However, since CPU+ playback profile group
> is one of the 3 worst possible choices for the playback profile group (along
> with the other 2 CPU<whatever> groups:  CPU++ and CPU--), others don't see
> the issue.

> Anyway, for the issue to get much attention, we need to at least be able to
> reproduce the issue.  Note, also, that it may just get "fixed" through code
> atrophy--the libmythui-osd branch is replacing the whole OSD, so if it's an
> OSD issue, it may get fixed when the old OSD is thrown out.
>
> Thanks, though, for helping with the testing.
>
> Mike
> _______________________________________________
> mythtv-users mailing list
> mythtv-users at mythtv.org
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
>

Foxconn Intel Atom 230 @1.6Ghz; GMA 950
Ubuntu 9.10, 2GB Memory,

Mike,

I ran the tests, but I fear that the results are not overly useful.
The first thing I did was to run against the default profiles (CPU+,
CPU++, CPU-, CPU--, Slim, Normal, and High Quality)  All seven froze
out the input when I hit E after advancing a channel in Watch TV.  So
I made a new profile for testing purposes with one entryl.  I then
iterated through the available Deinterlacers (None, Bob,  One Field,
Linear Blend, Kernel, Kernel(2x), Greedy High Motion, Yadif, and
Interlaced(2x), testing each one.

I am afraid that in each instance I was frozen out by MythFrontend.

I did vary the decoder between Standard and libmpeg2
I tried both softblend and chromakey for the OSD Renderer

I did not use the VDPAU profiles as I do not currently have that option
I did not vary the Video Renderers.  I left it on xv-blit.


More information about the mythtv-users mailing list