Seems to have gotten worse. Two photos still show processing. Has been said that you could safely delete the processing thumbnail as it is merely a duplicate. Well I know which picture should be seen and it is not. Simply two processing image thumbnails. I only uploaded five images. So deleting the processing thumbnails could result in one not having an image uploaded. This will be a real PITA if bulk uploading hundred of pics.
My Pictures : My Gear
I Reject Your Reality And Substitute My Own - Adam Savage
Seems to have gotten worse. Two photos still show processing. Has been said that you could safely delete the processing thumbnail as it is merely a duplicate. Well I know which picture should be seen and it is not. Simply two processing image thumbnails. I only uploaded five images. So deleting the processing thumbnails could result in one not having an image uploaded. This will be a real PITA if bulk uploading hundred of pics.
This is why my methodology includes going back and then re-uploading the entire batch with 'skip duplicates'. You'll have to do this until the number of images in the gallery matches your original batch. It took me three tries on my batch.
FWIW, I've always checked the number of images uploaded to see if it matches my original batch. I've regularly had issues with duplicates/missing files since I started with SM back in 2005, so this step is essential.
An FTP implementation like Exposure Manager uses could completely eliminate this problem as well as the almost 1 hour it took to set up the 7gb upload batch via SM's uploaders. And SM's uploaders still couldn't max out the 15Mb of upload bandwidth like Filezilla or another multi-threaded FTP client would have easily done. Vote for FTP!
Right now, you'll see these for maybe up to an hour after uploading, after that they should go away. We're still chasing down the problem where for some they are lingering way too long.
I'm not sure why, but bugs like this are taking around a month to squash right now. SM still has about a week left before it's fixed according to the recent track record.
Right now, you'll see these for maybe up to an hour after uploading, after that they should go away. We're still chasing down the problem where for some they are lingering way too long.
Not only is it still not fixed, it is worse. Now I get three copies being processed forever.
Did you still run into this? I've got 2000+ to upload, and once I get done fighting the stupid crashing SM uploaders, I want to know what other headache I'm going to run into.
Did you still run into this? I've got 2000+ to upload, and once I get done fighting the stupid crashing SM uploaders, I want to know what other headache I'm going to run into.
I'm so sorry you are having troubles, Samir We have customers uploading thousands of photos each, each day, with no trouble. I myself just sent up a few thousand - no problem. We'd love to help you, write our heroes and we will.
I'm so sorry you are having troubles, Samir We have customers uploading thousands of photos each, each day, with no trouble. I myself just sent up a few thousand - no problem. We'd love to help you, write our heroes and we will.
Oh, it's not SM as usual. I just don't have quad-processor computers sitting around just for uploading. The java uploader doesn't like it when you launch 4 of them and then throw 10gb at them on a 2.4ghz XPH system with 1GB of RAM.
Time to replicate my batch onto a second hd and then use a second system in parallel to get this up faster. Less than 4 simultaneous uploader sessions is only using 1/2-2/3 of my available bandwidth. In theory this upload should take 2hrs. I've been working on it for 4hrs.
This is why I want a native SM FTP process. Filezilla would've queued this up in 10 minutes and I would've started my upload Saturday night. But I knew it would be a pain, so I put it off until today.
Oh, it's not SM as usual. I just don't have quad-processor computers sitting around just for uploading. The java uploader doesn't like it when you launch 4 of them and then throw 10gb at them on a 2.4ghz XPH system with 1GB of RAM.
Duh, sounds like think you're overloading your system and trying to blame SM.
This computer is more than capable to doing anything else I've ever thrown at it. And it was running nothing else--just 4 instances of simple uploader. This shouldn't tax the system to the point of crashing if the uploader was written properly.
It's insane that I need to buy a computer just to upload to Smugmug when I can do everything else on the Internet on the same system without issues.
Smugmug's main retort is always, 'no one else is having problems uploading'. Well, from my point-of-view 'no other site on the Internet has an issue with my computer'.
I cut my upload batch in half and waited 3x as long as I should have to upload it. Luckily, I don't seem to see any processing thumbnails, so that issue may finally be fixed.
I didn't ask for any assistance. I was simply making a statement.
This computer is more than capable to doing anything else I've ever thrown at it. And it was running nothing else--just 4 instances of simple uploader. This shouldn't tax the system to the point of crashing if the uploader was written properly.
It's insane that I need to buy a computer just to upload to Smugmug when I can do everything else on the Internet on the same system without issues.
Smugmug's main retort is always, 'no one else is having problems uploading'. Well, from my point-of-view 'no other site on the Internet has an issue with my computer'.
I cut my upload batch in half and waited 3x as long as I should have to upload it. Luckily, I don't seem to see any processing thumbnails, so that issue may finally be fixed.
We've spent a fortune improving our uploading over the years, and a ton more than that, just recently - where you has positive comments on our uploading and the work we're doing. I'm saying it's hard to read you Samir, and sometimes maybe saying less is more. You know you use older and not-mainstream computer systems and uploading schemes that we can't possibly be expected to maximize an uploading experience for for millions of customers. We know you want FTP.
We want to help you as much as possible, whenever - so I try to keep up
We've spent a fortune improving our uploading over the years, and a ton more than that, just recently - where you has positive comments on our uploading and the work we're doing. I'm saying it's hard to read you Samir, and sometimes maybe saying less is more. You know you use older and not-mainstream computer systems and uploading schemes that we can't possibly be expected to maximize an uploading experience for for millions of customers. We know you want FTP.
We want to help you as much as possible, whenever - so I try to keep up
You yourself have said you have had no problems uploading on an XPH 1GB RAM system and that it meets SM's system requirements. I don't know how you can say this is not-mainstream. Yes, it is a bit older, but if you tested it to be fine, what difference should that make?
It is because the uploaders do not fully utilize my bandwidth that I have to bandaid the issue by launching multiple instances. The change where simple started uploading three files simultaneously helped, but not enough. I need a total of 9+ simultaneous file uploads to completely saturate my bandwidth, and the uploaders are limited to much less than that. And I don't know if any change is coming or not. The queue time is also tremendous, sometimes as much as 30 minutes when skipping files. I have dedicated one computer just to uploading because of this so I can work on something else in the meantime.
I know FTP can solve these problems for me, and I'm glad you're aware of that. I just get so frustrated with these issues at times when I have deadlines on my head. I worked 40hrs between Friday and Sunday, and I need to set an upload and go to sleep, wake up and get to work. Not spend my 8hrs while I'm awake attempting to upload.
On the bright side, I just uploaded over 4000 photos and didn't see the processing images thumbnail.
SamirD, don't you need a huge amount of RAM to handle that much upload? Would not that be a bottleneck?
FTP doesn't.
In my experience, the only place where RAM becomes an issue with SM uploaders is with video files. And this depends on the uploader as well. HTML5 and Flash have different implementations than Simple, and I've found Simple is much more reliable for these files. HTML5 memory usage varies based on the browser, and I haven't bothered with Flash yet.
When I can queue up the same 10gb and send it away via ftp with 100% utilization of bandwidth, and yet I need some sort of quad-processor 4gb ram system to do it via SM's uploaders, then SM's uploaders aren't exactly efficient. And this may just be because it's trying to send files reliably via http, which was never the purpose of the protocol in the first place. FTP was meant to be for this. That's why these protocols created in the first place and the port numbers were assigned.
It's kinda ironic that SM is using a protocol for something that it was never designed for, and I'm the one that's in the wrong for bringing it up.
I'm just happy the processing image problem is solved. I didn't want to go through thousands of images cleaning that up.
You yourself have said you have had no problems uploading on an XPH 1GB RAM system and that it meets SM's system requirements. I don't know how you can say this is not-mainstream. Yes, it is a bit older, but if you tested it to be fine, what difference should that make?
SamirD, WinXP and the systems you are using are many, many years old. Files today are huge. I cannot imagine being a professional photographer using a 1gb ram system. Simply can't. You are using an OS that came out in 2001, that's over 10 years ago. We do our best, but we're pushing the limits with your setup. I'm very sorry
SamirD, WinXP and the systems you are using are many, many years old. Files today are huge. I cannot imagine being a professional photographer using a 1gb ram system. Simply can't. You are using an OS that came out in 2001, that's over 10 years ago. We do our best, but we're pushing the limits with your setup. I'm very sorry
So then why did you say everything works fine on a system that you tested with similar specs in a previous discussion on this same topic? I also get confused with your answers at times.
I've asked point blank at one time what SM's system requirements are, but I never got a solid answer. And if it's an ever changing target, then state that with the ever changing specs. I know what browsers and OS's aren't supported, and I don't ask SM to change anything in relation to them. But you can't say we do support X, and then turn around and say X is too old.
So then why did you say everything works fine on a system that you tested with similar specs in a previous discussion on this same topic? I also get confused with your answers at times.
I've asked point blank at one time what SM's system requirements are, but I never got a solid answer. And if it's an ever changing target, then state that with the ever changing specs. I know what browsers and OS's aren't supported, and I don't ask SM to change anything in relation to them. But you can't say we do support X, and then turn around and say X is too old.
We BARELY support WinXP - with IE8 and above. But you are running 1gb machines and loading a kabillion files in - I'm not suprised that you have difficulty http://smu.gs/rqVfYM
We BARELY support WinXP - with IE8 and above. But you are running 1gb machines and loading a kabillion files in - I'm not suprised that you have difficulty http://smu.gs/rqVfYM
Nowhere on that page does it say the same thing you have stated here.
This is why I asked for HARD specs a long time ago, not the general guidelines like what you have in that link. If SM is software as a service, then supply system requirements like boxed software does--processor, video, ram, storage, browser, java, flash, and all the other things that make SM work or break it.
I have every right to express my opinion about a better way to do things. If you don't want to listen, that's your right. And I have no right to be upset if something doesn't work if my system is not meeting specs. But my system meets the specs listed in your link. Might want to add 'you can't run 1gb machines and loading a kabillion files in' under XP.
Nowhere on that page does it say the same thing you have stated here.
This is why I asked for HARD specs a long time ago, not the general guidelines like what you have in that link. If SM is software as a service, then supply system requirements like boxed software does--processor, video, ram, storage, browser, java, flash, and all the other things that make SM work or break it.
I have every right to express my opinion about a better way to do things. If you don't want to listen, that's your right. And I have no right to be upset if something doesn't work if my system is not meeting specs. But my system meets the specs listed in your link. Might want to add 'you can't run 1gb machines and loading a kabillion files in' under XP.
We love to listen. I won't add that because as far as I'm aware you're the only customer that pushes the limits of Win XP and SmugMug
Samir, there are specs and specs. Every day all day long there are pros and amateurs posting on Dgrin and other forums about what sort of Win or Mac machine should they use for their photo work - what will give them best performance for their workflow. Photography is so important to your business yet you're running 10year old underpowered stuff, I'm just surprised, that's all.
I suggest we call a standstill on this topic, after you get the last word if you want We both have plenty to do and we understand each other, I think?
Comments
Portfolio • Workshops • Facebook • Twitter
1575 just uploaded. 1606 in the gallery. 31 had to be deleted.
Want faster uploading? Vote for FTP!
I Reject Your Reality And Substitute My Own - Adam Savage
--- Denise
Musings & ramblings at https://denisegoldberg.blogspot.com
FWIW, I've always checked the number of images uploaded to see if it matches my original batch. I've regularly had issues with duplicates/missing files since I started with SM back in 2005, so this step is essential.
An FTP implementation like Exposure Manager uses could completely eliminate this problem as well as the almost 1 hour it took to set up the 7gb upload batch via SM's uploaders. And SM's uploaders still couldn't max out the 15Mb of upload bandwidth like Filezilla or another multi-threaded FTP client would have easily done. Vote for FTP!
Want faster uploading? Vote for FTP!
ENOUGH ALREADY
www.SaraPiazza.com - Edgartown News - Trad Diary - Facebook
Right now, you'll see these for maybe up to an hour after uploading, after that they should go away. We're still chasing down the problem where for some they are lingering way too long.
Portfolio • Workshops • Facebook • Twitter
Want faster uploading? Vote for FTP!
stueveshots.smugmug.com
Not only is it still not fixed, it is worse. Now I get three copies being processed forever.
Can we have a link to these please? Thanks.
Portfolio • Workshops • Facebook • Twitter
I have deleted them.
Still showing even after an hour...
http://www.phabulousphotos.com/ProfessionalSports/Orlando-Predators/New-Orleans-Voodoo-Orlando/18662430_dhxZ6H
www.phabulousphotos.com
Sportsshooter.com Member
http://www.sportsshooter.com/members.html?id=10162
David, I don't see any in this gallery at all
Portfolio • Workshops • Facebook • Twitter
Hey not there anymore for me either, I will keep a watch out but it was there when I posted. Thanks..
www.phabulousphotos.com
Sportsshooter.com Member
http://www.sportsshooter.com/members.html?id=10162
Want faster uploading? Vote for FTP!
I'm so sorry you are having troubles, Samir
Portfolio • Workshops • Facebook • Twitter
Time to replicate my batch onto a second hd and then use a second system in parallel to get this up faster. Less than 4 simultaneous uploader sessions is only using 1/2-2/3 of my available bandwidth. In theory this upload should take 2hrs. I've been working on it for 4hrs.
This is why I want a native SM FTP process. Filezilla would've queued this up in 10 minutes and I would've started my upload Saturday night. But I knew it would be a pain, so I put it off until today.
Want faster uploading? Vote for FTP!
So how are we to take your complaints about
????
Portfolio • Workshops • Facebook • Twitter
My Website index | My Blog
It's insane that I need to buy a computer just to upload to Smugmug when I can do everything else on the Internet on the same system without issues.
Smugmug's main retort is always, 'no one else is having problems uploading'. Well, from my point-of-view 'no other site on the Internet has an issue with my computer'.
I cut my upload batch in half and waited 3x as long as I should have to upload it. Luckily, I don't seem to see any processing thumbnails, so that issue may finally be fixed.
Want faster uploading? Vote for FTP!
We've spent a fortune improving our uploading over the years, and a ton more than that, just recently - where you has positive comments on our uploading and the work we're doing. I'm saying it's hard to read you Samir, and sometimes maybe saying less is more. You know you use older and not-mainstream computer systems and uploading schemes that we can't possibly be expected to maximize an uploading experience for for millions of customers. We know you want FTP.
We want to help you as much as possible, whenever - so I try to keep up
Portfolio • Workshops • Facebook • Twitter
It is because the uploaders do not fully utilize my bandwidth that I have to bandaid the issue by launching multiple instances. The change where simple started uploading three files simultaneously helped, but not enough. I need a total of 9+ simultaneous file uploads to completely saturate my bandwidth, and the uploaders are limited to much less than that. And I don't know if any change is coming or not. The queue time is also tremendous, sometimes as much as 30 minutes when skipping files. I have dedicated one computer just to uploading because of this so I can work on something else in the meantime.
I know FTP can solve these problems for me, and I'm glad you're aware of that. I just get so frustrated with these issues at times when I have deadlines on my head. I worked 40hrs between Friday and Sunday, and I need to set an upload and go to sleep, wake up and get to work. Not spend my 8hrs while I'm awake attempting to upload.
On the bright side, I just uploaded over 4000 photos and didn't see the processing images thumbnail.
Want faster uploading? Vote for FTP!
My Website index | My Blog
In my experience, the only place where RAM becomes an issue with SM uploaders is with video files. And this depends on the uploader as well. HTML5 and Flash have different implementations than Simple, and I've found Simple is much more reliable for these files. HTML5 memory usage varies based on the browser, and I haven't bothered with Flash yet.
When I can queue up the same 10gb and send it away via ftp with 100% utilization of bandwidth, and yet I need some sort of quad-processor 4gb ram system to do it via SM's uploaders, then SM's uploaders aren't exactly efficient. And this may just be because it's trying to send files reliably via http, which was never the purpose of the protocol in the first place. FTP was meant to be for this. That's why these protocols created in the first place and the port numbers were assigned.
It's kinda ironic that SM is using a protocol for something that it was never designed for, and I'm the one that's in the wrong for bringing it up.
I'm just happy the processing image problem is solved. I didn't want to go through thousands of images cleaning that up.
Want faster uploading? Vote for FTP!
SamirD, WinXP and the systems you are using are many, many years old. Files today are huge. I cannot imagine being a professional photographer using a 1gb ram system. Simply can't. You are using an OS that came out in 2001, that's over 10 years ago. We do our best, but we're pushing the limits with your setup. I'm very sorry
Portfolio • Workshops • Facebook • Twitter
I've asked point blank at one time what SM's system requirements are, but I never got a solid answer. And if it's an ever changing target, then state that with the ever changing specs. I know what browsers and OS's aren't supported, and I don't ask SM to change anything in relation to them. But you can't say we do support X, and then turn around and say X is too old.
Want faster uploading? Vote for FTP!
We BARELY support WinXP - with IE8 and above. But you are running 1gb machines and loading a kabillion files in - I'm not suprised that you have difficulty
Portfolio • Workshops • Facebook • Twitter
This is why I asked for HARD specs a long time ago, not the general guidelines like what you have in that link. If SM is software as a service, then supply system requirements like boxed software does--processor, video, ram, storage, browser, java, flash, and all the other things that make SM work or break it.
I have every right to express my opinion about a better way to do things. If you don't want to listen, that's your right. And I have no right to be upset if something doesn't work if my system is not meeting specs. But my system meets the specs listed in your link. Might want to add 'you can't run 1gb machines and loading a kabillion files in' under XP.
Want faster uploading? Vote for FTP!
We love to listen. I won't add that because as far as I'm aware you're the only customer that pushes the limits of Win XP and SmugMug
Samir, there are specs and specs. Every day all day long there are pros and amateurs posting on Dgrin and other forums about what sort of Win or Mac machine should they use for their photo work - what will give them best performance for their workflow. Photography is so important to your business yet you're running 10year old underpowered stuff, I'm just surprised, that's all.
I suggest we call a standstill on this topic, after you get the last word if you want
Portfolio • Workshops • Facebook • Twitter