Mailing List Archive

On Sat, 12 Sep 2020 20:05:05 -0700, you wrote:

>I thought I had a thread about this already. Maybe it was buried in some
>other thread. If so I apologize that I can't find it. I am having two
>problems after a recent rebuild/upgrade with ubuntu 18.04/myth31, and I
>don't know if they are related.
>
>One is that the screen is going black at random times. So far this has not
>happened while I was actually watching a recording, but after the frontend
>has been idle for some time. Just now it did happen immediately after
>reboot and before frontend start, so it's not being caused by the frontend.
>When this happens there is no reviving it. From the frontend machine
>ctl-alt-f2 does nothing. I tried SSHing from another machine and
>restarting Gnome. No help. Reboot is the only option. It's not that the
>video output is completely going away altogether bc my monitor tells me
>know if there's no signal. Its just a black screen. This has been
>happening since I rebuilt the system but frequency has been increasing. I
>assume it's a problem with x-10 or the video drivers.

Have you ensured that all the sources of screen saving are turned off?
It does not actually sound like a screen saver, as that should just go
away on any keyboard input (or IR remote input). But it is worth
checking. Gnome has options somewhere for settings for xscreensaver,
but you can also just kill the xscreensaver process to test if it is
the problem. The other problem I have always had is DMPS, where X
blanks the screen. There is an option to disable DPMS in xorg.conf:

Section "Monitor"
Option "DPMS" "false"
EndSection

That does not always work - sometimes DPMS still seems to be enabled
somehow. If that happens to you, try these options that allow DMPS to
be enabled, but individually set all the timers that cause it to blank
the screen to disabled:

Section "ServerFlags"
Option "BlankTime" "0"
Option "StandbyTime" "0"
Option "SuspendTime" "0"
Option "OffTime" "0"
EndSection

To get those options to work, you may need to set the DPMS option to
"true".

>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.
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

Hi DryHeat122!

> One is that the screen is going black at random times. So far this has not
> happened while I was actually watching a recording, but after the frontend
> has been idle for some time. Just now it did happen immediately after
> reboot and before frontend start, so it's not being caused by the frontend.
> When this happens there is no reviving it. From the frontend machine
> ctl-alt-f2 does nothing. I tried SSHing from another machine and
> restarting Gnome. No help. Reboot is the only option. It's not that the
> video output is completely going away altogether bc my monitor tells me
> know if there's no signal. Its just a black screen. This has been
> happening since I rebuilt the system but frequency has been increasing.

I have been having a similar problem but is a random black flashing as
opposed yours staying black.  From what I have read on the web the
problem seems to be more with the grounding of the monitor/TV than an
issue with the signal source (the Frontend).  I haven't explored too
much as currently using a temporary Frontend because the permanent one
is awaiting a replacement CPU fan.

The temporary Frontend is a Raspberry Pi 4, which from what I have read
is double insulated.  Powered via a two-prong wall wart (no ground
pin).  The TV also has 'only' two prongs.  I don't know if the plug is
polarized or not.  (Here in the United States one outlet slot is 'hot'
and the other 'neutral'.)  From what I read it was suggested to reverse
the plug's orientation if not polarized, else ground the monitor (TV). 
At this time not testing as the original Frontend will be back in
service shortly and hopefully no more problem.

As for the flashing with the current RPi, I have found rebooting via the
GUI didn't solve the problem -- in fact made it worse! However rebooting
via Terminal solved (whew!).  Another day instead of rebooting I tried
making sure the various HDMI connections were tight and this fixed it. 
(At the TV in, RPi out, and a coupler because I was too lazy and just
connected the two cables together.)

So admittedly my answer is not really too informative but may give you
an idea of what to test.

Barry





_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

On Sun, Sep 13, 2020 at 1:56 PM DryHeat122 <dryheat122@gmail.com> wrote:

