cutlist editor not correctly displaying current position in recording

[white-haired-uncle]

• Platform:

Debian 13
Linux hawkeye 4.18.0-553.58.1.el8_10.x86_64 #1 SMP Thu Jun 26 15:50:39 UTC 2025 x86_64 GNU/Linux

• MythTV version:

Please attach all output as a file in bug reports.
MythTV Version : v36-Pre-540-g0d422b0dbc
MythTV Branch : master
Network Protocol : 91
Library API : 36.20250212-1
QT Version : 5.15.15
Options compiled in:
 linux profile use_hidesyms using_alsa using_oss using_pulse using_pulseoutput using_airplay using_backend using_bindings_perl using_bindings_python using_bindings_php using_dvb using_firewire using_firewire_linux using_frontend using_hdhomerun using_iptv using_satip using_vbox using_ceton using_joystick_menu using_libcrypto using_gnutls using_libdns_sd using_libxml2 using_lirc using_mheg using_opengl using_egl using_qtwebengine using_qtscript using_qtdbus using_sqlite3 using_taglib using_v4l2 using_v4l2prime using_x11 using_system_libexiv2 using_system_libbluray using_system_libudfread using_systemd_notify using_systemd_journal using_drm using_bindings_perl using_bindings_python using_bindings_php using_freetype2 using_mythtranscode using_opengl using_egl using_drm using_vaapi using_nvdec using_vdpau using_qtwebengine using_ffmpeg_threads using_mheg using_libass using_libxml2

• Package version:

• Component:
  mythfrontend

What steps will reproduce the bug?

Recording is here:
https://mega.nz/folder/NrE3CI7D#kLOELT2BYUFGX6h69yDgNw

1. At 0:08, edit, cut to beginning
2. Skip ahead 6 minutes if desired
3. Watch until 7:06. With subtitles on, the sub for the theme song will show before the music starts.
4. Edit, create cut point.
5. Set skip to 20 seconds, skip ahead twice using right arrow
6. Note the time is 7:46 (I do not believe this is correct, and this I believe is the important part), the scene is a dark street.
7. Set skip to 5 seconds and skip backward, counting steps. This step is not consistent, you may end up at the beginning of the cut (7:06) after 8 skips, or it may take many more than 8.
8. From 7:06, skip forward 5 seconds x8.
9. Note that you are at 7:46 (I believe this is the "real" 7:46). Not on a dark street, but in a commercial.
10. Skip ahead 5sec x 7 to 8:21, returning to the approximate scene in step 6.

A. Delete cut list, exit, watch recording from beginning.
B. Repeat steps 1-6 above
C. Exit edit mode and watch from "7:46". Strange things happen, including temporary loss of sound.

How often does it reproduce? Is there a required condition?

For this series, I always see it at the first commercial break. I should note that this series looks pretty bad, like they're running as little bandwidth as possible. Any motion leads to blockiness in the recording (it's not just mythtv). I haven't noticed what I would all errors (with possible exception of subtitles, I don't know if they are errors or just mistakes, but there's some that just aren't right), just really poor picture quality.

For another series (since forgotten), I saw it consistently at either the last commercial break or the beginning of the end
credits - I forget the details but the important part is it was always at the same place (near the end) FOR THAT SERIES.

What is the expected behaviour?

Skipping ahead 40 seconds should land me about 40 seconds farther into the recording (with a little wiggle room for "keyframes" or whatever the term is), and skipping back the same amount should take me back to roughly where I started.

What do you see instead?

Additional information

MariaDB [mythconverg]> select * from recorded where chanid=2134 and starttime=20250429190000 \G
*************************** 1. row ***************************
         chanid: 2134
      starttime: 2025-04-29 19:00:00
        endtime: 2025-04-29 20:00:29
          title: The Unit
       subtitle: Hero
    description: A new team member joins the unit; Jonas coaches Betsy before her media tour.
         season: 4
        episode: 15
       category: Drama
       hostname: hawkeye
       bookmark: 0
       lastplay: 1
        editing: 0
        cutlist: 1
     autoexpire: 0
    commflagged: 0
       recgroup: Default
       recordid: 1333
       seriesid: EP00753792
      programid: EP007537920063
        inetref: 
   lastmodified: 2025-10-09 15:57:05
       filesize: 666712108
          stars: 0
