Mailing List Archive

Play from last played position
Hi all

Ive updated to master last week and have been using it and noticed that
play from last position doesn't seem work. It always plays from the start.

Looking into this, I found that in the recordedmarkup table there are
multiple entries for both LASTPLAYPOS and  BOOKMARK.

Also the query for the last played position grabs these into a QMap
where the key is the frame number and the value is the type. These keys
according to the QMap documentation are sorted in ascending order,
however the frame number is taken as the first element of the iterator
thus the lowest value (close to 0 (80) in this case).

This presents a design question.

1. should there be multiple entries in the recorded markup table per
recording for each type or are multiple ok?

2. If the above is ok, then query should be pulling from the last key
not the first.

What is the intended use and I'll fix this issue?

Using mariadb 10.6 (newly upgraded) but was on 10.2 previously. I don't
think this is a DB issue.

Cheers

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: Play from last played position [ In reply to ]
On Sat, 2022-05-28 at 13:03 +1000, Mark Spieth wrote:
> Hi all
>
> Ive updated to master last week and have been using it and noticed
> that
> play from last position doesn't seem work. It always plays from the
> start.
>
> Looking into this, I found that in the recordedmarkup table there are
> multiple entries for both LASTPLAYPOS and  BOOKMARK.
>
> Also the query for the last played position grabs these into a QMap
> where the key is the frame number and the value is the type. These
> keys
> according to the QMap documentation are sorted in ascending order,
> however the frame number is taken as the first element of the
> iterator
> thus the lowest value (close to 0 (80) in this case).
>
> This presents a design question.
>
> 1. should there be multiple entries in the recorded markup table per
> recording for each type or are multiple ok?

There should only be one LASTPLAYPOS entry per chanid/starttime pair.
I would expect that the BOOKMARK entries should also be one per
chanid/starttime pair.

This should also be true for the filemarkup table for tracking videos.
There should only be one LASTPLAYPOS entry per filename, and I would
only expect one BOOKMARK entry per filename too.

> 2. If the above is ok, then query should be pulling from the last key
> not the first.
>
> What is the intended use and I'll fix this issue?

Thanks.

David

_______________________________________________
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: Play from last played position [ In reply to ]
On 28/05/2022 16:21, David Hampton via mythtv-dev wrote:
> On Sat, 2022-05-28 at 13:03 +1000, Mark Spieth wrote:
>> Hi all
>>
>> Ive updated to master last week and have been using it and noticed
>> that
>> play from last position doesn't seem work. It always plays from the
>> start.
>>
>> Looking into this, I found that in the recordedmarkup table there are
>> multiple entries for both LASTPLAYPOS and  BOOKMARK.
>>
>> Also the query for the last played position grabs these into a QMap
>> where the key is the frame number and the value is the type. These
>> keys
>> according to the QMap documentation are sorted in ascending order,
>> however the frame number is taken as the first element of the
>> iterator
>> thus the lowest value (close to 0 (80) in this case).
>>
>> This presents a design question.
>>
>> 1. should there be multiple entries in the recorded markup table per
>> recording for each type or are multiple ok?
>
> There should only be one LASTPLAYPOS entry per chanid/starttime pair.
> I would expect that the BOOKMARK entries should also be one per
> chanid/starttime pair.
>
> This should also be true for the filemarkup table for tracking videos.
> There should only be one LASTPLAYPOS entry per filename, and I would
> only expect one BOOKMARK entry per filename too.
>
>> 2. If the above is ok, then query should be pulling from the last key
>> not the first.
>>
>> What is the intended use and I'll fix this issue?
>
> Thanks.
>
> David
>

FWIW playback from last played position works ok for me, in current
master.

