Mailing List Archive

render2019 comments
I briefly tried current render2019 789dda6 with Fedora29 x86_64 nvidia
GT_710 430.40, but have gone back to master.

Primary reason is that mythcommflag --rebuild and mythpreviewgen both
'Failed to initialise VAAPI connection' and quit. My cutting script
uses these.

Also panning shots in 1080p DVB-T2 recordings are as seen through jelly,
worse than in master. DLNA does it best (although subtitle sync seems
broken there). But I didn't try much fine-tuning.

HTH

John P

_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: render2019 comments [ In reply to ]
As requested in the IRC, a quick test of the render-2019, now from the
other side of the Channel.

Test on my development system: Intel i7-7700, only built-in Intel
graphics (no Nvidia card).
Software: Fedora 30 with LXDE desktop.
Mythfrontend graphics setting: (Setup / Video / Playback / Current
Video Playback Profile) VAAPI2 Normal
Mythfrontend plays in a 1280x720 window on a 1900x1200 desktop.
Content is 50Hz but monitor is 60Hz.
This is for me the usual setting.

Build: no problem.

Mythfrontend startup error message:
[AVHWDeviceContext @ 0x1422d00] Failed to initialise VAAPI connection:
-1 (unknown libva error).
Cannot load libcuda.so.1

Playback of recordings:
MPEG2 SD, i50 OK
H264 1080i50, playback OK but jump back/forward shows one frame
out-of-order about 0.5 second after the start
HEVC 1080p50 image not correct when panning, top of screen seems to
lag and judder; bottom looks ok.
Short time of blocking artefacts when jumping back and forth.

Video playback profile changed to OpenGL High Quality
MPEG2 SD, i50 OK and jumping back and forth now much faster than with
the previous profile.
H264 1080i50 OK, no out-of-order frames. Noticed also some lag/judder
at top of screen.
HEVC 1080p50 image not correct when panning, top of screen seems to
lag and judder; bottom looks ok.
Short time of blocking artefacts when jumping back and forth.

Both profiles show interlacing artefacts (or lack of de-interlacing).

Create new profile
-> ffmpeg & opengl
Change maxcpu from 1 to 4
Change deinterlacer quality (single rate) from None to High quality
Change deinterlacer quality (double rate) from None to High quality
Same for:
-> ffmpeg & opengl-yv12
Everything else left default.
Result (on all 3 content types): Interlacing is OK, other issues still present.

Also: some tearing near the top but this is also present (although
much less) in the master.

About the GUI.
Below the "Deinterlacer quality (single rate)" option are two lines
"Prefer OpenGL deinterlacers" and "Prefer driver deinterlacers".
These two lines are skipped over when "None" is the desired quality.
This makes sense after a few moments but initially it surprised me.
It would be great if it was possible to grey-out the not-applicable
options, as was recommended in the OSF-Motif style guide of the
previous century.
N.B. I do not know how to do that or if it is even possible in the
MythTV GUI. If I knew I would also use that in mythtv-setup.

Hope that this is what was requested,

Klaas.
_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: render2019 comments [ In reply to ]
Thanks for the feedback John - comments below.

On Sun, 29 Sep 2019 at 12:56, John Pilkington <johnpilk222@gmail.com> wrote:
>
> I briefly tried current render2019 789dda6 with Fedora29 x86_64 nvidia
> GT_710 430.40, but have gone back to master.
>
> Primary reason is that mythcommflag --rebuild and mythpreviewgen both
> 'Failed to initialise VAAPI connection' and quit. My cutting script
> uses these.

OK - there are a couple of static hardware decoder checks at startup
(VDPAU, VAAPI, NVDEC) that need to be cleaned up when either running
headless or without a GUI. They'll be fixed in the next few days.

> Also panning shots in 1080p DVB-T2 recordings are as seen through jelly,
> worse than in master. DLNA does it best (although subtitle sync seems
> broken there). But I didn't try much fine-tuning.

I'm pretty certain that you will be using software decoding as the
decoder/renderer selection has changed in the video display profile
settings screen. For example there is no longer a VDPAU renderer - it
just uses opengl (the renderer selection should show opengl-hw).
Without explicitly setting them to something new you will probably get
software decode - and hence performance will be poor? (not sure what
CPU you have)

I'm assuming there is nothing special about those recordings? (Do you
have a 60 second sample?) Otherwise some -v playback logs would be
informative.

Thanks again and regards,
Mark
_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: render2019 comments [ In reply to ]
On Sun, 29 Sep 2019 at 20:51, Klaas de Waal <klaas.de.waal@gmail.com> wrote:
>
> As requested in the IRC, a quick test of the render-2019, now from the
> other side of the Channel.

Thanks Klass

> Test on my development system: Intel i7-7700, only built-in Intel
> graphics (no Nvidia card).

Is that a Kabylake processor? If so, the new VAAPI code has not been
tested with Kabylake. It may be fine but I have come across
differences with older chipsets (tested on Sandybridge, Ironlake and
Coffeelake).

> Software: Fedora 30 with LXDE desktop.
> Mythfrontend graphics setting: (Setup / Video / Playback / Current
> Video Playback Profile) VAAPI2 Normal
> Mythfrontend plays in a 1280x720 window on a 1900x1200 desktop.
> Content is 50Hz but monitor is 60Hz.
> This is for me the usual setting.
>
> Build: no problem.

Is VAAPI enabled?

> Mythfrontend startup error message:
> [AVHWDeviceContext @ 0x1422d00] Failed to initialise VAAPI connection:
> -1 (unknown libva error).
> Cannot load libcuda.so.1

As noted to John - there are some static checks that need cleaning up
but in your case they should just be informative - not sure why the
VAAPI check would fail if VAAPI is enabled though.

> Playback of recordings:
> MPEG2 SD, i50 OK
> H264 1080i50, playback OK but jump back/forward shows one frame
> out-of-order about 0.5 second after the start
> HEVC 1080p50 image not correct when panning, top of screen seems to
> lag and judder; bottom looks ok.
> Short time of blocking artefacts when jumping back and forth.
>
> Video playback profile changed to OpenGL High Quality
> MPEG2 SD, i50 OK and jumping back and forth now much faster than with
> the previous profile.
> H264 1080i50 OK, no out-of-order frames. Noticed also some lag/judder
> at top of screen.
> HEVC 1080p50 image not correct when panning, top of screen seems to
> lag and judder; bottom looks ok.
> Short time of blocking artefacts when jumping back and forth.
>
> Both profiles show interlacing artefacts (or lack of de-interlacing).

Again, you probably need to make sure your display profiles are set to
something reasonable for the new code - otherwise you will get
software decode and no deinterlacing.

The partial lag/judder at the top of the screen sounds like a classic
OpenGL sync to vblank issue - afaik sync to vblank should be enabled
by default on intel open source drivers - have you made any changes to
your desktop setup?

> Create new profile
> -> ffmpeg & opengl
> Change maxcpu from 1 to 4
> Change deinterlacer quality (single rate) from None to High quality
> Change deinterlacer quality (double rate) from None to High quality
> Same for:
> -> ffmpeg & opengl-yv12
> Everything else left default.
> Result (on all 3 content types): Interlacing is OK, other issues still present.
>
> Also: some tearing near the top but this is also present (although
> much less) in the master.

If you have tearing in master and the branch - you definitely have a
vsync issue.

A quick google gave me this:-

https://askubuntu.com/questions/240923/enable-sync-to-vblank-on-lxde-with-intel-video-card

Otherwise try forcing sync to vbank from the command line (intel/amd
driver environment variable) :

vblank_mode=1 mythfrontend -v playback

