New version 1.0.0.275: cloud-compatible
New direct-to-the-cloud SM API behavior revealed a 5 year old bug that was hiding in the heart of the S*E uploading engine . As a result any upload action was considered "failed", thus forcing the rest of S*E to repeat the uploads over and over. :cry
It is fixed now, so S*E is back and even slightly faster, both due to the server's direct-to-the-cloud behavior and some further internal optimization.
I apologize for the inconvenince it caused to a few good people.
S*E uses the actual URLs for downloads instead of constructing them
Redirection issue (a long time plague) is fixed, allowing graceful scaling down in case a higher-res image is not allowed.
Get those new SM vertical Videos back!
Smugmug had a couple minute outage today while I was near the end of a 127 photo upload. I saw SE gets some failures and do some retries. When SE finished, the result was that 4 images were left in the upload queue as unable to upload. After the Smugmug issue cleared, I hit upload to finish the upload queue. It seemed as if everything worked as it should and it certainly worked a lot better than any of the Smugmug uploaders would have.
On the other hand, my gallery did not end up clean. I don't know how much of this is an SE issue that you could protect against vs. purely a SM issue, but I'll describe what I ended up with and you can decide. In my gallery, I ended up with four images that were permanently stuck in the state of no thumbnail (they have some sort of uploading placeholder thumbnail). Hours later, they were still that way. And, I ended up with a couple duplicates. I manually deleted the stuck images and manually deleted a few duplicates (at least the ones I found).
So, the good news is that SE seemed to properly detect that it had issues uploading a few images and kept them in the upload queue for me to manually upload later. The bad news is that the gallery didn't end up clean after that. Do you think there are non-atomic upload issues at Smugmug that should be reported to SM where they stop with a partial upload and don't clean up after themselves? Any SE issues that should be cleaned up when connectivity to SM goes away?
For reference, at the time of the SM outage, a regular SM page access was generating 503. I don't know what the situation was on the upload endpoint, but it was clearly getting some sort of failure too as I could see that in the SE upload log.
I can send you my SE upload log if you want that. I should mention that I was running 1.0.0.275 which I believe is what I downloaded from your site yesterday.
Smugmug had a couple minute outage today while I was near the end of a 127 photo upload. I saw SE gets some failures and do some retries. When SE finished, the result was that 4 images were left in the upload queue as unable to upload. After the Smugmug issue cleared, I hit upload to finish the upload queue. It seemed as if everything worked as it should and it certainly worked a lot better than any of the Smugmug uploaders would have.
On the other hand, my gallery did not end up clean. I don't know how much of this is an SE issue that you could protect against vs. purely a SM issue, but I'll describe what I ended up with and you can decide. In my gallery, I ended up with four images that were permanently stuck in the state of no thumbnail (they have some sort of uploading placeholder thumbnail). Hours later, they were still that way. And, I ended up with a couple duplicates. I manually deleted the stuck images and manually deleted a few duplicates (at least the ones I found).
So, the good news is that SE seemed to properly detect that it had issues uploading a few images and kept them in the upload queue for me to manually upload later. The bad news is that the gallery didn't end up clean after that. Do you think there are non-atomic upload issues at Smugmug that should be reported to SM where they stop with a partial upload and don't clean up after themselves? Any SE issues that should be cleaned up when connectivity to SM goes away?
For reference, at the time of the SM outage, a regular SM page access was generating 503. I don't know what the situation was on the upload endpoint, but it was clearly getting some sort of failure too as I could see that in the SE upload log.
I can send you my SE upload log if you want that. I should mention that I was running 1.0.0.275 which I believe is what I downloaded from your site yesterday.
Hi John,
a damn good question... I wish a had a similarly good answer...:-(
I don't know how to detect outage, "stuck" images, etc. I can go nuts checking the internet connections, SM availability and error codes, but in the end none of this would give me a 100% certainty, just would make the decision making a nightmare.
From the very launch of S*E my approach was very simple:
If I get the image ID (and later, key) back - this image was delivered to SM server and my part is done. I cannot do anything afterwards anyway, as there is no API (and I honestly don't think it's needed).
Similarly, if I don't (a hiccup, an outage, tornado, tsunami, etc.) - I can either try immediately a few times more (configurable) or leave it in the queue. If I finished the batch and there is some files in the queue still, again, depending on the configuration I can try to run this (hopefully, smaller) batch again or leave it up to the user to decided what needs to be done.
Unfortunately, at this point I don't have a reliable info telling me if it was a true or false negative. Simple approaches (like getting the content of all the affected albums and try to match it to the noon-yet uploaded portion in hope of finding those that actually made it and removing them from the queue) are totally unreliable due to the also simple fact that it can take an absolutely non-predictable time until the image actually shows up in the album. Normally it's not such a big period, but we're not talking about normal circumstances. And when SM is busy... well, it's busy. I've seen queue times far longer than 10.20 minutes... Not often, but I don't get errors often either.
So it's kinda a catch 22. When the delivery channel is working as it should, the number of issues is minimal, and my purely "true-or-false", "black-or-white" logic works just fine, no need to make it any more complex.
Yet when the situation becomes worse (power outage, weekend traffic jam, etc.) no feasible decision method can help, as the is no new immediately available data to make one.
I'll be happy to hear your or anybody's (hi devbobo! ) ideas how to get out of this "failed to receive the ID" conundrum without increasing the risk of creating duplicates.
Hi John,
a damn good question... I wish a had a similarly good answer...:-(
I don't know how to detect outage, "stuck" images, etc. I can go nuts checking the internet connections, SM availability and error codes, but in the end none of this would give me a 100% certainty, just would make the decision making a nightmare.
From the very launch of S*E my approach was very simple:
If I get the image ID (and later, key) back - this image was delivered to SM server and my part is done. I cannot do anything afterwards anyway, as there is no API (and I honestly don't think it's needed).
Similarly, if I don't (a hiccup, an outage, tornado, tsunami, etc.) - I can either try immediately a few times more (configurable) or leave it in the queue. If I finished the batch and there is some files in the queue still, again, depending on the configuration I can try to run this (hopefully, smaller) batch again or leave it up to the user to decided what needs to be done.
Unfortunately, at this point I don't have a reliable info telling me if it was a true or false negative. Simple approaches (like getting the content of all the affected albums and try to match it to the noon-yet uploaded portion in hope of finding those that actually made it and removing them from the queue) are totally unreliable due to the also simple fact that it can take an absolutely non-predictable time until the image actually shows up in the album. Normally it's not such a big period, but we're not talking about normal circumstances. And when SM is busy... well, it's busy. I've seen queue times far longer than 10.20 minutes... Not often, but I don't get errors often either.
So it's kinda a catch 22. When the delivery channel is working as it should, the number of issues is minimal, and my purely "true-or-false", "black-or-white" logic works just fine, no need to make it any more complex.
Yet when the situation becomes worse (power outage, weekend traffic jam, etc.) no feasible decision method can help, as the is no new immediately available data to make one.
I'll be happy to hear your or anybody's (hi devbobo! ) ideas how to get out of this "failed to receive the ID" conundrum without increasing the risk of creating duplicates.
That sheds some useful light on what probably happened. It looks like Smugmug accepted some partial uploads that were interrupted by the outage and then left them in my gallery that way. That sounds like a bug on their part.
And, the connectivity issues probably prevented you from getting a couple image IDs on something that did successfully upload, thus it was left in the queue or retried resulting in a couple dups. I guess dups are better than erring the other way (missing images) so perhaps that's decent failure mode if nothing better can be done (I assume that was your logic). The only bad failure here would be if uploads were completely, but imageIDs were not being fetched as SE might upload a lot of dups if SM was failing in that way.
I'm sure this problem (reliable transfers that both sides can reliably know whether the full transfer completed or not) even when there are connectivity hiccups has been solved many times before. Too bad something more robust isn't being offered.
That sheds some useful light on what probably happened. It looks like Smugmug accepted some partial uploads that were interrupted by the outage and then left them in my gallery that way. That sounds like a bug on their part.
And, the connectivity issues probably prevented you from getting a couple image IDs on something that did successfully upload, thus it was left in the queue or retried resulting in a couple dups. I guess dups are better than erring the other way (missing images) so perhaps that's decent failure mode if nothing better can be done (I assume that was your logic). The only bad failure here would be if uploads were completely, but imageIDs were not being fetched as SE might upload a lot of dups if SM was failing in that way.
I'm sure this problem (reliable transfers that both sides can reliably know whether the full transfer completed or not) even when there are connectivity hiccups has been solved many times before. Too bad something more robust isn't being offered.
It has been solved numerous times, indeed. All the solutions I know essentially operate on a concept of "transaction".
It can be done in a multitude of ways, and the gist looks like follows:
* Client (S*E in this case) initiates a new transaction
* Server (obviously, Smugmug) responds with a transaction ID and maybe some metadata
* Client starts uploading (in one piece, or, even better, in multiple chunks - the latter should make uploading large videos a breeze), each time indicating a transaction ID, and, optionally, a chunk ID
* Client indicates it's done uploading for this transaction
* Now, at any moment (within reason and settings) Client can ask Server if the transaction X is complete. The obvious answers are:
- No, still working - in this case Client would wait some time and will ask again.
- Yes, here is result ID/KEY (or whatever else is needed),
- Error: (unknown ID, missing chunk, corrupted data, invalid format, etc.)
This way it's foolproof. No matter what happens, both sides can reliably identify a subject (transaction id) and its status.
Practically, the only thing needed is that darn transaction ID to be sent back right away, as well as the ability to query against it. The image ID shall be only returned as a part of that query when transaction is complete.
Of course, one can use the image id as the transaction id, return it immediately and then only return the key if it went OK. This way certain ids would never come to fruition and whether SM would like to have those unused ids - it's a design question.
Given my experience with transaction-aware databases, Amazon SQS, MSMQ and other "delivery guaranteed" methods, it looks like it *can* be done, especially considering the fact that SM already utilizes AWS.
But whether it *will* be done - it's a whole different story.
New version 1.0.0.281: fixed download
Under certain scenarios originals were downloaded without an extention; X2Large were not downloaded at all.
Fixed.
WTB: 1GB and 512k CF cards.
I have a need for a decent # of these smaller cards. If you have multiple cards that would be great. I am located at zip code 35243 & 35255.
It sure does. By default it may be configured to ignore videos, but it's up to you to modify the Options and allow whatever types you want. Just make sure they are SM compatible.
It sure does. By default it may be configured to ignore videos, but it's up to you to modify the Options and allow whatever types you want. Just make sure they are SM compatible.
Ok that is what it was, I was selecting them but they were not showing up in upload queue. I have become frustrated with trying to upload some videos via smugmugs uploaders.
WTB: 1GB and 512k CF cards.
I have a need for a decent # of these smaller cards. If you have multiple cards that would be great. I am located at zip code 35243 & 35255.
I have become frustrated with trying to upload some videos via smugmugs uploaders.
Remember that if a video is not processing correctly via SM's uploaders, it won't be any different with SE. SM currently has issues with certain type of videos, and it's been going on for weeks.
Now, if the problem you're having is crashing or something of that nature, try a different type of uploader. HTML5 always crashes for me while Simple works fine. I've heard that the flash one is pretty good too.
Remember that if a video is not processing correctly via SM's uploaders, it won't be any different with SE. SM currently has issues with certain type of videos, and it's been going on for weeks.
Now, if the problem you're having is crashing or something of that nature, try a different type of uploader. HTML5 always crashes for me while Simple works fine. I've heard that the flash one is pretty good too.
Not really crashing just slow and tons of fails. Do you know what types of files its having issues with. I am trying to upload all .mov files from Canon cams.
It does seem in the recent weeks to be video issues. Has SM said anything, or is it there usual default position of, "User error".
WTB: 1GB and 512k CF cards.
I have a need for a decent # of these smaller cards. If you have multiple cards that would be great. I am located at zip code 35243 & 35255.
Not really crashing just slow and tons of fails. Do you know what types of files its having issues with. I am trying to upload all .mov files from Canon cams.
It does seem in the recent weeks to be video issues. Has SM said anything, or is it there usual default position of, "User error".
They've been having problems with some mpgs as well as audio codecs. It's interesting that movs are failing--that's what they keep telling me to convert to for success.
Are these raw files from the cameras? Have they worked without issues in the past? As far as speed, what type of bandwidth do you have?
These are files straight from the camera. I am very new to video, and don't have a reference point. I am on a fairly fast cable connection, like 20 down and 2 up.
WTB: 1GB and 512k CF cards.
I have a need for a decent # of these smaller cards. If you have multiple cards that would be great. I am located at zip code 35243 & 35255.
Can you change the quality settings in the camera in a way that affects the format? For example, SD vs HD, framerate, or the audio? Then we could experiment with uploading the different file types and see what works and what doesn't. Then we could pass this info onto the help desk.
With a 2Mb connection, you should be able to do about 1gb/hr if you're maxed out. Maxing out is the tough part since a single upload will rarely do it. So, realistically you have to look at 1gb/2-3hrs unless you're transferring multiple files simultaneously.
I was initially trying SM uploaders and also mistakenly thought that Star Explorer didn't do video (it does, I just needed to change a setting to allow it to). I am now having much better success using Star Explorer. Yeah I am coming close to a 20 hour mark for a little under 20GBs of videos (221 clips) from a wedding. I have about 50GBs from the wedding total (3 seperate cams). Like I said I am new to the video side and I am learning.
Thanks for the info Samir.
I might have a little time to experiment with the settings while on vacation in Washington State but probably not. So I will be somewhat gone for about 3 weeks.
WTB: 1GB and 512k CF cards.
I have a need for a decent # of these smaller cards. If you have multiple cards that would be great. I am located at zip code 35243 & 35255.
I was initially trying SM uploaders and also mistakenly thought that Star Explorer didn't do video (it does, I just needed to change a setting to allow it to). I am now having much better success using Star Explorer. Yeah I am coming close to a 20 hour mark for a little under 20GBs of videos (221 clips) from a wedding. I have about 50GBs from the wedding total (3 seperate cams). Like I said I am new to the video side and I am learning....
Glad to hear!
I do hope SM will come with "chunked" upload at some point in the future, so if those last few Kb of a 500Mb video do not go through you don't have to redo the whole video and only redo that bad chunk...
That's a lot of data. With your bandwidth, you'll be lucky to finish uploading in 50hrs. It's a big job to say the least. If you regularly plan on uploading this size of data, you need to upgrade your upload bandwidth, even if it means getting multiple 20m/2m connections.
Hello! Is anyone home at Star*Explorer? Been trying to contact via support email and Dgrin message with no response.
Acadiana Al
Smugmug: Bayou Oaks Studio
Blog: Journey to the Light
"Serendipity...the faculty of making happy, unexpected discoveries by accident." .... Horace Walpole, 1754 (perhaps that 'lucky shot' wasn't really luck at all!)
Hello! Is anyone home at Star*Explorer? Been trying to contact via support email and Dgrin message with no response.
Al,
I was out in the Sierras for a few days with no connection whatsoever.
There was (and still is) a warning on my website that no new licenses could be issued during that time...
Truly sorry about that.
Nikolai
Al,
I was out in the Sierras for a few days with no connection whatsoever.
There was (and still is) a warning on my website that no new licenses could be issued during that time...
Truly sorry about that.
Nikolai
Perhaps an auto-responder on your support email might have been helpful. Small businesses have a hard time taking some vacation.
Al,
I was out in the Sierras for a few days with no connection whatsoever.
There was (and still is) a warning on my website that no new licenses could be issued during that time...
Truly sorry about that.
Nikolai
Thanks. All is well now.
Acadiana Al
Smugmug: Bayou Oaks Studio
Blog: Journey to the Light
"Serendipity...the faculty of making happy, unexpected discoveries by accident." .... Horace Walpole, 1754 (perhaps that 'lucky shot' wasn't really luck at all!)
Comments
Albums2 Pro Package (S*E Pro/Studio License required):
Bugfixes (including upload cancellation)
New direct-to-the-cloud SM API behavior revealed a 5 year old
It is fixed now, so S*E is back and even slightly faster, both due to the server's direct-to-the-cloud behavior and some further internal optimization.
I apologize for the inconvenince it caused to a few good people.
- Video download bug fixed
- S*E uses the actual URLs for downloads instead of constructing them
- Redirection issue (a long time plague) is fixed, allowing graceful scaling down in case a higher-res image is not allowed.
Get those new SM vertical Videos back!On the other hand, my gallery did not end up clean. I don't know how much of this is an SE issue that you could protect against vs. purely a SM issue, but I'll describe what I ended up with and you can decide. In my gallery, I ended up with four images that were permanently stuck in the state of no thumbnail (they have some sort of uploading placeholder thumbnail). Hours later, they were still that way. And, I ended up with a couple duplicates. I manually deleted the stuck images and manually deleted a few duplicates (at least the ones I found).
So, the good news is that SE seemed to properly detect that it had issues uploading a few images and kept them in the upload queue for me to manually upload later. The bad news is that the gallery didn't end up clean after that. Do you think there are non-atomic upload issues at Smugmug that should be reported to SM where they stop with a partial upload and don't clean up after themselves? Any SE issues that should be cleaned up when connectivity to SM goes away?
For reference, at the time of the SM outage, a regular SM page access was generating 503. I don't know what the situation was on the upload endpoint, but it was clearly getting some sort of failure too as I could see that in the SE upload log.
I can send you my SE upload log if you want that. I should mention that I was running 1.0.0.275 which I believe is what I downloaded from your site yesterday.
Homepage • Popular
JFriend's javascript customizations • Secrets for getting fast answers on Dgrin
Always include a link to your site when posting a question
Hi John,
a damn good question... I wish a had a similarly good answer...:-(
I don't know how to detect outage, "stuck" images, etc. I can go nuts checking the internet connections, SM availability and error codes, but in the end none of this would give me a 100% certainty, just would make the decision making a nightmare.
From the very launch of S*E my approach was very simple:
If I get the image ID (and later, key) back - this image was delivered to SM server and my part is done. I cannot do anything afterwards anyway, as there is no API (and I honestly don't think it's needed).
Similarly, if I don't (a hiccup, an outage, tornado, tsunami, etc.) - I can either try immediately a few times more (configurable) or leave it in the queue. If I finished the batch and there is some files in the queue still, again, depending on the configuration I can try to run this (hopefully, smaller) batch again or leave it up to the user to decided what needs to be done.
Unfortunately, at this point I don't have a reliable info telling me if it was a true or false negative. Simple approaches (like getting the content of all the affected albums and try to match it to the noon-yet uploaded portion in hope of finding those that actually made it and removing them from the queue) are totally unreliable due to the also simple fact that it can take an absolutely non-predictable time until the image actually shows up in the album. Normally it's not such a big period, but we're not talking about normal circumstances. And when SM is busy... well, it's busy. I've seen queue times far longer than 10.20 minutes... Not often, but I don't get errors often either.
So it's kinda a catch 22. When the delivery channel is working as it should, the number of issues is minimal, and my purely "true-or-false", "black-or-white" logic works just fine, no need to make it any more complex.
Yet when the situation becomes worse (power outage, weekend traffic jam, etc.) no feasible decision method can help, as the is no new immediately available data to make one.
I'll be happy to hear your or anybody's (hi devbobo!
And, the connectivity issues probably prevented you from getting a couple image IDs on something that did successfully upload, thus it was left in the queue or retried resulting in a couple dups. I guess dups are better than erring the other way (missing images) so perhaps that's decent failure mode if nothing better can be done (I assume that was your logic). The only bad failure here would be if uploads were completely, but imageIDs were not being fetched as SE might upload a lot of dups if SM was failing in that way.
I'm sure this problem (reliable transfers that both sides can reliably know whether the full transfer completed or not) even when there are connectivity hiccups has been solved many times before. Too bad something more robust isn't being offered.
Homepage • Popular
JFriend's javascript customizations • Secrets for getting fast answers on Dgrin
Always include a link to your site when posting a question
It has been solved numerous times, indeed. All the solutions I know essentially operate on a concept of "transaction".
It can be done in a multitude of ways, and the gist looks like follows:
* Client (S*E in this case) initiates a new transaction
* Server (obviously, Smugmug) responds with a transaction ID and maybe some metadata
* Client starts uploading (in one piece, or, even better, in multiple chunks - the latter should make uploading large videos a breeze), each time indicating a transaction ID, and, optionally, a chunk ID
* Client indicates it's done uploading for this transaction
* Now, at any moment (within reason and settings) Client can ask Server if the transaction X is complete. The obvious answers are:
- No, still working - in this case Client would wait some time and will ask again.
- Yes, here is result ID/KEY (or whatever else is needed),
- Error: (unknown ID, missing chunk, corrupted data, invalid format, etc.)
This way it's foolproof. No matter what happens, both sides can reliably identify a subject (transaction id) and its status.
Practically, the only thing needed is that darn transaction ID to be sent back right away, as well as the ability to query against it. The image ID shall be only returned as a part of that query when transaction is complete.
Of course, one can use the image id as the transaction id, return it immediately and then only return the key if it went OK. This way certain ids would never come to fruition and whether SM would like to have those unused ids - it's a design question.
Given my experience with transaction-aware databases, Amazon SQS, MSMQ and other "delivery guaranteed" methods, it looks like it *can* be done, especially considering the fact that SM already utilizes AWS.
But whether it *will* be done - it's a whole different story.
Under certain scenarios originals were downloaded without an extention; X2Large were not downloaded at all.
Fixed.
Pictures | Website | Blog | Twitter | Contact
But you gotta get FIOS...
Remember there are people around here who still have rotary phones - that is no hyperbole.
Pictures | Website | Blog | Twitter | Contact
No. One of the local attractions ... http://www.amishacres.com/
Yes, I chuckle that they have a Internet presence and free WiFi
Pictures | Website | Blog | Twitter | Contact
I have a need for a decent # of these smaller cards. If you have multiple cards that would be great. I am located at zip code 35243 & 35255.
Ok that is what it was, I was selecting them but they were not showing up in upload queue. I have become frustrated with trying to upload some videos via smugmugs uploaders.
I have a need for a decent # of these smaller cards. If you have multiple cards that would be great. I am located at zip code 35243 & 35255.
Now, if the problem you're having is crashing or something of that nature, try a different type of uploader. HTML5 always crashes for me while Simple works fine.
Want faster uploading? Vote for FTP!
Not really crashing just slow and tons of fails. Do you know what types of files its having issues with. I am trying to upload all .mov files from Canon cams.
It does seem in the recent weeks to be video issues. Has SM said anything, or is it there usual default position of, "User error".
I have a need for a decent # of these smaller cards. If you have multiple cards that would be great. I am located at zip code 35243 & 35255.
Are these raw files from the cameras? Have they worked without issues in the past? As far as speed, what type of bandwidth do you have?
Want faster uploading? Vote for FTP!
I have a need for a decent # of these smaller cards. If you have multiple cards that would be great. I am located at zip code 35243 & 35255.
With a 2Mb connection, you should be able to do about 1gb/hr if you're maxed out. Maxing out is the tough part since a single upload will rarely do it. So, realistically you have to look at 1gb/2-3hrs unless you're transferring multiple files simultaneously.
Want faster uploading? Vote for FTP!
I was initially trying SM uploaders and also mistakenly thought that Star Explorer didn't do video (it does, I just needed to change a setting to allow it to). I am now having much better success using Star Explorer. Yeah I am coming close to a 20 hour mark for a little under 20GBs of videos (221 clips) from a wedding. I have about 50GBs from the wedding total (3 seperate cams). Like I said I am new to the video side and I am learning.
Thanks for the info Samir.
I might have a little time to experiment with the settings while on vacation in Washington State but probably not. So I will be somewhat gone for about 3 weeks.
I have a need for a decent # of these smaller cards. If you have multiple cards that would be great. I am located at zip code 35243 & 35255.
I do hope SM will come with "chunked" upload at some point in the future, so if those last few Kb of a 500Mb video do not go through you don't have to redo the whole video and only redo that bad chunk...
Want faster uploading? Vote for FTP!
Smugmug: Bayou Oaks Studio
Blog: Journey to the Light
"Serendipity...the faculty of making happy, unexpected discoveries by accident." .... Horace Walpole, 1754 (perhaps that 'lucky shot' wasn't really luck at all!)
I was out in the Sierras for a few days with no connection whatsoever.
There was (and still is) a warning on my website that no new licenses could be issued during that time...
Truly sorry about that.
Nikolai
Homepage • Popular
JFriend's javascript customizations • Secrets for getting fast answers on Dgrin
Always include a link to your site when posting a question
Thanks. All is well now.
Smugmug: Bayou Oaks Studio
Blog: Journey to the Light
"Serendipity...the faculty of making happy, unexpected discoveries by accident." .... Horace Walpole, 1754 (perhaps that 'lucky shot' wasn't really luck at all!)