Issue with PhotosGetInfo

[Jimmy-Jay]

This just started after the SmugMug buyout, but I don't think it's related.

I wrote a .net app that I use regularly to embed my Flickr albums, set title, description, etc into my wordpress blog. It's worked great for 2 years, but just started pooping on itself.

I can retrieve the set information, but as soon as I start retrieving photo info it hangs. Code snippet at the end, but this line is where I die - PhotoInfo piInfo = flickr.PhotosGetInfo(photo.PhotoId);

I see the data returned from flickr and populated into the responseCache.dat file, but we never return the data from the cache to the application. I've ensured that permissions to the cache folder are wide open.

I haven't changed anything on my end, except the usual Windows updates, etc - thoughts?

Thanks! //j

        foreach (Photo photo in pPhotos)
        {
            // our first photo's URL is added as our primary photo so we can set it as our blog post preview photo
            if (sPrimaryPhoto.Equals(string.Empty))
            {
                sPrimaryPhoto = photo.Medium640Url.ToString();
                txtFeaturedImage.Text = sPrimaryPhoto;
            }

            #region "Get our PhotoInfo"
            // get our PhotoInfo
            PhotoInfo piInfo = flickr.PhotosGetInfo(photo.PhotoId);
            Debug.WriteLine("photoinfo retrieved");

[lantram]

One of my Azure web apps came to screeching halt about 4 or 5 days ago, consistently ramping up to 100% CPU. I've spent a maddening amount of time since then to trying to figure out why. Eventually, I decided to use the Azure preview "Proactive CPU Monitoring" feature to have it create a memory dump when it next occurred. The rule I used was:

"When the site's process or any child processes of the site's process takes 75% of CPU for more than 30 seconds, collect a memory dump and analyze when all the dumps have been collected. Evaluate CPU usage every 15 seconds. Collect a maximum of 2 memory dumps. Monitoring will stop automatically after 7 days."

From that, the robot AI came up with this analysis:

"Multiple threads enumerating through a collection is intrinsically not a thread-safe procedure. If the dictionary object accessed by these threads is declared as static then the threads can go in an infinite loop while trying to enumerate the dictionary if one of the threads writes to the dictionary while the other threads are reading\enumerating through the same dictionary. You may also experience High CPU during this stage. For more details refer to High CPU in .NET app using a static Generic.Dictionary"

And it pointed to this as the culprit:

"FlickrNet.Flickr.PhotosGetInfo(System.String)"

I haven't looked at the Flickr.Net code - but I gotta assume the stupid robot AI was correct. I removed calls to that code, and my site is working fine again.

This must be the exact same issue you are experiencing.

So basically, there's a bug in Flickr.Net. Microsoft must have updated something-or-other that now exposes it. And as of now, the library is broken.

[Jimmy-Jay]

That's the same thing I'm seeing - thanks for taking the time to chime in. The same issue crops up retrieving place info from the flickr photos as well.

I'd be happy to send @samjudson a case of beer to get this one fixed since I use it heavily for my family blog :)

[samjudson]

Very weird.

Can you try disabling the cache completely, but setting Flickr.CacheDisabled = true?

My caching stuff probably works fine in a desktop scenarios where only one process is trying to touch the cache file, but I suspect in a web app when multiple people are potentially hitting the web site using a file for caching is likely going to cause problems.

I would recommend adding some either output caching, or memory caching though.

[Jimmy-Jay]

Cache disabled, same issue. The data returns from Flickr, but photoInfo and placeInfo doesn't populate. I also tested on 2 other Win10 machines with the same results.

When I re-enable the cache, here's the response data I see being returned for the photo from Flickr:

<rsp stat="ok">
<photo id="BLAH" secret="BLAH" server="65535" farm="66" dateuploaded="1559780502" isfavorite="0" license="0" safety_level="0" rotation="0" originalsecret="BLAH" originalformat="jpg" views="20" media="photo">
    <owner nsid="BLAH" username="BLAH" realname="BLAH" location="BLAH" iconserver="6182" iconfarm="7" path_alias="BLAH" />
    <title>Sharp Eyes</title>
    <description>BLAH</description>
    <visibility ispublic="1" isfriend="0" isfamily="0" />
    <dates posted="1559780502" taken="2019-04-28 10:51:42" takengranularity="0" takenunknown="0" lastupdate="1559780519" />
    <editability cancomment="0" canaddmeta="0" />
    <publiceditability cancomment="1" canaddmeta="0" />
    <usage candownload="1" canblog="0" canprint="0" canshare="1" />
    <comments>0</comments>
    <notes />
    <people haspeople="0" />
    <tags>
        <tag id="BLAH-48010491308-32275" author="BLAH" authorname="BLAH" raw="Arches National Park" machine_tag="0">archesnationalpark</tag>
        <tag id="BLAH-48010491308-465267" author="BLAH" authorname="BLAH" raw="Fiery Furnace" machine_tag="0">fieryfurnace</tag>
        <tag id="BLAH-48010491308-8674" author="BLAH" authorname="BLAH" raw="Jim" machine_tag="0">jim</tag>
        <tag id="BLAH-48010491308-19617" author="BLAH" authorname="BLAH" raw="Moab" machine_tag="0">moab</tag>
        <tag id="BLAH-48010491308-2994" author="BLAH" authorname="BLAH" raw="Nikon" machine_tag="0">nikon</tag>
        <tag id="BLAH-48010491308-7540801" author="BLAH" authorname="BLAH" raw="Nikon 20mm 2.8" machine_tag="0">nikon20mm28</tag>
        <tag id="BLAH-48010491308-14100229" author="BLAH" authorname="BLAH" raw="Nikon D700" machine_tag="0">nikond700</tag>
        <tag id="BLAH-48010491308-2290" author="BLAH" authorname="BLAH" raw="Utah" machine_tag="0">utah</tag>
    </tags>
    <location latitude="38.748066" longitude="-109.561447" accuracy="16" context="0">
        <neighbourhood woeid="0" />
    </location>
    <geoperms ispublic="1" iscontact="0" isfriend="0" isfamily="0" />
    <urls>
        <url type="photopage">https://www.flickr.com/photos/BLAH/BLAH/</url>
    </urls>
</photo>
</rsp>

[Jimmy-Jay]

I also just tried on a Win8 machine that's been powered off for about a year and a fresh Win10 VM to ensure that it wasn't a recent Windows Update that's breaking this. My guess would be something different in the response that Flickr is providing since the SmugMug purchase.

What's the chance that someone has a response cached from a month or two ago when this worked so we can compare them?

//j

[Jimmy-Jay]

And more troubleshooting info: The issue is only with geotagged photos. I created a test album and removed geodata from the photos in it, works like a champ. Add geodata back and it immediately hangs. Add geodata to a single photo in the album and it processes all the photos and then hangs on the one photo with geodata.

Something here: `

</location>
<geoperms ispublic="1" iscontact="0" isfriend="0" isfamily="0" />`

[samjudson]

That's great, thanks, I'll try and reproduce at my end.

[samjudson]

I believe its actually the <neighbourhood woeid="0" />. It is not expecting an empty tag for this element, and is probably going getting into some weird kind of infinite loop because of it.

[Jimmy-Jay]

Judging by other threads there's something wonky from Flickr with the woeid, which isn't too surprising since that's a Yahoo API providing it. https://www.flickr.com/help/forum/en-us/72157708955254091/

[clbell123]

Has anyone found a workaround to this?

[Jimmy-Jay]

I just set the geodata to private and do what I need to do with my app. Since I export all of my images from Lightroom, I created an export from LR that creates local minimal images with the geodata, and then rip the data from there to create the map that I embed in my post. I'd guess that @samjudson is probably working on a fix for this that ignores the woeid data completely, but I threw my quick fix together in the meantime since I take a lot of photos that I embed into my blog almost daily. //j

[clbell123]

I see Sam has made some code updates. I'd like to say many thanks and also request an update to the NuGet package.

[samjudson]

Yeah, that's next on my list... Hopefully tomorrow?

[clbell123]

Yeah, that's next on my list... Hopefully tomorrow?

Fantastic. Thanks.

[samjudson]

OK, there is a new version on NuGet. Could someone update and confirm it works as expected?

[clbell123]

OK, there is a new version on NuGet. Could someone update and confirm it works as expected?

Working great so far!

[Jimmy-Jay]

You sir, are awesome. Your efforts save me a bunch of time - send me your paypal and I'll send you a case of beer. Thanks! //j