CacheWriter doesn't correctly implement allowShortContent case

[temq09]

[REQUIRED] Searched documentation and issues

Found the article about video preloading here - https://medium.com/google-exoplayer/pre-caching-downloading-progressive-streams-in-exoplayer-3a816c75e8f6

[REQUIRED] Question

Hi! I have an issue when trying to preload the first part of a video. I don't know the exact size of the video so just trying to preload the first 800kb. In case the video is less than 800kb I get com.google.android.exoplayer2.upstream.HttpDataSource$HttpDataSourceException: java.io.EOFException even when enableEOFException==false. Is it intentional and how can I solve the issue in the application?

A full bug report captured from the device

Not a bug report, just stacktrace

     Caused by: com.google.android.exoplayer2.upstream.HttpDataSource$HttpDataSourceException: java.io.EOFException
        at com.google.android.exoplayer2.upstream.DefaultHttpDataSource.read(DefaultHttpDataSource.java:359)
        at com.google.android.exoplayer2.upstream.DefaultDataSource.read(DefaultDataSource.java:182)
        at com.google.android.exoplayer2.upstream.cache.CacheDataSource.read(CacheDataSource.java:308)
        at com.google.android.exoplayer2.upstream.TeeDataSource.read(TeeDataSource.java:71)
        at com.google.android.exoplayer2.upstream.cache.CacheDataSource.read(CacheDataSource.java:308)
        at com.google.android.exoplayer2.upstream.cache.CacheUtil.readAndDiscard(CacheUtil.java:314)
        at com.google.android.exoplayer2.upstream.cache.CacheUtil.cache(CacheUtil.java:210)
        at com.google.android.exoplayer2.upstream.cache.CacheUtil.cache(CacheUtil.java:128)
        at dev.temq.testexoplayercacheutil.MainActivity$onCreate$1.run(MainActivity.kt:55)
        at io.reactivex.rxjava3.internal.operators.completable.CompletableFromAction.subscribeActual(CompletableFromAction.java:36)
        at io.reactivex.rxjava3.core.Completable.subscribe(Completable.java:2850)
        at io.reactivex.rxjava3.internal.operators.completable.CompletableSubscribeOn$SubscribeOnObserver.run(CompletableSubscribeOn.java:64)
        at io.reactivex.rxjava3.internal.schedulers.ScheduledDirectTask.call(ScheduledDirectTask.java:41)
        at io.reactivex.rxjava3.internal.schedulers.ScheduledDirectTask.call(ScheduledDirectTask.java:28)
        at java.util.concurrent.FutureTask.run(FutureTask.java:266)
        at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:301)
        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)
     Caused by: java.io.EOFException
        at com.google.android.exoplayer2.upstream.DefaultHttpDataSource.readInternal(DefaultHttpDataSource.java:700)
        at com.google.android.exoplayer2.upstream.DefaultHttpDataSource.read(DefaultHttpDataSource.java:357)
        at com.google.android.exoplayer2.upstream.DefaultDataSource.read(DefaultDataSource.java:182) 
        at com.google.android.exoplayer2.upstream.cache.CacheDataSource.read(CacheDataSource.java:308) 
        at com.google.android.exoplayer2.upstream.TeeDataSource.read(TeeDataSource.java:71) 
        at com.google.android.exoplayer2.upstream.cache.CacheDataSource.read(CacheDataSource.java:308) 
        at com.google.android.exoplayer2.upstream.cache.CacheUtil.readAndDiscard(CacheUtil.java:314) 
        at com.google.android.exoplayer2.upstream.cache.CacheUtil.cache(CacheUtil.java:210) 
        at com.google.android.exoplayer2.upstream.cache.CacheUtil.cache(CacheUtil.java:128) 
        at dev.temq.testexoplayercacheutil.MainActivity$onCreate$1.run(MainActivity.kt:55) 
        at io.reactivex.rxjava3.internal.operators.completable.CompletableFromAction.subscribeActual(CompletableFromAction.java:36) 
        at io.reactivex.rxjava3.core.Completable.subscribe(Completable.java:2850) 
        at io.reactivex.rxjava3.internal.operators.completable.CompletableSubscribeOn$SubscribeOnObserver.run(CompletableSubscribeOn.java:64) 
        at io.reactivex.rxjava3.internal.schedulers.ScheduledDirectTask.call(ScheduledDirectTask.java:41) 
        at io.reactivex.rxjava3.internal.schedulers.ScheduledDirectTask.call(ScheduledDirectTask.java:28) 
        at java.util.concurrent.FutureTask.run(FutureTask.java:266) 
        at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:301) 
        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) 

Link to test content

Reproducible sample - https://github.com/temq09/TestExoPlayerCacheUtil

[otopba]

Same issue =/

[ojw28]

There are a bunch of things that need fixing here:

1. The case where the entire stream is cached already but SimpleCache doesn't know the stream's length. This can happen in the edge case that a previous write attempt fails right at the very end, between having written the last byte to the cache and having established that there are no subsequent bytes. To correctly handle this case, CacheDataSource.open should handle POSITION_OUT_OF_RANGE errors from upstream by trying to read the single previous byte, again from upstream, to confirm the stream length. There's also a point in CacheDataSource.read that will handle POSITION_OUT_OF_RANGE only if currentDataSpecLengthUnset. I think the handling there should probably be used if the length is set as well.
2. When CacheWriter attempts to read a fixed length that extends beyond the end of the stream, we need to make sure that when the end of the stream is encountered, both CacheDataSource and CacheWriter do the correct thing. CacheDataSource should fill in the content length if it's currently missing. CacheWriter should fail or not, depending on whether allowShortContent is true. One thing making this harder currently, is that different HttpDataSource implementations are not all throwing a consistent failure in this case. So a first step will be to clearly define the expected failure, and enforce that this is what happens across all of the HttpDataSource implementations (ideally all DataSource implementations).

[jonasN5]

This is still an issue.

[ojw28]

This is fixed in the dev-v2 branch, and will be included in the 2.14.0 release which is tentatively scheduled for the beginning of May.