Picasso saving cached data of continuous IPTV streams inside the app

The issue is a follow up reported in google/ExoPlayer (https://github.com/google/ExoPlayer/issues/3696).

Whenever I use ExoPlayer to stream IPTV content, the app starts to intensively cache some kind of data on local device storage (monitored by dumpsys diskstats) and it cache this data until it fills all the available storage on device. After the storage is filled, Android shows an alert the the device storage is low and apps will stop working.

It seems that the picasso extension (com.squareup.picasso) I am using is writing some kind of temporary file, but do you have any idea how it could be connected with ExoPlayer? I am using it for small images only, which do not exceed a couple of kilobytes, but the size of the cache is directly related to the stream being shown.

Is there anything that can be done to avoid this issue, because it’s quite critical at the moment.

Here’s the contents of one of those .tmp files (the smaller one), other file is encrypted content:

http://192.168.0.102:8001/1:0:1F:BC2:25:56:300000:0:0:0:
GET
0
HTTP/1.0 200 OK
6
Connection: Close
Content-Type: video/mpeg
Server: streamserver
X-Android-Selected-Protocol: http/1.0
X-Android-Sent-Millis: 1515708344386
X-Android-Received-Millis: 1515708344393

Below is the change in size during some time:

./cache/picasso-cache:
total 334672
drwx------ 2 u0_a99 u0_a99      4096 2018-01-12 00:05 .
drwxrwx--x 3 u0_a99 u0_a99      4096 2018-01-12 00:03 ..
-rw------- 1 u0_a99 u0_a99       261 2018-01-12 00:05 5198767f7d86a079eace4a3fcdfdbbe6.0.tmp
-rw------- 1 u0_a99 u0_a99 171335680 2018-01-12 00:08 5198767f7d86a079eace4a3fcdfdbbe6.1.tmp

./cache/picasso-cache:
total 364752
drwx------ 2 u0_a99 u0_a99      4096 2018-01-12 00:05 .
drwxrwx--x 3 u0_a99 u0_a99      4096 2018-01-12 00:03 ..
-rw------- 1 u0_a99 u0_a99       261 2018-01-12 00:05 5198767f7d86a079eace4a3fcdfdbbe6.0.tmp
-rw------- 1 u0_a99 u0_a99 186736640 2018-01-12 00:08 5198767f7d86a079eace4a3fcdfdbbe6.1.tmp

./cache/picasso-cache:
total 410624
drwx------ 2 u0_a99 u0_a99      4096 2018-01-12 00:05 .
drwxrwx--x 3 u0_a99 u0_a99      4096 2018-01-12 00:03 ..
-rw------- 1 u0_a99 u0_a99       261 2018-01-12 00:05 5198767f7d86a079eace4a3fcdfdbbe6.0.tmp
-rw------- 1 u0_a99 u0_a99 210223104 2018-01-12 00:08 5198767f7d86a079eace4a3fcdfdbbe6.1.tmp

./cache/picasso-cache:
total 453488
drwx------ 2 u0_a99 u0_a99      4096 2018-01-12 00:05 .
drwxrwx--x 3 u0_a99 u0_a99      4096 2018-01-12 00:03 ..
-rw------- 1 u0_a99 u0_a99       261 2018-01-12 00:05 5198767f7d86a079eace4a3fcdfdbbe6.0.tmp
-rw------- 1 u0_a99 u0_a99 232169472 2018-01-12 00:09 5198767f7d86a079eace4a3fcdfdbbe6.1.tmp

[JakeWharton]

You should also call Picasso.setSingletonInstance so that any consumer of the Picasso.with(Context) method uses your configured instance instead of a new one (which might fall back to HttpURLConnection if it doesn’t detect OkHttp).

[JakeWharton]

You could write an OkHttp interceptor to strip the cache headers on responses with such content types, but I don’t think those URLs should be going through Picasso in the first place. That’s the problem that I would aim to fix.