Holy CRAP!
I live in Princeton NJ, not far from NYC and on FIOS fiber premium speed 20MB/s up and 50MB/s down.
I complained on more than one ocassion about the upload speeds I was getting, they were horrible actually and after many contacts with the "Heros" that all blew smoke up my ass I finally gave up figuring I was stuck with miserable upload speeds. This is by far the fastest I have uploaded to smugmug, transfer speeds were around 3MB/s where I have been getting 250K on a good day before.
3) If you miss the drop area when dragging/dropping (something that's easy to do when managing multiple windows on a small screen), the browser window opens and shows one of your images and everything you already had dropped into the uploader is "poof" gone. This is terrible user interaction. Missing the target, but still in the same window should either accept into the target or do nothing. It shouldn't kill your entire upload.
You've been dead-on on this UI issue since the day it was introduced. I have no idea why it's not changed. Just to prevent this from happening, I have to select different uploader and then select my uploader again to get the full screen. Stupid, stupid, stupid design and a waste of time.
Holy CRAP!
I live in Princeton NJ, not far from NYC and on FIOS fiber premium speed 20MB/s up and 50MB/s down.
I complained on more than one ocassion about the upload speeds I was getting, they were horrible actually and after many contacts with the "Heros" that all blew smoke up my ass I finally gave up figuring I was stuck with miserable upload speeds. This is by far the fastest I have uploaded to smugmug, transfer speeds were around 3MB/s where I have been getting 250K on a good day before.
If you do a single upload session, this will probably be the case. If you launch multiple upload sessions (I'd recommend 7 for your bandwidth), and split your upload into these different uploaders, you should see almost all your total bandwidth utilized.
But the downside of this is all the prep time, and the good chance that the uploader will crash when it runs into memory issues. This is why I want FTP. Multi-session uploads are a breeze with any FTP client. And when getting the files to SM is half the chore, shouldn't this be the easiest step.
You've been dead-on on this UI issue since the day it was introduced. I have no idea why it's not changed. Just to prevent this from happening, I have to select different uploader and then select my uploader again to get the full screen. Stupid, stupid, stupid design and a waste of time.
This thread isn't about any changes to any of the uploaders themselves - it's about faster and more reliable uploading from the uploader to us, and faster verification steps once we have it.
John's feedback on the HTML5 uploader has been noted when he gave it to us, but unfortunately we don't have any way around the behavior if you mis-drop.
This thread isn't about any changes to any of the uploaders themselves - it's about faster and more reliable uploading from the uploader to us, and faster verification steps once we have it.
John's feedback on the HTML5 uploader has been noted when he gave it to us, but unfortunately we don't have any way around the behavior if you mis-drop.
Andy, that's a pretty naive answer. You control how large you make the drop area. You could just make it full screen - leave part of it transparent if you want it to look the same.
No comment on the images that refused to upload correctly? That's seems like a critical issue and what this thread was all about.
This thread isn't about any changes to any of the uploaders themselves - it's about faster and more reliable uploading from the uploader to us, and faster verification steps once we have it.
I'll see if I notice anything different. Does this still require the new cookie, or is it live for everyone?
Testing scenario wasn't great since most of the files are uploaded. But on the single session that is running it's over 2mb, which is something I've never seen before. I checked my router and it concurs--a single SM upload session is using over 60% of a 5mb pipe. Awesome. Now, I only need to have 6 upload sessions to max out my bandwidth vs 16.
Testing scenario wasn't great since most of the files are uploaded. But on the single session that is running it's over 2mb, which is something I've never seen before. I checked my router and it concurs--a single SM upload session is using over 60% of a 5mb pipe. Awesome. Now, I only need to have 6 upload sessions to max out my bandwidth vs 16.
I must be missing something. 2 * 60% = 120%. So 2 sessions should max your pipe out, not 6... ?
You couldn't want ftp that badly. Here you promised lots of feedback but I don't see any...am I missing something ?
I've been in almost constant communication with him via email. Each week we're finding and fixing bugs. I've been able to upload a gallery via his system 2-4x faster with 1/10 the setup on my end. Hitting 2MB on a single session of simple uploader is definitely a marked improvement, but that's about 200k/sec. I hit almost 400k/sec with smugftp, and setting up multiple sessions doesn't involve manually splitting a batch across several simple uploader sessions, but just selecting to use multiple threads in filezilla. It takes me less time to set up my entire upload in FTP than just launching simple uploader. It would just be nice to have something like this native in SM, especially with such high demand from the user base.
There is nothing wrong with these images as they've all been uploaded successfully before.
Hmmm, that's a good question and thanks for the screen shots.
It looks like the upload aborted for some reason, and whether it had to do with your browser or something upstream at your ISP, we're not sure. We're now directing most upload traffic directly to Amazon, so if you see more of these we'd love to know more about them.
One reason we're directing so much traffic to Amazon is we're seeing roughly a 60% decrease in upload errors. I suspect that has to do with fewer hops, the quality of bandwidth to them, etc.
But if there's one thing we've learned from comparing notes with our friends at facebook, yahoo, etc., we're all going for incremental improvements in uploading and no one is getting close to perfection. We all may approach perfection for some customers, but a change like we just made may represent a 60% improvement averaged among all our customers, but may be a bummer for you if for whatever reason your error rate ends up higher than it was. You, probably more than almost anyone on dgrin, are located very close to our data centers and I don't know if even Amazon could improve the error rates you were seeing to us with the connectivity you have.
I dunno what's available at your address but in Mountain View where I live I'm able to approach perfection on my uploads even though I upload very large stiched panos and videos, because we were able to upgrade our connection.
I know I am late to the party, but figured I would add my few cents and findings. I am currently on vacation so I have been doing testing at a hotel.
I am using Firefox 4.0 on a Mac using the HTML5 uploader. Mac OS is 10.6.7. A speed test from the hotel to SmugMug (smugmug.speedtest.net) is 4.62Mbps down and 0.58Mbps up doing. To the recommended speedtest server it is download 4.27Mbps and upload 0.55Mbps. I believe that the limiting factor is the hotel connection.
What I have found is the following:
1) Uploading using either of the upload end points both gave me failures of video uploads.
2) For 10 videos none larger that 54.6MB I got errors with both of the end points. The standard end point was 4 errors the new Amazon end point was 2 errors. I sent the same files to two different galleries to keep it fair.
Speed wise they were the same. I did not examine the upload log, but the account was storagebradfordbenn if you want to peek.
Let me know if you have questions or want me to check anything else - I have a bunch of vacation photos to upload.
Hmmm, that's a good question and thanks for the screen shots.
It looks like the upload aborted for some reason, and whether it had to do with your browser or something upstream at your ISP, we're not sure. We're now directing most upload traffic directly to Amazon, so if you see more of these we'd love to know more about them.
One reason we're directing so much traffic to Amazon is we're seeing roughly a 60% decrease in upload errors. I suspect that has to do with fewer hops, the quality of bandwidth to them, etc.
But if there's one thing we've learned from comparing notes with our friends at facebook, yahoo, etc., we're all going for incremental improvements in uploading and no one is getting close to perfection. We all may approach perfection for some customers, but a change like we just made may represent a 60% improvement averaged among all our customers, but may be a bummer for you if for whatever reason your error rate ends up higher than it was. You, probably more than almost anyone on dgrin, are located very close to our data centers and I don't know if even Amazon could improve the error rates you were seeing to us with the connectivity you have.
I dunno what's available at your address but in Mountain View where I live I'm able to approach perfection on my uploads even though I upload very large stiched panos and videos, because we were able to upgrade our connection.
I've NEVER had this type of problem uploading before and the first time I try your new uploader, three of four images fail. Are you really thinking this has to do with my connection? That would be an awful lot of coincidence.
I'm on a crappy hotel connection now so can't retest until next week (as a test from here would be meaningless).
I know I am late to the party, but figured I would add my few cents and findings. I am currently on vacation so I have been doing testing at a hotel.
I am using Firefox 4.0 on a Mac using the HTML5 uploader. Mac OS is 10.6.7. A speed test from the hotel to SmugMug (smugmug.speedtest.net) is 4.62Mbps down and 0.58Mbps up doing. To the recommended speedtest server it is download 4.27Mbps and upload 0.55Mbps. I believe that the limiting factor is the hotel connection.
What I have found is the following:
1) Uploading using either of the upload end points both gave me failures of video uploads.
2) For 10 videos none larger that 54.6MB I got errors with both of the end points. The standard end point was 4 errors the new Amazon end point was 2 errors. I sent the same files to two different galleries to keep it fair.
Speed wise they were the same. I did not examine the upload log, but the account was storagebradfordbenn if you want to peek.
Let me know if you have questions or want me to check anything else - I have a bunch of vacation photos to upload.
Hey Brad,
I had a look at your upload log and all the upload errors related to videos appear to be 'IncompleteFile' errors, which would suggest a connection problem between your hotel and SmugMug....and I'd suggest that uploading any file of any size to anywhere would most likely result in failure.
If this is the official view on it you should really kill the suggestion and give people back their votes. If a suggeston is top ten in your system, you can bet people hold high hopes, don't string us along.
Also, I know you guys and Samir have a "high ceiling" in your discussions but to readers who don't know, this could come off as dismissive bordering on rude.
Replacing images should be orders of magnitude quicker, they will upload the same speed as new uploads. As an example, a replace that took 45 secs using the old method took 13 secs using the cloud
Yes! Yes! Sooo much faster! Doing a Re-Publish of a few hundred images is now a "go make coffee" activity and no longer a "go out to dinner" activity! haha
...could come off as dismissive bordering on rude.
To be honest, I found it very rude especially coming from a developer. And when I attempted to post a link to the comment on the feedback site, it was never approved three times. If this is the official postition of SM on the topic, then let it be known to those that want the feature.
There's no approval by us on the feedback system - you can post at will there, if something didn't go, it's not because we disapproved it.
Sorry!
Interesting. I got the message at the top of the screen "your comment will be posted shortly", but it never did. I tried it a day later and saw that my comment on how my previous three comments weren't posted was actually posted.
I've NEVER had this type of problem uploading before and the first time I try your new uploader, three of four images fail. Are you really thinking this has to do with my connection? That would be an awful lot of coincidence.
I'm on a crappy hotel connection now so can't retest until next week (as a test from here would be meaningless).
I dunno, John. It's hard to draw conclusions from one upload where we have no data. I had a video upload fail from my home this morning, which isn't far from yours, and I don't remember having one before. The only data I have at hand is that for millions of uploads our error rate has dropped ~60%.
I am very interested in your case and mine, however, so I'm gonna try again from my home when I get a chance with http scoop running. I'd love to hear what happens on your next try.
BaldyRegistered Users, Super ModeratorsPosts: 2,853moderator
edited April 18, 2011
Hmmmm, my test result ended up being video too long, not an upload error. Apple seems to have a bug reporting the video as longer than it is in the video header when saved from Final Cut Pro as a QuickTime movie, and we're not working around the bug.
Once I re-saved the video using mpeg streamclip it uploaded fine.
I have been testing the new endpoint on slow connections as I have been traveling. I can say that it seems to be more stable on bad Internet connections. The test I ran using the old and new endpoint from a bad hotel connection were only different by a few seconds and that could be how closely I was watching it. The reason I say it looks more stable is the process of queuing up the images to upload happened much faster on the new end point. I was using the HTML5 uploader under Mac Firefox. I also used the exact same five images so it was a very fair test.
I'll be trying the new endpoint on a 9gb+ batch from this weekend. Setting it up will be a pain as usual, but I'll have some real hard data on the speed improvements.
I have been testing the new endpoint on slow connections as I have been traveling. I can say that it seems to be more stable on bad Internet connections. The test I ran using the old and new endpoint from a bad hotel connection were only different by a few seconds and that could be how closely I was watching it. The reason I say it looks more stable is the process of queuing up the images to upload happened much faster on the new end point. I was using the HTML5 uploader under Mac Firefox. I also used the exact same five images so it was a very fair test.
Be aware that we've directed almost all upload traffic through the new endpoint now so you may end up comparing the new endpoint to the new endpoint.
Be aware that we've directed almost all upload traffic through the new endpoint now so you may end up comparing the new endpoint to the new endpoint.
Thank you for the clarification. Is there a way to force one or the other? Perhaps the better question is as I travel over the next few days would it be helpful for me to compare the two for you?
Comments
I live in Princeton NJ, not far from NYC and on FIOS fiber premium speed 20MB/s up and 50MB/s down.
I complained on more than one ocassion about the upload speeds I was getting, they were horrible actually and after many contacts with the "Heros" that all blew smoke up my ass I finally gave up figuring I was stuck with miserable upload speeds. This is by far the fastest I have uploaded to smugmug, transfer speeds were around 3MB/s where I have been getting 250K on a good day before.
I'm glad you feel this way. Makes me want to leave SM even more now.
Want faster uploading? Vote for FTP!
Want faster uploading? Vote for FTP!
But the downside of this is all the prep time, and the good chance that the uploader will crash when it runs into memory issues. This is why I want FTP. Multi-session uploads are a breeze with any FTP client. And when getting the files to SM is half the chore, shouldn't this be the easiest step.
Want faster uploading? Vote for FTP!
This thread isn't about any changes to any of the uploaders themselves - it's about faster and more reliable uploading from the uploader to us, and faster verification steps once we have it.
John's feedback on the HTML5 uploader has been noted when he gave it to us, but unfortunately we don't have any way around the behavior if you mis-drop.
Portfolio • Workshops • Facebook • Twitter
No comment on the images that refused to upload correctly? That's seems like a critical issue and what this thread was all about.
Homepage • Popular
JFriend's javascript customizations • Secrets for getting fast answers on Dgrin
Always include a link to your site when posting a question
Want faster uploading? Vote for FTP!
You need the cookie
Portfolio • Workshops • Facebook • Twitter
Hopefully those that are smarter than me will address that one, stay tuned.
Portfolio • Workshops • Facebook • Twitter
Want faster uploading? Vote for FTP!
Samir,
You couldn't want ftp that badly. Here you promised lots of feedback but I don't see any...am I missing something ?
SmugMug API Developer
My Photos
I must be missing something. 2 * 60% = 120%. So 2 sessions should max your pipe out, not 6... ?
Want faster uploading? Vote for FTP!
It looks like the upload aborted for some reason, and whether it had to do with your browser or something upstream at your ISP, we're not sure. We're now directing most upload traffic directly to Amazon, so if you see more of these we'd love to know more about them.
One reason we're directing so much traffic to Amazon is we're seeing roughly a 60% decrease in upload errors. I suspect that has to do with fewer hops, the quality of bandwidth to them, etc.
But if there's one thing we've learned from comparing notes with our friends at facebook, yahoo, etc., we're all going for incremental improvements in uploading and no one is getting close to perfection. We all may approach perfection for some customers, but a change like we just made may represent a 60% improvement averaged among all our customers, but may be a bummer for you if for whatever reason your error rate ends up higher than it was. You, probably more than almost anyone on dgrin, are located very close to our data centers and I don't know if even Amazon could improve the error rates you were seeing to us with the connectivity you have.
I dunno what's available at your address but in Mountain View where I live I'm able to approach perfection on my uploads even though I upload very large stiched panos and videos, because we were able to upgrade our connection.
I am using Firefox 4.0 on a Mac using the HTML5 uploader. Mac OS is 10.6.7. A speed test from the hotel to SmugMug (smugmug.speedtest.net) is 4.62Mbps down and 0.58Mbps up doing. To the recommended speedtest server it is download 4.27Mbps and upload 0.55Mbps. I believe that the limiting factor is the hotel connection.
What I have found is the following:
1) Uploading using either of the upload end points both gave me failures of video uploads.
2) For 10 videos none larger that 54.6MB I got errors with both of the end points. The standard end point was 4 errors the new Amazon end point was 2 errors. I sent the same files to two different galleries to keep it fair.
Speed wise they were the same. I did not examine the upload log, but the account was storagebradfordbenn if you want to peek.
Let me know if you have questions or want me to check anything else - I have a bunch of vacation photos to upload.
Pictures | Website | Blog | Twitter | Contact
I'm on a crappy hotel connection now so can't retest until next week (as a test from here would be meaningless).
Homepage • Popular
JFriend's javascript customizations • Secrets for getting fast answers on Dgrin
Always include a link to your site when posting a question
Hey Brad,
I had a look at your upload log and all the upload errors related to videos appear to be 'IncompleteFile' errors, which would suggest a connection problem between your hotel and SmugMug....and I'd suggest that uploading any file of any size to anywhere would most likely result in failure.
Cheers,
David
SmugMug API Developer
My Photos
If this is the official view on it you should really kill the suggestion and give people back their votes. If a suggeston is top ten in your system, you can bet people hold high hopes, don't string us along.
Also, I know you guys and Samir have a "high ceiling" in your discussions but to readers who don't know, this could come off as dismissive bordering on rude.
Malte
Edit: Please disregard crankiness, Im better now.
FF 3.6.16
new cookie enabled
Simple uploader
2nd upload worked
My Website index | My Blog
Yes! Yes! Sooo much faster!
Want faster uploading? Vote for FTP!
There's no approval by us on the feedback system - you can post at will there, if something didn't go, it's not because we disapproved it.
Sorry!
Portfolio • Workshops • Facebook • Twitter
Want faster uploading? Vote for FTP!
I am very interested in your case and mine, however, so I'm gonna try again from my home when I get a chance with http scoop running. I'd love to hear what happens on your next try.
Once I re-saved the video using mpeg streamclip it uploaded fine.
Pictures | Website | Blog | Twitter | Contact
Want faster uploading? Vote for FTP!
EDit: disregard - Smugs down.
My Website index | My Blog
Thank you for the clarification. Is there a way to force one or the other? Perhaps the better question is as I travel over the next few days would it be helpful for me to compare the two for you?
Pictures | Website | Blog | Twitter | Contact