Recording watching progress on recordings list

[warpme]

**Is your feature request related to a problem?
No.

Describe the solution you'd like
There are users with habit of watching multiple shows in multiple short sessions.
Before watching - user does election what to watch. It can be based on various criteria - but quite frequently used is: advancement in given recording watching
(pls see see http://warped.inet2.org/12809.jpg (see % and thin progress bars on some rec.)
Additionally - it will be nice when UI can offer dedicated list sorted by "watching progress".

Such functionality was offered already by https://code.mythtv.org/trac/ticket/12809
I have #12809 patches ported to master (they were working well) - unfortunately recent Mark Kendal code improvements made #12809 patches not working anymore.

(For reference here are last working version of #12809 for master):
https://github.com/warpme/minimyth2/blob/55024baae4de4e8600cd3a008a91826ecd9ec59e/script/myth-master/mythtv/files/0305-ticket12809-Enable-Play-from-last-play-position.patch
https://github.com/warpme/minimyth2/blob/55024baae4de4e8600cd3a008a91826ecd9ec59e/script/myth-master/mythtv/files/0307-ticket12809-Playback-Watchlist-Improvements.patch
https://github.com/warpme/minimyth2/blob/55024baae4de4e8600cd3a008a91826ecd9ec59e/script/myth-master/mythtv/files/0308-ticket12809-Playback-Add-Unfinished-recording-filter.patch

#12809 offers also some other improvements. We may split all extra functionality into groups and add them group-by-group (or add only some of them)...

[linuxdude42]

Screenshots showing progress information in the "Scheduled Recordings" and "Watch Recordings" screens.

[kmdewaal]

Hi David, I do not know if you appreciate comments but here it is anyway.

I would like a progressbar below the preview picture, spanning the width of the picture. It looks like there is already support for it in the code but I do not see it in the screenshot.
I do not like the percentage being appended to the title. It is confusing because the percentage is not part of the title, and it does not like good because it is on a different position on each line. Instead, it would look much better if it has a column of its own just like date, time, cardid and everything else. This then also removes the need for the () brackets which saves another 2 positions.
This of course requires changing the theme. Users do have their own, slightly modified, themes so the new code should still work with the current MythCenter-wide theme to avoid breaking user systems.

Klaas.

[linuxdude42]

Hi Klaas,

The progressbar that you see in the xml for the recordings screen is for the disk space indicator in the upper left corner of the screen.

The positioning of the display items is mostly from the work Roger Siddons did five years ago. Putting the progress bar in the space below the preview picture would be nice, but that space is already allocated. The preview picture and the cover art share the same 320x240 area in the lower right corner, and that takes up all of the space to the right of the description and above the status icons. I have a sample of what it could look like with a separate column for the percentages...

David

[kmdewaal]

Hi David, This looks good to me. I suggest to use this for the v32 release, and forget the progressbar for a while. From my point of view the icons at the right/down corner are not that useful but probably people like them, but they could move to the left/bottom corner. Or put in in the "i" popup window. Which would give space for the progress bar. But that kind of change requires a lot of alignment so we could put it on the agenda for the next release. Klaas.

…

On Mon, 10 Jan 2022 at 23:35, David Hampton ***@***.***> wrote: Hi Klaas, The progressbar that you see in the xml for the recordings screen is for the disk space indicator in the upper left corner of the screen. The positioning of the display items is mostly from the work Roger Siddons did five years ago. Putting the progress bar in the space below the preview picture would be nice, but that space is already allocated. The preview picture and the cover art share the same 320x240 area in the lower right corner, and that takes up all of the space to the right of the description and above the status icons. I have a sample of what it could look like with a separate column for the percentages... David [image: Screenshot from 2022-01-10 17-33-23] <https://user-images.githubusercontent.com/26783531/148849579-d41ead55-2a54-4f52-8baa-1e640b93f7ee.png> — Reply to this email directly, view it on GitHub <#331 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACQBJGADESMKEOQXEA4X5JLUVNNJRANCNFSM4ZAC6L4Q> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you commented.Message ID: ***@***.***>

[warpme]

Guys,

What about strategy with:

1. let code be capable to offer max capabilities
2. what & how user see is dependent on theme (with capability that current themes shows no new functionality and new functionality not breaks anything on new-functionality-non-aware themes)

With this we will:
-have max flexibility
-allow nice UX customisations
-potentially(?) attract for new ppl looking on themes

My comments regarding above UI discussion:

-imho UX where user sees 2 types of info (title & progress) in single place (progress bar is background of title) is more ergonomic than UX where those 2 infos are in different parts of UI (so user need move focus to different UI region then go back)

-idea with separate colon for % progress - albeit looks nice - for recording with 0% progress has drawback of reducing title length (so we are reducing UI provided info without any benefit coming from this reduction).

[kmdewaal]

I think the "watch viewing progress on recording" should only be on the "Watch Recordings" page. It does not make much sense to put it in the "Scheduled Recordings" page. Note that also other information about the recording which is shown with icons in the right/bottom corner in the "Watch Recordings" page is not present in the "Scheduled Recordings".

[warpme]

David,
I give try on this code on quite weak device (Allwinner H6 tvbox) and performance is really good. Nice work!

One Q:
going to upcoming rec. screen i see nice progress for currently ongoing recording. This is nice enhancement as tells to user how given ongoing recording is progressed.
But going to recordings list screen and looking on on-going recordings - there is no progress.

It will be really good to have progress bar also of on-going recordings on also on recordings list screen.

[linuxdude42]

Hi Piotr. I'm not sure which screen you're referring to. Is it the "Manage Recording Rules" screen? If so, I might be able to make a progress bar work for single recordings, but I don't think it would for a "Record All" recording. I would need to explore how that code is designed.

[warpme]

David,

Pls look on my upcoming recordings screen:

On green is on-going recording. Pls note percentage & thin line of progress at title bottom.

Here is recording list:

And here is no percentage nor progress.
It would be nice have here the same percentage & progress (like we have in upcoming screen)

[linuxdude42]

I've updated the code for the Watched Recording page to provide progress bars for both the percent recorded and the percent watched. Here's a screenshot with an example of their usage. The per-show buttons also support both recorded and watched percentages, although this only shows the watched percentage. Recorded percentage only shows up while the show is actually recording.

I also changed the percent recorded number in the bottom half of the Scheduled Recordings screen to be a progress bar. The per-show buttons here only support a recorded percentages.

[linuxdude42]

Overlaying both progress bars on a currently recording show...

[kmdewaal]

The background of the titles that have a percentage is black instead of the blueish background (of MythCenter-wide). This black background is on my system not exactly the same length as the title, or exactly the area reserved for the title, but somewhere halfway. In the screenshot of "Scheduled Recordings" of "The Late Show With Stephen Colbert" this black background is shown across the full title. I think the correct behaviour is to have the standard blueish background and not change the background.

[kmdewaal]

It looks like the percentage is computed from the recording file size. I usually record about 20 minutes after the scheduled end time of the program. This means that when the program has been viewed until the end that the percentage shows "65%" or so.
I think it would be better if the percentage is computed relative to the scheduled program starttime and endtime. Then it would show 100% when the recording has been viewed to the end of the program.

[kmdewaal]

This screenshot shows both the partial black background of the program title and the 65% for a recording viewed to the end.

[kmdewaal]

I figured out a little bit later that there is a correlation between the length of the black bar behind the program title and that this is actually a progress bar. Which means that the progress of one program is now shown at three places: for each program as a background progress bar and as a percentage and for the selected recording also progress bar plus percentage at the bottom.
This is for me one progress bar too much.

The progress bar behind the program title can be easily removed by deleting the <progressbar name "buttonprogress1"> starting at line 197 in recordings-ui.xml
I suggest to apply the "progress bar behind program title" feature only the more experimental themes and not in MythCenter-wide for release version 32.

This then leaves the "65% watched" as the remaining bug. As said, it gives wrong information because it currently does not refer to the actual program. When a program is watched until the end the correct message is that it is 100% watched, not 65%.

[kmdewaal]

This shows another bug: the 100% after the program title cannot be displayed and instead 1... is shown. It looks like the field for the percentage needs to be a little bit bigger so that it an accommodate 100%.

Another issue is the location of the progressbar, the one that is showing here "100% recorded". This is shown on the same line as the program title. Not shown here, but if the program title is long enough to fill the whole line then the progressbar and the end of the title are drawn overlapping. This is an error. There are two solution: reduce the size of the area for the title or move the progressbar.
In the "Watch Recordings" page the recording progressbar is shown at the left/bottom corner. I suggest to move the recording progressbar in the "Upcoming Recordings" also to the same position. It is IMHO good user interface design if the same information can be found at the same place in different pages.
Note that in the "Upcoming Recordings" the field has to be moved to a position 10 units lower so that it will be horizontally aligned with the "1 (All) 2(Important)" text that is shown at center/bottom. It just looks bad if it is presented slightly higher.

[kmdewaal]

I think I found another bug. My living room is, since the year 0 or thereabouts, configured such that when you exit watching a recording the position is saved as a bookmark and when the playback is started again it continues from where it was.
This does NOT work all the time anymore; a lot of times when doing exit it seems to lose its current position and the next time playback is started it is from the initial position, not from the position when last exited. Also the bookmark icon is gone most of the time.
When I explicitly create a bookmark then playback will start from that bookmark, but this is not something I want do do each time playback is exited.

Note that I do like this feature and I do appreciate all the work that has gone into it but it is just not yet ready.

[kmdewaal]

Definitely progress, thanks! But we are not there yet.
Fixed issues:

• Title background in Watch Recordings and Scheduled Recordings is now again just background and not progressbar. OK.
• Position of "recorded" progress bar in Scheduled Recordings is now at the left/bottom corner. OK.
• Playback position is saved on playback exit. OK.
  New issues:
• In Scheduled Recordings the percentage is not horizontally aligned with the title and the card id, but it is a few pixels lower. This is already visible in the Scheduled Recordings screenshot on the line where "The Late Show With Stephen Colbert" is shown and on my screenshot with "Geplande Opnames" (Dutch translation) the first three recordings shown.
• Preview/thumbnail picture at right/bottom is from the wrong time. The previous, and correct, behavior is that on playback exit the preview/thumbnail picture is updated from what is shown at the moment of playback exit. In the current version the preview picture is updated but from a different position. This is a regression.
  Old issues not yet fixed:
• Percentage relates to file size and not to program start- and endtime. I will write a separate comment on this.

[kmdewaal]

About percentages for recording and playback.

The user, and that is here the person with a remote control that uses MythTV, does select a program to play and can play this program until the end of the program. On the app from a streaming service there is a progress bar below the preview picture and the progressbar is at 100% at the end of the program.
From the users perspective MythTV is just a streaming service but with the server in the attic instead of somewhere in the cloud and from this perspective the start of the program is 0% and the end of the program is 100%.

In MythTV there is some of uncertainty about the exact start time and end time of a program. With good quality EIT guide information the start times are usually within a minute or so but there can be bigger variations, especially with live sports events.
Therefore MythTV has the capability to start recording before the scheduled start of the program and to keep on recording for a while after the end of the program.
This does not change the users's perspective on the program; the program start is still 0% and the program end is still 100%. It does not make sense to change the number that indicates the end of the program, the 100%, when the amount of minutes that is recorded after the end of the program is changed.
It is purely the developers perspective that the end of the program can be at 60% of the file and that this is a meaningful number. It is not a meaningful number for users.

So the the question is what to do with the use case David Hampton mentioned, where a sports program starts much to late and 100% is only 15 minutes into the program. I think the obvious solution is that the percentage should not be clipped at 100% but that program start time and end time define 0% and 100% and from that any position in the file a percentage can be computed that identifies the position in the file.
When the scheduled start time and end time is exact then the program runs from 0% to 100%
When the program extends to after the scheduled end time then the program runs to more than 100%. Which makes perfect sense to me.

Hope this helps,
Klaas.

[paul-h]

If the actual recording time including any start early or end late is say 100 minutes then if you watch 10 minutes then you should be at 10% into the recording. If the recording is still in progress then you still take the predicted end time as 100%. Does that make sense?

[kmdewaal]

The first line of the "Upcoming Recordings" is already beyond the scheduled program end time.
The percentage at the right is shown at "1....".
The progressbar below/left shows "100%".

As argued before, it makes perfect sense to me that 100% marks the moment that the program has been recorded and that percentages bigger than 100, say 105% for this recording, is shown to indicate that the post-roll is being recorded.

So I suggest the following:

• do NOT change the computation of the percentage here!!!
• make room for 3 digits in the percentage field, so that 100% and also 105% and bigger can be displayed properly
• do not clip the value at 100% so that the actual value, e.g. 105% and bigger can be displayed.
• the progressbar below/left can be fully green at 100%, with bigger values only the number changes.

Note that this screenshot also shows that the percentage at the end of the line is shown a few pixels too low.

[paul-h]

How can a recording be 105% long? Surely the biggest it can be is 100% long. Just add up the pre roll time + the scheduled recording time + the post roll time and say that is 100%?

[kmdewaal]

How can a recording be 105% long? Surely the biggest it can be is 100% long. Just add up the pre roll time + the scheduled recording time + the post roll time and say that is 100%?
Of course that is possible. As written a few posts above, my preference is to have the end of the scheduled program recording at 100% and then recording the post roll will have bigger numbers. The advantage of this is that you can see in the Upcoming Recordings whether the recording of the program has finished, namely at 100%, without having to know the amount of post-roll chosen for that program.

[Jpilk]

But... you only have a post-roll because you aren't confident that what you want will end at the scheduled time. And if recording has ended, in my experience it won't be on that screen anyway. :-)
I haven't normally used 'restart where you finished' anyway, but I'll see how it goes.

[kmdewaal]

But... you only have a post-roll because you aren't confident that what you want will end at the scheduled time. And if recording has ended, in my experience it won't be on that screen anyway. :-)

