Goal

What do you want to achieve?

Expected Results

?

Actual Results

Full stack trace with exception, logcat output...

Steps & Code to Reproduce

Describe your current debugging efforts.

Sample app

Please try to reproduce the issue in our sample app.

Version of library and tooling

DTG version: ?

Android Studio version: ?

Android version and device: ?

Additional context

Add any other context about the problem here.

Could you please add some usage examples into readme.md?

Goal

What do you want to achieve?

Expected Results : Progress should stop at 100%

?

Actual Results : Progress is going above 100%

Please try to reproduce the issue in our sample app. Same issue on sample app

Whenever a url of any master HLS manifest file contains a query string, library fails to parse it. The reason appears to be a bug in the library, which causes the query string to be appended to the url one more time. So, for example, if we have a url like https://lol.srvr.8181.com/playlists/hls.m3u8?param1=hello&param2=world, at some phase of attempting the metadata url becomes
https://lol.srvr.8181.com/playlists/hls.m3u8?param1=hello&param2=world?param1=hello&param2=world which often prevents servers from handling such a request right. Therefore, the library can't obtain playlist's content and can't parse it as a result.

The TrackSelector#apply method signature has been changed in #34 but the documentation in https://kaltura.github.io/playkit/guide/android/dtg/#track-selection hasn't been updated to reflect the change.

The Race condition in HlsDownloader leading to ConcurrentModificationException & NPE ocurred after update from v2.6.4 to v2.6.9.

Currently, the HlsDownloader#createDownloadTasks function can be called from 2 places which are run in 2 separate Threads.

1. On track selection from TrackSelectorImp.apply, which uses AsyncTasks sDefaultExecutor.
   

   playkit-dtg-android/dtglib/src/main/java/com/kaltura/dtg/TrackSelectorImp.java

   Line 39 in d92e41e

   downloader.apply();

2. Download services after metadata completes, which uses a ThreadPoolExecutor to invoke HlsDownloader#createDownloadTasks further down the stack via AbrDownloader#apply call.
   

   playkit-dtg-android/dtglib/src/main/java/com/kaltura/dtg/DownloadService.java

   Line 395 in d92e41e

   newDownload(item);

   
   

   playkit-dtg-android/dtglib/src/main/java/com/kaltura/dtg/AbrDownloader.java

   Line 93 in d92e41e

   this.apply();

The race condition appeared after metadata fetching was moved to a dedicated ThreadPoolExecutor from AsyncTasks sDefaultExecutor which was reused reusing the same Thread for both calls.

Steps to reproduce

1. Start download.
2. Change track selection at the time when metadata loading finishes.

Expected Results

The download should start.

Actual Results

The following exceptions are thrown from dtg:

Fatal Exception: java.util.ConcurrentModificationException
       at java.util.ArrayList$Itr.next(ArrayList.java:860)
       at com.kaltura.dtg.hls.HlsDownloader.createDownloadTasks(HlsDownloader.java:88)
       at com.kaltura.dtg.AbrDownloader.applyInitialTrackSelection(AbrDownloader.java:122)
       at com.kaltura.dtg.hls.HlsDownloader.applyInitialTrackSelection(HlsDownloader.java:297)
       at com.kaltura.dtg.AbrDownloader.apply(AbrDownloader.java:235)
       at com.kaltura.dtg.TrackSelectorImp.lambda$apply$0(TrackSelectorImp.java:39)
       at com.kaltura.dtg.TrackSelectorImp.lambda$apply$0$TrackSelectorImp(TrackSelectorImp.java)
       at com.kaltura.dtg.-$$Lambda$TrackSelectorImp$nlSaArBap0OhKxA2tNBRIKRHnbY.run(-.java:4)
       at android.os.AsyncTask$SerialExecutor$1.run(AsyncTask.java:289)
       at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1167)
       at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641)
       at java.lang.Thread.run(Thread.java:919)

Fatal Exception: java.lang.NullPointerException: Attempt to read from field 'int i.n.b.b1.a$b.a' on a null object reference
       at com.kaltura.dtg.hls.HlsDownloader.createDownloadTasks(HlsDownloader.java:90)
       at com.kaltura.dtg.AbrDownloader.applyInitialTrackSelection(AbrDownloader.java:122)
       at com.kaltura.dtg.hls.HlsDownloader.applyInitialTrackSelection(HlsDownloader.java:297)
       at com.kaltura.dtg.AbrDownloader.apply(AbrDownloader.java:235)
       at com.kaltura.dtg.TrackSelectorImp.lambda$apply$0(TrackSelectorImp.java:39)
       at com.kaltura.dtg.TrackSelectorImp.lambda$apply$0$TrackSelectorImp(TrackSelectorImp.java)
       at com.kaltura.dtg.-$$Lambda$TrackSelectorImp$nlSaArBap0OhKxA2tNBRIKRHnbY.run(-.java:4)
       at android.os.AsyncTask$SerialExecutor$1.run(AsyncTask.java:289)
       at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1167)
       at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641)
       at java.lang.Thread.run(Thread.java:919)

Follow up on #101

The Race condition in HlsDownloader leading to ConcurrentModificationException & NPE ocurred after update from v2.6.4 to v2.6.9.

Currently, the HlsDownloader#createDownloadTasks function can be called from 2 places that are run in 2 separate Threads.

1. On track selection from TrackSelectorImp.apply, which uses AsyncTasks sDefaultExecutor.
   

   playkit-dtg-android/dtglib/src/main/java/com/kaltura/dtg/TrackSelectorImp.java

   Line 39 in d92e41e

   downloader.apply();

