I've been fighting with this most recent uploader upgrade almost every time I've been uploading lately. :cry It just likes to hang up after a few hours on what seems to be video files if I'm running a couple of instances simultaneously. Look like I'll just have to go back to using multiple computers simultaneously vs multiple instances on the same system for now.
FTP would solve all this. I spend 12 hours a few days ago uploading what technically should've taken under 2hrs.
I already own great easy to use FTP software: SMART FTP CLIENT and there is also FREE FTP from Mozilla: FireFtp.......SM just need to allow us to use what probably many of us already have.
I already own great easy to use FTP software: SMART FTP CLIENT and there is also FREE FTP from Mozilla: FireFtp.......SM just need to allow us to use what probably many of us already have.
Art, this is a 'bridge' between any FTP client and SM. I only played with it for 10 minutes, but seems like it has a lot of promise.
Can't speak for anybody but myself but, I'm not really comfortable with this solution. Some of my reasoning stems from issues brought up in said thread... But something I haven't seen mentioned, and what I'm curious/concerned with is that since this isn't being done 'in house', should something go wrong, it will be up to the gentleman whom created it to patch it up. Also, the creator of said app now has to be responsible for any overhead created by the needed bandwidth for transfers and such.
While contributions will help and that's all well and good, it leaves me wondering why such things couldn't just be part of the power and pro level subscriber costs? This way we have a more streamlined and better maintained ftp client/server.
While contributions will help and that's all well and good, it leaves me wondering why such things couldn't just be part of the power and pro level subscriber costs? This way we have a more streamlined and better maintained ftp client/server.
I do agree that an in-house solution would be best. But there hasn't even been any planning started on this in-house, so this is the next best thing if it works well.
After researching Amazon s3 for just a bit (which is what SM uses for the storage back-end), FTP would be quite easy to implement, much easier than I imagined.
Vote for FTP. There's no reason to deal with unreliable uploading any longer.
There's no reason to deal with unreliable uploading any longer.
I need to reduce the hyperbole here, Samir.
Uploading at SmugMug is extremely reliable, we're accepting zillions of photos every single day, and the number of complaints we're getting is very, very low (and remember, we have hundreds and hundreds of thousands of active customers uploading all the time. These few issues usually turn out to be connection issues.
After researching Amazon s3 for just a bit (which is what SM uses for the storage back-end), FTP would be quite easy to implement, much easier than I imagined.
Vote for FTP. There's no reason to deal with unreliable uploading any longer.
I don't work for Smugmug, so I don't have any inside information as to the technical details of how their system works. However, I suspect the complications with FTP come, not from implementing the actual protocol itself, but in representing your site's structure in the FTP environment.
When you make an FTP connection to a site, you basically are in a regular file system tree, with directories, sub-directories, and files. You can create/delete directories, copy files, move files, etc... much like looking at a folder in windows explorer or mac finder.
How would you go about representing your smugmug site as a file system tree? How would you prevent uploading of files into a folder that's just a category and not an actual gallery. How would you prevent the user from creating a sub-directory in a gallery, or creating sub-directories that are more levels down that allowable in a smugmug site? Those are just some of the questions that pop into mind off hand. I'm not saying it's impossible to build, but it's a whole lot more complicated that just turning on an FTP server.
I appreciate Andy's perspective & I like mbrady's breakdown... In no way am I dissatisfied with the vast offerings of upload tools, and with regards to FTP, the only feature that I'd like to see (spawned through working with ShootDotEdit for outsourcing some processing) is the capacity to upload a set of folders which corresponds with separate galleries.
For me it's an inconvenience that ShootDotEdit doesn't upload individual folders to the appropriate galleries, but instead is looking for a batch upload to SmugMug. (I guess other photo sites have this behavior.) That's a challenge for me, but not unbearable. When I receive the archive disk, I can simply open the 10 tabs of each gallery and drop the correct set of images to the uploader. Easy peasy.
At the moment, I'll keep my fingers crossed that something comes out of the woodwork. It would be mighty slick to have it done without having to think about it.
Uploading at SmugMug is extremely reliable, we're accepting zillions of photos every single day, and the number of complaints we're getting is very, very low (and remember, we have hundreds and hundreds of thousands of active customers uploading all the time. These few issues usually turn out to be connection issues.
I don't refute that Andy, and to be honest I only thought it was me that wanted FTP.
But when it's the #8 thing on your customer feedback site, and someone in China of all places gets so fed up that they create an FTP method, there's some real weight to this request.
For the longest time I thought it was because of the infrastructure. But looking at the Amazon s3 product shows how easily you can create an ftp frontend for s3 and then transfer the uploaded images to Amazon EC2 (or whatever SM is using) with no bandwidth charges. This type of setup is very similar to what I really liked at Exposure Manager. And the transfer from their FTP side to their galleries wasn't automatic. You had to tell it to process the upload, which wasn't painful, but also eliminated any extra programming to try to automate that step or try to make it 'smart'.
Bottom line is that I believe this is easier to implement on the technical side than I once thought. But I do understand there could be other business reasons why SM doesn't want to implement FTP. On the other hand, the users continue to request it.
I don't work for Smugmug, so I don't have any inside information as to the technical details of how their system works. However, I suspect the complications with FTP come, not from implementing the actual protocol itself, but in representing your site's structure in the FTP environment.
When you make an FTP connection to a site, you basically are in a regular file system tree, with directories, sub-directories, and files. You can create/delete directories, copy files, move files, etc... much like looking at a folder in windows explorer or mac finder.
How would you go about representing your smugmug site as a file system tree? How would you prevent uploading of files into a folder that's just a category and not an actual gallery. How would you prevent the user from creating a sub-directory in a gallery, or creating sub-directories that are more levels down that allowable in a smugmug site? Those are just some of the questions that pop into mind off hand. I'm not saying it's impossible to build, but it's a whole lot more complicated that just turning on an FTP server.
I appreciate Andy's perspective & I like mbrady's breakdown... In no way am I dissatisfied with the vast offerings of upload tools, and with regards to FTP, the only feature that I'd like to see (spawned through working with ShootDotEdit for outsourcing some processing) is the capacity to upload a set of folders which corresponds with separate galleries.
When I receive the archive disk, I can simply open the 10 tabs of each gallery and drop the correct set of images to the uploader. Easy peasy.
See, that exact same step crashes even my fastest system which is an hp dc5750 with 3gb of ram. Videos are usually the culprit as the uploader attempts to parse the entire video before queuing it. Put a couple of these requests in parallel and the uploader locks up in the queuing stage. :cry
...and with regards to FTP, the only feature that I'd like to see (spawned through working with ShootDotEdit for outsourcing some processing) is the capacity to upload a set of folders which corresponds with separate galleries.
StarExplorer can do this also. Give it a folder hierarchy and it will create categories, sub-categories and galleries to match the directory hierarchy and then upload the images.
StarExplorer can do this also. Give it a folder hierarchy and it will create categories, sub-categories and galleries to match the directory hierarchy and then upload the images.
Thank you for adding this John. I didn't remember if SE could do that or not.
StarExplorer can do this also. Give it a folder hierarchy and it will create categories, sub-categories and galleries to match the directory hierarchy and then upload the images.
Keep in mind that it is StarExplorer that's handling all the Smugmug work - creating galleries, making sure the files go where they need to go, etc. It uses the Smugmug API to tell the Smugmug server to create galleries, send photos to galleries, etc.
FTP clients know nothing of Smugmug or the Smugmug API - how to create galleries, the differences between categories and galleries, where photos can be uploaded, etc.
FTP clients just send files to a folder on a server.
I'm not saying that it's impossible to implement, but it's certainly no cakewalk either. The devil is in the details.
Keep in mind that it is StarExplorer that's handling all the Smugmug work - creating galleries, making sure the files go where they need to go, etc. It uses the Smugmug API to tell the Smugmug server to create galleries, send photos to galleries, etc.
FTP clients know nothing of Smugmug or the Smugmug API - how to create galleries, the differences between categories and galleries, where photos can be uploaded, etc.
FTP clients just send files to a folder on a server.
I'm not saying that it's impossible to implement, but it's certainly no cakewalk either. The devil is in the details.
I'm not sure what you mean by your comments. I was referring to a non-ftp solution that could solve the issue of creating a hierarchy from the file system (nothing to do with ftp). Yes, StarExplorer does all the work to read the folder hierarchy and use the Smugmug API to create desired categories, sub-categories and galleries. That work is already done and works in StarExplorer.
FTP clients know nothing of Smugmug or the Smugmug API - how to create galleries, the differences between categories and galleries, where photos can be uploaded, etc. FTP clients just send files to a folder on a server.
I'm not saying that it's impossible to implement, but it's certainly no cakewalk either. The devil is in the details.
Who's looking for those features? Not me. I just want a fast way to get the files to a nearline SM server. Then if I have to go into control panel to tell it to put 'folder-y' in 'gallery-z', so be it. This is the implementation of Exposure Manager and it's flawless. And with Amazon's available services, it's a lot simpler than I first thought.
Vote to make FTP a reality. I've lost another day dealing with inefficient and overwhelmed uploaders crashing computers. With my bandwidth, FTP would've had all this up in 3hrs. I've been at this since 9am...
And I don't want to hear how great it is for everyone else or how it's something on my end...save that for another day.
Vote to make FTP a reality. I've lost another day dealing with inefficient and overwhelmed uploaders crashing computers. With my bandwidth, FTP would've had all this up in 3hrs. I've been at this since 9am...
And I don't want to hear how great it is for everyone else or how it's something on my end...save that for another day.
On the FTP Uploading feature request page, I see a post from FidelGonzales had success with SmugFTP. Does that not work for you?
Ah, nevermind, read more of the discussion re: 3rd party tools, support, bugs. On the other hand, Nikolai's Star*Explorer has a dedicated following and he provides stellar support. So it could end up being something great.
On the FTP Uploading feature request page, I see a post from FidelGonzales had success with SmugFTP. Does that not work for you?
I do use it. Very often in fact as Liangzan and I are almost in constant communication about it. But it doesn't work perfectly and when I absolutely need perfect uploads, the SM uploaders have it beat...for now. But they still have issues.
It's 6:25pm cst. I have been attempting to complete uploads since 9:30a cst. I have spent a total of maybe 30 minutes eating and every other second has been in front of my two fastest systems setting up uploads, queuing more, rebooting systems when the uploader crashes and I have to set up everything all over again. That's over 8hrs without a break. I haven't even had time for a shower! It's ridiculous. It's a full time job to upload? Something that otherwise could have been queued up in filezilla and then left alone?
This is why I got an exposure manager account right before SM added video. I was ready to ditch all the 'prettiness' for something that just worked faster and with less headache. But I need video too, so I'm stuck for now.
Ah, nevermind, read more of the discussion re: 3rd party tools, support, bugs. On the other hand, Nikolai's Star*Explorer has a dedicated following and he provides stellar support. So it could end up being something great.
Nikolai and I have worked extensively on SE and it completely dumbfounds me why it doesn't work for me. Two different physical locations with two different Internet connections, every operating system from 98se to xp home/embedded/pro, systems ranging from bare bones p3-500s to Athlon x2's. And it crashes in every one of these scenarios. I actually bought SE to upload my archive of 100gb. I had to do that manually via SM's uploaders. That was a serious pain.
FTP is an ancient and robust technology that still works. It can work well for SM too. And apparently I'm not the only pro that thinks so from the votes.
I can't wait to start testing smugftp again. I lost another hour today to the SM uploaders--"all files uploaded"...check the gallery and find files missing, *sigh*...re-enqueue, which takes for-ev-er...uploader crashes...$#%$#&&...restart uploader...re-enqueue...so much easier if we had a built-in ftp system...
Uploading videos is a nightmare. The drag & drop uploader always tries to do 3 at a time, so takes forever to complete anything. Videos often get stuck at the end with "verifying upload" while the upload log shows "incomplete file". 3 get stuck, and the whole process stops. I left my computer uploading 6 videos overnight, and only 2 got uploaded successfully. Pathetic.
And I'm on a reasonably fast cable connection, with no obvious connection issues. Hate to think what it's like for people on slower DSL or worse...
I also now have a wireless router with USB ports, which I reflashed with open-source Linux based DD-WRT firmware. I could put all my files on a USB stick, plug it into the router, and ftp upload directly from the router -- no need to tie up my PC or leave it on unnecessarily, can manage the process remotely from home and work, etc etc. All could be made possible by SmugMug supporting ftp.
Uploading videos is a nightmare. The drag & drop uploader always tries to do 3 at a time, so takes forever to complete anything. Videos often get stuck at the end with "verifying upload" while the upload log shows "incomplete file". 3 get stuck, and the whole process stops. I left my computer uploading 6 videos overnight, and only 2 got uploaded successfully. Pathetic.
And I'm on a reasonably fast cable connection, with no obvious connection issues. Hate to think what it's like for people on slower DSL or worse...
I also now have a wireless router with USB ports, which I reflashed with open-source Linux based DD-WRT firmware. I could put all my files on a USB stick, plug it into the router, and ftp upload directly from the router -- no need to tie up my PC or leave it on unnecessarily, can manage the process remotely from home and work, etc etc. All could be made possible by SmugMug supporting ftp.
Comments
Let's make FTP a reality. FTP uploading is now one of the top 10 requests on uservoice.
http://smugmug.uservoice.com/forums/17723-smugmug/suggestions/294159-ftp-uploading
Want faster uploading? Vote for FTP!
Voted. Twice :-)
FTP would solve all this. I spend 12 hours a few days ago uploading what technically should've taken under 2hrs.
Want faster uploading? Vote for FTP!
http://smugmug.uservoice.com/forums/17723-smugmug/suggestions/294159-ftp-uploading
Want faster uploading? Vote for FTP!
http://feedback.smugmug.com/forums/17723-smugmug/suggestions/294159-ftp-uploading
Want faster uploading? Vote for FTP!
http://www.dgrin.com/showthread.php?t=188870
Portfolio • Workshops • Facebook • Twitter
Want faster uploading? Vote for FTP!
I already own great easy to use FTP software: SMART FTP CLIENT and there is also FREE FTP from Mozilla: FireFtp.......SM just need to allow us to use what probably many of us already have.
Want faster uploading? Vote for FTP!
Can't speak for anybody but myself but, I'm not really comfortable with this solution. Some of my reasoning stems from issues brought up in said thread... But something I haven't seen mentioned, and what I'm curious/concerned with is that since this isn't being done 'in house', should something go wrong, it will be up to the gentleman whom created it to patch it up. Also, the creator of said app now has to be responsible for any overhead created by the needed bandwidth for transfers and such.
While contributions will help and that's all well and good, it leaves me wondering why such things couldn't just be part of the power and pro level subscriber costs? This way we have a more streamlined and better maintained ftp client/server.
Doug
Want faster uploading? Vote for FTP!
Vote for FTP. There's no reason to deal with unreliable uploading any longer.
Want faster uploading? Vote for FTP!
I need to reduce the hyperbole here, Samir.
Uploading at SmugMug is extremely reliable, we're accepting zillions of photos every single day, and the number of complaints we're getting is very, very low (and remember, we have hundreds and hundreds of thousands of active customers uploading all the time. These few issues usually turn out to be connection issues.
Portfolio • Workshops • Facebook • Twitter
I don't work for Smugmug, so I don't have any inside information as to the technical details of how their system works. However, I suspect the complications with FTP come, not from implementing the actual protocol itself, but in representing your site's structure in the FTP environment.
When you make an FTP connection to a site, you basically are in a regular file system tree, with directories, sub-directories, and files. You can create/delete directories, copy files, move files, etc... much like looking at a folder in windows explorer or mac finder.
How would you go about representing your smugmug site as a file system tree? How would you prevent uploading of files into a folder that's just a category and not an actual gallery. How would you prevent the user from creating a sub-directory in a gallery, or creating sub-directories that are more levels down that allowable in a smugmug site? Those are just some of the questions that pop into mind off hand. I'm not saying it's impossible to build, but it's a whole lot more complicated that just turning on an FTP server.
For me it's an inconvenience that ShootDotEdit doesn't upload individual folders to the appropriate galleries, but instead is looking for a batch upload to SmugMug. (I guess other photo sites have this behavior.) That's a challenge for me, but not unbearable. When I receive the archive disk, I can simply open the 10 tabs of each gallery and drop the correct set of images to the uploader. Easy peasy.
At the moment, I'll keep my fingers crossed that something comes out of the woodwork. It would be mighty slick to have it done without having to think about it.
About Me • Photography • Blog • Juneau, AK SMUG • Facebook • Twitter
But when it's the #8 thing on your customer feedback site, and someone in China of all places gets so fed up that they create an FTP method, there's some real weight to this request.
For the longest time I thought it was because of the infrastructure. But looking at the Amazon s3 product shows how easily you can create an ftp frontend for s3 and then transfer the uploaded images to Amazon EC2 (or whatever SM is using) with no bandwidth charges. This type of setup is very similar to what I really liked at Exposure Manager. And the transfer from their FTP side to their galleries wasn't automatic. You had to tell it to process the upload, which wasn't painful, but also eliminated any extra programming to try to automate that step or try to make it 'smart'.
Bottom line is that I believe this is easier to implement on the technical side than I once thought. But I do understand there could be other business reasons why SM doesn't want to implement FTP. On the other hand, the users continue to request it.
Want faster uploading? Vote for FTP!
http://aws.amazon.com/s3/
Want faster uploading? Vote for FTP!
See, that exact same step crashes even my fastest system which is an hp dc5750 with 3gb of ram. Videos are usually the culprit as the uploader attempts to parse the entire video before queuing it. Put a couple of these requests in parallel and the uploader locks up in the queuing stage. :cry
Want faster uploading? Vote for FTP!
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!
Keep in mind that it is StarExplorer that's handling all the Smugmug work - creating galleries, making sure the files go where they need to go, etc. It uses the Smugmug API to tell the Smugmug server to create galleries, send photos to galleries, etc.
FTP clients know nothing of Smugmug or the Smugmug API - how to create galleries, the differences between categories and galleries, where photos can be uploaded, etc.
FTP clients just send files to a folder on a server.
I'm not saying that it's impossible to implement, but it's certainly no cakewalk either. The devil is in the details.
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!
And I don't want to hear how great it is for everyone else or how it's something on my end...save that for another day.
Want faster uploading? Vote for FTP!
On the FTP Uploading feature request page, I see a post from FidelGonzales had success with SmugFTP. Does that not work for you?
Ah, nevermind, read more of the discussion re: 3rd party tools, support, bugs. On the other hand, Nikolai's Star*Explorer has a dedicated following and he provides stellar support. So it could end up being something great.
It's 6:25pm cst. I have been attempting to complete uploads since 9:30a cst. I have spent a total of maybe 30 minutes eating and every other second has been in front of my two fastest systems setting up uploads, queuing more, rebooting systems when the uploader crashes and I have to set up everything all over again. That's over 8hrs without a break. I haven't even had time for a shower! It's ridiculous. It's a full time job to upload? Something that otherwise could have been queued up in filezilla and then left alone?
This is why I got an exposure manager account right before SM added video. I was ready to ditch all the 'prettiness' for something that just worked faster and with less headache. But I need video too, so I'm stuck for now.
Nikolai and I have worked extensively on SE and it completely dumbfounds me why it doesn't work for me. Two different physical locations with two different Internet connections, every operating system from 98se to xp home/embedded/pro, systems ranging from bare bones p3-500s to Athlon x2's. And it crashes in every one of these scenarios. I actually bought SE to upload my archive of 100gb. I had to do that manually via SM's uploaders. That was a serious pain.
FTP is an ancient and robust technology that still works. It can work well for SM too. And apparently I'm not the only pro that thinks so from the votes.
Want faster uploading? Vote for FTP!
http://feedback.smugmug.com/forums/17723-smugmug/suggestions/294159-ftp-uploading
Want faster uploading? Vote for FTP!
Want faster uploading? Vote for FTP!
And I'm on a reasonably fast cable connection, with no obvious connection issues. Hate to think what it's like for people on slower DSL or worse...
I also now have a wireless router with USB ports, which I reflashed with open-source Linux based DD-WRT firmware. I could put all my files on a USB stick, plug it into the router, and ftp upload directly from the router -- no need to tie up my PC or leave it on unnecessarily, can manage the process remotely from home and work, etc etc. All could be made possible by SmugMug supporting ftp.
http://smugftp.com/
SmugMug API Developer
My Photos