MythTV General Discussion and Support

I saw these on the EB Games website, $2 for a pre-owned one, but only available in store and I could only find a single store on the other side of the country that had stock.

 

I have picked some Sony PlayTV modules up from Gumtree, EBay and OCAU at reasonable prices.

 

PlayTV Tuners also work with TVHeadend and give two tuners per module.

I have TVHeadend setup on my Jellyfin.

 

I'm not a fan of TVHeadend. After my old MythTV backend died, I was running TVHeadend in a docker container but it would regularly stop recording programs, even though they were still in the recording schedules. I also tried NextPVR but ended up back at MythTV, but now running as a docker container.

 

I believe Mythtv to be the best.
Just a shame that Mythbuntu stopped as it was on the right track to make installing a lot more easier.
I first started using Mythtv back on Ubuntu 10.04.
Now using Ubuntu 16.04, 18.04 and 20.04 and all still working great.

 

These work so well I have six of these running in my MythTV setup.
(Had to manually recompile the kernel as it defaults to a max of 8 tuners)

If I happen to be going past an EB Games shop I will drop in to see if they have any pre-loved ones out the back. I like to always keep a couple of spares on hand.
Can usually get them for $10 or $15 each.

 

I've moved from MythTV to Jellyfin* a year or so ago now (probably closer to 2) which is much more media management/playing than just live TV recording, but it's live TV features are solid.


* it's much the same as Plex and Emby, but they don't try and extort money out of you for basic features (HW transcoding, recording, EPG etc.).

 

Wow.. it has been a long time since I bought one from EB Games!!

 

In my TV signal area there is only Five TV Signal Streams. Channel ID 35, 36, 37, 38 and 39.
I only use two PlayTV modules giving me Four TV Signal Streams I can record at once. Two of the streams I only record every now and then so I don't need Five.
For those that might not understand the TV Signal Streams. If you were to record a TV show on say Channel 8 (Nine Newcastle), 82 (9Gem Newcastle), 84 (9Life Newcastle) and 88 (9GO! Newcastle) all at the same time it would only use One TV Tuner for recording the four different TV shows. The TV Tuner splits out the different channels for recording.
If you look in "Mythweb / settings /channel info" you can see the channel ID (36) and Freq: 585.500 Mhz (Newcastle NSW Area) is the same for all these channels.
Yours would be relevant to your reception area.

 

The reason I have so many is that I hate shows running late and missing the end of it.
I have a default rule that every recording rule that is set up, records an additional 20 mins after the scheduled show is due to end.
Also, I have another rule that records anything in the Documentary genre regardless of the channel it is on.
Regardless of what is recording or how long recordings run over, there is never an issue whereby something doesn't record due to tuners cards not being available.

As per what Fleasidewinder said, Myth is pretty good at scheduling recordings off the same multiplex (i.e. 9 and 9Gem for example) if it can do so using only a single tuner (it essentially uses a virtual tuner for the second recording associated with the real, parent tuner card).
If it can't do this due to recording times not being identical for both programs on the same multiplex though, it simply grabs one of the other tuners to use for recording.

Sounds complex but the Myth scheduler looks after all this kind of housekeeping...

 

Hi all, for my MythTV frontend attached to a 4k TV, I have an NUC7i5BNH (i5 7260m@2.2GHz, 8Gb RAM, Iris Pro 640, 128Gb NVMe SSD). I've noticed that for some media I have, the playback is choppy to the point that it's unwatchable. I think that it's related to the bitrate of the media, for example, this file is fine (as reported by mediainfo):

• MKV file, HEVC, 3840x1608, video bitrate 5Mb/s (overall bitrate is 10.5Mb/s) (yep, CPU levels are about 120-150%, load of 1.5)

But this one is choppy:

• MVK file, HEVC, 3840x2160, video bitrate 27.2Mb/s (overall bitrate is 27.9Mb/s) (yep, CPU is 230% and load is about 2.7)