But the end marker in the cutlist editor has a problem: go to end (Page
Down) goes to frame n, step back from that and forward again (left,
right arrows) goes to n-m, then n+1, and repeated stepping *forward*
from there alternates between n-m and n+1.

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: Play from last played position [ In reply to ]
On 29/05/2022 2:22 am, John Pilkington wrote:
> On 28/05/2022 16:21, David Hampton via mythtv-dev wrote:
>> There should only be one LASTPLAYPOS entry per chanid/starttime pair.
>> I would expect that the BOOKMARK entries should also be one per
>> chanid/starttime pair.
>>
>> This should also be true for the filemarkup table for tracking videos.
>> There should only be one LASTPLAYPOS entry per filename, and I would
>> only expect one BOOKMARK entry per filename too.
>>
>>
>
> FWIW playback from last played position works ok for me, in current
> master.
>
> But the end marker in the cutlist editor has a problem:  go to end
> (Page Down) goes to frame n, step back from that and forward again
> (left, right arrows) goes to n-m, then n+1, and repeated stepping
> *forward* from there alternates between n-m and n+1.

This is all what I expected.

I found my problem.

It *is* mariadb. From 10.2.1 onwards there is a stricter check on the
string used for datetime type for DELETE FROM only. The Z at the end of
an ISO8601 is not allowed. Thus the old bookmark/lastplayedpos was not
being deleted before the new one was injected.

phpmyadmin with EXPLAIN pointed me in the correct direction. Strangely
enough, SELECT, UPDATE, REPLACE all work ok with a Z suffix on the
iso8601 string. The mariadb doco does indicate that trailing Z is not
allowed but the DELETE FROM only behaviour is unexpected.

I have made a PR for further testing as I'm not able to test with mysql.
Merge when you think its ok and delete the feature branch.

Cheers

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: Play from last played position [ In reply to ]
On Sun, May 29, 2022 at 4:55 AM Mark Spieth <mark@digivation.com.au> wrote:

> On 29/05/2022 2:22 am, John Pilkington wrote:
> > On 28/05/2022 16:21, David Hampton via mythtv-dev wrote:
> >> There should only be one LASTPLAYPOS entry per chanid/starttime pair.
> >> I would expect that the BOOKMARK entries should also be one per
> >> chanid/starttime pair.
> >>
> >> This should also be true for the filemarkup table for tracking videos.
> >> There should only be one LASTPLAYPOS entry per filename, and I would
> >> only expect one BOOKMARK entry per filename too.
> >>
> >>
> >
> > FWIW playback from last played position works ok for me, in current
> > master.
> >
> > But the end marker in the cutlist editor has a problem: go to end
> > (Page Down) goes to frame n, step back from that and forward again
> > (left, right arrows) goes to n-m, then n+1, and repeated stepping
> > *forward* from there alternates between n-m and n+1.
>
> This is all what I expected.
>
> I found my problem.
>
> It *is* mariadb. From 10.2.1 onwards there is a stricter check on the
> string used for datetime type for DELETE FROM only. The Z at the end of
> an ISO8601 is not allowed. Thus the old bookmark/lastplayedpos was not
> being deleted before the new one was injected.
>
> phpmyadmin with EXPLAIN pointed me in the correct direction. Strangely
> enough, SELECT, UPDATE, REPLACE all work ok with a Z suffix on the
> iso8601 string. The mariadb doco does indicate that trailing Z is not
> allowed but the DELETE FROM only behaviour is unexpected.
>
> I have made a PR for further testing as I'm not able to test with mysql.
> Merge when you think its ok and delete the feature branch.
>
> Cheers
>
> Mark
>
> I cannot reproduce this issue on

MythTV Version : v32.0+fixes.202205111848.26079f815a~ubuntu22.04.1
QT Version : 5.15.3
mariadb Ver 15.1 Distrib 10.6.7-MariaDB, for debian-linux-gnu (x86_64)
using EditLine wrapper

It looks for me, that this issue is already addressed by the
mysql driver of QT or additional patches from the distribution.

See https://github.com/MythTV/mythtv/issues/490 , too

