Open oliverhausler opened 9 years ago
This line seems to cause the problem. It's hard to debug, but when I remove it, it seems not to happen. Is that possible?
imagePreview.setImageDrawable(null);
When I go into my app info and "Clear cache" it works again.
When I apply .skipMemoryCache() [I know it's deprecated] images are always loaded from network and the issue does not occur.
When I apply .memoryPolicy(MemoryPolicy.NO_STORE) the issue happens.
When I have indicators for memory/disk/network access enabled and the image stays black, the indicator is not shown.
Very strange, but the problem happens after the device has been in standby or idling for some time. I can almost reproduce it by letting the app sit for some time. If somebody there wants to debug this with me, let me know. I have no idea why it happens, but this might be the issue why people keep complaining about images that don't load.
And more strange, it seems to happen only to images served from Google Cloud Storage, images served from the Facebook CDN stay fine (photos taken with the same device/same camera, but compressed/served either by Android/Google and Facebook, respectively).
Is it possible that the image format plays a role? I would possibly exclude the server, as images are downloaded fine at first.
I'm facing the same issue, images served from FB CDN never gave me any problem.
However when I load my images from Azure blob storage I will get this issue.
04-13 05:23:50.522 32088-32088/com.backyard.shoptizen D/Picasso﹕ Main created [R227] Request{https://shoptizenstorage.blob.core.windows.net/pictures/0b57bd8dd915c7bbde3460f1592b1bfc.jpg resize(300,0)} 04-13 05:23:50.523 32088-32088/com.backyard.shoptizen D/Picasso﹕ Main created [R228] Request{https://shoptizenstorage.blob.core.windows.net/pictures/b876b55c1daeae7395e38a727241243e.jpg resize(300,0)} 04-13 05:23:50.533 32088-32131/com.backyard.shoptizen D/Picasso﹕ Hunter joined [R227]+11ms to [R183]+60s, [R227]+11ms 04-13 05:23:50.533 32088-32131/com.backyard.shoptizen D/Picasso﹕ Hunter joined [R228]+9ms to [R184]+60s, [R228]+9ms 04-13 05:23:50.893 32088-32088/com.backyard.shoptizen D/Picasso﹕ Main created [R229] Request{https://shoptizenstorage.blob.core.windows.net/pictures/90af9bdd48bc3290871d91584adc7376.jpg resize(300,0)} 04-13 05:23:50.894 32088-32088/com.backyard.shoptizen D/Picasso﹕ Main created [R230] Request{https://shoptizenstorage.blob.core.windows.net/pictures/a500a17398401545749cfe16c144dfca.jpg resize(300,0)} 04-13 05:23:50.895 32088-32088/com.backyard.shoptizen D/Picasso﹕ Main created [R231] Request{https://shoptizenstorage.blob.core.windows.net/pictures/3bd06fbd7551374a3e83e0c7cd494926.jpg resize(300,0)} 04-13 05:23:50.896 32088-32131/com.backyard.shoptizen D/Picasso﹕ Hunter joined [R229]+3ms to [R185]+59s, [R229]+3ms 04-13 05:23:50.896 32088-32131/com.backyard.shoptizen D/Picasso﹕ Hunter joined [R230]+2ms to [R186]+59s, [R230]+2ms 04-13 05:23:50.896 32088-32131/com.backyard.shoptizen D/Picasso﹕ Hunter joined [R231]+1ms to [R187]+59s, [R231]+1ms
I kept trying things and it looks like the culprit was okhttp. Updated from 2.0.0. to 2.3.0 and voilà, all images reloaded. [Now I'm only hoping this is not a temporary effect because okhttp reloads all images after an updated in any case. We'll see...]
@alexenderjohanson are you using okhttp, and which version? I didn't see your post, but I just updated to 2.3.0 and I hope the problem is now gone.
@oliverhausler Works like a charm. I updated okhttp from 2.0.0 to 2.3.0.
And it still works :) so apparently Picasso is not compatible with okhttp 2.0.0. You may want to add a few words to your readme.
When you look at the logs using okhttp 2.0.0, you will find something like "not found: cacheControl" - I don't remember the exact message.
After 2 weeks, I'd say it works. At least it won't crash anymore. I leave this open because it still doesn't work as supposed:
Probably an okhttp issue, but I'll keep watching it.
I have encountered this issue recently and I need a fix ASAP.
Images loaded from GCS will work, but will stop after some time. Clearing the app cache fixes the issue, as described in this issue thread.
How can I fix this?
There are customers using our app and we can't have broken images.
PS I am not using okhttp
all speeds as "felt" ;-)
Obviously, there was a bug in 2.0.0, which has been fixed dirty in 2.3.0 and properly in 2.4.0. I did not dig any deeper.
Hi Oliver,
i am facing the same issue , have you found any solution for this.
thank you for your feedback
Antony
Hi Antony,
I have updated to
compile 'com.squareup.picasso:picasso:2.5.2'
and since not seen it.
Oliver.
I am using Picasso 2.5.2 and some images doesnt load for reasons i am not able to debug. It works when i clear the app's data.
Hi Oliver, I was facing the same issue and updating okhttp to 2.4.0 fixed the problem. It now works perfectly. Thank you.
Well, It is late but @rahulrj You can put Picasso.with(context).setLoggingEnabled(true);
to debug
I had this issue with compile 'com.squareup.picasso:picasso:2.5.2'
.
I got it with debug enabled:
D/Picasso: Main created [R67] Request{http://graph.facebook.com/......./picture?type=square} D/Picasso: Dispatcher enqueued [R67]+1ms D/Picasso: Hunter executing [R67]+1ms D/Picasso: Main created [R68] Request{http://graph.facebook.com/......./picture?type=square} D/Picasso: Hunter executing [R68]+0ms D/Picasso: Dispatcher enqueued [R68]+0ms D/Picasso: Main created [R69] Request{http://graph.facebook.com/......./picture?type=square} D/Picasso: Hunter joined [R69]+1ms to [R68]+4ms, [R69]+1ms D/Picasso: Main created [R70] Request{http://graph.facebook.com/......./picture?type=square} D/Picasso: Hunter joined [R70]+2ms to [R68]+9ms, [R69]+7ms, [R70]+3ms D/Picasso: Main created [R71] Request{http://graph.facebook.com/......./picture?type=square} D/Picasso: Hunter joined [R71]+0ms to [R68]+12ms, [R69]+10ms, [R70]+5ms, [R71]+0ms D/Picasso: Main created [R72] Request{http://graph.facebook.com/......./picture?type=square} D/Picasso: Hunter joined [R72]+2ms to [R68]+17ms, [R69]+15ms, [R70]+10ms, [R71]+5ms, [R72]+2ms D/Picasso: Main created [R73] Request{http://graph.facebook.com/......./picture?type=square} D/Picasso: Hunter joined [R73]+1ms to [R68]+20ms, [R69]+17ms, [R70]+13ms, [R71]+8ms, [R72]+4ms, [R73]+1ms D/Picasso: Main created [R74] Request{http://graph.facebook.com/......./picture?type=square} D/Picasso: Hunter joined [R74]+2ms to [R68]+23ms, [R69]+20ms, [R70]+16ms, [R71]+11ms, [R72]+8ms, [R73]+4ms, [R74]+2ms D/Picasso: Dispatcher batched [R68]+371ms, [R69]+368ms, [R70]+364ms, [R71]+359ms, [R72]+356ms, [R73]+352ms, [R74]+350ms for error D/Picasso: Dispatcher batched [R67]+427ms for error D/Picasso: Main errored [R68]+574ms D/Picasso: Main errored [R69]+571ms D/Picasso: Main errored [R70]+567ms D/Picasso: Main errored [R71]+562ms D/Picasso: Main errored [R72]+559ms D/Picasso: Main errored [R73]+555ms D/Picasso: Main errored [R74]+553ms D/Picasso: Main errored [R67]+579ms D/Picasso: Dispatcher delivered [R68]+575ms, [R69]+572ms, [R70]+568ms, [R71]+563ms, [R72]+560ms, [R73]+556ms, [R74]+554ms, [R67]+580ms
I put okhttp version 2.4.0 and It works.
compile 'com.squareup.okhttp:okhttp:2.4.0'
compile 'com.squareup.picasso:picasso:2.5.2'
Yes, I would like to confirm that this is okhttp fault. Remove that and try again, it will definitely work. Or use latest okhttp version.
Just Use Glide, it solved my problem and it's easy to change.
https://guides.codepath.com/android/Displaying-Images-with-the-Glide-v3-Library
Thank you @FelipeTartarotti we already did. :)
I have same issue , I am using com.squareup.picasso:picasso:2.71828. so there are some images shown as black when I load it from URL then the issue will be resolved by clearing the cache
I commented on #626, but this might be a new issue, so I moved it here.
Not sure if Picasso can do anything about it, but I believe I found a possible issue related to disk caching:
Images that previously loaded fine suddenly stop working. Instead of the image, a black screen is displayed and the error image specified in .error() is NOT loaded. Restarting the app or the device doesn't clear the problem, but uninstall/reinstall does. After a reinstall images are loaded normally.
Based on this, I figured it must be a disk caching problem, and most probably the cached images are defunct. So I want to tell you what I did and what might have caused this:
I am loading a lot of large images into a scroll view, of which most are outside the viewport. So I played with removing images from imageViews that are currently not visible. I randomly applied the following code found here http://stackoverflow.com/questions/8349958/imageview-automatically-recycle-bitmap-if-imageview-is-not-visible-within-scro - or parts of it:
It seems like Picasso still held a reference to the drawable at the same time and recycling the drawable destroyed it in the other thread, which rendered it defunct. But Picasso still believes it has a valid drawable cached and tries to reuse it the next time it is loaded.
Possibly a simple check if a cached image is valid - and reverting to loading from memory or the network in case it is not - would fix the problem.
Here my original post:
I don't know if this is related, but Picasso suddenly stopped displaying certain images (which were most possibly cached on disk). After uninstall/reinstall it worked normally again.
before:
04-11 08:36:38.900 20448-20448/cc.closeup.android D/Picasso﹕ Main created [R0] Request{https://storage.googleapis.com/closeup0002/7836f5829298440787be11cf53b8fd39.jpeg resize(1280,720) centerCrop} 04-11 08:36:38.910 20448-20740/cc.closeup.android D/Picasso﹕ Dispatcher enqueued [R0]+15ms 04-11 08:36:38.915 20448-20770/cc.closeup.android D/Picasso﹕ Hunter executing [R0]+20ms 04-11 08:36:38.935 20448-20448/cc.closeup.android D/Picasso﹕ Main created [R2] Request{https://storage.googleapis.com/closeup0002/8edb01cc933942439b815c32b62aff39.jpeg resize(1280,720) centerCrop} 04-11 08:36:38.940 20448-20448/cc.closeup.android D/Picasso﹕ Main created [R4] Request{https://storage.googleapis.com/closeup0002/a7c0aeb1914248aaaffc7bcc549ff8db.jpeg resize(1280,720) centerCrop} 04-11 08:36:38.940 20448-20743/cc.closeup.android D/Picasso﹕ Dispatcher enqueued [R2]+7ms 04-11 08:36:38.950 20448-20777/cc.closeup.android D/Picasso﹕ Hunter executing [R4]+11ms 04-11 08:36:38.950 20448-20746/cc.closeup.android D/Picasso﹕ Dispatcher enqueued [R4]+11ms 04-11 08:36:38.950 20448-20776/cc.closeup.android D/Picasso﹕ Hunter executing [R2]+16ms 04-11 08:36:39.500 20448-20746/cc.closeup.android D/Picasso﹕ Dispatcher retrying [R4]+559ms 04-11 08:36:39.500 20448-20784/cc.closeup.android D/Picasso﹕ Hunter executing [R4]+563ms 04-11 08:36:39.505 20448-20740/cc.closeup.android D/Picasso﹕ Dispatcher retrying [R0]+605ms 04-11 08:36:39.505 20448-20743/cc.closeup.android D/Picasso﹕ Dispatcher retrying [R2]+568ms 04-11 08:36:39.505 20448-20786/cc.closeup.android D/Picasso﹕ Hunter executing [R2]+570ms 04-11 08:36:39.505 20448-20787/cc.closeup.android D/Picasso﹕ Hunter executing [R0]+610ms
after:
04-11 08:40:08.380 22348-22348/cc.closeup.android D/Picasso﹕ Main created [R0] Request{https://storage.googleapis.com/closeup0002/7836f5829298440787be11cf53b8fd39.jpeg resize(1280,720) centerCrop} 04-11 08:40:08.385 22348-22348/cc.closeup.android D/Picasso﹕ Main created [R2] Request{https://storage.googleapis.com/closeup0002/8edb01cc933942439b815c32b62aff39.jpeg resize(1280,720) centerCrop} 04-11 08:40:08.390 22348-22348/cc.closeup.android D/Picasso﹕ Main created [R4] Request{https://storage.googleapis.com/closeup0002/a7c0aeb1914248aaaffc7bcc549ff8db.jpeg resize(1280,720) centerCrop} 04-11 08:40:08.395 22348-22764/cc.closeup.android D/Picasso﹕ Dispatcher enqueued [R2]+7ms 04-11 08:40:08.395 22348-22808/cc.closeup.android D/Picasso﹕ Hunter executing [R2]+8ms 04-11 08:40:08.405 22348-22767/cc.closeup.android D/Picasso﹕ Dispatcher enqueued [R4]+14ms 04-11 08:40:08.405 22348-22810/cc.closeup.android D/Picasso﹕ Hunter executing [R4]+16ms 04-11 08:40:08.410 22348-22761/cc.closeup.android D/Picasso﹕ Dispatcher enqueued [R0]+32ms 04-11 08:40:08.415 22348-22812/cc.closeup.android D/Picasso﹕ Hunter executing [R0]+35ms 04-11 08:40:09.150 22348-22812/cc.closeup.android D/Picasso﹕ Hunter decoded [R0]+774ms 04-11 08:40:09.160 22348-22808/cc.closeup.android D/Picasso﹕ Hunter decoded [R2]+771ms 04-11 08:40:09.160 22348-22810/cc.closeup.android D/Picasso﹕ Hunter decoded [R4]+772ms 04-11 08:40:09.320 22348-22812/cc.closeup.android D/Picasso﹕ Hunter transformed [R0]+943ms 04-11 08:40:09.370 22348-22761/cc.closeup.android D/Picasso﹕ Dispatcher batched [R0]+991ms for completion 04-11 08:40:09.415 22348-22808/cc.closeup.android D/Picasso﹕ Hunter transformed [R2]+1027ms 04-11 08:40:09.430 22348-22764/cc.closeup.android D/Picasso﹕ Dispatcher batched [R2]+1044ms for completion 04-11 08:40:09.535 22348-22810/cc.closeup.android D/Picasso﹕ Hunter transformed [R4]+1145ms 04-11 08:40:09.535 22348-22767/cc.closeup.android D/Picasso﹕ Dispatcher batched [R4]+1145ms for completion 04-11 08:40:09.570 22348-22761/cc.closeup.android D/Picasso﹕ Dispatcher delivered [R0]+1193ms 04-11 08:40:09.570 22348-22348/cc.closeup.android D/Picasso﹕ Main completed [R0]+1192ms from NETWORK 04-11 08:40:09.685 22348-22764/cc.closeup.android D/Picasso﹕ Dispatcher delivered [R2]+1246ms 04-11 08:40:09.700 22348-22348/cc.closeup.android D/Picasso﹕ Main completed [R2]+1314ms from NETWORK 04-11 08:40:09.735 22348-22767/cc.closeup.android D/Picasso﹕ Dispatcher delivered [R4]+1346ms 04-11 08:40:09.745 22348-22348/cc.closeup.android D/Picasso﹕ Main completed [R4]+1357ms from NETWORK