And anything encoded with H265 is always choppy.

Should my integrated Iris Pro 640 video be capable of playing this file, or should I be looking at getting a discreet card and building a new frontend?

Edit (more info): OK, playing a '1080' FTA recorded show (it may be broadcast in 1080, but the source material sure as shit ain't 1080!) gets the CPU going at 64% on OpenGL Normal but only 25% on VAAPI Normal, so it looks like the VA-API playback profile is working. The 4k TV desktop is running at 3840x2160 in the Ubuntu desktop.

More edits: Looks like this may be a smoking gun, this is the output of vainfo:

Code:

libva info: VA-API version 1.7.0
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/iHD_drv_video.so
libva info: Found init function __vaDriverInit_1_7
libva info: va_openDriver() returns 0
vainfo: VA-API version: 1.7 (libva 2.6.0)
vainfo: Driver version: Intel iHD driver for Intel(R) Gen Graphics - 20.1.1 ()
vainfo: Supported profile and entrypoints
      VAProfileMPEG2Simple            :   VAEntrypointVLD
      VAProfileMPEG2Main              :   VAEntrypointVLD
      VAProfileH264Main               :   VAEntrypointVLD
      VAProfileH264Main               :   VAEntrypointEncSliceLP
      VAProfileH264High               :   VAEntrypointVLD
      VAProfileH264High               :   VAEntrypointEncSliceLP
      VAProfileJPEGBaseline           :   VAEntrypointVLD
      VAProfileJPEGBaseline           :   VAEntrypointEncPicture
      VAProfileH264ConstrainedBaseline:   VAEntrypointVLD
      VAProfileH264ConstrainedBaseline:   VAEntrypointEncSliceLP
      VAProfileVP8Version0_3          :   VAEntrypointVLD
      VAProfileHEVCMain               :   VAEntrypointVLD
      VAProfileHEVCMain10             :   VAEntrypointVLD
      VAProfileVP9Profile0            :   VAEntrypointVLD
      VAProfileVP9Profile2            :   VAEntrypointVLD

Should there be a line in there with "...H265..." in it? Answer, 'no', there are lines in there with 'HVEC', which is H.265, hah!

I'm aware that I'm mixing up two problems here, one that the CPU load is too high for higher bitstreams, and that H.265 doesn't work.

I've now installed 'libde265-0', so we'll see how we go.

 

Drrt. Nope, no difference, oh well.

elvis, you used NUCs as 4k frontends, didn't you? Based on your experience, am I missing something/doing something wrong?? Thanks!

 

1) what sort of network connection does this machine have (wired ethernet, wifi, etc)?

2) What kernel are you running? ("uname -r" will tell you)

3) What does the following say about each bit of media:

ffprobe filename.mkv 2>&1 | grep Stream

My guess (until ffprobe info comes back) is that some of your media is yuv420 and some is yuv444 and your CPU/GPU can't decode the latter. Most hardware accelerated h265/hevc decode is limited to yuv420 currently.

HEVC = H265.

These two:

VAProfileHEVCMain : VAEntrypointVLD
VAProfileHEVCMain10 : VAEntrypointVLD

Say you can do HEVC/H265 8 and 10 bit, but again I'm guessing it's the yuv420/yuv444 issue (ffprobe output will confirm).

 

Same move to Jellyfin for media and use the smart TV built in browser as WebOS has no Kodi package available.

 

Thanks elvis!

Thanks, yeah, I figured that out, but forgot to update the OP, thanks...

1Gb wired

Code:

$ uname -a
Linux mythtvlounge20 5.8.0-41-generic #46~20.04.1-Ubuntu SMP Mon Jan 18 17:52:23 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

Ah, thanks! Here's the outputs:
First file:

• Stream #0:0: Video: hevc (Main 10), yuv420p10le(tv, bt2020nc/bt2020/smpte2084), 3840x1608 [SAR 1:1 DAR 160:67], 23.98 fps, 23.98 tbr, 1k tbn, 23.98 tbc (default)

