[mythtv-users] 30 vs 31

[John Pilkington]

On 02/06/2020 13:25, Paul Gardiner wrote:
> 
> 
> On 02/06/2020 07:12, Stephen Worthington wrote:
>> On Mon, 1 Jun 2020 23:03:06 -0700, you wrote:
>>
>>> On 5/24/20 2:59 AM, jam wrote:
>>>>
>>>>> On 24 May 2020, at 5:04 pm, Paul Gardiner <lists at glidos.net> wrote:
>>>>>
>>>>>>>> Hi all
>>>>>>>> I’m asking for advocasy. Why should I use 31 and not 30
>>>>>>>> I find 31 slow to start, 30 odd secs for 31 vs 1 sec for 30
>>>>>>>> On my high sierra mac, thanks to John’s hard work, a frontend 
>>>>>>>> does run, but the audio and video drift to be many seconds apart.
>>>>>>>> A virtualBox VM running ubuntu (downloaded packages) and 
>>>>>>>> opensuse Tumbleweed (built from src) has the same audio drift
>>>>>>>> A parallels VN tunning either of the above distros frontend does 
>>>>>>>> *not* show the drift.
>>>>>>> Things may be different on Macs, but I believe that a/v sync 
>>>>>>> drift in recent frontends is usually caused by frame dropping 
>>>>>>> when the selected deinterlacer is working too hard.  Try one that 
>>>>>>> isn't quite so demanding.
>>>>>>>
>>>>>>> Setup > Video > Playback > Current Video Playback Profile >  ....
>>>>>> John thanks
>>>>>> I was decieved by cpu load but changing the deinterlacer fixed the 
>>>>>> problem
>>>>> Isn't that still a bad sign for the new synchronisation mechanism, 
>>>>> though? = that it should drift so far when the video is struggling.
>>>> And we are not talking mS but 10s S or minutes
>>>> James
>>>
>>> Still haven't seen a response that answers the question "Why should I
>>> use 31 and not 30?".  Are there bug fixes, features, improvements of any
>>> kind?  So far, all I've seen are new bugs.
>>>
>>> Dave D.
>>
>> The new rendering code is the big change - a behind the scenes change,
>> but quite significant.  If you have Intel or AMD video, then I believe
>> the new rendering code is now able to use them just as well as Nvidia.
> 
> Which is awesome, but it does seem worrying (although not at all 
> surprising) that some regressions have been introduced in the process... 
> I guess they'll get fixed in time.
> 
> It's a shame there is no roll-back procedure for the database (other 
> than installing a backup and losing recent additions). It would be so 
> good to try new versions for a month and then be able to roll back if 
> the regressions outweigh the improvements.

I'm not sure that there are 'regressions'.  Mostly there are new 
options, and maybe their defaults aren't always autoselected 
appropriately for all sets of hardware.

The main benefit of this remarkable effort is probably maintainability.

John P