I can understand that, as it's the usual development course at SM, but there's something broken at the back end, and it's going to come out sooner or later. There's absolutely nothing wrong with wget. If you had googled it, you would read what a solid open source product this is.
I give up. Another broken thing at SM I can't use anymore. What a shame.
Samir, I'll point to this post one last time since you didn't respond before. There are simply much easier ways to do your backup than you are doing now that would take a lot less of your time and leave you more time for your business (something you said was important). I won't get into the merits of your current system vs. Smugmug's features, but right now it is what it is and sometimes when you run into a brick wall, it's better to find a way around it rather than keep yelling at the wall to move itself out of the way.
Samir, I'll point to this post one last time since you didn't respond before. There are simply much easier ways to do your backup than you are doing now that would take a lot less of your time and leave you more time for your business (something you said was important). I won't get into the merits of your current system vs. Smugmug's features, but right now it is what it is and sometimes when you run into a brick wall, it's better to find a way around it rather than keep yelling at the wall to move itself out of the way.
We've gone over this. It doesn't work for me. And it sucks that a broken feature on SM becomes a brick wall. I really don't like the fact that SM's development works the same way FB's does. I'm simply going to start looking for other solutions rather than trying to fix stuff. The heck with it.
I give up. Another broken thing at SM I can't use anymore. What a shame.
But how is this broken if we're not getting complaints from people downloading? I have downloaded your files and many, many others. And we rarely (very rarely, and when it happens, it's usually a broken connection that is magically fixed the next time they download) hear about this, Samir. I'm really sorry it's causing trouble for you
But how is this broken if we're not getting complaints from people downloading? I have downloaded your files and many, many others. And we rarely (very rarely, and when it happens, it's usually a broken connection that is magically fixed the next time they download) hear about this, Samir. I'm really sorry it's causing trouble for you
That's the common SM cop out to bad programming. Fine, it's not broken. I'm not using it anymore so it's not going to affect me anymore. There's a part of me that really doesn't want to even use SM anymore, but I don't have a choice right now as it's the 'best fit' service out there. But I'm on the hunt again. After fighting uploading gremlins today and these downloading gremlins, it might be easier to find a better fit for me than deal with all this headache.
We've gone over this. It doesn't work for me. And it sucks that a broken feature on SM becomes a brick wall. I really don't like the fact that SM's development works the same way FB's does. I'm simply going to start looking for other solutions rather than trying to fix stuff. The heck with it.
Samir, I see nothing broken on Smugmug here. Your ISP (or somewhere in your connection chain) is apparently regularly dropping packets and you're expecting Smugmug to design for that. They haven't and it simply hasn't been important to the business they are in.
Further, we've never gone over my post that suggested using a much better backup system than you are using. You never responded once when I suggested that earlier in this thread so NO, we've not gone over this ever. Smugmug is not designed to be the optimal backup solution in the world. Solutions optimized for backup all have an automatic agent that backs things up for you without any human intervention (after all, that's the only reliable backup).
By trying to cobble together your own backup system on top of Smugmug, you are making an enormous amount of work for yourself that does not need to be that way and on top of it you're insisting on using a process that doesn't tolerate dropped packets very well. BackBlaze does not have that issue. It just merrily keeps going by itself until the job is done. I never have to worry about connectivity issues with it and my stuff is all backed up perfectly. IMO, you should find a different solution than Smugmug for backup.
Samir, I see nothing broken on Smugmug here. Your ISP (or somewhere in your connection chain) is apparently regularly dropping packets and you're expecting Smugmug to design for that. They haven't and it simply hasn't been important to the business they are in.
When a single dropped packet foils a 2gb download, I think that's a design flaw. And that's fine if they don't want to fix it. It's their choice. Others won't ever say there's a problem and will just move to another service.
Further, we've never gone over my post that suggested using a much better backup system than you are using. You never responded once when I suggested that earlier in this thread so NO, we've not gone over this ever. Smugmug is not designed to be the optimal backup solution in the world. Solutions optimized for backup all have an automatic agent that backs things up for you without any human intervention (after all, that's the only reliable backup).
By trying to cobble together your own backup system on top of Smugmug, you are making an enormous amount of work for yourself that does not need to be that way and on top of it you're insisting on using a process that doesn't tolerate dropped packets very well. BackBlaze does not have that issue. It just merrily keeps going by itself until the job is done. I never have to worry about connectivity issues with it and my stuff is all backed up perfectly. IMO, you should find a different solution than Smugmug for backup.
I already told you that your solutions won't work for me. I'm not stupid John, and your comments border on insulting my intelligence. Your assumption that your solution fits better for my situation is presumptuous at best.
I've found a way around this entire issue, so I don't %$% care what SM does with it.
When a single dropped packet foils a 2gb download, I think that's a design flaw. And that's fine if they don't want to fix it. It's their choice. Others won't ever say there's a problem and will just move to another service.
I already told you that your solutions won't work for me. I'm not stupid John, and your comments border on insulting my intelligence. Your assumption that your solution fits better for my situation is presumptuous at best.
I've found a way around this entire issue, so I don't %$% care what SM does with it.
I think we should put this in perspective for others reading this. Both a regular browser download and wget use the TCP/IP protocol for communication with Smugmug's servers which is a "reliable" protocol. TCP/IP detects and handles dropped packets with it's own packet sequencing and retransmission scheme. When TCP can't handle a lossy issue, there are a LOT of dropped packets - enough to overwhelm TCP. This is not an issue of a single dropped packet. This is a serious interruption of the connection in some way.
I think we should put this in perspective for others reading this. Both a regular browser download and wget use the TCP/IP protocol for communication with Smugmug's servers which is a "reliable" protocol. TCP/IP detects and handles dropped packets with it's own packet sequencing and retransmission scheme. When TCP can't handle a lossy issue, there are a LOT of dropped packets - enough to overwhelm TCP. This is not an issue of a single dropped packet. This is a serious interruption of the connection in some way.
There's a very limited retransmission scheme when it comes to downloading things via http. You know this, and I know this. And anyone who has had a download stop mid-stream knows this.
Quit trying to discredit me and minimize my issue beacuse you feel it's a non-issue. If you don't have a solution for me that fits within my parameters, it's not a solution for me. I thank you for your input as always, but we're getting nowhere with this banter.
There's a very limited retransmission scheme when it comes to downloading things via http. You know this, and I know this. And anyone who has had a download stop mid-stream knows this.
Quit trying to discredit me and minimize my issue beacuse you feel it's a non-issue. If you don't have a solution for me that fits within my parameters, it's not a solution for me. I thank you for your input as always, but we're getting nowhere with this banter.
YOU have a connection reliability issue that makes typical and normal download tools not work for you that work for nearly all others. I'm just trying to put this issue in perspective. It's your choice how to deal with that (find a service that works differently, keep trying to get Smugmug to change something, find a workflow that works differently, etc...). I'm not intending to insult you at all, just putting things in perspective. Your words were a "single dropped packet" and that is probably not what is happening here.
YOU have a connection reliability issue that makes typical and normal download tools not work for you that work for nearly all others. I'm just trying to put this issue in perspective. It's your choice how to deal with that (find a service that works differently, keep trying to get Smugmug to change something, find a workflow that works differently, etc...). I'm not intending to insult you at all, just putting things in perspective. Your words were a "single dropped packet" and that is likely not what is happening here.
And why whenever I have a problem, it's always my fault? You haven't even addressed the FACT that lenghty http downloads have historically ALWAYS had problems because of slight glitches in the stream. It's not my problem that the system doesn't work for me, it's a bad design that ignores a fundamental problem of Internet architecture. And for the record, this same flaw is what make uploading to SM just as bad as downloading. I've been trying to get a 4gb gallery online for three days now that would've taken under an hour via FTP.
Comments
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!
But how is this broken if we're not getting complaints from people downloading? I have downloaded your files and many, many others. And we rarely (very rarely, and when it happens, it's usually a broken connection that is magically fixed the next time they download) hear about this, Samir. I'm really sorry it's causing trouble for you
Portfolio • Workshops • Facebook • Twitter
Want faster uploading? Vote for FTP!
Further, we've never gone over my post that suggested using a much better backup system than you are using. You never responded once when I suggested that earlier in this thread so NO, we've not gone over this ever. Smugmug is not designed to be the optimal backup solution in the world. Solutions optimized for backup all have an automatic agent that backs things up for you without any human intervention (after all, that's the only reliable backup).
By trying to cobble together your own backup system on top of Smugmug, you are making an enormous amount of work for yourself that does not need to be that way and on top of it you're insisting on using a process that doesn't tolerate dropped packets very well. BackBlaze does not have that issue. It just merrily keeps going by itself until the job is done. I never have to worry about connectivity issues with it and my stuff is all backed up perfectly. IMO, you should find a different solution than Smugmug for backup.
Homepage • Popular
JFriend's javascript customizations • Secrets for getting fast answers on Dgrin
Always include a link to your site when posting a question
We discussed this in January of 2010:
http://www.dgrin.com/showthread.php?t=156472
I already told you that your solutions won't work for me. I'm not stupid John, and your comments border on insulting my intelligence. Your assumption that your solution fits better for my situation is presumptuous at best.
I've found a way around this entire issue, so I don't %$% care what SM does with it.
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
Quit trying to discredit me and minimize my issue beacuse you feel it's a non-issue. If you don't have a solution for me that fits within my parameters, it's not a solution for me. I thank you for your input as always, but we're getting nowhere with this banter.
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!
http://serverfault.com/questions/183959/how-to-tell-wget-to-use-the-name-of-the-target-file-behind-the-http-redirect
Now I'm able to have whatever file names I want again.
And for the record, I tried the new SM bandwidth test tool and it shows NO packet loss. It's not my connection.
Want faster uploading? Vote for FTP!