>
> On Sun, Sep 13, 2020 at 8:27 AM alain <alain@alain.homeunix.org> wrote:
>
>> Hi,
>>
>> I've had this problem on two different system in the past and currently
>> on my main mythfrontend.
>> Do ssh back to your computer and check the output of xrandr. In
>> particular, the display being used.
>> After blanking the screen, when restoring the display, on some
>> driver/hardware/software version, the X output is reconnected to the wrong
>> screen. If you have more than one interface on your graphic card, the odds
>> are that this is your problem.
>> You can verify by either connecting a display on the other port or by
>> using xrandr to switch to another screen.
>> I've written a script which monitors the output of xrandr and fixes the
>> problem when it detects the problem.
>>
>> Alain
>>
>
> For the black screen problem, when I tried from the SSH terminal xrandr
> returns "Can't open display"
>

I figured out the proper command is xrandr -d :0, which resulted in a
listing of two outputs (DVI-I-1 and VGA), and a whole bunch of size
options for the former. I rebooted and it booted to a black screen, again
and again. So I searched on the error and wound-up here
<https://www.stephenwagner.com/2019/05/05/ubuntu-linux-black-screen-frozen-system-after-upgrade-install/#:~:text=After%20upgrading%20a%20computer%20from,and%20the%20system%20becomes%20frozen.&text=This%20is%20due%20to%20a,system%20to%20halt%20or%20freeze.>.
I followed the advice about adding nomodeset to the grub config. Now it
will boot, but the resolution is 1280 x 1024 and the display app won't
allow setting to any other resolution. xrandr -d :0 returns:

xrandr: Failed to get size of gamma for output default
Screen 0: minimum 1280 x 1024, current 1280 x 1024, maximum 1280 x 1024
default connected primary 1280x1024+0+0 0mm x 0mm
1280x1024 77.00*

Whereas before it listed the monitor name "Samsung TV" and as I said a
whole bunch of possible resolutions and the DVI and VGA outputs on the
video card. I looked up this issue and somebody said to make sure you
don't have nomodeset in the grub config!

On Sun, 13 Sep 2020 14:47:39 -0700, you wrote:

>On Sun, Sep 13, 2020 at 1:56 PM DryHeat122 <dryheat122@gmail.com> wrote:
>
>>
>> On Sun, Sep 13, 2020 at 8:27 AM alain <alain@alain.homeunix.org> wrote:
>>
>>> Hi,
>>>
>>> I've had this problem on two different system in the past and currently
>>> on my main mythfrontend.
>>> Do ssh back to your computer and check the output of xrandr. In
>>> particular, the display being used.
>>> After blanking the screen, when restoring the display, on some
>>> driver/hardware/software version, the X output is reconnected to the wrong
>>> screen. If you have more than one interface on your graphic card, the odds
>>> are that this is your problem.
>>> You can verify by either connecting a display on the other port or by
>>> using xrandr to switch to another screen.
>>> I've written a script which monitors the output of xrandr and fixes the
>>> problem when it detects the problem.
>>>
>>> Alain
>>>
>>
>> For the black screen problem, when I tried from the SSH terminal xrandr
>> returns "Can't open display"
>>
>I figured out the proper command is xrandr -d :0, which resulted in a
>listing of two outputs (DVI-I-1 and VGA), and a whole bunch of size
>options for the former.

To get xrandr to work from ssh, there are two things needed. You need
to tell it which display (-d :0 as you discovered). But you also need
to run xrandr as the same user as the desktop is running under. So if
your ssh login does not match, you have to do something like:

sudo -u <desktop user> xrandr -d :0

>I rebooted and it booted to a black screen, again
>and again. So I searched on the error and wound-up here
><https://www.stephenwagner.com/2019/05/05/ubuntu-linux-black-screen-frozen-system-after-upgrade-install/#:~:text=After%20upgrading%20a%20computer%20from,and%20the%20system%20becomes%20frozen.&text=This%20is%20due%20to%20a,system%20to%20halt%20or%20freeze.>.
>I followed the advice about adding nomodeset to the grub config. Now it
>will boot, but the resolution is 1280 x 1024 and the display app won't
>allow setting to any other resolution. xrandr -d :0 returns:
>
>xrandr: Failed to get size of gamma for output default
>Screen 0: minimum 1280 x 1024, current 1280 x 1024, maximum 1280 x 1024
>default connected primary 1280x1024+0+0 0mm x 0mm
> 1280x1024 77.00*
>
>Whereas before it listed the monitor name "Samsung TV" and as I said a
>whole bunch of possible resolutions and the DVI and VGA outputs on the
>video card. I looked up this issue and somebody said to make sure you
>don't have nomodeset in the grub config!

