Hi, I'm using FFImageLoading 2.2.9 in my Xamarin.Forms 2.3.3.193 project. Sometimes CachedImage controls shows wrong image when loading from cache. I'm currently testing on iOS:

Screenshot on the left is correct one while on the right side you can see a bug - wrong image for first cell in the second row. I must note that this bug appears from time to time and can appear for any CachedImage. Any advices/steps that can help me nail do this bug? I don't want to return to Xamarin.Forms stock Image control.
Can you try downgrading to FFImageLoading 2.2.6? I think this is a newly introduced bug.
Few days after downgrading I start to believe that it really is a new bug. Or I'm just lucky)
It only started happening when I upgraded to 2.2.8 for me. Our app is in production and that's when the reports started.
I think I'm seeing a variant of this. Currently verified on Android only.
I have an image bound to a VM property of type ImageSource, which is set when the user picks an image from the phone's media storage:
public async void ChangeProfilePicture()
{
MemoryStream profilePictureStream = await MediaPicker.PickImageAsync();
ProfilePictureSource = ImageSource.FromStream(() => profilePictureStream);
OnPropertyChanged(() => ProfilePictureSource);
}
This works the first time - if I invoke this again and select a different picture, the control still shows the initially selected one. Furthermore (and that show's that it's a caching issue): If I close and reopen the page (new page instance), loading any picture still displays the initially selected one.
I try to get this fixed by setting the cache duration to 0, or the cache type to Memory, and invoking CachedImage.InvalidateCachebefore changing the image source in my view model. That also didn't work.
I saw this the first time in 2.2.8 (dunno what I upgraded from), still present in 2.2.9
Moving more details from #530
TLDR: restart the app seems to fix individual broken images. Reload from memory still shows the wrong image. So it looks like the wrong image is picked up from disk and cached into memory.
I traced it through my code:
ImageService.Instance.LoadUrl(ImageSourcePath).Into(ProfilePicture);
ImageSourcePath is correct. I opened the URL on a browser and it shows up correctly. However, ProfilePicture displays a different URL.
This happens when I refresh the app as well (i.e. when loading from memory). But if I kill the app and restart it, it loads the correct image and then occasionally introduces errors in other images.
I suspect it is something at the memory level cache of FFImageLoading.
What would be the temporary fix for this? Should I downgrade to 2.2.6? (I'm currently using 2.2.9)
Thanks in advance.
@stringo downgrading to 2.2.6 fixed it for me
@patookllc thanks, the version 2.2.6 it's working fine for me too. Looking forward for the new version with this correction.
I was going nuts about this problem, and it took 2 days for me to understand the reason for this behaviour.
After first upload, image is downloaded and cached as expected, because there was no image at this URL location yet and image with that name/url wasn't cached previously.
After second upload it seams that wrong image was downloaded from server and cached on disk and in memory also.
And this was true, but the cause wasn't FFImageLoading library, but the backend server upload procedure.
I'm using Azure Blob, along with Web Job that makes several sizes of image, after I upload a new image.
It takes 1-3 seconds for Web Job to awake and do the job.
If I set "DataLocationUri" property to early, before new version of image even exists at "DataLocationUri" location, I will get previously uploaded version eventhough I use CustomCachedKey. This is way FFImageLoading will get that "wrong" image and preserve it in cache also.
What I really had to do is is change my upload procedure on backend server so it removes old version of image (all sizes) and only after it completes save a new version of image.
In order to be more user friendly so user thinks it is still loading and allow ImageService to perform several retries I had to change two properties:
RetryCount = 20;
RetryDelayInMs = 200;
If Azure Web Job does the job in 4 seconds (and normally it should do it), user should see correct uploaded image.
If others don't use Web Jobs, but upload image to live location directly, the same approach apply because it might be the problem with server caching of images.
In that situation you should additionaly change your backend procedure so you:
http://my.domain.com/live/myImage.jpg#THIS_IS_THE_HASH
This is old web programming approach used to avoid caching problem with newly uploaded images.
Does it happen on the latest prerelease nuget too? There were some fixes that could potentially fix the issue. Thanks.
I see this occasionally in the latest pre-release and earlier versions. It's hard to track but here is my scenario. I have a ListView of images people have posted, using a simple loading placeholder as well. When scrolling the ListView up and down sometimes the wrong image will load, can't really figure out a pattern to it. Also note I am not using RecycleElement.
Could you test the newest prerelease as there were some fixes with memory cache? (https://github.com/luberda-molinet/FFImageLoading/commit/9b88540b43083a19b2fa0f46011c02d68ca8fee2)
Initial tests look good! I'd like to play around with it more as it was hard to create in the first place.
Xamarin / Xamarin Forms 2.2.10-pre-408 on Android, the issue still persists when deployed over existing installation. Is there any way to invalidate the cache ?
My problem is that it's returning old image, although cachevalidity is set to one minute, on other page caching is disabled and still it's returning old image.
I believe it's fixed in the newest stable. Please reopen if you still experience it. Thanks.
I'm a little afraid that this issue still persists, my app is using 2.2.10 and I can see old image being loaded although cache is set to one minute, the image contains timestamp so it's easy to spot. My tests are quite limited maybe not enough to reopen the case.
@kakoskin Currenty, old cache items are only purged at app startup, we'll need to improve that.
Most helpful comment
Initial tests look good! I'd like to play around with it more as it was hard to create in the first place.