I have a post-roll for everything just in case. And yes, if the recording has ended then it is gone but then you do know that the recording is finished. I really do like the recording progress and I think it is more informative to have the 100% marking the scheduled end time of the program, excluding the post roll. I have a fixed amount of 20 minutes post roll for everything so that means that to see if e.g. 65% is the end of the program I need to know the scheduled length of the program and then do the mathematics to see if the program is already recorded. I do use this information to see whether it is safe to reboot the backend for instance.

[kmdewaal]

Preview/thumbnail picture at right/bottom is from the wrong time. The previous, and correct, behavior is that on playback exit the preview/thumbnail picture is updated from what is shown at the moment of playback exit. In the current version the preview picture is updated but from a different position. This is a regression.

This is fixed now.

[paul-h]

It still makes more sense to me to have a simple 0 - 100%. It seems crazy to me that the recording progress can reach 100% but the recording has not finished recording \0/ Am I alone in thinking this?

On a more serious note the Watch Recording screen is a pretty important one in MythTV so if this is not ready for inclusion in the pending 32.0 release then it should be removed or disabled until after the release and we will have to work on the quirks later.

[linuxdude42]

I also think that recording progress should include the entire time that MythTV is copying frames from the encoder to the disk, not the scheduled time of the recording (which may or may not be correct).