> About the GUI.
> Below the "Deinterlacer quality (single rate)" option are two lines
> "Prefer OpenGL deinterlacers" and "Prefer driver deinterlacers".
> These two lines are skipped over when "None" is the desired quality.
> This makes sense after a few moments but initially it surprised me.
> It would be great if it was possible to grey-out the not-applicable
> options, as was recommended in the OSF-Motif style guide of the
> previous century.
> N.B. I do not know how to do that or if it is even possible in the
> MythTV GUI. If I knew I would also use that in mythtv-setup.

I was expecting that feedback at some point:)

I didn't want to make the extra preferences another screen as it makes
the setup much more complicated and requires a lot more code.

There are 2 'states' that I found in the code for the checkboxes -
enabled and visible. The visible state doesn't seem to have been
designed for this purpose - as setting visible to true again does not
show the setting.

So I settled on enabled for now - and as you note, there is no code
(as far as I can see) to change the presentation state when the
setting is disabled. Like you, I was hoping it would grayed out (or
something similar).

Anyone familiar with the settings UI code have any ideas/suggestions?

> Hope that this is what was requested,

Absolutely!

Thanks
Mark
_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: render2019 comments [ In reply to ]
On 30/09/2019 07:55, Mark Kendall wrote:
> Thanks for the feedback John - comments below.
>
> On Sun, 29 Sep 2019 at 12:56, John Pilkington <johnpilk222@gmail.com> wrote:
>>
>> I briefly tried current render2019 789dda6 with Fedora29 x86_64 nvidia
>> GT_710 430.40, but have gone back to master.
>>
>> Primary reason is that mythcommflag --rebuild and mythpreviewgen both
>> 'Failed to initialise VAAPI connection' and quit. My cutting script
>> uses these.
>
> OK - there are a couple of static hardware decoder checks at startup
> (VDPAU, VAAPI, NVDEC) that need to be cleaned up when either running
> headless or without a GUI. They'll be fixed in the next few days.
>
>> Also panning shots in 1080p DVB-T2 recordings are as seen through jelly,
>> worse than in master. DLNA does it best (although subtitle sync seems
>> broken there). But I didn't try much fine-tuning.
>
> I'm pretty certain that you will be using software decoding as the
> decoder/renderer selection has changed in the video display profile
> settings screen. For example there is no longer a VDPAU renderer - it
> just uses opengl (the renderer selection should show opengl-hw).
> Without explicitly setting them to something new you will probably get
> software decode - and hence performance will be poor? (not sure what
> CPU you have)
>
> I'm assuming there is nothing special about those recordings? (Do you
> have a 60 second sample?) Otherwise some -v playback logs would be
> informative.
>
> Thanks again and regards,
> Mark

Thanks Mark: This is a 2.8 GHz Core2Duo system, so no VAAPI. IIRC the
cpu loads were around 40%, while VDPAU usually gives perhaps 15%. Clip
link below. I should be able to reinstall if more tests would help.

https://drive.google.com/open?id=1SSxabQJVYN-PRirSF_5zPwEd2FYeaoWp

John



_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: render2019 comments [ In reply to ]
On Mon, 30 Sep 2019 at 09:38, John Pilkington <johnpilk222@gmail.com> wrote:

> Thanks Mark: This is a 2.8 GHz Core2Duo system, so no VAAPI. IIRC the
> cpu loads were around 40%, while VDPAU usually gives perhaps 15%. Clip
> link below. I should be able to reinstall if more tests would help.
>
> https://drive.google.com/open?id=1SSxabQJVYN-PRirSF_5zPwEd2FYeaoWp

John,

Thanks for the clip. It plays fine here with both VDPAU and software
decode (and VAAPI and NVDEC).

The only potential issue (though not entirely relevant to this
discussion) is that the stream is marked as interlaced but looks to be
progressive. It is hard to tell though as there is not a lot of quick
movement to look out for. The stream is H264 MBAFF - which is a form
of interlacing that no open source players handle very well.
Deinterlacing should only be done at a macroblock level but we have no
visibility of that (though the VDPAU deinterlacers may cope with it -
hard to know).

I'm fixing the vaapi/vdpau checks/crashes for mythcommflag etc.

Thanks and regards
Mark
_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: render2019 comments [ In reply to ]
On 30/09/2019 10:38, Mark Kendall wrote:
> On Mon, 30 Sep 2019 at 09:38, John Pilkington <johnpilk222@gmail.com> wrote:
>
>> Thanks Mark: This is a 2.8 GHz Core2Duo system, so no VAAPI. IIRC the
>> cpu loads were around 40%, while VDPAU usually gives perhaps 15%. Clip
>> link below. I should be able to reinstall if more tests would help.
>>
>> https://drive.google.com/open?id=1SSxabQJVYN-PRirSF_5zPwEd2FYeaoWp
>
> John,
>
> Thanks for the clip. It plays fine here with both VDPAU and software
> decode (and VAAPI and NVDEC).
>
> The only potential issue (though not entirely relevant to this
> discussion) is that the stream is marked as interlaced but looks to be
> progressive. It is hard to tell though as there is not a lot of quick
> movement to look out for. The stream is H264 MBAFF - which is a form
> of interlacing that no open source players handle very well.
> Deinterlacing should only be done at a macroblock level but we have no
> visibility of that (though the VDPAU deinterlacers may cope with it -
> hard to know).
>
> I'm fixing the vaapi/vdpau checks/crashes for mythcommflag etc.
>
> Thanks and regards
> Mark

OK, two builds later and I'm on 04a2952975b. mythcommflag --rebuild
still complains about vaapi, but it works, and I can cut recordings.
Panning is still shuddery, but I think less than it was, and isn't
distressing. My recent DVB-T2 recordings of BBC Proms have the channel
ident as 1080p and the content is interlaced; the change is handled
smoothly.

The menu/playback/playback_data display is showing ffmpeg decoding for
all H.264 and MPEG-2. I have 'NVDEC Normal' selected and it is shown as
being supported in the frontend startup and on this page (in the
'complete list' section, GeForce GT 710) so I'm not sure what to
believe. I'm not using AVSync2 because ISTR it used to have problems
with DVB-T Radio; I haven't investigated that recently.

https://developer.nvidia.com/video-encode-decode-gpu-support-matrix

Anyway it's looking good and I plan to live with it.

Cheers,

John



_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: render2019 comments [ In reply to ]
Test update after rebuilding just now:

2019-09-30 15:53:20.346755 C mythfrontend version: devel/2019-render
[v31-Pre-1033-g04a2952975] www.mythtv.org

>
> > Test on my development system: Intel i7-7700, only built-in Intel
> > graphics (no Nvidia card).
>
> Is that a Kabylake processor? If so, the new VAAPI code has not been
> tested with Kabylake. It may be fine but I have come across
> differences with older chipsets (tested on Sandybridge, Ironlake and
> Coffeelake).

Yes this is a Kaby Lake according to the Intel website
https://ark.intel.com/content/www/us/en/ark/products/97128/intel-core-i7-7700-processor-8m-cache-up-to-4-20-ghz.html

>
> > Software: Fedora 30 with LXDE desktop.
> > Mythfrontend graphics setting: (Setup / Video / Playback / Current
> > Video Playback Profile) VAAPI2 Normal
> > Mythfrontend plays in a 1280x720 window on a 1900x1200 desktop.
> > Content is 50Hz but monitor is 60Hz.
> > This is for me the usual setting.
> >
> > Build: no problem.
>
> Is VAAPI enabled?

This is what the ./configure says:
# Video Output Support
x11 support yes
xnvctrl support yes (system)
xrandr support yes
VDPAU support yes
VAAPI support yes
NVDEC support yes
Video4Linux codecs yes
MMAL decoder support no
OpenGL support yes
OpenGL video yes
OpenGL ThemePainter yes
MHEG support yes
libass subtitle support yes

