[mythtv-users] Display weirdness

Paul Gardiner lists at glidos.net
Sun Oct 18 07:49:57 UTC 2020



On 18 October 2020 02:26:53 BST, DryHeat122 <dryheat122 at gmail.com> wrote:
>On Sat, Oct 17, 2020, 3:53 PM Greg Oliver <oliver.greg at gmail.com>
>wrote:
>
>> On Sat, Oct 17, 2020 at 5:33 PM DryHeat122 <dryheat122 at gmail.com>
>wrote:
>>
>>> On Sun, Sep 13, 2020 at 12:59 AM Stephen Worthington <
>>> stephen_agent at jsw.gen.nz> wrote:
>>>
>>>> On Sat, 12 Sep 2020 20:05:05 -0700, you wrote:
>>>>
>>>> [snip]
>>>
>>>
>>>
>>>> >Today a new problem cropped up.  From the program guide I started
>ESPN
>>>> HD
>>>> >from the "watch this channel" menu item to watch Lakers v Rockets.
>>>> HDPVR2
>>>> >started fine but the picture was shrunk to about half the size of
>the
>>>> >monitor. Esc and try again, same result.  Rebooted, and same
>result.  I
>>>> >noticed when it was starting from the program guide it showed the
>ESPN
>>>> HD
>>>> >icon, but another tv icon with SD below it.  So  somebody thinks
>they're
>>>> >getting a SD signal. You can get HD video off component video
>outputs of
>>>> >the HDPVR2, right?  Here's the kicker.  After watching the game on
>>>> another
>>>> >system, I went back and tried ESPN again on the Myth box as above.
>Now I
>>>> >still get the TV/SD idon on startup but the picture is full
>screen.
>>>> WTF?!?
>>>>
>>>> There can be a number of things that can cause this, including
>bugs.
>>>> But the things to look at are how you have the config set up for
>>>> playing video.  There are options that allow the video playback to
>>>> change the video mode separately from the GUI screens - see Setup >
>>>> Appearance > Separate modes for GUI and playback.  If that is set,
>>>> then whenever you are playing video, the content of the video is
>>>> matched against your playback profiles and the settings for the
>>>> matching profile are applied.  This can also cause xrandr commands
>to
>>>> be sent to the X display to get the display to change mode to a
>mode
>>>> that matches the video that is being played.  Such mode changes can
>>>> happen if the video being played changes mode in the middle (eg
>sport
>>>> is 720p, but it changes to 1080i for the ad breaks).  The available
>>>> mode changes are the modes that X lists in its Xorg.0.log file when
>it
>>>> starts up.  You can get a problem that there are modes available
>that
>>>> are not actually what you want for your screen.  So if the
>recording
>>>> is 576p, for example, the matching mode may be only for displaying
>on
>>>> 1/4 of the screen, when it should be set up to reprocess the frames
>to
>>>> a 1080 screen size.  I have just been fighting a slightly different
>>>> version of this problem where I do not want any interlaced modes
>used
>>>> as when there is onscreen GUI overlaying video output, the GUI part
>of
>>>> the display gets distorted by the interlacing.  The solution I am
>>>> currently trying for this is to tell X not to use the EDID sourced
>>>> modelines (and lots of other modeline sources) and just to use the
>>>> modelines I have specified in my xorg.conf file.  I turned on this
>>>> option:
>>>>
>>>> Section "Screen"
>>>>   Option    "ModeDebug" "true"
>>>> EndSection
>>>>
>>>> so that X logs details of all the modes it sees and edited the
>output
>>>> of that to create the modelines I wanted, then disabled all the
>other
>>>> modes.  Along the way, I had some modes from other sources still
>>>> enabled that caused exactly what you are seeing where the video
>only
>>>> used part of the screen.  After turning off those modes, it now
>seems
>>>> to be working well, but it has only been a few days so far and I
>need
>>>> to test it on various video files to be sure.
>>>>
>>>> You can find out what mode your screen currently is in by opening a
>>>> terminal and using xrandr.  I hate xrandr - it is difficult to use
>and
>>>> does not actually allow you to see the modes in the way they are
>>>> reported in X's logs, but the required information is there.  So
>when
>>>> you next have this problem, make sure you have the ModeDebug option
>on
>>>> first, then run "xrandr" and see which mode has the * character by
>it,
>>>> telling you that is the current mode.  Then match that to the modes
>>>> reported in the X logs, and see if there is a problem.  You may
>need
>>>> to disable that mode so a better one gets chosen, or you may need
>to
>>>> use an xorg.conf option to set scaling for that mode so it will
>fill
>>>> the full screen.  Your TV may also have a menu or remote key that
>will
>>>> get it to display information about its current screen mode.
>>>>
>>>> BTW You have not said what video card you are using.  I am using an
>>>> Nvidia GT1030, so things may work differently if you are using
>Intel
>>>> or AMD.
>>>>
>>>
>>> Found some time to get back to this issue.   All the problems with
>screen
>>> sizing were resolved when I updated my Nvidia drivers (video card
>>> is Geforce 8400 GS Rev. 2).  Now the issue is jankey/stuttering
>video/audio
>>> when watching live TV.   It's odd because if I record these same
>channels
>>> then play the recording everything is fine.  The only problem is
>when I'm
>>> trying to watch live.
>>>
>>> I am still getting the SD symbol when I "watch this channel" on HD
>>> channels where I encounter the stuttering.  Maybe it's occurring
>because
>>> the system is trying to down-sample the HD to SD and the processor
>can't
>>> keep up?
>>>
>>> I think this advice pertained to the screen size issue, but just in
>case
>>> I checked setup and  "Separate modes for GUI and playback" is not
>enabled.
>>> I also had a look at  Xorg.0.log for modes listed, and there don't
>seem to
>>> be any except auto-select.  Here is the output of  cat Xorg.0.log |
>grep
>>> mode:
>>>
>>> [     7.808] (==) Matched modesetting as autoconfigured driver 2
>>> [     7.828] (II) LoadModule: "modesetting"
>>> [     7.828] (II) Loading
>/usr/lib/xorg/modules/drivers/modesetting_drv.so
>>> [     7.829] (II) Module modesetting: vendor="X.Org Foundation"
>>> [     7.832] (II) modesetting: Driver for Modesetting Kernel
>Drivers: kms
>>> [     7.841] (WW) Falling back to old probe method for modesetting
>>> [     8.331] (==) NVIDIA(0): No modes were requested; the default
>mode
>>> "nvidia-auto-select"
>>> [     8.331] (==) NVIDIA(0):     will be used as the requested mode.
>>> [     8.368] (II) UnloadModule: "modesetting"
>>> [     8.368] (II) Unloading modesetting
>>> [     8.375] (II) NVIDIA(0): Setting mode "DFP-0:nvidia-auto-select"
>>> [     8.550] (**) Option "xkb_model" "pc105"
>>> [     8.553] (**) Option "xkb_model" "pc105"
>>> [     8.571] (**) Option "xkb_model" "pc105"
>>>
>>>
>>> Maybe there are no modes because I don't have ModeDebug set as
>suggested,
>>> but I'm not sure how to do that.
>>>
>>
>> MythTV has long had live TV issues with stutttering, etc.  Just a
>shot in
>> the dark - have you started live TV and immediately pressed back
>(left
>> arrow) to see if it stops?
>>
>> Just making sure you have not tried this already - a lot of
>improvement
>> was made by Peter Bennett a while back, but it still plays best when
>you
>> let it (I'll call it, for simplicity) fill the buffers.
>>
>> If you have tried this, then please, disregard.
>>
>> -Greg
>>
>
>Have not tried that, but will.  So you mean start watching a channel,
>then
>back it up a few times?
>
>The odd thing is I never had this problem with 0.28 and 31 is running
>on
>same hardware, except I now have SSDs which are faster storage. Only
>other
>change was from hdpvr to hdpvr-2.

I've also seen stuttering with 31 that I didn't see in 29, but pausing for a moment fixes it for me.


More information about the mythtv-users mailing list