I stated getting this with trunk as well. If I wait long enough (minutes) I even get a browser page saying the images have been successfully uploaded, but they don't show up.

The console is dead silent about this, even with --debug. It takes around 20 minutes for the 'success' page to appear.

Created attachment 112822 [details]
the 'success' page is blank like this

This seems to be network related. I have just returned from travels where export to flickr worked just fine. But here at home it doesn't work on the very same machine with the very same flickr account. 

What is odd, I can upload photos with Postr[1] just fine. I have been able to upload using f-spot in the past as well. I have not changed anything on my router/firewall, I have not switched ISPs.

[1] http://burtonini.com/blog/computers/postr

Created attachment 113847 [details]
A packet capture using wireshark when uploading a small image to flickr using postr

Created attachment 113848 [details]
f-spot packet capture uploading the same file. SUCCESSFULLY

I was going to attach an f-spot capture doing the same and timing out, but AMAZINGLY it just started orking today :((( So this one also succesfully uploaded. This bug is a mystery.

I am seeing a similar symptom. In my case it stopped with "Waiting for response 20 of ..." and "... 8 of ...". The 20 and 8 pictures (of each attempt) did indeed appear on Flickr. 

This is one of those cases where you want to log the complete conversation between the client and server (excluding perhaps the image data). Is there a way to capture such a log with F-Spot?

I never got the "success" after upload page, but then I only left it sitting in the no-visible-progress state for 20 and 10 minutes respectively.

This would be F-Spot 0.4.3.1 on Ubuntu, in my case.

jimmac issue was networkk related, and he solved it by

ifconfig eth0 mtu 1450

(with the correct ethernet interface instead of eth0)

am quite sure Preston issue is not related to jimmac's

Same problem for me on Ubuntu with 0.4.3.1 revision.

(In reply to comment #10)
> Same problem for me on Ubuntu with 0.4.3.1 revision.
> 

Step(In reply to comment #9)
> jimmac issue was networkk related, and he solved it by
> 
> ifconfig eth0 mtu 1450
> 
> (with the correct ethernet interface instead of eth0)
> 
> am quite sure Preston issue is not related to jimmac's
> 

Your solution is working, can you explain the trouble and how to have this configuration permanently ?

I saw this "waiting for response" symptom many times over 3-4 days. Since then I have done large uploads w/o error. Keep in mind my internet provider (Cox Cable in Orange County, California) is generally very reliable and performance over their network is excellent. Also note that uploading photos is about my only activity that involves large uploads.

I wonder if some of us are getting bit by ISPs attempting to manage traffic.
http://www.dslreports.com/shownews/Cox-Also-Disrupting-P2P-Traffic-89481

Note that Cox doing traffic management (as they should), not necessarily targeting any one specific protocol or application.

Only one thing changed in my network configuration that *might* be relevant. A few weeks back I'd bought a new 802.11n router. Where the signal from my old routers was weak and unreliable in spots, the signal from the new router was strong everywhere. Perhaps too much so. The initial setup was unsecured. A few days before I ran into the reported problem, I noticed several uninvited "guests", and secured the wireless network.

Now ... if those "guests" were generating a lot of upload traffic, it is possible that Cox had my modem targeted for traffic suppression. It might take a few days before the Cox network folk note reducing traffic and remove that sort of filter.

A few days after the reported problem, all my photo uploads complete w/o trouble.

Just a guess, but they may be related. 

The upshot of all this is that the f-spot upload function needs timeout/retry logic - does not matter what the cause (there are always going to be network disruptions of one sort or another) ... and tweaking MTU parameters is an unlikely(!) solution.

Also for me the fix described above by Stephane Delcroix in item #9 worked, changing the MTU to 1450

However, My network interfaces are managed by NetworkManager, and I don't know how to make this change stick. And in gerenal, it seems that I should not need to. Either this is a bug with network manager, or with the Flickr Export?

Most people using f-spot will not be searching bugzilla reports and even if they did, and found this one, would not be able to fix their problem.

*** Bug 556536 has been marked as a duplicate of this bug. ***

I have the same issue, version 0.5.0.3 (Ubuntu Intrepid). Setting the MTU does not seem to help. How is it related to this issue?

The exact same machine logged in at work uploads just fine. At home (with a faster network) it just hangs as described above. Other Flickr uploader applications work fine at both sites. If I try enough times, I will occasionally get an image uploaded.

Same problem here. version 0.5.0.3 on Intrepid. I have not tried the MTU trick but that seems like a really bad solution, considering that other uploaders (FlickrUploadr, http://micampe.it/projects/flickruploadr, in my case) have no problem.

This might be the first time attempting to upload from my apartment in Japan, so there's a possibility of incompatible network settings. But the fact still remains that I had no problem with other uploaders, so it theoretically can work fine.

Update: It seemed to upload fine from work (also in Japan), so there appears to be some incompatibility between certain networks and f-spot. At work I even had to set the proper proxy settings.

Hi all!

I had the same problem on Intrepid.
I changed MTU to 1492 and then disable/enable local connection in Network Manager. Now everything is fine.

Igor.

Bug (and solution) reproduced on ubuntu 8.04, f-spot 0.4.3.1.  When I set the mtu to 1492 uploading to flickr works, when I set it back to 1500 it stops working again reproducibly.

You should be able to permanently set your mtu in /etc/network/interfaces, try man interfaces for more info.

I've set my MTU via the network manager, right click notification are icon, edit connections, select the relevant connection, edit, change the MTU field to the Desired amount (1450) . Was the easiest way for me as I regularly change networks.

Hope it helps.

I get the following Debug output:

Problems uploading picture: FlickrNet.FlickrApiException: POST size too large! Try something smaller, mmkay? (93)
  at FlickrNet.Flickr.UploadPicture (System.IO.Stream stream, System.String title, System.String description, System.String tags, Int32 isPublic, Int32 isFamily, Int32 isFriend, ContentType contentType, SafetyLevel safetyLevel, HiddenFromSearch hiddenFromSearch) [0x00000] 
  at FlickrNet.Flickr.UploadPicture (System.String filename, System.String title, System.String description, System.String tags, Boolean isPublic, Boolean isFamily, Boolean isFriend) [0x00000] 
  at FlickrRemote.Upload (IBrowsableItem photo, IFilter filter, Boolean is_public, Boolean is_family, Boolean is_friend) [0x00000] 
System.Exception: FlickrNet.FlickrApiException: POST size too large! Try something smaller, mmkay? (93)
  at FlickrNet.Flickr.UploadPicture (System.IO.Stream stream, System.String title, System.String description, System.String tags, Int32 isPublic, Int32 isFamily, Int32 isFriend, ContentType contentType, SafetyLevel safetyLevel, HiddenFromSearch hiddenFromSearch) [0x00000] 
  at FlickrNet.Flickr.UploadPicture (System.String filename, System.String title, System.String description, System.String tags, Boolean isPublic, Boolean isFamily, Boolean isFriend) [0x00000] 
  at FlickrRemote.Upload (IBrowsableItem photo, IFilter filter, Boolean is_public, Boolean is_family, Boolean is_friend) [0x00000] 
  at FlickrRemote.Upload (IBrowsableItem photo, IFilter filter, Boolean is_public, Boolean is_family, Boolean is_friend) [0x00000] 
  at FSpotFlickrExport.FlickrExport.Upload () [0x00000]

Typically, "POST size too large! Try something smaller", which appears to come from FlickrNet, a .Net API for Flickr.

It could be the FlickrNet API not working properly, or the f-spot implementation to use it is buggy.

There is an issue regarding the upload progress logged on the FlickrNet site:
http://flickrnet.codeplex.com/WorkItem/View.aspx?WorkItemId=6542

I've looked in the source code, it's difficult to see where it may be going wrong, especially with out more debug info. There's not much exception handling.

Tempted to write an uploader myself and see if the f-spot guys will consider it. 

In fact think I've possibly seen a bug for the progress bar, and why it's not working properly.

In the source code HttpWebRequest.GetRequestStream() instead of HttpWebRequest.BeginGetRequestStream()

The former is not Asynchronous so will happen in one go until the thread has finished. The problem is after that call it does the upload progress calculation (it will already have been uploaded!). 

BeginGetRequestStream is asynchronous so the stream can be uploading, and updating the upload progress as the thread goes along.


For uploads, I can only guess that they are timing out. More logging and exception handling in the code is really needed to know what and where it's going wrong.

rob, isn't your bug something different from the one in subject?

I still suffer from the "Waiting for response" problem. I can leave the pc for hours and it'll still be the same. My photos are typically around 2-4mb in size.

What I mentioned above is related to the issue. In the background it's throwing errors that the post is too big, but it still shows "Waiting for response". f-spot isn't giving me any errors or updating the UI to reflect this.

I also looked into:
a) Why the progress bar doesn't work properly (ie doesn't update as my photo uploads)
b) Why the upload is not working

I may be wrong, but it looks like the error is in FlickrNet (and possibly f-spots implementation of it), the library that f-spot uses when exporting to Flickr.

The FlickrNet code used:
1) isn't asynchronous, hence the progress bar not showing how much of each photo has uploaded.
2) Doesn't have much exception handling etc... or logging so it's hard to see exactly where the problem lies. It's one HttpWebRequest that is made per photo upload, which is typically a bad way to do uploads if you're not chunking the data (which we can't). It may be that the request is failing, and then sitting there until it times out. The code doesn't appear to throw any exceptions if this is the case, so it could be that f-spot doesn't know what to do, so just sits there.

I'm still seeing this, and I've tried setting the MTU to both 1450 and 1492, but neither work. I tried setting the MTU via both ifconfig and network-manager, reconnecting to the network, and restarting F-Spot each time. I'm now in Taiwan, and have used both the wireless and wired connections (through the same router, though). At some point during all of these experiments (not sure which one), I did get one picture through, but I'm not sure if that was a success, because I never got the "Waiting for response" progress bar to finish.

This bug is still present in the latest f-spot 0.6.1.1

I've still yet to successfully upload a photo to flickr.

does the mtu trick works ?

Almost certainly the spotty results from altering the MTU are a false solution. The results are pretty scattered.

My guess is the upload is encountering some sort of error, and has no allowance for re-try (or is just badly written, and does not handle the usual variance in network send/receive). Writing network code is a bit tricky, and easy to get wrong.

I had a look at the code in my earlier posts. F-spot uses the FlickNet code on CodePlex. I checked out the source. I can't say much for the actual upload, but the "In Progress" message I couldn't see how it could possibly work.

There's an HttpRequest method, and the asynchronous version in C#/Mono hasn't been used. This means it will upload the whole file before moving to the next line of code. This means the UI won't appear progressive as the file uploads.

If the asynchronous method had been used, it can upload and update the UI at the same time.

I too agree that the MTU most likely isn't the cause of it.

The MTU trick worked for me. Did you try it? (It could be at least a debugging to find the error)

I've had similar problems with current 0.8.1 I think that the problem is in the upload code, could it using the MTU of the local machine and ignoring PMTU messages from Flickr?

I have an MTU of 1492 on the external ppp0 interface of my router and my desktop normally has an MTU of 1500 and the flickr upload hangs. If I drop the MTU on my desktop back to 1492 then the upload works correctly.

f-spot is not under active development anymore, has not seen code changes for five years, and saw its last tarball release in the year 2010.
Its codebase has been archived: https://gitlab.gnome.org/Archive/f-spot/commits/master

Closing this report as WONTFIX as part of Bugzilla Housekeeping to reflect reality. Please feel free to reopen this ticket (or rather transfer the project to GNOME Gitlab, as GNOME Bugzilla is deprecated) if anyone takes the responsibility for active development again.