I have never used nomodeset, but this seems to explain what it does:

https://askubuntu.com/questions/207175/what-does-nomodeset-do

That page is pretty old now, so things have likely changed since then.

So what all this implies is that you have graphics driver problems,
which I think you already know. Using nomodeset may get you to be
able to see a GUI screen, but it is not a long term solution as it is
likely that the kernel modesetting code is now used by all video
drivers and you will not get anything except the most basic
unaccellerated video modes without it. The mode that it is using is a
bit strange too. It is 77.0 Hz, which reads like a text mode rather
than a graphics one. I am guessing that it is the mode provided by
the VESA code in the BIOS that has the highest clock rate. I think
you are lucky that your screen actually supports that mode, as it
appears that using nomodeset means that the video drivers do not probe
the hardware at all to find out what might match.

What is the video card? What drivers are you using for it? Is there
a PPA you can install to get later drivers? Can you install an older
version of the graphics drivers and get it to work?

From the command line, the ubuntu-drivers command can be used to
select which video drivers are installed. As I have the Nvidia PPA
installed, I get a lot of options to choose from with my Nvidia GT1030
card:

root@mypvr:/etc/X11# ubuntu-drivers list
nvidia-driver-410
nvidia-driver-450
nvidia-driver-415
nvidia-driver-440-server
nvidia-driver-418-server
nvidia-driver-390
nvidia-driver-435
root@mypvr:/etc/X11# ubuntu-drivers devices
== /sys/devices/pci0000:00/0000:00:02.0/0000:01:00.0 ==
modalias : pci:v000010DEd00001D01sv00001043sd000085F4bc03sc00i00
vendor : NVIDIA Corporation
model : GP108 [GeForce GT 1030]
driver : nvidia-driver-415 - third-party free
driver : nvidia-driver-390 - distro non-free
driver : nvidia-driver-418-server - distro non-free
driver : nvidia-driver-450 - third-party free recommended
driver : nvidia-driver-435 - distro non-free
driver : nvidia-driver-440-server - distro non-free
driver : nvidia-driver-410 - third-party free
driver : xserver-xorg-video-nouveau - distro free builtin

If you have an Nvidia card, to update to the latest PPA versions, just
add the PPA:

https://launchpad.net/~graphics-drivers/+archive/ubuntu/ppa

sudo add-apt-repository ppa:graphics-drivers/ppa
sudo apt update

and then run:

sudo ubuntu-drivers install

You can also use apt install to select specific versions of the video
driver packages.

I am currently running the 450 drivers as they seem better than the
earlier ones (slightly less buggy). I have been getting video lockups
where the screen freezes but the rest of the system is still running
fine. Occasionally I was able to get Ctrl-Alt-Backspace to restart X
and recover from the freezes, but mostly I needed to wait until I was
not recording and then reboot as nothing else worked. I have not been
on the 450 series drivers long enough to know if they fix this as the
freezes were only once or twice a week and seemed to happen when a
screen mode change was done. Since I have now changed all my mode
setup to prevent the use of interlaced modes, that may also be
helping.
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

On Sun, 13 Sep 2020 at 04:06, DryHeat122 <dryheat122@gmail.com> wrote:
> 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?!?

I *think* there may be an issue in 0.31 with livetv and displaying
HD/4K video - just starting to join the dots between differing
comments and reports; and if there is an issue it seems to be
intermittent.

So when you say you went back and tried ESPN again and it was working
- do you mean from livetv? or from a show that was recorded.
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

On Sun, 13 Sep 2020 at 09:00, Stephen Worthington
<stephen_agent@jsw.gen.nz> wrote:
> 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.

This shouldn't happen. The display code filters out any modes that are
interlaced and should ignore them.

Can you post the output from 'mythfrontend -v playback
--loglevel=debug'. That should show (at startup) what modes are
available and what are being ignored.

Regards
Mark
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

On Tue, Sep 15, 2020, 3:26 AM Mark Kendall <mark.kendall@gmail.com> wrote:

> On Sun, 13 Sep 2020 at 09:00, Stephen Worthington
> <stephen_agent@jsw.gen.nz> wrote:
> > 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.
>
> This shouldn't happen. The display code filters out any modes that are
> interlaced and should ignore them.
>
> Can you post the output from 'mythfrontend -v playback
> --loglevel=debug'. That should show (at startup) what modes are
> available and what are being ignored.
>
> Regards
> Mark