[gigem]

The actual amount of post-roll to be used is not knowable until after the recording ends. Those who use ridiculously, high values of post roll instead of end-late deserve to get erratic results before that time. David -- David Engel ***@***.***

[warpme]

Just my 0.02$

From good UX design practices:
-any design decision leading UX user to questions or doubts is imho bad decision
-progress above 100% is usually perceived as error or issue (unless user contextually knows > 100% means something valid so user is prepared)

I see Klaas point with passing extra info to user.
If i looked on progress from new user perspective (all v32 users i think) - most intuitive for me is align 0..100% progress with total recording on disk (so NOT include pre/post-roll).

why not include pre/post-roll in progress?

because doing this correctly for all cases (so many different cases like show begins earlier than; end later; etc) will create more user questions than perception of: hey, this is nice enhancement.

to pass per/post-roll i.e. we can go with:

• bookmark in pre-roll: "<0%"
• bookmark in not in per/post-roll: "0..100%"
• bookmark in post-roll: ">100%"

[Jpilk]

Using EIT in the UK: Channel 5, for example, often schedules a news bulletin within a film. If I notice, (it isn't automatic), I will extend recording of part 1 and ignore part 2. An inappropriate calculation could easily give 300%. Then, after cutting, ...?

[kmdewaal]

Summing this up, although I do like the feature, it looks like it is not yet mature enough to put in the v32 release. Given that the code does work with the old/unmodified MythCenter-wide there is no need to revert the code changes.

Therefore, a possible way forward is the following:

• Keep the new code in master so it will also be in the v32 release
• Keep the old MythCenter-wide, so without the changes from this ticket
• Create a new theme, e.g. MythCenter-NextGen or so, that does contain all the theme changes
  This way, users running v32 can use the new theme if they want. There is a Theme Chooser for that.

As I understand it, the plan is to have a v33 release about a half year from now so that is a good period to get feedback from the users and to reach consensus on the desired behavior and to have enough time to properly implement and test it.

[linuxdude42]

I take offense at that comment. Yes, there is an ongoing discussion about the meaning of 100%, but that doesn't make the feature any less mature.

Two other ways forward:

1. leave the feature as is, and ship it in the V32 release
2. give users a knob so they can decide what 100% means, and ship it in the V32 release

[kmdewaal]

David, do what you want. I think I have said enough and maybe more than that; I will keep quiet. May the force be with you!

[warpme]

Hmm

"is not yet mature enough" - forgive me but i disagree.

Lack of consensus is lack of consensus - not lack of immaturity imho.

Intuition tells me:

user poll with q: do you prefer

a\feature provides you enhancement but you probably will soon discover subjectively better realisation of this feature is possible

b\no this feature - because you may discover feature might be realised subjectively better for you

i think a\ will win.

issue is in subjectivens (so thats why no consensus i think)

Side effect of selecting a\ for devs will req. for change/enhancement.

imho this seems to be even desired in alive project - isn't?

[kmdewaal]

It could be that I am the only one experiencing this, but the recording percentage shown when the post-roll is being recorded is shown as "1..." in the Upcoming Recordings page on the line of the recording. It is shown as "100%" in the progress bar on the bottom.
See the screenshot I posted 10 days ago. Maybe it could be fixed before the "final cut" of version 32 if there are more people experiencing it. Or maybe it is intentional to indicate 100% or more.

Note that the percentage is now shown correctly aligned horizontally, i.e. not too low like in the screenshot.

About putting this feature in version 32. My wife does like it very much and does absolutely not care about the percentage numbers having a different meaning when recording and when not recording anymore or playing back.
Also there have been no regressions observed while this all ran in my living room.
So yes, I now think it is a good idea to put it in version 32.

[linuxdude42]

Hi Klaas. No its not just you. I was looking on the wrong screen last time you mentioned that problem. I see the problem as well on the Upcoming Recordings page, and have a fix coming soon. Thank you for all your testing, and your suggestions for the placement and alignment of the data.

[kmdewaal]

Just for inspiration, this is the recordings-ui.xml and schedule-ui.xml from my living room, based on today's master. It contains fixes to get the percentage displayed properly and of course also adjustments to other fields to make it all fit. It also contains other changes that I like, such as disabling dynamic background pictures which is something that reduces the readability. All changes are annotated.

mcwide-kdw.zip

[kmdewaal]

I am currently toiling on the Dutch translation.. but it looks like the "xx% recorded" and "xx% watched" cannot be translated.
If my understanding is correct, the strings "watched" and "recorded" are defined in recordings-ui.xml (lines 485: %|recordedpercent|%% recorded and line 500: %|watchedpercent|%% watched) and are thus not subject to Qt translation.
The text in the progressbar in the left/top corner, which shows the disk usage, is defined by the program code and can be translated. Possibly the same way of programming could be used for the "recorded" and "watched" progress bar texts.

[linuxdude42]

I don't think that's correct. I see other template strings like "Keep at most %n episode(s)" that only exist in the themes directory. I think the question is why did the tool that generates the themes/themestrings.h file not pick up the new template strings.

[kmdewaal]

On Sat, 12 Feb 2022 at 16:23, David Hampton ***@***.***> wrote: I don't think that's correct. I see other template strings like "Keep at most %n episode(s)" that only exist in the themes directory. I think the question is why did the tool that generates the themes/themestrings.h file not pick up the new template strings. — Reply to this email directly, view it on GitHub <#331 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACQBJGEHZMALIYPDSAJNXZTU2Z3NNANCNFSM4ZAC6L4Q> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you modified the open/close state.

Hi David, thanks for looking into this. Then it could just be that Nick has generated the strings to be translated before this feature was committed, or that the tool has an issue.

…

Message ID: ***@***.***>