Images no longer displayed after killing/updating the app

[Nivl]

When I install my app on my device, everything works perfectly. But when I update it (like using the "run" button from Android Studio), or just kill it (by swiping it from my "Recent apps"), the images are no longer displayed.

My code:

Picasso picasso = Picasso.with(mContext);
picasso.setLoggingEnabled(true);
picasso.load(url).into(viewHolder.mainPicture, new Callback() {
    @Override
    public void onSuccess() {
        Log.i(TAG, "PICASSO OK");
    }

    @Override
    public void onError() {
        Log.i(TAG, "PICASSO KO");
    }
});

Logs

08-27 16:22:41.266      654-654/io.shace.app D/Picasso﹕ Main        created      [R2] Request{http://192.168.0.5:9000/assets/medias/14ce899e-7021-44ef-b44d-bbab5307fa0f.jpg}
08-27 16:22:41.266      654-746/io.shace.app D/Picasso﹕ Dispatcher  enqueued     [R2]+2ms
08-27 16:22:41.276      654-762/io.shace.app D/Picasso﹕ Hunter      executing    [R2]+2ms
08-27 16:22:41.856      654-746/io.shace.app D/Picasso﹕ Dispatcher  retrying     [R2]+586ms
08-27 16:22:41.856      654-748/io.shace.app D/Picasso﹕ Hunter      executing    [R2]+587ms
08-27 16:22:42.576      654-746/io.shace.app D/Picasso﹕ Dispatcher  retrying     [R2]+1307ms
08-27 16:22:42.576      654-749/io.shace.app D/Picasso﹕ Hunter      executing    [R2]+1308ms
08-27 16:22:42.596      654-746/io.shace.app D/Picasso﹕ Dispatcher  batched      [R2]+1326ms for error
08-27 16:22:42.796      654-654/io.shace.app I/EventAdapter﹕ PICASSO KO
08-27 16:22:42.796      654-746/io.shace.app D/Picasso﹕ Dispatcher  delivered    [R2]+1528ms
08-27 16:22:42.796      654-654/io.shace.app D/Picasso﹕ Main        errored      [R2]+1528ms

Looks like a cache issue to me. The URL is obviously working (locally) since it's working when I uninstall/reinstall the app. The image is not huge (58KB). It's also the only image I'm trying to load so it's probably not a cache size issue.

The code is inside getView() on a custom Adapter.

[Jakevin]

Me too!

has same question..

[npmccallum]

Some of my app's users are seeing the same problem.

[jzaccone]

Having a similar issue. When I attach a listener using Picasso.Builder(context).listener(... The exception I am getting says "Received response with 0 content-length header." I am using OkHttp client and cache via the PicassoUtils.

I am interested to know what you guys see if you do this...

[jzaccone]

For me this is the same as #633. Occurs after an update from Picasso version 2.3.1 to 2.3.3, and from using HttpUrlConnection to explicitly specifying OkHttpDownloader as the downloader.

build.gradle before:

compile 'com.squareup.picasso:picasso:2.3.1'

picasso usage before:

Picasso.with(getActivity()).load(thumborUrl).into(holder.titleImage);

build.gradle after

compile 'com.squareup.okhttp:okhttp:2.0.0'
compile 'com.squareup.okhttp:okhttp-urlconnection:2.0.0'
compile 'com.squareup.picasso:picasso:2.3.3'

picasso usage after:

PicassoUtils.with(getActivity()).load(thumborUrl).into(holder.titleImage);

(see Picasso Utils)

Exception.message() : Received response with 0 content-length header.

Some logs:

08-30 13:47:12.244 21405-21504/? D/Picasso﹕ Dispatcher retrying [R10]+1022ms
08-30 13:47:12.244 21405-21506/? D/Picasso﹕ Hunter executing [R10]+1023ms
08-30 13:47:12.345 21405-21504/? D/Picasso﹕ Dispatcher retrying [R11]+1054ms
08-30 13:47:12.345 21405-21524/? D/Picasso﹕ Hunter executing [R11]+1056ms
08-30 13:47:12.752 21405-21504/? D/Picasso﹕ Dispatcher batched [R10]+1532ms for error (will replay)
08-30 13:47:12.861 21405-21504/? D/Picasso﹕ Dispatcher batched [R11]+1570ms for error (will replay)
08-30 13:47:12.955 21405-21504/? D/Picasso﹕ Dispatcher delivered [R10]+1736ms, [R11]+1665ms
08-30 13:47:12.955 21405-21405/? D/Picasso﹕ Main errored [R10]+1736ms

[dnkoutso]

Can anyone provide a sample url?

[dnkoutso]

This appears to be NetworkBitmapHunter:23 sometimes the response header content-length is 0.

I cant repro on the sample app...it might have to do with loading from disk...can someone with the problem debug and see the response received from downloader?

[dnkoutso]

Also specify what version okhttp you are using.

[cnordvik]

I updated Picasso from 2.1.1 to 2.3.2 and updated our app. Now I am receiving daily emails about users having empty images in our app. A reinstall fixes it, but then they appear empty again so it seems related to this issue. I have not specified okhttp anywhere. Some of my gradle file:
compile 'com.squareup.picasso:picasso:2.3.2'
compile 'com.mcxiaoke.volley:library:1.0.+'

A sample image:
http://fotmobapi.s3.amazonaws.com/image_resources/logo/teamlogo/8650.png

[cnordvik]

I had three users install the exact same version where I changed my gradle file to:
compile 'com.squareup.picasso:picasso:2.1.1'

and it solved the "images-not-loading-on-app-restart" problems they had.

[cukepie]

I also encountered the same problem, how to fix it? #633 @JakeWharton @dnkoutso

[cukepie]

okhttp:2.0.0
picasso:2.3.4
logs:
09-09 17:49:50.848 4303-4359/? D/Picasso﹕ Dispatcher batched [R112]+530ms for error (will replay)
09-09 17:49:50.888 4303-4359/? D/Picasso﹕ Dispatcher batched [R111]+636ms for error (will replay)
09-09 17:49:50.918 4303-4359/? D/Picasso﹕ Dispatcher batched for error (will replay)
09-09 17:49:50.938 4303-4636/? D/Picasso﹕ Hunter executing [R117]+2ms
09-09 17:49:50.938 4303-4359/? D/Picasso﹕ Dispatcher enqueued [R117]+2ms
09-09 17:49:50.958 4303-4359/? D/Picasso﹕ Dispatcher batched for error (will replay)
09-09 17:49:51.048 4303-4359/? D/Picasso﹕ Dispatcher delivered [R112]+732ms, [R111]+798ms, ,
09-09 17:49:51.058 4303-4303/? D/Picasso﹕ Main errored [R112]+733ms
09-09 17:49:51.058 4303-4303/? D/Picasso﹕ Main errored [R111]+802ms
09-09 17:49:51.118 4303-4303/? D/Picasso﹕ Main created [R118]

[cnordvik]

@dnkoutso Any chance of an update here? We have millions of active users and have to issue an update with downgraded Picasso now because of this. Wondering switching to Glide because of this...

[mori-honest]

Same problem

[cnordvik]

@JakeWharton @dnkoutso We updated our 2 million users with Picasso 2.1.1 and it solved it for all the users that had issues. Hope this bug gets fixed at some point! :-)

[lucasr]

Seems related to #594 too.

[ghost]

Having the exact same issue. The images are displayed correctly - both from network and memory - but after some time (if I open the app the next day - I don't know actually what is triggering the issue) they stop showing.

At first I was only using the Picasso compiled version, but tried to fix this issue by adding OkHttp. The behaviour still remains the same.

I am using the following compiled version:

• picasso-2.3.4.jar

The issue remains with same with or without the following compiled versions:

• okhttp-2.0.0.jar
• okhttp-urlconnection-2.0.0-RC2.jar
• okio-1.0.0.jar

The call to onImageLoadFailed comes with the following exception:
java.io.IOException: Received response with 0 content-length header.

However, if I make the request my self, these are the headers for the image:
HTTP/1.1 200 OK
Content-Length: 141565
Content-Type: image/png
Content-MD5: 64jcU4AWFxlPILJX7tbcnQ==
Last-Modified: Wed, 15 Oct 2014 16:10:49 GMT
ETag: 0x8D1B6A9B82A0873
Server: Windows-Azure-Blob/1.0 Microsoft-HTTPAPI/2.0
x-ms-request-id: dc6727e3-0001-00ca-2d3f-cb4849000000
x-ms-version: 2009-09-19
x-ms-lease-status: unlocked
x-ms-blob-type: BlockBlob
Date: Mon, 20 Oct 2014 09:36:53 GMT

Log:
Dispatcher enqueued [R7]+32ms
Dispatcher enqueued [R8]+0ms
Hunter executing [R7]+32ms
Hunter executing [R8]+1ms
Dispatcher retrying [R7]+553ms
Hunter executing [R7]+554ms
Dispatcher retrying [R8]+523ms
Hunter executing [R8]+533ms
Dispatcher retrying [R7]+1078ms
Hunter executing [R7]+1078ms
Dispatcher retrying [R8]+1048ms
Hunter executing [R8]+1049ms
Dispatcher batched [R7]+1586ms for error (will replay)
Dispatcher batched [R8]+1556ms for error (will replay)
Main errored [R7]+1789ms
Main errored [R8]+1757ms
Dispatcher delivered [R7]+1790ms, [R8]+1758ms

UPDATE:
This issue is apparently fixed when the server sends the cache-control HTTP header.

[ionull]

I have exactly the same issue. I thought it is too slow to load, but it is not.

[ghost]

@ionull I was able to solve this by asking the server to add cache-control HTTP header.

[ionull]

@dwbrito but the image server is controlled by Microsoft, will try to roll back to an old version.

[cnordvik]

Then it looks like the missing headers are the problem because we don't set these when uploading to Amazon S3. Problem is that we have 10000+ images without headers, will have to see if we can set them somehow. But why is this problem not present in Picasso 2.1.1? I tried moving over to Glide because of this but that introduced other issues so back on Picasso now.

[expilu]

I've experienced this behaviour too. Using Picasso 2.4.0
No fix yet? The only thing I can do right now is going back to 2.1.1?

[anxiaoyi]

same problem

[dnkoutso]

We will need to investigate this.

[cwhsu1984]

I can load image in res folder with Picasso 2.4.0 but cannot load image with url.

[cnordvik]

We moved to 2.4.0, added cache-control headers but today we got a new users saying no images are loading for him. We have two versions on Google Play now, one with 2.1.1 and one with 2.4.0. The 2.1.1 version works fine for the user but no images load on the 2.4.0 version.

We have a lot of users and it seems to only affect a very small percentage of them, but I am not sure how to help those users. Is there anything they can try on their side? This one user has tried both wifi and 3g and also tried reinstalling the app.

compile 'com.squareup.okhttp:okhttp:2.0.0'
compile 'com.squareup.okio:okio:1.0.1'
compile 'com.squareup.okhttp:okhttp-urlconnection:2.0.0'
compile 'com.squareup.picasso:picasso:2.4.0'

Here are the response headers in case it has any :

Accept-Ranges:bytes
Age:26
Cache-Control:public, max-age=2678400
Connection:keep-alive
Content-Length:36415
Content-Type:image/png
Date:Wed, 17 Dec 2014 08:26:33 GMT
ETag:"481cd1f75282d0bfb12742b09f418b03"
Last-Modified:Tue, 02 Dec 2014 08:42:36 GMT
Server:AmazonS3
Via:1.1 69138579f0e00411ece41ff78ec07fb6.cloudfront.net (CloudFront)
X-Amz-Cf-Id:ML6_pw3FSS5niemeUH1WapJCBQiiBEeJlWEIULALPo3pBYvFJ7qHXQ==
x-amz-meta-cache-control:max-age=2678400
X-Cache:Hit from cloudfront

[dnkoutso]

in 312cce2 a change added for request replaying causing Picasso to retry requests with content-length 0.

This is why it works in Picasso 2.1.1 and not 2.2 and after.

We need a way to distinguish whether this was a "replay" failure or an actual server response. I think I have a fix.

[cnordvik]

@dnkoutso I recompiled our app with the latest snapshot "picasso-2.4.1-20141231.132545-8.jar" but the user with the issues still experienced the same behavior with images not loading and loads fine with Picasso 2.1.1. Anything I can do to help investigate the issue? Not very easy to troubleshoot since it works fine for 99% of the users including me.

[cnordvik]

@dnkoutso Actually it seems this user have a different issue because for him the images don't load at all, not even the first time. I will try to investigate more by sending him some debug versions so maybe this issue is fixed after all. I will open a new issue if I manage to get some more information.

[dnkoutso]

Its not fixed in 2.5 yet.

[ricky-hufei]

@dnkoutso does Picasso support max-age from the HTTP header? I mean, automatically expire and evict the image from cache after "max-age" is reached. I read the whole LruCache.java file and didn't see anything specially done to track the expiration of specific image. Just want double check with you about that. Thanks.

[f2prateek]

@ricky-hufei The HTTP caching is implemented by the networking client, not Picasso.

[dnkoutso]

What version of okhttp are you guys using? This might be fixed in the later versions of okhttp.

[dnkoutso]

I need a case where i can reproduce this. We have an idea of what the problem is but without reproducing this its hard to know it works.

Can someone who can reproduce build and try dimitris/content-lenght (I know branch has a typo)?

[perlmonk]

I encouraged "Received response with 0 content-length header." before. I don't know if is related to 'If-Modified-Since' header and 304 status. I wrote a customize a downloader to solve this.

Heres the real http download method. The result contains response byte data, we insert a cache between load() and this.

    @Override
    public Response load(Uri path, boolean localCacheOnly) throws IOException {
        String url = path.toString();
        CachedData data = getFromCache(url);

        if (data != null && data.expired) {
            Result getUrlManualDealRedirect(url, data.modifiedData or data.cacheCreateDate);
            if (result.getStatus() == 304) {
                // the expired cache data not expires :)
                // result.getContentLength() is 0
                return convert(data);
            } else {
                // update cache
                return convert(result);
            }
        }

        // ...
    }
    private Result getUrlManualDealRedirect(String url, String headerIfModifideSince) throws IOException {
        boolean tryNext = false;

        Result result;
        do {
            CurlHttp curlHttp = CurlHttp.newInstance();

            // Important, we care redirect(301 and 302)
            curlHttp.setFollowLocation(false);
            if (headerIfModifideSince != null) {
                curlHttp.addHeader("If-Modified-Since", headerIfModifideSince);
            }

            result = curlHttp.getUrl(url).perform();

            if (result.getStatus() == 301 || result.getStatus() == 302) {
                String nextUrl = result.getHeader("Location");
                if (url.equals(nextUrl)) {
                    throw new IOException("redirect loop: url=" + url + ", Location=" + nextUrl);
                }
                if (StringUtils.isBlank(nextUrl)) {
                    throw new IOException("redirect response without Location header, url=" + nextUrl);
                }
                url = nextUrl;
                tryNext = true;
            } else {
                tryNext = false;
            }
        } while (tryNext == true);

        return result;
    }

[soniccat]

Can be easily reproduced using these urls:
"http://commondatastorage.googleapis.com/android-tv/Sample%20videos/Zeitgeist/Zeitgeist%202010_%20Year%20in%20Review/bg.jpg",
"http://commondatastorage.googleapis.com/android-tv/Sample%20videos/Demo%20Slam/Google%20Demo%20Slam_%2020ft%20Search/bg.jpg",
"http://commondatastorage.googleapis.com/android-tv/Sample%20videos/April%20Fool's%202013/Introducing%20Gmail%20Blue/bg.jpg",
"http://commondatastorage.googleapis.com/android-tv/Sample%20videos/April%20Fool's%202013/Introducing%20Google%20Fiber%20to%20the%20Pole/bg.jpg",
"http://commondatastorage.googleapis.com/android-tv/Sample%20videos/April%20Fool's%202013/Introducing%20Google%20Nose/bg.jpg",

[Jakevin]

is fixed now ?

compile 'com.squareup.okhttp:okhttp:2.3.0'
compile 'com.squareup.okhttp:okhttp-apache:2.3.0'
compile 'com.squareup.okio:okio:1.3.0'
compile 'com.squareup.picasso:picasso:2.5.2'
compile 'com.squareup.okhttp:okhttp-urlconnection:2.3.0'

Picasso.with(context).load(url)
                .transform(transformation)
                .priority(Picasso.Priority.HIGH)
                .networkPolicy(NetworkPolicy.OFFLINE)
                .into(imageView);

the same

[michaelclarkjr]

I'm getting similar results with Picasso version 2.5.2. Force Stop and suddenly no image is shown where previously it was showing.

[ajaykk50]

I'm facing the same problem now.I am not getting large images into image view from url in Picasso.Any solution for this one.