>
> > Mythfrontend startup error message:
> > [AVHWDeviceContext @ 0x1422d00] Failed to initialise VAAPI connection:
> > -1 (unknown libva error).
> > Cannot load libcuda.so.1
>
> As noted to John - there are some static checks that need cleaning up
> but in your case they should just be informative - not sure why the
> VAAPI check would fail if VAAPI is enabled though.
>
The message is still present.

> > Playback of recordings:
> > H264 1080i50, playback OK but jump back/forward shows one frame
> > out-of-order about 0.5 second after the start
This is present with playback profile 'VAAPI2 Normal' but NOT with
'VAAPI Normal'.
Jumping back and forth with playback profile 'VAAPI2 Normal' gives the
following messages:

2019-09-30 16:02:55.154076 I Player(7): Waiting for video buffers...
2019-09-30 16:02:55.169912 N GetNextFreeFrame() served a busy frame
A. Dropping. UL(au)UuALAuLUuuuuLLL
2019-09-30 16:02:55.179095 N GetNextFreeFrame() served a busy frame
C. Dropping. UL(au)UuLuLULUuUuuLLu
2019-09-30 16:02:55.179114 N GetNextFreeFrame() served a busy frame
C. Dropping. ULuUuLuLULUuUuuLLu
2019-09-30 16:02:55.504087 I Player(7): Video is 3.07792 frames ahead of audio,

>
> If you have tearing in master and the branch - you definitely have a
> vsync issue.
>
> A quick google gave me this:-
>
> https://askubuntu.com/questions/240923/enable-sync-to-vblank-on-lxde-with-intel-video-card
>
> Otherwise try forcing sync to vbank from the command line (intel/amd
> driver environment variable) :
>
> vblank_mode=1 mythfrontend -v playback
>
The 'vblank_mode=1' did not make any difference, the first one will be
tested after the next reboot.
Agree that this has probably nothing to do with your changes.

Thanks,
Klaas.
_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: render2019 comments [ In reply to ]
On 30/09/2019 19:29, John Pilkington wrote:

> The menu/playback/playback_data display is showing ffmpeg decoding for
> all H.264 and MPEG-2.  I have 'NVDEC Normal' selected and it is shown as
> being supported in the frontend startup and on this page (in the
> 'complete list' section, GeForce GT 710) so I'm not sure what to
> believe.  I'm not using AVSync2 because ISTR it used to have problems
> with DVB-T Radio;  I haven't investigated that recently.
>
> https://developer.nvidia.com/video-encode-decode-gpu-support-matrix
>
> Anyway it's looking good and I plan to live with it.

I'm now on b449f5e. I wondered if I had appropriate driver-extras
installed, and looked at

https://rpmfusion.org/Howto/NVIDIA#NVENC.2FNVDEC

I had the cuda-libs package, and have now added vdpauinfo,
libva-vdpau-driver and libva-utils as suggested in the VDPAU/VAAPI
section. On frontend startup NVDEC is available and VAAPI is recognised
as using a VDPAU backend and ignored. NVDEC codecs are MPEG1,2,4, VC-1
and H.264
The OSD always says it's using ffmpeg and no deint.

>
> Cheers,
>
> John
>
>
>

_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: render2019 comments [ In reply to ]
On 29/09/2019 12:55, John Pilkington wrote:
> I briefly tried current render2019 789dda6 with Fedora29 x86_64 nvidia
> GT_710 430.40, but have gone back to master.
>
> Primary reason is that mythcommflag --rebuild and mythpreviewgen both
> 'Failed to initialise VAAPI connection' and quit.  My cutting script
> uses these.
>
> Also panning shots in 1080p DVB-T2 recordings are as seen through
> jelly, worse than in master.  DLNA does it best (although subtitle
> sync seems broken there).  But I didn't try much fine-tuning.
>
> HTH
>
> John P


I have tried 2019-render branch on a few different machines, accelerated
playback works ok once I had setup new video profile.

Originally the frontends were running master branch with appropriate
accelerated video profile.

Is it intended to automatically migrate old profiles to  new profiles or
will Users have to reconfigure ?

I have tried on Intel Graphics : TV via HDMI 1920x1080 50Hz and laptop
1366x768 @60HZ

Nvidia Graphics: laptop 1920x1080 @60Hz

AMD Ryzen 3 2200G with Radeon Vega Graphics: TV via HDMI 3840x2160 @50Hz
and 60Hz


I can also try on Raspberry Pi models 2,3 and 4 if someone can give me
the build incantations for OpenMax (Pi 2 Pi3) and Opengl vc4-fkms-v3d
(pi4), including what other build depends are required (some mesa-dev
libraries ?).


The only real problem I have is the UK Freeview DVB-T/T2 LiveTV channel
switching issue (trac ticket https://code.mythtv.org/trac/ticket/13292
is now even worse in that it takes much longer to show failure.


Using any of my tuners: TBS6280 (dual tuner PCI-e) or SiliconDust HD
HomeRun CONNECT QUATTRO (model HDHR5-4DT, firmware  20190621) or
Hauppauge Quad HD (PCI-e)  or TBS 6522 (dual tuner PCI-e) or Astrometa
(USB).

I have put a few mythfrontend logs (-v playback,libav --loglevel debug)
in my Dropbox
https://www.dropbox.com/sh/0n0t3ebp4nwiy3g/AACeC4WijoHLzj6Mrq1pgdmDa?dl=0

The change  m_ic->max_analyze_duration = 60 * AV_TIME_BASE; has had some
effect in that some channel changes are now "working" after 20 seconds
or more, depending on channel rate.

I still see instances of the wrong codec being opened and the reopening
failing (invalid argument). Also I see Probe size (5000000) being hit.

2019-10-01 13:46:56.032686 I [23348/23348] CoreContext
decoders/avformatdecoder.cpp:2107 (ScanStreams) - AFD: Already opened
codec not matching (MP2 vs MP2). Reopening
Looking at the code

avformatdecoder.cpp seems to have a error starting at if block at line 2102

        if (enc->codec && par->codec_id != enc->codec_id)
        {
            LOG(VB_PLAYBACK, LOG_INFO, LOC +
                QString("Already opened codec not matching (%1 vs %2).
Reopening")
.arg(ff_codec_id_string(enc->codec_id))
.arg(ff_codec_id_string(enc->codec->id)));
gCodecMap->freeCodecContext(m_ic->streams[strm]);
            enc = gCodecMap->getCodecContext(m_ic->streams[strm]);
        }


l2106 .arg(ff_codec_id_string(enc->codec_id))
l2107 .arg(ff_codec_id_string(enc->codec->id)));
both have the same codec, I suspect one of them should refer to
par->codec_id

Mike
Re: render2019 comments [ In reply to ]
I now have b449f5e running under el7 on this Core2duo Intel Q33 2.8 GHz
box with no extra video card and a single monitor at 75 Hz. It seems
fine for DVB-T SD recordings.

In my earlier tests I had only tried changing the 'Current Video
Playback Profile' and saw no change in the OSD playback_data. Now both
boxes have that set to Normal, and define Decoder, Max CPUs etc in the
screens that follow it; NVDEC (where present) and deinterlacing type
are now shown.

On the el7 box I get this sort of report on startup and with
mythpreviewgen and mythcommflag --rebuild. It works, and says what it
would like to do. :-)

{{{

running: ionice -c3 mythpreviewgen --chanid 10001 --starttime
20191001223800 -q
Failed to open VDPAU backend libvdpau_va_gl.so: cannot open shared
object file: No such file or directory
libva info: VA-API version 0.40.0
libva info: va_getDriverName() returns 0
libva info: Trying to open /usr/lib64/dri/i915_drv_video.so
libva info: va_openDriver() returns -1
[AVHWDeviceContext @ 0x250ed80] Failed to initialise VAAPI connection:
-1 (unknown libva error).
Preview created.
}}}