Re previous question, it was when I came back to live tv. This happened
more than a week ago and I don't think I can find the relevant log
entries. If it happens again I will get the log entries and post.

TBH this could have also been caused by my driver problems, which I have
now (hopefully) fixed.

>

On Sun, Sep 13, 2020 at 7:43 PM Stephen Worthington <
stephen_agent@jsw.gen.nz> wrote:

> On Sun, 13 Sep 2020 14:47:39 -0700, you wrote:
>
> >On Sun, Sep 13, 2020 at 1:56 PM DryHeat122 <dryheat122@gmail.com> wrote:
> >
> >>
> >> On Sun, Sep 13, 2020 at 8:27 AM alain <alain@alain.homeunix.org> wrote:
> >>
> >>> Hi,
> >>>
> >>> I've had this problem on two different system in the past and currently
> >>> on my main mythfrontend.
> >>> Do ssh back to your computer and check the output of xrandr. In
> >>> particular, the display being used.
> >>> After blanking the screen, when restoring the display, on some
> >>> driver/hardware/software version, the X output is reconnected to the
> wrong
> >>> screen. If you have more than one interface on your graphic card, the
> odds
> >>> are that this is your problem.
> >>> You can verify by either connecting a display on the other port or by
> >>> using xrandr to switch to another screen.
> >>> I've written a script which monitors the output of xrandr and fixes the
> >>> problem when it detects the problem.
> >>>
> >>> Alain
> >>>
> >>
> >> For the black screen problem, when I tried from the SSH terminal xrandr
> >> returns "Can't open display"
> >>
> >I figured out the proper command is xrandr -d :0, which resulted in a
> >listing of two outputs (DVI-I-1 and VGA), and a whole bunch of size
> >options for the former.
>
> To get xrandr to work from ssh, there are two things needed. You need
> to tell it which display (-d :0 as you discovered). But you also need
> to run xrandr as the same user as the desktop is running under. So if
> your ssh login does not match, you have to do something like:
>
> sudo -u <desktop user> xrandr -d :0
>
> >I rebooted and it booted to a black screen, again
> >and again. So I searched on the error and wound-up here
> ><
> https://www.stephenwagner.com/2019/05/05/ubuntu-linux-black-screen-frozen-system-after-upgrade-install/#:~:text=After%20upgrading%20a%20computer%20from,and%20the%20system%20becomes%20frozen.&text=This%20is%20due%20to%20a,system%20to%20halt%20or%20freeze
> .>.
> >I followed the advice about adding nomodeset to the grub config. Now it
> >will boot, but the resolution is 1280 x 1024 and the display app won't
> >allow setting to any other resolution. xrandr -d :0 returns:
> >
> >xrandr: Failed to get size of gamma for output default
> >Screen 0: minimum 1280 x 1024, current 1280 x 1024, maximum 1280 x 1024
> >default connected primary 1280x1024+0+0 0mm x 0mm
> > 1280x1024 77.00*
> >
> >Whereas before it listed the monitor name "Samsung TV" and as I said a
> >whole bunch of possible resolutions and the DVI and VGA outputs on the
> >video card. I looked up this issue and somebody said to make sure you
> >don't have nomodeset in the grub config!
>
> I have never used nomodeset, but this seems to explain what it does:
>
> https://askubuntu.com/questions/207175/what-does-nomodeset-do
>
> That page is pretty old now, so things have likely changed since then.
>
> So what all this implies is that you have graphics driver problems,
> which I think you already know. Using nomodeset may get you to be
> able to see a GUI screen, but it is not a long term solution as it is
> likely that the kernel modesetting code is now used by all video
> drivers and you will not get anything except the most basic
> unaccellerated video modes without it. The mode that it is using is a
> bit strange too. It is 77.0 Hz, which reads like a text mode rather
> than a graphics one. I am guessing that it is the mode provided by
> the VESA code in the BIOS that has the highest clock rate. I think
> you are lucky that your screen actually supports that mode, as it
> appears that using nomodeset means that the video drivers do not probe
> the hardware at all to find out what might match.
>
> What is the video card? What drivers are you using for it? Is there
> a PPA you can install to get later drivers? Can you install an older
> version of the graphics drivers and get it to work?
>
> From the command line, the ubuntu-drivers command can be used to
> select which video drivers are installed. As I have the Nvidia PPA
> installed, I get a lot of options to choose from with my Nvidia GT1030
> card:
>
> root@mypvr:/etc/X11# ubuntu-drivers list
> nvidia-driver-410
> nvidia-driver-450
> nvidia-driver-415
> nvidia-driver-440-server
> nvidia-driver-418-server
> nvidia-driver-390
> nvidia-driver-435
> root@mypvr:/etc/X11# ubuntu-drivers devices
> == /sys/devices/pci0000:00/0000:00:02.0/0000:01:00.0 ==
> modalias : pci:v000010DEd00001D01sv00001043sd000085F4bc03sc00i00
> vendor : NVIDIA Corporation
> model : GP108 [GeForce GT 1030]
> driver : nvidia-driver-415 - third-party free
> driver : nvidia-driver-390 - distro non-free
> driver : nvidia-driver-418-server - distro non-free
> driver : nvidia-driver-450 - third-party free recommended
> driver : nvidia-driver-435 - distro non-free
> driver : nvidia-driver-440-server - distro non-free
> driver : nvidia-driver-410 - third-party free
> driver : xserver-xorg-video-nouveau - distro free builtin
>
> If you have an Nvidia card, to update to the latest PPA versions, just
> add the PPA:
>
> https://launchpad.net/~graphics-drivers/+archive/ubuntu/ppa
>
> sudo add-apt-repository ppa:graphics-drivers/ppa
> sudo apt update
>
> and then run:
>
> sudo ubuntu-drivers install
>
> You can also use apt install to select specific versions of the video
> driver packages.
>
> I am currently running the 450 drivers as they seem better than the
> earlier ones (slightly less buggy). I have been getting video lockups
> where the screen freezes but the rest of the system is still running
> fine. Occasionally I was able to get Ctrl-Alt-Backspace to restart X
> and recover from the freezes, but mostly I needed to wait until I was
> not recording and then reboot as nothing else worked. I have not been
> on the 450 series drivers long enough to know if they fix this as the
> freezes were only once or twice a week and seemed to happen when a
> screen mode change was done. Since I have now changed all my mode
> setup to prevent the use of interlaced modes, that may also be
> helping.
>


