Why is my Exoplayer2 CacheDataSource not writing the downloaded stream to the designated cache?

Question

I have implemented a custom cache for Exoplayer2 - and am migrating from 2.11.x to 2.12.3. I have reviewed several posts here on SO (ex: here), as well as various parts from the latest Exoplayer2 developer docs (ex: here). I can get the video streamed from a local source or a remote source (ex: Dropbox) and it plays, but I don't see anything being saved in the folder I've designated as my cache other than two files (and both are extremely small):

5eedc471fe18491e.uid
cached_content_index.exi

I am guessing that the .exi file is the index that is supposed to track the cache segments, and the .uid file is a segment - but it is always 0 bytes. So for some reason, Exoplayer recognizes the cache location, but doesn't stream anything into it.

In my app, I do this:

MediaSource mediaSource = getCachedMediaSourceFactory(context, listener).createMediaSource(uri);
exoPlayer.setMediaSource(mediaSource);
exoPlayer.setPlayWhenReady(true);
exoPlayer.prepare();

getCachedMediaSourceFactory() in turn looks like:

private static ProgressiveMediaSource.Factory getCachedMediaSourceFactory(Context context, CacheDataSource.EventListener listener) {
    if ( cachedMediaSourceFactory == null ) {
        cachedMediaSourceFactory = new ProgressiveMediaSource.Factory(
                new InTouchCacheDataSourceFactory(context,
                        DEFAULT_MEDIA_CACHE_FRAGMENT_SIZE_IN_BYTES,
                        listener));
    }
    return cachedMediaSourceFactory;
}

InTouchCacheDataSourceFactory in turn looks like:

public class InTouchCacheDataSourceFactory implements DataSource.Factory {
    private final DefaultDataSourceFactory defaultDatasourceFactory;
    private final CacheDataSource.EventListener listener;
    private final long maxCacheFragmentSize;

    public InTouchCacheDataSourceFactory(Context context, long maxCacheFragmentSize) {
        this(context, maxCacheFragmentSize, null);
    }

    public InTouchCacheDataSourceFactory(Context context, long maxCacheFragmentSize, CacheDataSource.EventListener listener) {
        this.maxCacheFragmentSize = maxCacheFragmentSize;
        this.listener = listener;

        defaultDatasourceFactory =
                new DefaultDataSourceFactory(context,
                                             new DefaultHttpDataSourceFactory(Util.getUserAgent(context, APP_NAME)));

    }

    @Override
    public DataSource createDataSource() {
        return new CacheDataSource(InTouchUtils.getMediaCache(),
                                   defaultDatasourceFactory.createDataSource(),
                                   new FileDataSource(),
                                   new CacheDataSink(InTouchUtils.getMediaCache(), maxCacheFragmentSize),
                             CacheDataSource.FLAG_BLOCK_ON_CACHE | CacheDataSource.FLAG_IGNORE_CACHE_ON_ERROR,
                                   listener);
    }
}

And InTouchUtils.getMediaCache looks like:

public static SimpleCache getMediaCache() {
    if ( mediaCache == null ) {
        Context context = InTouch.getInstance().getApplicationContext();
        long requestedCacheSize = Long.parseLong(PreferenceManager.getDefaultSharedPreferences(context).getString(context.getString(R.string.pref_default_cache_size_key), String.valueOf(DEFAULT_MEDIA_CACHE_SIZE_IN_MB)));
        File contentDirectory = new File(context.getCacheDir(), MEDIA_CACHE_DIRECTORY);
        mediaCache = new SimpleCache(contentDirectory, new LeastRecentlyUsedCacheEvictor(requestedCacheSize*(1024*1024)));
    }
    return mediaCache;
}

Again, the video plays fine - but it doesn't appear to be actually writing the streamed file into the cache. Why not?

I have also implemented the CacheDataSource.EventListener interface in my app, and have overridden these two methods:

@Override
public void onCachedBytesRead(long cacheSizeBytes, long cachedBytesRead) {
    Timber.d("Lifecycle: Cache read, size in bytes is: %d, bytes read was: %d", cacheSizeBytes, cachedBytesRead);
}

@Override
public void onCacheIgnored(int reason) {
    switch (reason) {
        case CacheDataSource.CACHE_IGNORED_REASON_ERROR:
            Timber.d("Lifecycle: Cache ignored due to error");
            break;
        case CacheDataSource.CACHE_IGNORED_REASON_UNSET_LENGTH:
            Timber.d("Lifecycle: Cache ignored due to unset length");
            break;
    }
}