John P
_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: render2019 comments [ In reply to ]
Den 2019-09-30 kl. 09:24, skrev Mark Kendall:
> On Sun, 29 Sep 2019 at 20:51, Klaas de Waal <klaas.de.waal@gmail.com> wrote:
>> About the GUI.
>> Below the "Deinterlacer quality (single rate)" option are two lines
>> "Prefer OpenGL deinterlacers" and "Prefer driver deinterlacers".
>> These two lines are skipped over when "None" is the desired quality.
>> This makes sense after a few moments but initially it surprised me.
>> It would be great if it was possible to grey-out the not-applicable
>> options, as was recommended in the OSF-Motif style guide of the
>> previous century.
>> N.B. I do not know how to do that or if it is even possible in the
>> MythTV GUI. If I knew I would also use that in mythtv-setup.
>
> I was expecting that feedback at some point:)
>
> I didn't want to make the extra preferences another screen as it makes
> the setup much more complicated and requires a lot more code.
>
> There are 2 'states' that I found in the code for the checkboxes -
> enabled and visible. The visible state doesn't seem to have been
> designed for this purpose - as setting visible to true again does not
> show the setting.
>
> So I settled on enabled for now - and as you note, there is no code
> (as far as I can see) to change the presentation state when the
> setting is disabled. Like you, I was hoping it would grayed out (or
> something similar).
>
> Anyone familiar with the settings UI code have any ideas/suggestions?

I'm afraid the documentation for theming the settings has not been written yet. You should however be able to do what you want with the states disabledinactive and disabledactive of the buttonitem statetype widget that is used in button lists. That's just standard MythUI but for settings there is also the widgettype statetype which can be used to display the type of a setting (checkbox, textedit, etc).

Documentation of the button lists can be found here:
https://www.mythtv.org/wiki/MythUI_Theme_Development#The_buttonlist_widget

The current definition just changes the background for disabled settings:
https://github.com/MythTV/mythtv/blob/master/mythtv/themes/default/standardsetting-ui.xml#L181
https://github.com/MythTV/mythtv/blob/master/mythtv/themes/default/standardsetting-ui.xml#L188

Cheers
Jonatan
_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: render2019 comments [ In reply to ]
On Wed, 2 Oct 2019 at 12:53, John Pilkington <johnpilk222@gmail.com> wrote:
>
> I now have b449f5e running under el7 on this Core2duo Intel Q33 2.8 GHz
> box with no extra video card and a single monitor at 75 Hz. It seems
> fine for DVB-T SD recordings.
>
> In my earlier tests I had only tried changing the 'Current Video
> Playback Profile' and saw no change in the OSD playback_data. Now both
> boxes have that set to Normal, and define Decoder, Max CPUs etc in the
> screens that follow it; NVDEC (where present) and deinterlacing type
> are now shown.

Sorry - I meant to get back to you earlier. I was going to suggest
that you probably needed to edit the profile itself to ensure you were
getting nvdec.

> On the el7 box I get this sort of report on startup and with
> mythpreviewgen and mythcommflag --rebuild. It works, and says what it
> would like to do. :-)
>
> {{{
>
> running: ionice -c3 mythpreviewgen --chanid 10001 --starttime
> 20191001223800 -q
> Failed to open VDPAU backend libvdpau_va_gl.so: cannot open shared
> object file: No such file or directory
> libva info: VA-API version 0.40.0
> libva info: va_getDriverName() returns 0
> libva info: Trying to open /usr/lib64/dri/i915_drv_video.so
> libva info: va_openDriver() returns -1
> [AVHWDeviceContext @ 0x250ed80] Failed to initialise VAAPI connection:
> -1 (unknown libva error).
> Preview created.
> }}}

For what it's worth - most of those messages are driver library
messages (not mythtv logging). They are harmless.

The reason I added functionality checks on startup (in
AVFormatDecoder) was to ensure that we didn't clutter the video
settings pages with decoders that were not useable. On most Intel
systems, for example, you will normally get VAAPI, VDPAU, NVDec and
V4L2 codecs support compiled in (VDPAU headers are normally present,
NVDEC is largely a runtime check in FFmpeg and V4L2 will always be
available but usually not functioning) - but only VAAPI is viable.

The one problem at the moment is that I get intermittent NVDEC
functionality check failures - this also happens at seemingly random
times when starting playback.

Furthermore, I've not made any attempt to remove those checks when not
using mythfrontend or mythavtest. This is because a roughly 2 line
patch would enable hardware accelerated decoding for commercial
flagging - which may be of use/interest to some. It would also require
new settinga but does have complications around how to manage the
number of concurrent GPU hardware contexts (most systems will only
manage one), prioritising playback over other operations, commflagging
operations would in most cases need to be running with a display (so
headless operation would not work - with the current exception of MMAL
for the Pi) and given that we farm out a lot of this to separate
processes, how to coordinate between them.

- there will also, I'm sure, be someone who has a dual GPU setup who
wants to use their discreet card for video playback and integrated GPU
for commercial flagging...

Thanks and regards
Mark
_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: render2019 comments [ In reply to ]
On Wed, 2 Oct 2019 at 21:22, Jonatan Lindblad <lindbladjonatan@gmail.com> wrote:
> > Anyone familiar with the settings UI code have any ideas/suggestions?
>
> I'm afraid the documentation for theming the settings has not been written yet. You should however be able to do what you want with the states disabledinactive and disabledactive of the buttonitem statetype widget that is used in button lists. That's just standard MythUI but for settings there is also the widgettype statetype which can be used to display the type of a setting (checkbox, textedit, etc).
>
> Documentation of the button lists can be found here:
> https://www.mythtv.org/wiki/MythUI_Theme_Development#The_buttonlist_widget
>
> The current definition just changes the background for disabled settings:
> https://github.com/MythTV/mythtv/blob/master/mythtv/themes/default/standardsetting-ui.xml#L181
> https://github.com/MythTV/mythtv/blob/master/mythtv/themes/default/standardsetting-ui.xml#L188

Jonatan,

If I'm reading that correctly - then all I need to do is edit the
disabledinactive state? but presumably the standard settings is themed
individually and hence overridden by each theme... (showing my
ignorance here no doubt)

Thanks,
Mark
_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: render2019 comments [ In reply to ]
On Tue, 1 Oct 2019 at 07:44, Klaas de Waal <klaas.de.waal@gmail.com> wrote:
> > > Software: Fedora 30 with LXDE desktop.
> > > Mythfrontend graphics setting: (Setup / Video / Playback / Current
> > > Video Playback Profile) VAAPI2 Normal
> > > Mythfrontend plays in a 1280x720 window on a 1900x1200 desktop.
> > > Content is 50Hz but monitor is 60Hz.
> > > This is for me the usual setting.
> > >
> > > Build: no problem.

Klaas

As noted elsewhere - I think you actually need to go into the video
display profile details and update them. You will need a combination
of vaapi (decoder) and opengl-hw (renderer).

> > Is VAAPI enabled?
>
> This is what the ./configure says:
> # Video Output Support
> x11 support yes
> xnvctrl support yes (system)
> xrandr support yes
> VDPAU support yes
> VAAPI support yes
> NVDEC support yes
> Video4Linux codecs yes
> MMAL decoder support no
> OpenGL support yes
> OpenGL video yes
> OpenGL ThemePainter yes
> MHEG support yes
> libass subtitle support yes
>
> >
> > > Mythfrontend startup error message:
> > > [AVHWDeviceContext @ 0x1422d00] Failed to initialise VAAPI connection:
> > > -1 (unknown libva error).
> > > Cannot load libcuda.so.1
> >
> > As noted to John - there are some static checks that need cleaning up
> > but in your case they should just be informative - not sure why the
> > VAAPI check would fail if VAAPI is enabled though.
> >
> The message is still present.

