[mythtv] Call for testing branch devel/ffmpeg-resync (mpegts-harmonize)
scott.the.elm at gmail.com
Thu Aug 11 18:16:45 UTC 2022
On 8/11/22 05:47, John Pilkington wrote:
> On 02/08/2022 19:44, Scott Theisen wrote:
>> On 8/1/22 10:47, John Pilkington wrote:
>>> Largely as an excercise-for-the-student, I now have a build from
>>> Scott's pull request, labelled 32Pre4276, git f27fd9c, installed and
>>> running. The MHEG menu works on the recent clip, and also on an HD
>>> clip from last year where the cutting had retained the full set of
>> Good to hear that my new version works correctly.
>>> Both show today's date...
>> This is probably intentional since it is intended to be used with
>> live TV. What I think is happening is the MHEG program is calling
>> GetCurrentDate() and then FormatDate() instead of hard coding into
>> the stream what date (and time) it wants formatted.
> Hmm. I now have fixes/32 and devel/ffmpeg-resync both playing the
> same recording-in-progress.
> fixes/32 says it's
> 06:10 on Thursday 20 Jan
> while the newer version shows
> 10:46 on Thursday 11 Aug
That is a bug I fixed in
as part of https://github.com/MythTV/mythtv/pull/564 . I'll see about
backporting it to fixes/32.
The day of the week is from GetDayOfWeek which is for the current time.
However, FormatDate incorrectly used QDateTime::fromMSecsSinceEpoch()
instead of QDateTime::fromSecsSinceEpoch() (note: MS instead of S, so
off by a factor of 1000).
https://www.wolframalpha.com/input?i=1660214760+unix+time is 10:46:00 am
UTC | Thursday, August 11, 2022
https://www.wolframalpha.com/input?i=1660214+unix+time is 5:10:14 am UTC
| Tuesday, January 20, 1970
There should be a daylight saving time offset of an hour to one of
those, so it is as I expect the bug to manifest.
More information about the mythtv-dev