previouslyshown: 1
originalairdate: 2009-03-08
       preserve: 0
         findid: 0
  deletepending: 0
     transcoder: 0
    timestretch: 1
    recpriority: 0
       basename: 2134_20250429190000.ts
      progstart: 2025-04-29 19:00:00
        progend: 2025-04-29 20:00:00
      playgroup: Default
        profile: Default
      duplicate: 1
     transcoded: 0
        watched: 0
   storagegroup: Default
 bookmarkupdate: 2025-10-09 15:53:31
     recgroupid: 1
     recordedid: 15933
      inputname: Input 1


MariaDB [mythconverg]> select count(offset) from recordedseek where chanid=2134 and starttime=20250429190000;
+---------------+
| count(offset) |
+---------------+
|          8344 |
+---------------+

[kmdewaal]

The issue can be reproduced easily with the recording provided. Just skipping back and forth in the cutlist editor with the interval set to 1 minute is enough; the picture shown is not consistent with the position.
My own recordings do position correctly, but these are today usually H264 and with a fairly high bitrate.
My best guess at this moment is that the really low quality of the recording (low bitrate, long GOP) induces MythTV to go wrong.

[kmdewaal]

Version fixes/35 is OK, it does NOT have the cursor position problem.

[kmdewaal]

The difference in behaviour between fixes/35 and master on my Intel laptop is caused by differences in environment variable settings.
In order to get Qt6 to work with VAAPI the following setting is needed:

export MYTHTV_NO_EGL=1
export LIBVA_DRI3_DISABLE=1

After removing these two environment variables also mythtv master does NOT have the cursor position problem.
This does mean that the cursor position problem is not a problem in the cutlist editor code but that it is really a problem deep in the graphic layers.

[kmdewaal]

@white-haired-uncle please comment on the above analysis.

Also: the problem in using mythcommflag --rebuild for video files has been found and will be fixed.

[white-haired-uncle]

I haven't really been able to follow. I THINK the video stuff turned out to be something else, and "the cursor problem" is the original issue, which you see only on my sample and only with master and the environment variables for qt6/vaapi?

I'm on a not terrribly old master, no qt6, no vaapi (I use ffmpeg for playback). I haven't tried v35, but I could.

[kmdewaal]

I do not see difference between behavior on master and v35 so no need to try that.
My current thinking is that this is bug somewhere deep in the video output and not in the cutlist editor code.
This would mean that the cutlist editing itself is correct but that the picture shown while editing is wrong.

[white-haired-uncle]

I'm going to do a lossless transcode while making a cut (end) at 0:07:46 (the spot where the cutlist editor seems to show the wrong video in my first post). I noticed this, which seems really minor but could indicate maybe the math is not done the same way everywhere:

2025-11-04 11:27:51.384775 I [3422/3422] CoreContext mythtranscode.cpp:622:main  Honoring the cutlist while transcoding
2025-11-04 11:27:51.388985 I [3422/3422] CoreContext mpeg2fix.cpp:784:InitAV  Opening /mythdata/recorded1/2124_20250429190000.ts
2025-11-04 11:27:51.396200 I [3422/3422] CoreContext mpeg2fix.cpp:61:my_av_print  PES packet size mismatch
2025-11-04 11:27:51.396221 I [3422/3422] CoreContext mpeg2fix.cpp:61:my_av_print  Packet corrupt (stream = 1, dts = 3720446202).
2025-11-04 11:27:51.396953 I [3422/3422] CoreContext mpeg2fix.cpp:61:my_av_print  Input #0, mpegts, from '/mythdata/recorded1/2124_20250429190000.ts':
2025-11-04 11:27:51.396975 I [3422/3422] CoreContext mpeg2fix.cpp:61:my_av_print    Duration: 01:00:27.77, start: 37711.091133, bitrate: 1470 kb/s

According to the FE, the recording is 01:00:26, not 01:00:27.77

[white-haired-uncle]

From the (lossless) transcode log, looking at the cut points I created at 0:08, 7:06, and 7:46. Dividing by 29.97 which should be the fps, the cuts seem to be in more or less the correct place (the 7:06 one may be actually about 7:07.23, I'm chalking that up to keyframes unless there's a reason to dig any deeper there).