If you are still getting that VAAPI error message then there is
something wrong. Are you running under Wayland? The only thing I can
think of is the "Decoder device for VAAPI hardware decoding' that is
under settings->video->playback->advanced playback settings. The code
will default to /dev/dri/renderD128

Regards,
Mark
_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: render2019 comments [ In reply to ]
On Tue, 1 Oct 2019 at 16:07, Mike Bibbings <mike.bibbings@gmail.com> wrote:
> I have tried 2019-render branch on a few different machines, accelerated playback works ok once I had setup new video profile.
>
> Originally the frontends were running master branch with appropriate accelerated video profile.
>
> Is it intended to automatically migrate old profiles to new profiles or will Users have to reconfigure ?

I'm not sure how to deal with this yet. I considered adding some code
to ensure they were set to sensible equivalents in the display profile
pages - but that would require the user to actually go into the
settings pages.

I'm not sure it is best handled with a schema upgrade - there are
currently no schema changes. Some video display profile elements are
now redundant/removed (e.g. the OSD selection) - it is just the values
that have changed.

The best option may be to automatically check at startup and if any
changes are made then send a UI message saying that - and ask the use
to check their profiles.

or just say in the release notes that you need to update your profiles...

> I have tried on Intel Graphics : TV via HDMI 1920x1080 50Hz and laptop 1366x768 @60HZ
>
> Nvidia Graphics: laptop 1920x1080 @60Hz

I'm working through some issues with Piotr for nvidia/VDPAU - should
be resolved shortly but you may get out of memory issues.

> AMD Ryzen 3 2200G with Radeon Vega Graphics: TV via HDMI 3840x2160 @50Hz and 60Hz

I'd be interested to see some -v playback logs with radeon graphics -
I've not tested with AMD at all.

>
> I can also try on Raspberry Pi models 2,3 and 4 if someone can give me the build incantations for OpenMax (Pi 2 Pi3) and Opengl vc4-fkms-v3d (pi4), including what other build depends are required (some mesa-dev libraries ?).

I don't have a working Pi build at the moment - that's not to say the
mythtv code doesn't work - it's just a mess with raspbian at the
moment.

MMAL and V4L2 are now the decoders for the pi.

MMAL requires the closed source/broadcom driver to work for direct
rendering but that requires that you build your own version of Qt5
with pi support built in (though it has just occurred to me that there
may be a workaround!). Direct rendering is also not that speedy
currently and there is no hardware (MMAL) deinterlacing.

V4L2 requires the opensource OpenGL driver (which is now the default
on the Pi4). The main problem here is that there is no direct
rendering support, so it is not as fast as it could be, and the pi
v4l2 codecs driver does not pass through interlaced flags - so auto
deinterlacing does not work.

I've put most of this on a wiki page (it's a work in progress) -

https://www.mythtv.org/wiki/2019-render

>
> The only real problem I have is the UK Freeview DVB-T/T2 LiveTV channel switching issue (trac ticket https://code.mythtv.org/trac/ticket/13292) is now even worse in that it takes much longer to show failure.
>
>
> Using any of my tuners: TBS6280 (dual tuner PCI-e) or SiliconDust HD HomeRun CONNECT QUATTRO (model HDHR5-4DT, firmware 20190621) or Hauppauge Quad HD (PCI-e) or TBS 6522 (dual tuner PCI-e) or Astrometa (USB).
>
> I have put a few mythfrontend logs (-v playback,libav --loglevel debug) in my Dropbox https://www.dropbox.com/sh/0n0t3ebp4nwiy3g/AACeC4WijoHLzj6Mrq1pgdmDa?dl=0
>
> The change m_ic->max_analyze_duration = 60 * AV_TIME_BASE; has had some effect in that some channel changes are now "working" after 20 seconds or more, depending on channel rate.
>
> I still see instances of the wrong codec being opened and the reopening failing (invalid argument). Also I see Probe size (5000000) being hit.
>
> 2019-10-01 13:46:56.032686 I [23348/23348] CoreContext decoders/avformatdecoder.cpp:2107 (ScanStreams) - AFD: Already opened codec not matching (MP2 vs MP2). Reopening
> Looking at the code
>
> avformatdecoder.cpp seems to have a error starting at if block at line 2102
>
> if (enc->codec && par->codec_id != enc->codec_id)
> {
> LOG(VB_PLAYBACK, LOG_INFO, LOC +
> QString("Already opened codec not matching (%1 vs %2). Reopening")
> .arg(ff_codec_id_string(enc->codec_id))
> .arg(ff_codec_id_string(enc->codec->id)));
> gCodecMap->freeCodecContext(m_ic->streams[strm]);
> enc = gCodecMap->getCodecContext(m_ic->streams[strm]);
> }
>
>
> l2106 .arg(ff_codec_id_string(enc->codec_id))
> l2107 .arg(ff_codec_id_string(enc->codec->id)));
> both have the same codec, I suspect one of them should refer to par->codec_id

I've seen some of these issues (I'm using an old HDHomeRun dvb-t
tuner). Live tv is, as ever, a black hole:) I'll take a look.

The max_analyze_duration change is probably only helping in some cases
as in others the stream will be scanned and not fully parsed but the
ffmpeg code will still report success.

My gut feeling is that the in memory check needs to go...

Thanks and regards
Mark
_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: render2019 comments [ In reply to ]
On Thu, 3 Oct 2019 at 10:29, Mark Kendall <mark.kendall@gmail.com> wrote:
> On Tue, 1 Oct 2019 at 16:07, Mike Bibbings <mike.bibbings@gmail.com> wrote:
> > I have put a few mythfrontend logs (-v playback,libav --loglevel debug) in my Dropbox https://www.dropbox.com/sh/0n0t3ebp4nwiy3g/AACeC4WijoHLzj6Mrq1pgdmDa?dl=0
> >
> > The change m_ic->max_analyze_duration = 60 * AV_TIME_BASE; has had some effect in that some channel changes are now "working" after 20 seconds or more, depending on channel rate.
> >
> > I still see instances of the wrong codec being opened and the reopening failing (invalid argument). Also I see Probe size (5000000) being hit.
> >
> > 2019-10-01 13:46:56.032686 I [23348/23348] CoreContext decoders/avformatdecoder.cpp:2107 (ScanStreams) - AFD: Already opened codec not matching (MP2 vs MP2). Reopening
> > Looking at the code
> >
> > avformatdecoder.cpp seems to have a error starting at if block at line 2102
> >
> > if (enc->codec && par->codec_id != enc->codec_id)
> > {
> > LOG(VB_PLAYBACK, LOG_INFO, LOC +
> > QString("Already opened codec not matching (%1 vs %2). Reopening")
> > .arg(ff_codec_id_string(enc->codec_id))
> > .arg(ff_codec_id_string(enc->codec->id)));
> > gCodecMap->freeCodecContext(m_ic->streams[strm]);
> > enc = gCodecMap->getCodecContext(m_ic->streams[strm]);
> > }
> >
> >
> > l2106 .arg(ff_codec_id_string(enc->codec_id))
> > l2107 .arg(ff_codec_id_string(enc->codec->id)));
> > both have the same codec, I suspect one of them should refer to par->codec_id
>
> I've seen some of these issues (I'm using an old HDHomeRun dvb-t
> tuner). Live tv is, as ever, a black hole:) I'll take a look.
>
> The max_analyze_duration change is probably only helping in some cases
> as in others the stream will be scanned and not fully parsed but the
> ffmpeg code will still report success.
>
> My gut feeling is that the in memory check needs to go...

