- Increase the default cache file size to 5MB
- Recommended a minimum cache file size of 2MB to discourage
applications from specifying values small enough such that
unreasonably large numbers of cache files are generated
- Allow maxCacheFileSize=C.LENGTH_UNSET, equivalent to setting it
to MAX_VALUE. This is just for API consistency with other APIs
we have that accept LENGTH_UNSET
Issue: #4253
PiperOrigin-RevId: 227524233
CacheEvictor.onStartFile currently receives a length, which is the
maximum size of the content that might be written. The LRU cache
evictor will make sure there's sufficient space for the specified
size. If the actual size of the content is unknown, CacheDataSink
passes maxCacheFileSize.
The current behavior isn't ideal. It seems valid for a developer to
specify maxCacheFileSize=Long.MAX_VALUE if they don't want any
file fragmentation in the cache. However if they then attempt to
cache something with unknown length, LRU cache will try and make
room for content of length Long.MAX_VALUE, and end up evicting the
entire cache to do so.
This change alters the logic so a length is only passed if the
actual size of the content is known. In other cases C.LENGTH_UNSET
is now passed. The LRU evictor will not evict until after the file
is committed. Note a custom LRU evictor could still opt to evict to
ensure some application specified amount of space, if that's the
desired behavior.
PiperOrigin-RevId: 227509525
This also applies when seeking or transitioning to unprepared media, which
isn't clear from the current documentation.
Issue:#5267
PiperOrigin-RevId: 226486685
When a Download is created it's set to queued state but doesn't notify
listeners about this state. DownloadManager checks if it can start the
download. After this checks it notifies the listeners.
With this change Download can immediately check if it can be started and
sends correct notification.
PiperOrigin-RevId: 225967129
This is useful to write integration tests for MediaSources which check that the
stream keys returned by getStreamKeys are compatible with the respective manifest
parser.
PiperOrigin-RevId: 225542606
Problem: There is nothing in the Cache interface that enforces that
these methods are implemented by reading/writing content metadata,
however our own code (CacheDataSource) relies on this property since
it mixes use of [get|set]ContentLength and use of metadata. Using
metadata is the right approach because it minimizes the number of
index writes (e.g. it allows the redirect URI and the content length
to be committed by a single write).
Solution: Remove [get|set]ContentLength, which are redundant anyway,
and use metadata everywhere. Also expose the keys being used through
the public API; there's no particular reason why they shouldn't be.
We previously had an API for getting and setting content length, but
no API for getting and setting redirect uri.
PiperOrigin-RevId: 225383211