Second file:

• Stream #0:0: Video: hevc (Main 10), yuv420p10le(tv, bt709), 3840x2160 [SAR 1:1 DAR 16:9], 23.98 fps, 23.98 tbr, 1k tbn, 23.98 tbc (default)

So both files are yuv420p10le, hooray! What's the 'bt709' part mean and how is that different to the 'bt2020n/bt2020/smpte2084' bit?

Apart from that, there's a difference in the resolution, is there anything else that's significantly different?

 

bt709/bt2020 is the colour space encoding. That won't affect performance (Rec.709 is older and "smaller" than Rec.2020, in fact).

https://en.wikipedia.org/wiki/Rec._709
https://en.wikipedia.org/wiki/Rec._2020

My initial guess wrong, which means the big difference is the bitrate. The highly compressed one is 5Mbit/s, and the less compressed one is around 30Mbit's. Neither of these should really kill a NUC I would think, and you've got wired 1000MBit/s so its not the network letting you down. Kernel 5.8 is nice and modern, so that's good for video drivers and DRM too.

All I can consider is that the bitrate is just too high, or perhaps the audio stream is too hefty (can you paste the audio component from ffprobe too?).

You can test the raw decode performance of your system with ffmpeg on the command line, like this:

ffmpeg -i filename.mkv -f null /dev/null

That will decode the file and "play" it to nowhere, measuring your FPS as it goes. If the decoded FPS is higher than the video FPS, that means you can decode realtime, and the problem is something else (GPU drivers maybe?).

 

OK! I got onto the frontend, finally, and mapped the shares with cifs, and used the ffmpeg command as above to play the file. The CPU usage of ffmpeg shoots up to 375%, and the fps reported by ffmpeg is about 38, so yeah, the video isn't being played successfully, boo.

I thought I'd just try playing that file in VLC, on the frontend. The file opens in VLC in a maximum size window, and ... is as smooth as silk!!! Checking VLC CPU usage, VLC is running at 23% CPU!

Here's the output of VLC from the command line:

Code:

VLC media player 3.0.9.2 Vetinari (revision 3.0.9.2-0-gd4c1aefe4d)
[00005640c5c0f5b0] main libvlc: Running vlc with the default interface. Use 'cvlc' to use vlc without interface.
[00005640c5cddc70] main audio output error: too low audio sample frequency (0)
[00007fe04cc9d5e0] main decoder error: failed to create audio output
[00005640c5cddc70] vlcpulse audio output error: digital pass-through stream connection failure: Not supported
[00005640c5cddc70] main audio output error: module not functional
[00007fe04cc9d5e0] main decoder error: failed to create audio output
libva info: VA-API version 1.7.0
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/iHD_drv_video.so
libva info: Found init function __vaDriverInit_1_7
libva info: va_openDriver() returns 0
[00007fe04ccf3350] avcodec decoder: Using Intel iHD driver for Intel(R) Gen Graphics - 20.1.1 () for hardware decoding
QObject::~QObject: Timers cannot be stopped from another thread

So... if VLC does play the file successfully, seems like the mythtv frontend isn't leveraging iHD_drv_video properly?!?!

I'll go run the frontend from the command line and see what is reported when I start playing this file in the frontend...

Alrighty, in the log file from the mythfrontend, with this command: $mythfrontend 2>&1 > playfile.log

Code:

2021-02-12 15:16:47.894985 I  OpenGLInterop: Rendering supported for frame type 'VAAPI' with VAAPI DRM
2021-02-12 15:16:47.895106 I  AFD: Using vaapi for video decoding
2021-02-12 15:16:47.895285 I  AFD: Opened codec 0x5634a0520c40, id(H265) type(Video)
2021-02-12 15:16:47.909728 I  AOBase: Opening audio device 'default' ch 6(6) sr 48000 sf 32 bit floating point reenc 0
2021-02-12 15:16:47.964077 I  OpenGLInterop: Rendering supported for frame type 'VAAPI' with VAAPI DRM
2021-02-12 15:16:48.006653 I  Clearing OpenGL painter cache.
2021-02-12 15:16:48.074243 I  VideoOutput: SetDeinterlacing (Doublerate 1): Single High|CPU|GLSL|DRIVER Double High|CPU|GLSL|DRIVER
2021-02-12 15:16:48.074569 I  TV::StartPlayer(): Created player.
2021-02-12 15:16:48.074604 I  TV::HandleStateChange(): Changing from None to WatchingVideo
2021-02-12 15:16:48.075554 I  Player(0): Queuing callback for VAAPI context creation
2021-02-12 15:16:48.077757 I  TV::HandleStateChange(): Main UI disabled.
2021-02-12 15:16:48.077787 I  TV::StartTV(): Entering main playback loop.
2021-02-12 15:16:48.082280 I  ScreenSaverDBus: Successfully inhibited screensaver via org.freedesktop.ScreenSaver. cookie 1451158123. nom nom
2021-02-12 15:16:48.082698 W  ScreenSaverDBus: Failed to disable screensaver: Type of message, “(ss)”, does not match expected type “(susu)”
2021-02-12 15:16:48.129664 I  ScreenSaverX11Private: DPMS Deactivated 1
2021-02-12 15:16:48.132938 I  Player(0): Executing VAAPI context creation
2021-02-12 15:16:48.132955 I  OpenGLInterop: Rendering supported for frame type 'VAAPI' with VAAPI DRM
2021-02-12 15:16:48.136447 I  VAAPIInterop: Created VAAPI 1.7 display for VAAPI DRM (Intel iHD driver for Intel(R) Gen Graphics - 20.1.1 ())
DRM_IOCTL_I915_GEM_CONTEXT_DESTROY failed: Bad file descriptor
2021-02-12 15:16:48.143809 E  AFD: video avcodec_send_packet error: Input/output error (-5) gotpicture:0
2021-02-12 15:16:48.148978 E  AFD: video avcodec_send_packet error: Input/output error (-5) gotpicture:0
2021-02-12 15:16:48.153617 E  AFD: video avcodec_send_packet error: Input/output error (-5) gotpicture:0
2021-02-12 15:16:48.159083 E  AFD: video avcodec_send_packet error: Input/output error (-5) gotpicture:0
2021-02-12 15:16:48.159333 E  AFD: video avcodec_send_packet error: Input/output error (-5) gotpicture:0
2021-02-12 15:16:48.159465 E  AFD: video avcodec_send_packet error: Input/output error (-5) gotpicture:0
2021-02-12 15:16:48.159601 E  AFD: video avcodec_send_packet error: Input/output error (-5) gotpicture:0
2021-02-12 15:16:48.159725 E  AFD: video avcodec_send_packet error: Input/output error (-5) gotpicture:0
....<lots of these messages clipped>
2021-02-12 15:16:48.177583 I  AFD: Opened codec 0x5634a0519e40, id(Unknown Codec ID) type(Subtitle)
2021-02-12 15:16:48.177590 I  AFD: Opened codec 0x5634a051d500, id(Unknown Codec ID) type(Subtitle)
2021-02-12 15:16:48.178170 I  Player(0): Queuing callback for Destroy OpenGL interop
2021-02-12 15:16:48.179690 I  Player(0): Executing Destroy OpenGL interop
2021-02-12 15:16:48.338013 I  AFD: Using ffmpeg for video decoding
2021-02-12 15:16:48.338226 I  AFD: Opened codec 0x7f813e7b6c80, id(H265) type(Video)
2021-02-12 15:16:48.343429 N  Player(0): Waited 206ms for video buffers AAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
2021-02-12 15:16:48.343553 I  VideoOutput: SetDeinterlacing (Doublerate 1): Single High|CPU|GLSL|DRIVER Double High|CPU|GLSL|DRIVER
2021-02-12 15:16:48.446208 N  Player(0): Waited 309ms for video buffers LLLLAAAAAAAAAAAAAAAAAAAAAAAAAA
2021-02-12 15:16:48.548973 N  Player(0): Waited 411ms for video buffers LLLLLLLLAAAAAAAAAAAAAAAAAAAAAA
2021-02-12 15:16:48.651282 N  Player(0): Waited 514ms for video buffers LALAALLLLLLAAAAAAAAAAAAAAAAAAA
2021-02-12 15:16:48.752847 N  Player(0): Waited 615ms for video buffers UAAAAALAAALLLAAAAAAAAAAAAAAAAA
2021-02-12 15:16:48.854639 N  Player(0): Waited 717ms for video buffers UAAAAAuAAALULLLAAAAAAAAAAAAAAA
2021-02-12 15:16:48.956452 N  Player(0): Waited 819ms for video buffers UAAAAAuAAAuULULLLAAAAAAAAAAAAA
2021-02-12 15:16:49.058239 N  Player(0): Waited 921ms for video buffers UAAAAAUAAAuUuUuLLLLAAAAAAAAAAA
2021-02-12 15:16:49.069165 W  GLVid: New frame format: None:None 3840x2160 (Tex: 2D) -> YUV420P10:YUV420P10 3840x2160 (Tex: 2D)
2021-02-12 15:16:50.074071 N  Player(0): Waited 100ms for video buffers AULLLLAAAAAAAAAAAAAAAUfAAuUuUu
2021-02-12 15:16:50.587081 N  Player(0): To see more buffering messages use -v playback
2021-02-12 15:16:59.216641 I  TV::HandleStateChange(): Attempting to change from WatchingVideo to None
2021-02-12 15:16:59.316801 W  Player(0): Waited 100ms for decoder to pause
2021-02-12 15:16:59.603262 I  TV::HandleStateChange(): Changing from WatchingVideo to None

I can also see in the terminal window (and it's not in the logfile, I'm sure it's some other output buffer I don't know how to redirect ), the same VA-API information as what was displayed when VLC played the file:

Code:

libva info: VA-API version 1.7.0
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/iHD_drv_video.so
libva info: Found init function __vaDriverInit_1_7
libva info: va_openDriver() returns 0
DRM_IOCTL_I915_GEM_CONTEXT_DESTROY failed: Bad file descriptor

There's also in the terminal window and earlier in the log file "Cannot load libcuda.so.1", I'm not sure if that is relevant. I can't find any information about this "DRM_IOCTL_I915..." message.

I've checked the how to on enabling VAAPI here: https://www.mythtv.org/wiki/VAAPI
It appears that the 'Painter' setting doesn't exist in the current version of MythTV, but the playback profile sure is set to 'VAAPI Normal'.
Some packages don't exist any more:

Code:

dpkg -l libva1 i965-va-driver libva-intel-vaapi-driver vainfo
dpkg-query: no packages found matching libva1
dpkg-query: no packages found matching libva-intel-vaapi-driver
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name                 Version        Architecture Description
+++-====================-==============-============-=====================================================
ii  i965-va-driver:amd64 2.4.0-0ubuntu1 amd64        VAAPI driver for Intel G45 & HD Graphics family
ii  vainfo               2.6.0+ds1-1    amd64        Video Acceleration (VA) API for Linux -- info program

Found this thread, which has the same error line (at least, the same capitalisation part): https://forum.mythtv.org/viewtopic.php?t=3544
But no solution

Elvis, any ideas?

 

Good tests.

OK, so that rules out a bunch of things I think. If VLC can play it locally then that's hardware, drivers and at least VLC's statically linked internal version of ffmpeg that all work.

Three ideas to try:

1) Force the output to be scaled to 1080p60:

https://www.mythtv.org/wiki/User_Manual:JudderFree

Force your playback resolution to be the same as your display resolution. This is definitely what VLC is doing, but perhaps MythTV is switching modes and causing some weird screen refresh to frame sync lockup? Worth a test at least.

2) Try a bleeding edge ffmpeg:

I was going to point to the Ubuntu ffmpeg ppa here, but they don't support newer than 18.04LTS. If you're comfortable with building from source, you can pull from git and build your own. If not, let me know, and I'll do a static build for you and upload it. You can plonk it in a separate directory and try it in parallel to your apt/dpkg installed version.

 

Thanks elvis - I realised that the VLC window was full screen, but the menu was being displayed and there were black bars either side of the video content, so I went back and ran "vlc -f source.mkv" and the content still played full screen buttery-smooth with ~20% CPU usage

In the MythTV frontend config, I set the 'Video Output' to 3840x2160 (same as the Ubuntu desktop resolution) but no joy, the video still jumps and skips.

Talking about ffmpeg versions made me think, what version is built into mythtv? Does the system ffmpeg/play binary work? So I played the content with mythffplay and ffplay and found that they both result in skipping and jumping video for this particular content, and they both send the CPU skyrocketing over 200%.
The installed version of ffplay and mythffplay are both 4.2.4-1ubuntu0.1, the configuration for ffplay does not have the --enable-vaapi switch, and the config for mythffplay does have the --enable-vaapi switch! (Running 'ffplay' and 'mythffplay' from the prompt and they both spit out the configuration line used to compile them.)

So the VAAPI stuff in VLC does work, I would expect ffplay to not work, but I would expect mythffplay to work! Rage!

I've gone back to basics, and changed the video playback method on the frontend to OpenGL, and checked the CPU level, and it's at 200% (for this content) for OpenGL as opposed to using VAAPI for frontend playback! Irrespective of the settings in the mythfrontend, if neither ffplay or mythffplay are using the VAAPI hardware, it doesn't matter what the settings in the mythfrontend are, right?

I don't think this is part of the problem, because VLC could play the video with VAAPI acceleration, but the permissions of the VAAPI device is:

Code:

~$ ll /dev/dri/
total 0
drwxr-xr-x   3 root root        100 Feb 15 11:58 ./
drwxr-xr-x  20 root root       4300 Feb 15 11:58 ../
drwxr-xr-x   2 root root         80 Feb 15 11:58 by-path/
crw-rw----+  1 root video  226,   0 Feb 15 12:59 card0
crw-rw----+  1 root render 226, 128 Feb 15 11:58 renderD128

I created a new video playback profile, and configured it like this:
Decoder: VAAPI Acceleration
Max CPUs: 4
Deblocking filter: enabled
Video Renderer: OpenGL Hardware
Deinterlacer quality (single rate): None
Deinterlacer quality (double rate): None
And... the content plays smoothly. The CPU runs about 140-300%, but the playback is now smooth! I'm sure it's all CPU based decoding, but it'll do for now.

I checked and the newer version of ffmpeg in groovy (4.3.1-4ubuntu1) hasn't been backported to focal-backports, oh well. If mythffplay doesn't seem to be accessing the VAAPI device successfully, will using a newer version (4.2.x -> 4.3.x) of myth/ffplay make a difference?

 

Even in fullscreen, VLC is changing it's output to match your screen.

MythTV can change the screen to match the output - i.e.: change desktop resolution and refresh rate (the latter especially being what I'm wondering about).

Can you confirm it's the same res and refresh? i.e.: MythTV is outputting at 60FPS, and not changing to 24/25/30/whatever? You'll need to verify via your TV I suspect (the info button on most TVs shows the mode and refresh rate).

But all the same, the "200% CPU" thing definitely suggests your "VAAPI/not-VAAPI" thing is on the money.

Any chance you can share this particular piece of media with me? I'd be interested to try it out on a bunch of different systems I have here and see if I can replicate your issue.