I've just had a quick 5 minute stress test of livetv with the live tv
in memory 'optimisation' removed (line 1003 of avformatdecoder).

Error free - no channel change failures, no audio failures. Without
that change, switching to BBC2 (for some reason) would fail 90% of the
time and would often get the audio error noted above.

Only problem is - some changes (again to BBC2) take an age - there is
a consistent 12 seconds delay for certain switches. Others are 'fine'
- a second or so.

Regards
Mark
_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: render2019 comments [ In reply to ]
>>> I'm not sure how to deal with this yet. I considered adding some code
>>> to ensure they were set to sensible equivalents in the display profile
>>> pages - but that would require the user to actually go into the
>>> settings pages.


Maybe a mythtv-setup "first start wizard" that walks people through the areas that you want them to visit at least once.

Doug
_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: render2019 comments [ In reply to ]
On 03/10/2019 10:55, Mark Kendall wrote:
> On Thu, 3 Oct 2019 at 10:29, Mark Kendall <mark.kendall@gmail.com> wrote:
>> On Tue, 1 Oct 2019 at 16:07, Mike Bibbings <mike.bibbings@gmail.com> wrote:
>>> I have put a few mythfrontend logs (-v playback,libav --loglevel debug) in my Dropbox https://www.dropbox.com/sh/0n0t3ebp4nwiy3g/AACeC4WijoHLzj6Mrq1pgdmDa?dl=0
>>>
>>> The change m_ic->max_analyze_duration = 60 * AV_TIME_BASE; has had some effect in that some channel changes are now "working" after 20 seconds or more, depending on channel rate.
>>>
>>> I still see instances of the wrong codec being opened and the reopening failing (invalid argument). Also I see Probe size (5000000) being hit.
>>>
>>> 2019-10-01 13:46:56.032686 I [23348/23348] CoreContext decoders/avformatdecoder.cpp:2107 (ScanStreams) - AFD: Already opened codec not matching (MP2 vs MP2). Reopening
>>> Looking at the code
>>>
>>> avformatdecoder.cpp seems to have a error starting at if block at line 2102
>>>
>>> if (enc->codec && par->codec_id != enc->codec_id)
>>> {
>>> LOG(VB_PLAYBACK, LOG_INFO, LOC +
>>> QString("Already opened codec not matching (%1 vs %2). Reopening")
>>> .arg(ff_codec_id_string(enc->codec_id))
>>> .arg(ff_codec_id_string(enc->codec->id)));
>>> gCodecMap->freeCodecContext(m_ic->streams[strm]);
>>> enc = gCodecMap->getCodecContext(m_ic->streams[strm]);
>>> }
>>>
>>>
>>> l2106 .arg(ff_codec_id_string(enc->codec_id))
>>> l2107 .arg(ff_codec_id_string(enc->codec->id)));
>>> both have the same codec, I suspect one of them should refer to par->codec_id
>> I've seen some of these issues (I'm using an old HDHomeRun dvb-t
>> tuner). Live tv is, as ever, a black hole:) I'll take a look.
>>
>> The max_analyze_duration change is probably only helping in some cases
>> as in others the stream will be scanned and not fully parsed but the
>> ffmpeg code will still report success.
>>
>> My gut feeling is that the in memory check needs to go...
> I've just had a quick 5 minute stress test of livetv with the live tv
> in memory 'optimisation' removed (line 1003 of avformatdecoder).
>
> Error free - no channel change failures, no audio failures. Without
> that change, switching to BBC2 (for some reason) would fail 90% of the
> time and would often get the audio error noted above.
>
> Only problem is - some changes (again to BBC2) take an age - there is
> a consistent 12 seconds delay for certain switches. Others are 'fine'
> - a second or so.
>
> Regards
> Mark
> _______________________________________________

Mark,

I have rebuilt with the "optimisation" commented out, no failures of any
kind with livetv channel switching.

However many of the channel changes are taking a long time up to around
30 seconds. There are some which are 1-2 seconds.

I have put mythfrontend log files (-v playback) in my Dropbox

https://www.dropbox.com/sh/0n0t3ebp4nwiy3g/AACeC4WijoHLzj6Mrq1pgdmDa?dl=0

mythfrontend.20191003122731.9862-many-channel-changes-livetv-disabled.log
mythfrontend.20191003131140.11497-many-channel-changes-livetv-disabled.log

The tests were done on my AMD Ryzen 2200G system.

Below is an extract from mythconverg database showing chanid, name, mplexid, freqid just in case it is useful.


