[mythtv-users] Video card update fail
Stephen Worthington
stephen_agent at jsw.gen.nz
Thu Oct 11 16:55:18 UTC 2018
On Thu, 11 Oct 2018 08:17:35 -0700, you wrote:
>On Wed, Oct 10, 2018 at 8:00 PM Stephen Worthington <
>stephen_agent at jsw.gen.nz> wrote:
>
>> On Wed, 10 Oct 2018 15:23:17 -0700, you wrote:
>>
>> >On Wed, Oct 10, 2018 at 2:57 PM Greg Oliver <oliver.greg at gmail.com>
>> wrote:
>> >
>> >> On Wed, Oct 10, 2018 at 4:32 PM Allen Edwards <
>> allen.p.edwards at gmail.com>
>> >> wrote:
>> >>
>> >>>
>> >>>
>> >>> On Wed, Oct 10, 2018 at 2:12 PM Mark Perkins <perkins1724 at hotmail.com>
>> >>> wrote:
>> >>>
>> >>>>
>> >>>>
>> >>>> On 11 October 2018 6:53:56 am Allen Edwards <
>> allen.p.edwards at gmail.com>
>> >>>> wrote:
>> >>>>
>> >>>>> My reply was too long with the log that Mark requested so it didn't
>> get
>> >>>>> posted. See end for comments without the log in THIS color.
>> >>>>>
>> >>>>>
>> >>> Here is the log <http://l-36.com/mythtv.txt>. I tried Steven's patch
>> >>> for the rtc and it didn't work. Not sure how important that is as I do
>> not
>> >>> see the audio video sync issues in the log.
>>
>> What does this command show:
>>
>> ls -al /dev/rt*
>>
>> This is what I get with my udev rule working:
>>
>> root at mypvr:~# ls -al /dev/rt*
>> lrwxrwxrwx 1 root root 4 Oct 8 04:30 /dev/rtc -> rtc0
>> crw-rw---- 1 root mythtv 249, 0 Oct 8 04:30 /dev/rtc0
>>
>
>I had root as the group. Changed it to mythtv. I must have implemented
>only half your instructions.
>I no longer see the "Could not open /dev/rtc:" error
>
>dad at NewMyth:~$ ls -al /dev/rt*
>lrwxrwxrwx 1 root root 4 Oct 10 13:21 /dev/rtc -> rtc0
>crw-rw---- 1 root mythtv 251, 0 Oct 10 13:21 /dev/rtc0
>
>The new log file is here: http://L-36.com/mythtv2.txt
>I do still see an error on RTC
>VSYNC: RTCVideoSync: Could not set RTC frequency:
>eno: Permission denied (13)
This is not a fatal problem, and there is probably some way around it.
But I am not sure what to do next. In the mean time, you will be
using a less good timing source for mythfrontend, and that may
possibly cause some timing artifacts, such as jerkiness, but would not
cause the blocky artifacts you are really having problems with. So I
think we just ignore it for now.
>I am still seeing artifacts, horizontal blocks. I am unsure if they are in
>the source or in the playback. That will take some more careful checking.
>But they are somewhere and we did not see that with Mythbunty 8 and the
>6200. Of course, I can't prove that but I am pretty sure I would have
>noticed them and they would have upset me sometime in the last 10 years.
You can check if the files are the problem by using other video
players, such as mplayer or VLC. The ultimate test is to export the
file to a known good PC (running Windows?) and play it there.
>> >>> I did notice a block of color in the playback and there was nothing in
>> >>> the log at the time. This was just a few minutes ago and not the
>> session
>> >>> in the log. I also noticed using VLC on my desktop that it is in the
>> >>> source file so not a Myth playback problem. That means it is either
>> 1) in
>> >>> the transmission 2) A receive error due to low signal strength, bad HD
>> >>> Homnerun channel, etc, 3) a problem in the backend.
>
>> >>> I don't know if I can put photos in this list so here is a link to a
>> >>> screen photo. http://L-36.com/mythtv.jpg
>> >>>
>> >>> For now I will see if these latest changes make "Wife Happy" again.
>> >>>
>> >>> Allen
The blocky artifact in the above screen photo is typical of a short
bit of missing data in the file. There are endless reasons for this
happening, starting with a real signal problem as received by the
aerial, and working through from there, with aerial cable problems,
tuner hardware problems, power supply problems, tuner cable problems,
USB driver problems, tuner driver problems, network congestion
problems, ... But not usually problems with mythbackend itself.
However, one problem that seems to creep up on people and is not so
obvious is that when your hard drive is overloaded, mythbackend only
has short buffers for writing to disk and when they overflow, data
will be lost. Typically, with a modern hard disk, that will happen
when you are doing three or more accesses on the same disk at the same
time and the heads have to move too far between the accesses, so they
arrive too late to do a write for mythbackend. So how many hard
drives do you have to record to, and how many recordings do you have
going to each one at any one time? And are you recording to your
system drive, which can get extremely busy when it is doing a database
backup or database maintenance?
I recommend adding the "-v record" option to the mythbackend command
line to get it to do extra logging about the recording process. Then
running this command after a recording completes:
grep -a "overall_score=\"0" /var/log/mythtv/mythbackend.log
That will display the recording quality log messages that mythbackend
will create, but only the ones where the quality was less that 1.0, in
other words, the recordings where there were problems that mythbackend
detected. Here is an example of a recording of mine that had a
problem a couple of days ago:
Oct 10 11:54:00 mypvr mythbackend: mythbackend[2756]: I TVRecEvent
tv_rec.cpp:863 (FinishedRecording) TVRec[92]:
FinishedRecording(10208_2018-10-09T21:59:00Z) damaged
recq:<RecordingQuality overall_score="0"
key="10208_2018-10-09T21:59:00Z" countinuity_error_count="7"
packet_count="4865468">#012 <Gap start="2018-10-09T22:09:37Z"
end="2018-10-09T22:50:00Z" duration="2422" />#012</RecordingQuality>
It had 7 continuity errors. I think that means that mythbackend did
not see the timestamps in the streams increasing properly - they
jumped 7 times. And then the recording just stopped happening -
nothing more was recorded for 2422 seconds, from when that problem
happened until the scheduled end of the recording. I know what causes
this - the minisatip software I use for my satellite tuners has a bug
that happens when too many recordings are happening at once. What you
are more likely to see is just short gaps happening in the range of
1-10 seconds. What gets recorded as a 1 second gap can be quite a bit
shorter, as mythbackend seems to only use an integer to store the gap
size. A "1" second gap is what the screen capture you posted shows -
just a short bit of missing data. In the screen shot, the missing
data was in the video stream, but it can be in the audio stream or
both audio and video, depending on when it happened.
>> >>>
>> >>
>> >> I cannot remember (I think Mythbuntu 14) what version you said you were
>> >> running on things, but I would make sure you are not using Wayland, but
>> >> Xorg instead and use an older video driver (step down until you get
>> desired
>> >> results) if that does not fix it. I have no idea if Mythbuntu tracks
>> >> Ubuntu version numbering, so unsure if Wayland is even there or not. I
>> >> would not recommend using Wayland with 3rd party (non-kernel included)
>> >> drivers - especially nVidia. I do not use Wayland for more important
>> >> reasons to me, but it is worth a shot.
>> >>
>> >>
>> >I am running Mythbuntu 16. If I said 14, it was an error. I am not sure
>> >what Wayland is but I am running X11 so perhaps not Wayland.
>>
>> I do not think Wayland is in Mythbuntu 16.x. That happened in 17.10.
>>
>> >I will see what my wife thinks about the latest changes. I am now running
>> >VDPAU Normal successfully. There are some video issues but at least the
>> >one I saw was not in playback.
>> >
>> >I would still need to get audio to both the HiFi (SPDIF) and the TV
>> >(analog). Right now I can do one or the other. The only thing I can
>> think
>> >of trying is to remove Pulse Audio which might have been installed by my
>> >son as part of troubleshooting.
>>
>> Have you tried enabling both outputs in alsamixer and then selecting
>> ALSA:default as the output in mythfrontend? That is what works for me
>> to get analogue and SPDIF at the same time.
>>
>
>I tried it again just to make sure. All I get is the SPDIF output with ALSA
>default.
>What I find really strange is that I need to set Myth to the nvidia
>settings to get analog.
>Here are the settings after I did the test this morning. Not what I set
>but should have worked.
>http://L-36.com/mythtv2.jpg
>
>The ALSA behavior is consistent with the fact that YouTube only plays over
>SPDIF in spite of the alsamixer settings.
>It is also strange that something changes my alsamixer settings but master
>and front are still unmuted so it should work
That screen shot shows an obvious reason for the analogue output not
working - the "line" output is muted. The "line out" (lime green RCA
socket on your motherboard) is your main analogue output and usually
carries the front left and front right speaker outputs.
>>
>> >On a related topic, I can't seem to find which tuner was used to record a
>> >program. I could swear that I could see that on the old Mythvuntu 8
>> system.
>>
>> If you go to a recording and hit the I key twice (info on the remote)
>> the "Recording Input:" line shows you that. Depending on your theme,
>> you may need to scroll down to see it.
>>
>
>Just to be clear, I have two HD Home Runs and that translates to 8 tuners,
>two per physical tuner. The information on which tuner was used for the
>recording was not in the "I-I" information.
The information on which tuner a recording was done on was only added
to the database in a recent MythTV version. Try doing I-I on a new
recording and it should show the tuner data. You may need to set the
"displayname" field in the database for the tuner - that is what gets
stored for each recording. I am not sure how you set the
"displayname" from mythtv-setup, as I just did it using SQL directly
into the capturecard.displayname field in the database.
>
>>
>> >Also, the timer display on programs is gone. I probably need to start
>> >different threads for these different problems if I can't find solutions
>> >with Google.
>>
>> What do you mean by "timer display"? Are you talking about the
>> progress bar across the bottom of the screen when you are playing a
>> recording and hit the I key once?
>>
>> Yes, the progress bar. It is gone suddenly.
>http://L-36.com/mythtv3.jpg
I have never seen that before, but I have had things disappear when
the theme was badly mismatched to the display. But you can see all of
the surround for the progress bar, so I can not see any reason for it
to disappear. I think this is one of those problems that may simply
go away if we can fix your bigger problems.
>> I am still looking at your mythfrontend log file, but there are a
>> couple of obvious things so far. Your desktop size is showing as:
>
>
>> Desktop video mode: 2560x1024 60.000 Hz
>>
>> which is a rather strange size. Here is what mine shows:
>>
>> Desktop video mode: 1920x1080 59.939 Hz
>>
>> which matches my TV screen size.
>>
>> I also have:
>>
>> UI Screen Resolution: 1920 x 1080
>>
>> where you have:
>>
>> UI Screen Resolution: 1280 x 720
>>
>> So what sort of screen are you using? What is its native size and
>> frequency and what other output modes can it handle? And what theme
>> are you using?
>>
>> Generally, things work better when the output you are sending to the
>> screen matches the physical screen size. TVs and monitors can handle
>> output of a different size to the screen, but they may have to
>> re-render it to do so, which can cause artifacts. US TVs are
>> typically quite limited in the number of modes they support, where in
>> other parts of the world they support many different modes for various
>> NTSC and PAL screen sizes and frequencies.
>>
>> From a terminal session opened on the X display, try running this
>> command:
>>
>> xrandr
>>
>> It should show all the video modes that are available for your display
>> and video card/driver combination. Here is what mine shows:
>>
>> root at mypvr:~# xrandr
>> Screen 0: minimum 8 x 8, current 1920 x 1080, maximum 8192 x 8192
>> DVI-I-0 disconnected (normal left inverted right x axis y axis)
>> VGA-0 disconnected (normal left inverted right x axis y axis)
>> DVI-I-1 connected primary 1920x1080+0+0 (normal left inverted right x
>> axis y axis) 1600mm x 900mm
>> 1920x1080 60.00 + 59.94* 50.00 23.97 60.05 60.00
>> 50.04
>> 1280x1024 60.02
>> 1280x720 60.00 59.94 50.00
>> 1024x768 60.00
>> 800x600 60.32
>> 720x576 50.00 50.08
>> 720x480 59.94 60.05
>> 640x480 59.94 59.93
>> HDMI-0 disconnected (normal left inverted right x axis y axis)
>>
>> I have an Nvidia 220 card and an old Sony Bravia KDL-32V5500 TV. It
>> native display is 1920x1080 and 50 Hz, but it supports most other
>> TV/video frequencies, as you can see on the 1920x1080 line above.
>>
>
>VGA-0 connected 1280x1024+0+0 (normal left inverted right x axis y axis)
>338mm x 270mm
> 1280x1024 60.02*+ 75.02
> 1024x768 75.03 70.07 60.00
> 800x600 75.00 72.19 60.32 56.25
> 640x480 75.00 72.81 59.95 59.94
>DVI-D-0 connected primary 1280x720+1280+0 (normal left inverted right x
>axis y axis) 1600mm x 900mm
> 1920x1080 60.00 + 59.94 23.98 60.05 60.00
> 1440x480 60.05
> 1280x1024 60.02
> 1280x720 60.00* 59.94
> 1024x768 60.00
> 800x600 60.32
> 720x480 59.94
> 640x480 59.94 59.93
>HDMI-0 disconnected (normal left inverted right x axis y axis)
>I do not know where the 2560x1024 comes from.
>
>I have two displays. One is a projector and one a Sony TV. The projector
>is 1024x720 and as the HDTV OTA source is generally that resolution, I just
>set things up for that. I have a DVI splitter so the signal goes to both
>the TV and the projector at the same time. I have not tried to get that to
>work and the sound must be digital for that to be useful so I am a ways
>from that. Right now I have disconnected the splitter because the TV was
>reporting invalid signals with it inline. I assume it would work now that I
>have the resolution locked to a valid value.
>
>Allen
What xrandr is showing is that you have one 1280x1024 display
connected to your analogue VGA connector (the DSUB one) and one
display connected to your DVI-D connector. The VGA display does not
look like a TV - it appears to be a computer monitor.
The DVI-D display looks like a typical US style TV (it only does 60 Hz
and the "film" frequency of 23.98 Hz). It is a bad idea to have a TV
configured to 1280x720 mode - you really need to make it 1920x1080.
With an Nvidia card, you should be able to run each device with
different screen sizes with no problems. However, mythfrontend may be
switching to 1920x1080 where necessary to play back recordings - to
find out, start playing a 1920x1080 recording or video file, then
Alt-Tab to a command prompt and run xrandr again while it is playing.
There is mythfrontend configuration for making it switch to match the
video file it is playing from, but you may not have that configured
yet:
https://www.mythtv.org/wiki/User_Manual:JudderFree
If you have set that up, then you can have your GUI screen size
different to your video screen size. Without that setup, it can cause
problems - the Nvidia card will have to squeeze the 1920x1080 picture
down to 1280x720 (which it is perfectly capable of), and then the TV
will expand it up again to 1920x1080 (which it is also perfectly
capable of). But the picture will lose quality through that process
and may display artifacts.
If you want to add your projector as well, I do not think a DVI
splitter is the way to go. I would put the TV on the HDMI port and
the projector on the DVI-D port. That will allow each screen to be
correctly set up for its individual needs. Then you can switch
mythfrontend between them using command line options to tell it which
X display to use. The mythfrontend command line options can be seen
by using the command "mythfrontend --help". You can set up menu items
or desktop icons with different mythfrontend command lines, or you can
have a script that you run that alters the mythfrontend command line
that is normally used.
You can buy an HDMI to DVI converter if you need to use an existing
DVI cable to the TV or projector - they are fairly cheap and work well
(but will not do audio).
More information about the mythtv-users
mailing list