Thanks for reporting! I'll submit a fix for this problem. Note that the duration estimation will still be broken for files longer than 26.5 hours, but this duration is increasingly unlikely to occur in practice.

I have upgraded to version 1.2.1. The fix has made things worse. On a 14 hour ts file the video length is shown correctly, but seeks are extremely slow. Seek forward 1 minute takes 30 seconds or more while the screen shows a spinning progress bar. A seek 1 hour into the 14 hour video showed a spinning progress bar for 5 minutes before I gave up waiting.

With a 13 hour ts file, seeks are fine. Seek forward 1 minute takes 1 second and seek forward 1 hour takes about 1.5 seconds.

When I test this with the 14 hour file I created, seeking behaves normally. Are you able to share the file you have? You can send a Google Drive link or similar to [email protected] and report back here if you've done that.

I sent the email.

To create the 13 hr ts file run this
ffmpeg -f concat -safe 0 -i 13_hr.txt -c copy TS_13_hr.ts
To create the 14 hr ts file run this
ffmpeg -f concat -safe 0 -i 14_hr.txt -c copy TS_14_hr.ts
Everything works with the 13 hr file, but with the 14 hr file seeks do not work.

When attempting seek with the 14 hr file, logcat shows an unending stream of messages "Target buffer size reached with less than 500ms of buffered media data.".

2024-01-31 09:07:57.235 22506-22650 DefaultLoadControl      org.mythtv.leanfront                 W  Target buffer size reached with less than 500ms of buffered media data.
2024-01-31 09:07:57.246 22506-22650 DefaultLoadControl      org.mythtv.leanfront                 W  Target buffer size reached with less than 500ms of buffered media data.
2024-01-31 09:07:57.257 22506-22650 DefaultLoadControl      org.mythtv.leanfront                 W  Target buffer size reached with less than 500ms of buffered media data.

I can't reproduce this problem I'm afraid. And I also don't see the mentioned Target buffer size reached with less than 500ms of buffered media data. error message while playing the 14 hour file.

Given the error message, could it be related to how your DefaultLoadControl is configured? This usually only happens with a large back buffer and a very small configured maximum buffer size that isn't sufficient to hold enough data.

I tried the demo application of media with the latest version from main. It shows the length of all of the TS files as 0, even the 1 hour file, and does not allow seeking on any of them. I don't understand this, it was working before on files up to 13 hours. On my own application, using v 1.2.1 it gets the correct length and seeks on files up to 13 hours.

This is not an important bug to me. Recordings of longer than 6 hours are not normally supported, so I am happy to leave this as is. If you want to pursue it further I can give you any assistance you need.

I tried the demo application of media with the latest version from main. It shows the length of all of the TS files as 0, even the 1 hour file, and does not allow seeking on any of them. I don't understand this, it was working before on files up to 13 hours.

I'm also testing on the main branch and everything seems to work just fine, both for files below and above 13 h duration... Are you sure this is an unmodified checkout of the library demo app? Or is there is anything else that is special about how you built the demo app for testing?

I cloned from github the androidx/media repository. I did a pull of the main branch and I made 2 changes to make it work. One change to add my sample videos to the list, and one change to allow Clear Text Traffic, as I do not have https on my server. I an using Android Studio Giraffe 2022.3.1. I am testing with an "onn 4K streaming Box", latest version with Google TV.
I also tried with checking out the 1.2.1 tag (that is the version I am using in my app). I have attached a screenshot that shows where it has zero length and forward and back skip disabled, with the 1 hour ts file.

diff --git a/demos/main/src/main/AndroidManifest.xml b/demos/main/src/main/AndroidManifest.xml
index da13a42ca4..9bd126a8a7 100644
--- a/demos/main/src/main/AndroidManifest.xml
+++ b/demos/main/src/main/AndroidManifest.xml
@@ -41,6 +41,7 @@
       android:allowBackup="false"
       android:supportsRtl="true"
       android:name="androidx.multidex.MultiDexApplication"
+      android:usesCleartextTraffic="true"
       tools:targetApi="29">
 
     <activity android:name=".SampleChooserActivity"
diff --git a/demos/main/src/main/assets/media.exolist.json b/demos/main/src/main/assets/media.exolist.json
index 17e3c5ef82..bcb99cabd0 100644
--- a/demos/main/src/main/assets/media.exolist.json
+++ b/demos/main/src/main/assets/media.exolist.json
@@ -737,6 +737,18 @@
       {
         "name": "One hour frame counter (MP4)",
         "uri": "https://storage.googleapis.com/exoplayer-test-media-1/mp4/frame-counter-one-hour.mp4"
+      },
+      {
+        "name": "1 hour (TS)",
+        "uri": "http://rocinante:6544/Content/GetVideo?Id=7790"
+      },
+      {
+        "name": "13 hours (TS)",
+        "uri": "http://rocinante:6544/Content/GetVideo?Id=7792"
+      },
+      {
+        "name": "14 hours (TS)",
+        "uri": "http://rocinante:6544/Content/GetVideo?Id=7789"
       }
     ]
   }

The reason that skips work on my application and not the demo application may be that I have implemented my own Extractors factory so that I can supply a larger value to the timestampSearchBytes parameter of the TsExtractor constructor. I am using a value of 488800 instead of the default 112800.

I checked again on a clean checkout of the main branch that the 1 hour TS file you provided plays perfectly fine and has a known duration. The only difference I see is that I copied the file to a local path instead of loading it from a remote server, but that shouldn't change any of the parsing logic.

I found what is causing the problem with the demo application. The demo is now working correctly, as you have said, on 1 hour, 13 hour and 14 hour files. Clearly the problem is on my side with the web server. Sorry for the trouble.

Thanks for the confirmation!