mysql> select chanid,name,mplexid,freqid from channel order by chanid;
+--------+---------------------+---------+--------+
| chanid | name | mplexid | freqid |
+--------+---------------------+---------+--------+
| 10001 | BBC ONE East W | 3 | 27 |
| 10002 | BBC TWO | 3 | 27 |
| 10003 | ITV | 2 | 24 |
| 10004 | Channel 4 | 2 | 24 |
| 10005 | Channel 5 | 2 | 24 |
| 10006 | ITV2 | 2 | 24 |
| 10009 | BBC FOUR | 3 | 27 |
| 10010 | ITV3 | 2 | 24 |
| 10011 | Pick | 4 | 36 |
| 10012 | QUEST | 6 | 51 |
| 10013 | E4 | 2 | 24 |
| 10014 | Film4 | 2 | 24 |
| 10015 | Channel 4+1 | 2 | 24 |
| 10016 | QVC | 6 | 51 |
| 10017 | Really | 4 | 36 |
| 10018 | More 4 | 2 | 24 |
| 10019 | Dave | 4 | 36 |
| 10020 | Drama | 6 | 51 |
| 10021 | 5 USA | 6 | 51 |
| 10022 | Ideal World | 5 | 48 |
| 10023 | Create & Craft | 4 | 36 |
| 10024 | ITV4 | 2 | 24 |
| 10025 | Yesterday | 5 | 48 |
| 10026 | ITVBe | 6 | 51 |
| 10027 | ITV2 +1 | 6 | 51 |
| 10028 | E4+1 | 4 | 36 |
| 10029 | 4Music | 5 | 48 |
| 10030 | 5STAR | 6 | 51 |
| 10031 | 5Spike | 5 | 48 |
| 10032 | Sony Movies | 4 | 36 |
| 10033 | ITV +1 | 2 | 24 |
| 10034 | ITV3+1 | 6 | 51 |
| 10035 | QVC Beauty | 5 | 48 |
| 10036 | QVC Style | 5 | 48 |
| 10037 | DMAX | 5 | 48 |
| 10038 | Quest Red | 4 | 36 |
| 10039 | CBS Justice | 5 | 48 |
| 10040 | Sony Movies Action | 6 | 51 |
| 10041 | Food Network | 4 | 36 |
| 10042 | Home | 5 | 48 |
| 10043 | Gems TV | 4 | 36 |
| 10044 | Channel 5+1 | 6 | 51 |
| 10045 | Film4+1 | 2 | 24 |
| 10046 | Challenge | 4 | 36 |
| 10047 | 4seven | 5 | 48 |
| 10049 | TJC | 4 | 36 |
| 10054 | Paramount Network | 6 | 51 |
| 10055 | 5SELECT | 6 | 51 |
| 10056 | 5STAR+1 | 8 | 56 |
| 10057 | 5USA+1 | 7 | 55 |
| 10058 | ITVBe+1 | 6 | 51 |
| 10059 | ITV4+1 | 6 | 51 |
| 10063 | Blaze | 6 | 51 |
| 10064 | FreeSports | 8 | 56 |
| 10065 | TBN UK | 4 | 36 |
| 10066 | CBS Reality | 6 | 51 |
| 10067 | CBS Reality +1 | 7 | 55 |
| 10070 | Horror Channel | 6 | 51 |
| 10071 | CBS Drama | 5 | 48 |
| 10072 | YourTV | 4 | 36 |
| 10073 | Sewing Quarter | 5 | 48 |
| 10074 | Jewellery Maker | 7 | 55 |
| 10076 | QUEST+1 | 4 | 36 |
| 10077 | TCC | 6 | 51 |
| 10078 | Quest Red+1 | 7 | 55 |
| 10079 | Dave ja vu | 5 | 48 |
| 10080 | Blaze+1 | 6 | 51 |
| 10081 | TalkingPictures TV | 5 | 48 |
| 10083 | NOW 80s | 8 | 56 |
| 10084 | NOW 90s | 8 | 56 |
| 10085 | Hochanda | 6 | 51 |
| 10086 | More4+1 | 1 | 21 |
| 10089 | Together TV | 4 | 36 |
| 10091 | PBS America | 8 | 56 |
| 10092 | Pick+1 | 7 | 55 |
| 10093 | Together TV+1 | 8 | 56 |
| 10096 | Forces TV | 8 | 56 |
| 10099 | Smithsonian Channel | 7 | 55 |
| 10101 | BBC ONE HD | 1 | 21 |
| 10102 | BBC TWO HD | 1 | 21 |
| 10103 | ITV HD | 1 | 21 |
| 10104 | Channel 4 HD | 1 | 21 |
| 10105 | Channel 5 HD | 1 | 21 |
| 10106 | BBC FOUR HD | 8 | 56 |
| 10107 | BBC NEWS HD | 7 | 55 |
| 10109 | Channel 4+1 HD | 7 | 55 |
| 10110 | 4seven HD | 7 | 55 |
| 10111 | QVC HD | 8 | 56 |
| 10112 | QVC Beauty HD | 8 | 56 |
| 10113 | RT HD | 7 | 55 |
| 10114 | QUEST HD | 8 | 56 |
| 10201 | CBBC | 3 | 27 |
| 10202 | CBeebies | 3 | 27 |
| 10203 | CITV | 6 | 51 |
| 10204 | CBBC HD | 1 | 21 |
| 10205 | CBeebies HD | 8 | 56 |
| 10206 | POP | 5 | 48 |
| 10231 | BBC NEWS | 3 | 27 |
| 10232 | BBC Parliament | 3 | 27 |
| 10233 | Sky News | 4 | 36 |
| 10234 | RT | 5 | 48 |
| 10235 | Al Jazeera Eng | 5 | 48 |
| 10250 | BBC Red Button | 3 | 27 |
| 10601 | BBC RB 1 | 3 | 27 |
| 10670 | ADULT Section | 6 | 51 |
| 10672 | ADULT smileTV2 | 5 | 48 |
| 10673 | ADULT smileTV3 | 4 | 36 |
| 10674 | ADULT Babestn | 5 | 48 |
| 10675 | ADULT Party | 6 | 51 |
| 10678 | ADULT Xpanded TV | 4 | 36 |
| 10679 | ADULT Studio 66 | 6 | 51 |
| 10680 | ADULT Xpanded2 | 6 | 51 |
| 10699 | ADULT Section | 5 | 48 |
| 10700 | BBC Radio 1 | 3 | 27 |
| 10701 | BBC R1X | 3 | 27 |
| 10702 | BBC Radio 2 | 3 | 27 |
| 10703 | BBC Radio 3 | 3 | 27 |
| 10704 | BBC Radio 4 | 3 | 27 |
| 10705 | BBC R5L | 3 | 27 |
| 10706 | BBC R5SX | 3 | 27 |
| 10707 | BBC 6 Music | 3 | 27 |
| 10708 | BBC Radio 4 Ex | 3 | 27 |
| 10709 | BBC Asian Net. | 3 | 27 |
| 10710 | BBC World Sv. | 3 | 27 |
| 10711 | Hits Radio | 5 | 48 |
| 10712 | KISS FRESH | 5 | 48 |
| 10713 | KISS | 5 | 48 |
| 10714 | KISSTORY | 5 | 48 |
| 10715 | Magic | 5 | 48 |
| 10716 | heat | 5 | 48 |
| 10717 | Kerrang! | 5 | 48 |
| 10718 | Smooth Radio | 5 | 48 |
| 10719 | BBC Norfolk | 3 | 27 |
| 10720 | BBC Three Counties | 3 | 27 |
| 10721 | BBC Radio London | 3 | 27 |
| 10722 | BBC Cambridge | 3 | 27 |
| 10723 | talkSPORT | 4 | 36 |
| 10724 | Capital | 6 | 51 |
| 10725 | Premier Radio | 5 | 48 |
| 10727 | Absolute Radio | 6 | 51 |
| 10728 | Heart | 6 | 51 |
| 10730 | RNIB Connect | 4 | 36 |
| 10731 | Classic FM | 4 | 36 |
| 10732 | LBC | 4 | 36 |
| 10733 | Trans World Radio | 7 | 55 |
| 10734 | BBC Northampton | 3 | 27 |
| 10790 | QUEST+1 | 6 | 51 |
| 10792 | Together TV | 8 | 56 |
+--------+---------------------+---------+--------+
148 rows in set (0.00 sec)






_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: render2019 comments [ In reply to ]
Den 2019-10-03 kl. 10:58, skrev Mark Kendall:
> On Wed, 2 Oct 2019 at 21:22, Jonatan Lindblad <lindbladjonatan@gmail.com> wrote:
>>> Anyone familiar with the settings UI code have any ideas/suggestions?
>>
>> I'm afraid the documentation for theming the settings has not been written yet. You should however be able to do what you want with the states disabledinactive and disabledactive of the buttonitem statetype widget that is used in button lists. That's just standard MythUI but for settings there is also the widgettype statetype which can be used to display the type of a setting (checkbox, textedit, etc).
>>
>> Documentation of the button lists can be found here:
>> https://www.mythtv.org/wiki/MythUI_Theme_Development#The_buttonlist_widget
>>
>> The current definition just changes the background for disabled settings:
>> https://github.com/MythTV/mythtv/blob/master/mythtv/themes/default/standardsetting-ui.xml#L181
>> https://github.com/MythTV/mythtv/blob/master/mythtv/themes/default/standardsetting-ui.xml#L188
>
> Jonatan,
>
> If I'm reading that correctly - then all I need to do is edit the
> disabledinactive state?

Yes, that is correct. You can check out Steppes for an example, https://github.com/MythTV-Themes/Steppes/blob/master/standardsetting-ui.xml#L169.

> but presumably the standard settings is themed
> individually and hence overridden by each theme... (showing my
> ignorance here no doubt)

It seems like the only themes customizing this are the different Steppes versions and Monochrome so if you update the default one most of the themes would actually benefit from it.

Cheers
Jonatan
_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: render2019 comments [ In reply to ]
On Thu, 3 Oct 2019 at 14:57, Mike Bibbings <mike.bibbings@gmail.com> wrote:
> Mark,
>
> I have rebuilt with the "optimisation" commented out, no failures of any
> kind with livetv channel switching.
>
> However many of the channel changes are taking a long time up to around
> 30 seconds. There are some which are 1-2 seconds.
>

Mike - try the attached patch.

Seems to be working without issue (i.e. no failures and fast(er)
channel changes (circa 3 seconds max)).

Regards,
Mark
Re: render2019 comments [ In reply to ]
On 04/10/2019 08:48, Mark Kendall wrote:
> On Thu, 3 Oct 2019 at 14:57, Mike Bibbings <mike.bibbings@gmail.com> wrote:
>> Mark,
>>
>> I have rebuilt with the "optimisation" commented out, no failures of any
>> kind with livetv channel switching.
>>
>> However many of the channel changes are taking a long time up to around
>> 30 seconds. There are some which are 1-2 seconds.
>>
> Mike - try the attached patch.
>
> Seems to be working without issue (i.e. no failures and fast(er)
> channel changes (circa 3 seconds max)).
>
> Regards,
> Mark

Hi Mark,

Thanks for the patch, it is looking good on DVB-T/T2 with my Hauppauge
Quad HD tuner (PCI-e), yet to be tested with DVB-S/S2.

I have switched my production system from master to the 2019-render
branch, with the patch, to give it a workout.

My production system uses PCI-e DVB-T/T2 and network DVB-S/S2 tuners.


Mike

_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: render2019 comments [ In reply to ]
On Thu, 3 Oct 2019 at 21:57, Jonatan Lindblad <lindbladjonatan@gmail.com> wrote:
>
> Den 2019-10-03 kl. 10:58, skrev Mark Kendall:
> > On Wed, 2 Oct 2019 at 21:22, Jonatan Lindblad <lindbladjonatan@gmail.com> wrote:
> >>> Anyone familiar with the settings UI code have any ideas/suggestions?
> >>
> >> I'm afraid the documentation for theming the settings has not been written yet. You should however be able to do what you want with the states disabledinactive and disabledactive of the buttonitem statetype widget that is used in button lists. That's just standard MythUI but for settings there is also the widgettype statetype which can be used to display the type of a setting (checkbox, textedit, etc).
> >>
> >> Documentation of the button lists can be found here:
> >> https://www.mythtv.org/wiki/MythUI_Theme_Development#The_buttonlist_widget
> >>
> >> The current definition just changes the background for disabled settings:
> >> https://github.com/MythTV/mythtv/blob/master/mythtv/themes/default/standardsetting-ui.xml#L181
> >> https://github.com/MythTV/mythtv/blob/master/mythtv/themes/default/standardsetting-ui.xml#L188
> >
> > Jonatan,
> >
> > If I'm reading that correctly - then all I need to do is edit the
> > disabledinactive state?
>
> Yes, that is correct. You can check out Steppes for an example, https://github.com/MythTV-Themes/Steppes/blob/master/standardsetting-ui.xml#L169.
>
> > but presumably the standard settings is themed
> > individually and hence overridden by each theme... (showing my
> > ignorance here no doubt)
>
> It seems like the only themes customizing this are the different Steppes versions and Monochrome so if you update the default one most of the themes would actually benefit from it.
>
> Cheers
> Jonatan

The grey-out, as implemented now in 2019-render with commit "4fe3b:
Settings: Update standard theme to 'gray out' disabled settings" does
break mythtv-setup page "Capture Card / Card type". Here I apparently
use this attribute to skip the field 'Frontend ID' and that is now
grey. This field should not be grey because it is relevant to the
page; the field is skipped with editing becausee it shows content that
cannot be edited.
Maybe we do need a separate function to set the grey/not-grey state of
a field? Or should I do something different for the "Frontend ID"
field?

Groetjes,
Klaas.
_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: render2019 comments [ In reply to ]
On Sat, 5 Oct 2019 at 07:51, Klaas de Waal <klaas.de.waal@gmail.com> wrote:
>
> The grey-out, as implemented now in 2019-render with commit "4fe3b:
> Settings: Update standard theme to 'gray out' disabled settings" does
> break mythtv-setup page "Capture Card / Card type". Here I apparently
> use this attribute to skip the field 'Frontend ID' and that is now
> grey. This field should not be grey because it is relevant to the
> page; the field is skipped with editing becausee it shows content that
> cannot be edited.
> Maybe we do need a separate function to set the grey/not-grey state of
> a field? Or should I do something different for the "Frontend ID"
> field?

Klaas,

Looking at that setup page and the code - it looks like the Frontend
ID is informative (i.e. it helps the user identify what /dev/dvb/xxx
actually is - in the case where there are multiple cards) and it is
not stored in the database. So it is essentially not a setting - but
the settings ui does not currently have the ability to show something
that isn't a setting.

I would suggest either extending standard settings to have a
'ReadOnly' state - though not sure how much code that would require -
or alternatively, on that setup page, append the Frontend ID to the
device/adapter selection. So instead of DVB device showing (in my
case) '/dev/dvb/adapter0/frontend0' it would read
/dev/dvb/adapter0/frontend0 (ST STV0299 DVB-S) - which I think would
require only a slight modification to the code. The one obvious
problem is that string is quite long...

Thoughts?

Regards, Mark
_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: render2019 comments [ In reply to ]
Hi Mark,

It is not a problem if the Frontend ID is enabled, it is read-only
anyway. Navigating to this field means that there can be a help text
presented which is also nice. See for example the field "Delivery
system" (mythtv-setup page Input Connections, select one input and
then the page with this field shows) which also only presents a value
but is enabled and so it can be selected.

There are other places where the enabled is used to prevent changing
the value. It would be good to have a ReadOnly setting for this and it
would be even better to change the presentation to remove the
decorations that show the field can be modified.
For example, the down-arrow button at the left of the field which
indicates a popup list should not be drawn if the field is ReadOnly.
So to summarize I think that Enable/Disable which does greying out and
disables navigation, and a ReadOnly that prevents editing and that
removes the arrows would be great. However, I have no idea how much
work this would be and how many people would like this also.

About the greying-out itself, it does only grey out the label value
(at the left) but not the field value (at the right). I would expect
both the field and the value to be greyed-out. It is not really
visible with a checkbox but with the "Frontend ID" field it does look
really odd.

Sorry for hijacking this thread...

Groetjes,
Klaas.




On Sun, 6 Oct 2019 at 19:18, Mark Kendall <mark.kendall@gmail.com> wrote:
>
> On Sat, 5 Oct 2019 at 07:51, Klaas de Waal <klaas.de.waal@gmail.com> wrote:
> >
> > The grey-out, as implemented now in 2019-render with commit "4fe3b:
> > Settings: Update standard theme to 'gray out' disabled settings" does
> > break mythtv-setup page "Capture Card / Card type". Here I apparently
> > use this attribute to skip the field 'Frontend ID' and that is now
> > grey. This field should not be grey because it is relevant to the
> > page; the field is skipped with editing becausee it shows content that
> > cannot be edited.
> > Maybe we do need a separate function to set the grey/not-grey state of
> > a field? Or should I do something different for the "Frontend ID"
> > field?
>
> Klaas,
>
> Looking at that setup page and the code - it looks like the Frontend
> ID is informative (i.e. it helps the user identify what /dev/dvb/xxx
> actually is - in the case where there are multiple cards) and it is
> not stored in the database. So it is essentially not a setting - but
> the settings ui does not currently have the ability to show something
> that isn't a setting.
>
> I would suggest either extending standard settings to have a
> 'ReadOnly' state - though not sure how much code that would require -
> or alternatively, on that setup page, append the Frontend ID to the
> device/adapter selection. So instead of DVB device showing (in my
> case) '/dev/dvb/adapter0/frontend0' it would read
> /dev/dvb/adapter0/frontend0 (ST STV0299 DVB-S) - which I think would
> require only a slight modification to the code. The one obvious
> problem is that string is quite long...
>
> Thoughts?
>
> Regards, Mark
> _______________________________________________
> mythtv-dev mailing list
> mythtv-dev@mythtv.org
> http://lists.mythtv.org/mailman/listinfo/mythtv-dev
> http://wiki.mythtv.org/Mailing_List_etiquette
> MythTV Forums: https://forum.mythtv.org
_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

1 2  View All