My drivers are as follows:

steve@steve-EP45-UD3P:~$ ubuntu-drivers devices
== /sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0 ==
modalias : pci:v000010DEd000006E4sv00003842sd0000C725bc03sc00i00
vendor : NVIDIA Corporation
model : G98 [GeForce 8400 GS Rev. 2]
driver : nvidia-340 - distro non-free recommended
driver : xserver-xorg-video-nouveau - distro free builtin

I updated the nvidia drivers, something was definitely installed, and the
same driver is shown. I got rid of the nomodeset argument to grub. Now it
boots to the normal screen at the normal resolution. Going back to an
earlier recommendation of yours, I check the X11 conf file and it had DMPS
set to false already. So I set it to true and added the section setting
the timings to zero. So far, I've not had the black screen problem again.

On Tue, 15 Sep 2020 at 20:57, DryHeat122 <dryheat122@gmail.com> wrote:
> Re previous question, it was when I came back to live tv. This happened more than a week ago and I don't think I can find the relevant log entries. If it happens again I will get the log entries and post.
>
> TBH this could have also been caused by my driver problems, which I have now (hopefully) fixed.

If it does happen again - please shout:)

Thanks and regards
Mark
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

On Sun, Sep 13, 2020 at 12:59 AM Stephen Worthington <
stephen_agent@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.

On Sat, Oct 17, 2020 at 5:33 PM DryHeat122 <dryheat122@gmail.com> wrote:

> On Sun, Sep 13, 2020 at 12:59 AM Stephen Worthington <
> stephen_agent@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

-Greg

On Sat, Oct 17, 2020, 3:53 PM Greg Oliver <oliver.greg@gmail.com> wrote:

> On Sat, Oct 17, 2020 at 5:33 PM DryHeat122 <dryheat122@gmail.com> wrote:
>
>> On Sun, Sep 13, 2020 at 12:59 AM Stephen Worthington <
>> stephen_agent@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.

>

On Sat, Oct 17, 2020 at 7:27 PM DryHeat122 <dryheat122@gmail.com> wrote:

>
> 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.
>
>>
> Out of sheer curiosity, which model SSD? Does it have DRAM Cache, or no?
Cacheless drives can have rather sporadic write delays, which might cause
stuttering for realtime content. It's something to consider.

Mike

On Sat, 17 Oct 2020 15:31:20 -0700, you wrote:

>Maybe there are no modes because I don't have ModeDebug set as suggested,
>but I'm not sure how to do that.

To turn on ModeDebug, you just add this to your /etc/X11/xorg.conf
file:

Section "Screen"
Option "ModeDebug" "true"
EndSection

If there is already a "Screen" section, just put:

Option "ModeDebug" "true"

in that section.

About the stuttering, I agree with Greg Oliver - the first thing to
try is to just pause live TV for a few seconds to allow the buffers to
fill. This has been a very longstanding problem - MythTV does not
correctly calculate and adjust how much data needs to be buffered to
play a particular combination of video and audio streams for a
channel. The streams are made up of packets of video and audio data
and when playing a video packet, the audio packet that matches that
video packet needs to be already available in the buffers. If it is
not, then the playback stops until it becomes available. The packets
are normally sent with a small delay between when the matching video
and audio packets arrive. Since they are sent in the same stream of
data with packets from other channels, the packets for all the
channels are interleaved with each other. Even if the matching audio
packet starts immediately after the video packet, it still will take a
short time to be received. If there are packets for other channels in
between the video and audio packet (and there often are), the delay to
receive the audio packet will be a lot longer. The delay can also be
a bit variable as it depends on the size of the packets, which can
change a bit if something is happening on another channel. As can the
number of packets, if, for example, a new channel starts up on the
multiplex while you are watching a different channel. When playing a
recording, the problems are much less - the recording file only has
the streams for the one channel stored in it, and MythTV gets the
buffering calculation right or adjusts the delay in the first second
or so of playback so that it becomes right.

Note that this description is a bit simplified - for example, I can
not remember if it is valid for the audio packets to be arriving
before the video packets, or not.

Also, you should check your mythfrontend.log file to see if it is
giving you any audio prealloc warning messages:

grep -a prealloc /var/log/mythtv/mythfrontend.log

If that finds any messages, do what they say to adjust the audio
prealloc buffer setting.
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

On 18 October 2020 02:26:53 BST, DryHeat122 <dryheat122@gmail.com> wrote:
>On Sat, Oct 17, 2020, 3:53 PM Greg Oliver <oliver.greg@gmail.com>
>wrote:
>
>> On Sat, Oct 17, 2020 at 5:33 PM DryHeat122 <dryheat122@gmail.com>
>wrote:
>>
>>> On Sun, Sep 13, 2020 at 12:59 AM Stephen Worthington <
>>> stephen_agent@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.
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

On Sat, Oct 17, 2020 at 6:42 PM Mike Hodson <mystica@gmail.com> wrote:
[snip]


> Out of sheer curiosity, which model SSD? Does it have DRAM Cache, or no?
> Cacheless drives can have rather sporadic write delays, which might cause
> stuttering for realtime content. It's something to consider.
>
> Mike
>

It is a Crucial BX500 and apparently it does not have a dram cache.

On Sun, Oct 18, 2020, 11:33 AM DryHeat122 <dryheat122@gmail.com> wrote:

>
>
> On Sat, Oct 17, 2020 at 6:42 PM Mike Hodson <mystica@gmail.com> wrote:
> [snip]
>
>
>> Out of sheer curiosity, which model SSD? Does it have DRAM Cache, or no?
>> Cacheless drives can have rather sporadic write delays, which might cause
>> stuttering for realtime content. It's something to consider.
>>
>> Mike
>>
>
> It is a Crucial BX500 and apparently it does not have a dram cache.
>

Also, pausing playback indeed fixed the stuttering.

I wonder why Myth doesn't just delay start of playback until the buffer is
full. Seems like that should be a straightforward thing to do. Yet you
guys say this has been a problem for some time.

>
>