Seeking takes a loong time and sometimes fails on a recording

[faginbagin]

The recording in question is not marked as damaged by mythtv. I used dd to extract the first 5+ minutes and found the same problem when added to my video library. leanfront's progress bar shows the cut as being over 15 hours long while mythfrontend shows a more accurate 5:30. If you try to seek forward 1 minute or backward 20 seconds, it takes about a minute. It might work, or it might end with a "Playback failed" pop up. If you leave playback or are forced to leave because of "Playback failed" and have a last played position, and try to start playback at the last played position, you will have to wait a minute before playback starts or fails.

The 5+ minute cut recording is about 400MB and can be found here:
https://drive.google.com/file/d/1TYdw6icX6oEUrZS3mL2uGPCkc_QNG7mw/view?usp=drive_link

[bennettpeter]

I suspect this is related to androidx/media#855 . That is a bug where the time stamp wraps to zero in the file. They claim it is fixed but I am not convinced. Their fix worked on the demo program but not in leanfront. Since it seemed to be restricted to recordings of over 13 hours, i did not follow up further. I wonder about the time stamp wrapping in the middle of a normal length recording, but I have not had a complaint related to that before, or had a file to test it on.

[faginbagin]

Issue androidx/media#855 makes for interesting reading. Maybe my recording just had the misfortune of catching a wrap around timestamp very near the beginning of the recording and why my 5 minute cut can reproduce the problem.

[bennettpeter]

The sample plays correctly with vlc. With the exoplayer sample app it shows a length of 0:00, which has the effect of preventing seeking. I don't know why there is a difference in behavior. Iwill look into it.

[bennettpeter]

It looks like there is a bogus starting timestamp detected at the beginning of the file. I suspect that if you take the original file, or this file, and strip the first few seconds off that it would work OK. I am still looking into whether this is an exoplayer bug, how to detect the error when it happens, and how to bypass it.

Perhaps the start of the file is corrupted somehow.

If you are able to, please confirm whether stripping off a few seconds at the start avoids the problem.

[bennettpeter]

I made a patch to start at the second timestamp instead of the first, and then the sample plays fine. Shows the duration correctly as 5:32.
See from the values that the first pcr is far off from where it should be
firstpcrvalue = 2627444899 (0x9C9BA0A3)
second = 7567343281 (0x1C30C7EB1)
lastpcrvalue = 7597187842 (0x1C4D3E302)
I don't want to make a permanent change. I don't know the consequence of using the second timestamp instead of the first, and how do I know that the second is perhaps not the incorrect one?

I will open an issue with exoplayer and see what they say.

Try fixing the file by dropping the first couple of seconds.

Let me know if it happens on another file.

[faginbagin]

I have, on occasion, had a similar problem with other recordings. But this one was different. Those other recordings were usually on my PBS station, and if I went to mythfrontend and set a bookmark past the problem point, leanfront could pick up and play/seek/whatever from that point. But that trick didn't work with this recording.

As for cutting out a few seconds from the front, Can you suggest how many bytes? I ask because it's been my understanding that mythtv doesn't start recording until it's got a good starting point, like with the start of a complete packet. Or maybe that's not an issue? Maybe I can figure it out from the recordedseek table?

[bennettpeter]

I suggest remove 100 kB from the front - that will be about 5 seconds. It does not matter if you are not at a logical place - the player should be able to sort it out.

[bennettpeter]

Exoplayer issue is androidx/media#3033

[faginbagin]

Removing the first 100k does the trick. Seeking no longer involves a minute wait and the duration is now in line with reality.

Please keep in mind that seeking is the real issue, not the duration. Waiting a minute between seeks is what makes watching the original recording on leanfront intolerable. The exoplayer issue only talks about duration.

[bennettpeter]

The incorrect duration causes the seek problem. The seek does a binary search through the file and when it has a wrong duration the calculations go wrong.

Strangely, when I tested this in the demo app, the duration was showing the bogus value, but the seek worked correctly without the delays. I don't understand why, either they have changed the seek algorithm in the latest version of ExoPlayer or the fact that I ran the demo app with Apache web server rather than mythbackend.

Since the seek was OK in the demo app I could not complain about it not working.