2025-11-04 11:27:51.411961 I [3422/3422] CoreContext mpeg2fix.cpp:2360:Start  Del map found 0 at 244 (244)
2025-11-04 11:27:51.502357 I [3422/3422] CoreContext mpeg2fix.cpp:1873:ConvertToI  Converting frame #14 from B to I 
2025-11-04 11:27:51.510074 I [3422/3422] CoreContext mpeg2fix.cpp:1873:ConvertToI  Converting frame #15 from B to I 
2025-11-04 11:27:51.524060 I [3422/3422] CoreContext mpeg2fix.cpp:1873:ConvertToI  Converting frame #16 from P to I 
2025-11-04 11:27:51.539104 I [3422/3427] MPEG2Replex multiplex.cpp:857:init_multiplex  Mux rate: 3.16 Mbit/s
2025-11-04 11:27:53.232887 I [3422/3422] CoreContext mpeg2fix.cpp:2360:Start  Del map found 1 at 12804 (12804)
2025-11-04 11:27:53.261161 I [3422/3422] CoreContext mpeg2fix.cpp:1873:ConvertToI  Converting frame #0 from B to I 
2025-11-04 11:27:53.318808 I [3422/3422] CoreContext mpeg2fix.cpp:2360:Start  Del map found 0 at 13982 (13982)

watching the recording after transcode, after the cut I end up at step 9 in the original post.

Seems to me to confirm:

This would mean that the cutlist editing itself is correct but that the picture shown while editing is wrong.

[white-haired-uncle]

Ran into something that might be interesting. Another program on a different channel, broadcast in 720p with a much better picture quality sometimes shows this issue right at the end. At the end of a certain episode I just watched, right as the credits start, I pause, edit, go back 0.5 seconds to set my cut to end, but the picture doesn't change. Keep going back like 20 times until it finally changes, and then I can skip forward 7 times to return to the beginning of the credits.

Here's the interesting part. Another episode, which will be recorded, follows on the same channel. Myth will start the next recording several seconds early (and/or end the first late, maybe both?), so I have another recording that recorded the same sequence of events for the same program at the same time using the same tuner. On that recording, I can move around the same area in the cutlist editor and the video doesn't freeze in one place and then jump.

Not sure if I described that clearly. The episode ends with a character saying "I have a story to tell", and then the credits start. That same sequence exists at the end of recording A and at the beginning of recording B, but I only see weirdness when editing recording A.

P.S. Can't imagine it would make a difference, but A and B are on different storage directories ( /export/video2 and /export/video, respectively).

[white-haired-uncle]

Playing around with iptv. I've found that myth does not handle positioning (cutlist or not) in these files very well (to the point of regular segfaults, working on gathering info for a separate issue there). Granted, there's some thing(s) off about these files, but myth sees issues where vlc works fine.

In this case, which might(?) be related to this issue, edit this recording, around the 18:00 mark. Try moving forward and backward by 1 second. I don't know what is going on, but the OSD indicator says we're moving forward 0.235 seconds at a time and backward 5.0 seconds.

https://mega.nz/file/tnF0ABzL#tMKKufKRYnTivn7nCiQfXFUFgnW-VoM2avpFuYFRzWw

P.S. It's not just that file. Same thing on other recordings. Noticed these are logging to the terminal where I started the fe:

2025-11-26 19:26:25.632016 I  ScreenSaverX11: Uninhibited screensaver
2025-11-26 19:26:25.632482 I  ScreenSaverX11: DPMS Reactivated 1
2025-11-26 19:26:57.076501 I  AFD: Frame rate 30.00 rounded to nearest standard rate 30.00
2025-11-26 19:26:57.454212 I  AFD: Frame rate 30.00 rounded to nearest standard rate 30.00
2025-11-26 19:26:57.661375 I  GLVid: New frame format: None:None 1216x684 (Tex: 2D) -> YUV420P:YUV420P 1216x684 (Tex: 2D)
2025-11-26 19:27:12.820180 I  AFD: Frame rate 30.00 rounded to nearest standard rate 30.00
2025-11-26 19:27:12.958370 I  GLVid: New frame format: None:None 1280x716 (Tex: 2D) -> YUV420P:YUV420P 1280x716 (Tex: 2D)
2025-11-26 19:27:14.087518 I  AFD: Frame rate 30.00 rounded to nearest standard rate 30.00
2025-11-26 19:27:14.183774 I  GLVid: New frame format: None:None 1216x684 (Tex: 2D) -> YUV420P:YUV420P 1216x684 (Tex: 2D)

[kmdewaal]

I can reproduce the forward/backward behaviour with the cutlist editor on your recording.
When set to 1 second, backward goes per 5 seconds and forward goes per second. To be investigated.

I also tried playing this file with vlc. This plays OK but vlc cannot determine the playing time; end time is 0.0 in the GUI.
There are also loads of error messages from vlc about decoding erors and timestamp conversion errors.

It looks like the greatest source of unhappiness, both for mythtv and vlc, are the discontinuities between the actual program, the commercials and the "Pluto" intermezzo's. MythTV tries to synchronize audio and video but maybe this should not be done with these files.