2. Download services after metadata completes, which uses a ThreadPoolExecutor to invoke HlsDownloader#createDownloadTasks further down the stack via AbrDownloader#apply call.
   

   playkit-dtg-android/dtglib/src/main/java/com/kaltura/dtg/DownloadService.java

   Line 395 in d92e41e

   newDownload(item);

   
   

   playkit-dtg-android/dtglib/src/main/java/com/kaltura/dtg/AbrDownloader.java

   Line 93 in d92e41e

   this.apply();

The race condition appeared after metadata fetching was moved to a dedicated ThreadPoolExecutor from AsyncTasks sDefaultExecutor which was reused reusing the same Thread for both calls.

Steps to reproduce

The sample project:
Ilya-Gh@e21576d

I have added the code that restarts the download when it finishes so it will be easier to observe the crash (the reproducibility rate is about 5% for me).

The line that makes the app crash is Ilya-Gh@e21576d#diff-d59630304bf15fb3aa1e3709f4ca60a982485601c69b7eff2d94c94e37cad140R501

1. Start downloading HLS video.

Expected Results

The download should start

Actual Results

The following exceptions are thrown from dtg:

FATAL EXCEPTION: AsyncTask #2
Process: com.kaltura.dtg.demo, PID: 6983
java.util.ConcurrentModificationException
	at java.util.ArrayList$Itr.next(ArrayList.java:860)
	at com.kaltura.dtg.hls.HlsDownloader.createDownloadTasks(HlsDownloader.java:98)
	at com.kaltura.dtg.AbrDownloader.applyInitialTrackSelection(AbrDownloader.java:122)
	at com.kaltura.dtg.hls.HlsDownloader.applyInitialTrackSelection(HlsDownloader.java:314)
	at com.kaltura.dtg.AbrDownloader.apply(AbrDownloader.java:235)
	at com.kaltura.dtg.TrackSelectorImp.lambda$apply$0$com-kaltura-dtg-TrackSelectorImp(TrackSelectorImp.java:39)
	at com.kaltura.dtg.TrackSelectorImp$$ExternalSyntheticLambda0.run(Unknown Source:4)
	at android.os.AsyncTask$SerialExecutor$1.run(AsyncTask.java:305)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1167)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641)
	at java.lang.Thread.run(Thread.java:920)

Background

Loading metadata is an initial mandatory step before the download can be started. Metadata is fetched using DownloadItem#loadMetadata method:

However, there is no way to cancel metadata loading, which includes HTTP requests:

Not being able to cancel metadata results in DownloadStateListener#onDownloadMetadata and DownloadStateListener#onTracksAvailable and others callbacks invocations even after download cancellation using
ContentManager#removeItem

Proposal

Provide API to cancel metadata loading HTTP requests and other related work.

Another option would be to cancel pending metadata loading in ContentManager#removeItem for the current item.

Prerequisites

• Have you checked for duplicate issues

jcenter is shutting down and playkit-android is currently hosted there. It will become read-only on March 31st, 2021 and will be terminated on February 1st, 2022. Please consider switching from jcenter to Maven Central.

Hello Sir. I'm a UI/UX and Graphics Designer. I'm happy to see an open source project, So, I want provide a logo for you. Would you mind if I propose a new logo design for your project as my Open Source Contribution?

Thanks before.

DownloadStateListener#onDownloadFailure
is invoked multiple times for an HLS stream download.

Steps:

1. Start downloading tears-multi-hls via sample app
2. Turn off WiFi and mobile data
3. DownloadStateListener#onDownloadFailure called multiple times.

2020-05-06 15:25:00.900 29812-30075/com.kaltura.dtg.demo D/MainActivity: onDownloadFailure: <com.kaltura.dtg.DownloadItemImp itemId=tears-multi-hls contentUrl=http://cdntesting.qa.mkaltura.com/p/1091/sp/109100/playManifest/entryId/0_ttfy4uu0/protocol/http/format/applehttp/flavorIds/0_yuv6fomw,0_i414yxdl,0_mwmzcwv0,0_g68ar3sh/a.m3u8?playbackType=offline&clientTag=playkit-dtg%2Fandroid-dev.7572fa6&referrer=TXlBcHBsaWNhdGlvbg%3D%3D&playSessionId=af71bf25-cce8-4443-8da1-6e31f7745701 state=FAILED addedTime=Wed May 06 15:24:24 GMT+03:00 2020 estimatedSizeBytes=161957006 downloadedSizeBytes=7246506>
2020-05-06 15:25:00.901 29812-30075/com.kaltura.dtg.demo D/MainActivity: onDownloadFailure: <com.kaltura.dtg.DownloadItemImp itemId=tears-multi-hls contentUrl=http://cdntesting.qa.mkaltura.com/p/1091/sp/109100/playManifest/entryId/0_ttfy4uu0/protocol/http/format/applehttp/flavorIds/0_yuv6fomw,0_i414yxdl,0_mwmzcwv0,0_g68ar3sh/a.m3u8?playbackType=offline&clientTag=playkit-dtg%2Fandroid-dev.7572fa6&referrer=TXlBcHBsaWNhdGlvbg%3D%3D&playSessionId=af71bf25-cce8-4443-8da1-6e31f7745701 state=FAILED addedTime=Wed May 06 15:24:24 GMT+03:00 2020 estimatedSizeBytes=161957006 downloadedSizeBytes=7246506>

That happens because onDownloadFailure is invoked for each HLS segment failure which can happen simultaneously like connection drop:

I would expect onDownloadFailure to be invoked only once for a single HLS playlist download as startDownload is called of the whole video and not on individual segments: