Forums › Forums › Farktography General Chat › Farktography Pub and Grill › Important Image Hosting Changes at Fark Please Read
- This topic has 33 replies, 8 voices, and was last updated 10 years, 7 months ago by Elsinore.
-
AuthorPosts
-
July 4, 2013 at 6:20 pm #51778CauseISaidSoParticipant
Well, from my observations over the last few weeks, I think this is how it works:
- Before and during the contest: When an image is first posted, if it’s already scaled to Fark sizes, it’s posted with its original image link; otherwise, if the image has to be resized, it goes straight to img.fark.net.
- After the contest closes: All images are cached and links converted to img.fark.net links.
You can see this behavior by looking at bibliostats now. All of the thumbs for this contest should pop to their original source, which means everyone’s posts must’ve already been Fark-sized. Once the contest closes, those will all change to img.fark.net links and those links change periodically which means the bibliostats links shortly go to the Fark 403 page.
I could modify the scraper to keep the original link from when the contest is live and ignore the changeover to the image cache, but that’s a little bit of work and it still wouldn’t address non-Fark-sized images that go directly to the cache.
I think the ideal solution would be to get Mike to put the full original link in either the alt or title attribute of the img link. Right now, those are set to just the domain of the image host and they’re also changed to “img.fark.net” when cached.
July 11, 2013 at 1:19 am #51779ElsinoreKeymasterI could modify the scraper to keep the original link from when the contest is live and ignore the changeover to the image cache, but that’s a little bit of work and it still wouldn’t address non-Fark-sized images that go directly to the cache.
I think the ideal solution would be to get Mike to put the full original link in either the alt or title attribute of the img link. Right now, those are set to just the domain of the image host and they’re also changed to “img.fark.net” when cached.
That sounds like good feedback…I can pass that along to Mike.
July 11, 2013 at 5:06 am #51780Choc-Ful-AParticipantI don’t think the images post with the original links, even before the contest goes live.
Here’s what leads me to believe that… I did the following, in this order a few days before the current contest went live.
1. upload an image to my hosting service (SmugMug)
2. post an entry in the Farktography contest using an image that was small enough that it didn’t need to be re-sized
3. discovered that I’d screwed up the entry and it looked terrible due to bad HTML
4. deleted the image from my hosting site, meaning the URL of the image in step #1 no longer worked
5. re-uploaded the images to SmugMug
6. posted a second entry to the Farktography contest using the step #5 image, again with an image that was small enough to post without re-sizing
Prior to the image caching changes that would have fixed the problem since Fark would detect that the first posting had a broken image reference and the entry would automatically be taken down.
However… The content entry persisted since the image was being served by Fark and not pulled from my hosting site. Which led to the embarrassing final step.
7. Post a note asking a moderator to help clean up the mess and delete the first entry with the broken HTML.
So IMO, if Fark was using the original image URL it would have noticed it was broken. But that didn’t happen. Which leads me to believe that aside from the initial pull from the image host, to get it to the Fark server, the contest don’t use the original hosting service and the entries are setup to reference the Fark local storage (or cache) from the very beginning.
July 11, 2013 at 6:12 am #51781CauseISaidSoParticipantSorry to disagree with ya, Choc-Ful-A, but I’ve got the image sources right in front of me and they’re all from the original hosts. For example, here are yours:
- http://cnamejj.smugmug.com/Photography/Places/Mendocino-2012/i-dd272pM/0/X2/dsc_0105-cr-ad-X2.jpg
- http://cnamejj.smugmug.com/Photography/Farktography-2013/Waterscapes-2013/i-hQKLsR8/0/X2/dsc_0276-cr-ad-X2.jpg
- http://cnamejj.smugmug.com/Photography/Farktography-2013/Waterscapes-2013/i-F5dkMvD/0/O/dsc_0030-ad-W850.jpg
Based on what you saw, though, I’d probably revise my theory to guess that they’re cached immediately but that the caching URL isn’t used unless the image goes missing or until the contest ends.
July 11, 2013 at 6:33 am #51782Choc-Ful-AParticipantSomething odd is going on then… The URL that I uploaded into a posting didn’t work in a browser, but the Fark entry was still showing the image. Meaning one tab in a browser shows a broken image, and another tab with the Fark contest shows the entry with the image.
And yes, I should have checked the HTML carefully.
July 11, 2013 at 6:48 am #51783CauseISaidSoParticipantSomething odd is going on then… The URL that I uploaded into a posting didn’t work in a browser, but the Fark entry was still showing the image.
Yep, that’s why I modified my theory. Once Fark detected that your image went missing (the URL that didn’t work because you deleted the image), it replaced the bad (original) URL with the one that points to the cache, which means that Fark has to cache everything immediately after it’s posted.
But, to explain what I see, Fark doesn’t use the cached image unless or until:
- The original image exceeds the Fark size limits
- The image goes missing (like yours)
- The contest ends (after which all images are replaced with the cached version)
July 11, 2013 at 10:24 am #51784Choc-Ful-AParticipantThat’s very, very obnoxious behavior IMO. 🙂 But it’s not my website so I’ll either deal with it or go someplace else.
July 11, 2013 at 7:58 pm #51785ElsinoreKeymasterJust FYI, Bibliostats picked up several Scarlet R’s this week, so is that feature working after all despite the Fark cache thingy? Or is that only working for those images that are posted Fark size in the first place, as opposed to being resized by Fark? I’m starting to get confuzzled 😆
July 11, 2013 at 8:13 pm #51786CauseISaidSoParticipantJust FYI, Bibliostats picked up several Scarlet R’s this week, so is that feature working after all despite the Fark cache thingy?
Yes and no, but you’re mostly correct on your speculation.
Since most images are posted pre-scaled to Fark sizes, they’re shown on Fark with their original URLs instead of the cache URL. So, they can be checked against other contests that used the same URL.
But, once the contest closes, all original URLs are converted to cache URLs which are worthless for checking reposts. So any contest scanned after caching was implemented cannot be used to detect reposts.
Basically, reposts will be detected if:
- The image is already pre-scaled to Fark sizes; AND
- The original post occurred in a contest prior to caching implementation.
Caching implementation started with contest #418, so reposts can only be detected in contests 417 and earlier.
July 11, 2013 at 11:24 pm #51787YugoboyParticipantCaching implementation started with contest #418, so reposts can only be detected in contests 417 and earlier.
Interesting…
😈 * rubs hands together while smirking and walking innocently into the darkness from whence he came* 😈
July 12, 2013 at 11:26 am #51788ElsinoreKeymasterI passed along your feedback to Mike, and this was his response:
Can you just use a hash or checksum of the image? That’s how *we* determine dupes — using the SHA1 of the image data. It’s much more reliable than using the URL.
(hint: our cached filename is based on the SHA1 of the pre-thumbnailed image already.)
Does this help at all?
July 12, 2013 at 4:16 pm #51789CauseISaidSoParticipantYeah, that’s a possibility. It would mean rescanning all prior contests to calculate the hashes, and of course any entry that has since dropped off wouldn’t get calculated. Then again, if the entry has dropped off, it’s not going to be reposted under that same URL anyway, so that’s not really an issue.
I’ll look into it, but it’ll be a couple of months at least before I can do anything about it as I’ve got a lot on my plate right now (hence the lack of recent participation :().
Edited to add: It also doesn’t solve the pop-to-original-from-thumbnail breakage that occurs with the cached URLs.
July 12, 2013 at 8:14 pm #51790ElsinoreKeymasterYeah we can muddle through if need be. I’ll ask about the pop-to-original thing. I didn’t think those were broken, but then I might be misunderstanding.
July 12, 2013 at 9:16 pm #51791CauseISaidSoParticipantPop-to-original works while the contest is live (as long as the original image is pre-scaled to Fark size), but once the contest ends and the links are changed to cache URLs (basically the last pass that the scanner makes), it becomes broken. Click on the thumb for any image from contest #418 forward (except for the current live contest) and you’ll get directed to a Fark 403 page.
July 13, 2013 at 4:44 pm #51792fluffybunnyParticipantSo is there a way to rescan the contest after is it archived and convert biblio-links to the now cached version? A kind of two step process I guess.
-
AuthorPosts
- The topic ‘Important Image Hosting Changes at Fark Please Read’ is closed to new replies.