I am not seeing either method getting called.

Answer 1

UPDATE May 2021

I have created a sample app on GitHub that shows this cached data source working, for any readers that are interested to see it.

Tapping the top button in the app launches a SAF-based chooser to select a local video (so no cache is necessary or used). The Uri of the selected file shows in the EditText, and you can tap "Play Video" to see it play.

However by default the sample Uri in the EditText is on the Internet, and as it is "not a local Uri" (the semantics of which are not anything really "official", just a simple delineation I created for the purposes of this test app) it uses the custom cache data source factory which causes Exoplayer's cache mechanics to kick into gear.

You can review the differences in LogCat while the app runs, and can see after playing the video streamed from the internet the first time, on the second run you start getting hits from the cache as evidenced by calls to the onCachedBytesRead() callback.

You can also open up your device explorer while running it on a hardware device connected to Android Studio, and you should see something along these lines:

As you can see, after the first time I played the video, it was cached in the location I specified, and thereafter Exoplayer2 grabs the video from there, not from the Internet again.

For streamed videos, make sure you use a Url like:

https://www.learningcontainer.com/wp-content/uploads/2020/05/sample-mp4-file.mp4.

and NOT something unique such as a YouTube "watch" one, i.e.

https://www.youtube.com/watch?v=Cn8PiqIXEjQ

Also, this sample uses the Exoplayer2 "Progressive" type media source to stream Uri from the Internet (which is now the default one since the Extractor type was deprecated a while back). If a url entered into this app points to a file requiring the DASH type, obviously it won't work.

The Exoplayer2 Source Code has an example app which does a much more sophisticated job of trying the various media source implementations against the target Uri until it finds the right onw.

There is a good basic Exoplayer2 tutorial here.

====

It turns out that this not caching is the default behavior, then in the normal course of DataSource management it is turned on in most cases. In my case it was not getting so because the Uri in question was a content:// Uri pointing to Dropbox that gets resolved by a custom SAF provider which uses Dropbox APIs to stream the video back. So the length of the file never gets recognized, thus the default behavior does not get changed.

Oliver Woodman of the Exoplayer team suggested two solutions. The first (quickest), was to change my custom DataSourceFactory implementation from returning a CacheDataSource, to returning a custom DataSource that "wraps" the CacheDataSource - forwarding the method calls from the DataSource interface to the CacheDataSource instance, except for the open() method. In that case it changes the DataSpec argument first, then passes it along:

/**
 * Class specifically to turn off the flag that would not cache streamed docs.
 */
private class InTouchCacheDataSource implements DataSource {
    private CacheDataSource cacheDataSource;
    InTouchCacheDataSource(CacheDataSource cacheDataSource) {
        this.cacheDataSource = cacheDataSource;
    }

    @Override
    public void addTransferListener(TransferListener transferListener) {
        cacheDataSource.addTransferListener(transferListener);
    }

    @Override
    public long open(DataSpec dataSpec) throws IOException {
        return cacheDataSource.open(dataSpec
                .buildUpon()
                .setFlags(dataSpec.flags & ~DataSpec.FLAG_DONT_CACHE_IF_LENGTH_UNKNOWN)
                .build());
    }

    @Nullable
    @Override
    public Uri getUri() {
        return cacheDataSource.getUri();
    }

    @Override
    public void close() throws IOException {
        cacheDataSource.close();
    }

    @Override
    public int read(byte[] target, int offset, int length) throws IOException {
        return cacheDataSource.read(target, offset, length);
    }
}

This class is then used by the custom factory like this:

@Override
public DataSource createDataSource() {
    CacheDataSource dataSource = new CacheDataSource(InTouchUtils.getMediaCache(),
            defaultDatasourceFactory.createDataSource(),
            new FileDataSource(),
            new CacheDataSink(InTouchUtils.getMediaCache(), maxCacheFragmentSize),
            CacheDataSource.FLAG_BLOCK_ON_CACHE | CacheDataSource.FLAG_IGNORE_CACHE_ON_ERROR,
            listener);
    return new InTouchCacheDataSource(dataSource);
}

This works perfectly, and Oliver assures me that Exoplayer will do the right thing even if the stream were to fill the cache (i.e. first envoke the evictor, then if that fails stop trying to write to the cache and just continue to stream).

The other option is to write a custom DataSource using ContentDataSource as a start, and incorporate the customized SAF into it (since in my case at least, I actually do know the size of the file but the standard SAF methods being used to afford the opportunity to pass this back in the standard SAF provider/resolver approach).