Roland
Re: Play from last played position [ In reply to ]
>
> This is all what I expected.
>
> I found my problem.
>
> It *is* mariadb. From 10.2.1 onwards there is a stricter check on the string used for datetime type for DELETE FROM only. The Z at the end of an ISO8601 is not allowed. Thus the old bookmark/lastplayedpos was not being deleted before the new one was injected.
>
> phpmyadmin with EXPLAIN pointed me in the correct direction. Strangely enough, SELECT, UPDATE, REPLACE all work ok with a Z suffix on the iso8601 string. The mariadb doco does indicate that trailing Z is not allowed but the DELETE FROM only behaviour is unexpected.
>
> I have made a PR for further testing as I'm not able to test with mysql. Merge when you think its ok and delete the feature branch.
>
> Cheers
>
> Mark

Mark,

You may look https://github.com/MythTV/mythtv/issues/490
Root cause is not in MariaDB - but in Qt5 i think....




_______________________________________________
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: Play from last played position [ In reply to ]
On 29/05/2022 8:46 pm, Piotr Oniszczuk wrote:
>> This is all what I expected.
>>
>> I found my problem.
>>
>> It *is* mariadb. From 10.2.1 onwards there is a stricter check on the string used for datetime type for DELETE FROM only. The Z at the end of an ISO8601 is not allowed. Thus the old bookmark/lastplayedpos was not being deleted before the new one was injected.
>>
>> phpmyadmin with EXPLAIN pointed me in the correct direction. Strangely enough, SELECT, UPDATE, REPLACE all work ok with a Z suffix on the iso8601 string. The mariadb doco does indicate that trailing Z is not allowed but the DELETE FROM only behaviour is unexpected.
>>
>> I have made a PR for further testing as I'm not able to test with mysql. Merge when you think its ok and delete the feature branch.
>>
>> Cheers
>>
>> Mark
> Mark,
>
> You may look https://github.com/MythTV/mythtv/issues/490
> Root cause is not in MariaDB - but in Qt5 i think....
>
You are correct. Similar fix. Different place.

However, given that it has not been merged yet in 5.15 (I checked the
latest 5.15.4), that would mean everyone has to build a new qt for their
dist. This includes ubuntu/debian. That is not really a viable option
for most.

I think it is prudent to put this workaround in until we move to qt6

The MariaDB doc says it was more tolerant of this and just dropped
everything after the Z before 10.2.1

It is good to know that mysql has the same issue so I feel comfortable
that this will fix every installation regardless of the qt version
installed.

Yes it is easy to patch the android build but this doesn't fix any
server issues on my linux system. Debian testing is still on
5.15.2-dsfg-16 which also doesnt have this fix.

Opinions...

Cheers

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: Play from last played position [ In reply to ]
On Mon, May 30, 2022 at 1:18 AM Mark Spieth <mark@digivation.com.au> wrote:

> However, given that it has not been merged yet in 5.15 (I checked the
> latest 5.15.4)

I suspect (but have not verified) that the latest KDE Qt
patches would address this (they include patches
that Qt has accepted upstream (and this looks to be
accepted internally) and not yet released under the
available open source releases and for which people
have nominated for inclusion). So maybe all this
requires is to verify that the patch has been nominated,
and for distro maintainers to include the KDE patches?

Yes, the entire Qt open source release process looks
to be forever broken for legacy Qt releases, but that
may encourage more distros to release the latest and
greatest (Qt6) and move encourage more projects
to support Qt6.

> I think it is prudent to put this workaround in until we move to qt6

The project should do the what it needs to do to
maintain a (sort of) compatibility, but I would
suggest any significant effort likely needs to
be moving to Qt6, even if that means releasing
v33 RSN. There was a proposed set of patches
that just disabled the functionality that had not
yet moved to Qt6 compatibility, but had substantial
pushback from a few as I recall. I am thinking it is
time to gore those oxen, and let the chips fall
(oxen chips, of course).
_______________________________________________
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