SmugLoader - manage your SmugMug photos and videos

udy

It seems that the alphas never end.

So the 10th alpha is available, bringing the following new stuff:

• Merged Add Media To Album with the batch upload. Folders, or media files can be added to the queue. This gives the batch upload advantage - history, many concurrent uploads - and ends the life of the Media Upload Dialog;
• Now when the user cancels ALL the downloads, the application removes the files from the history;
• Added new icons for when the batches are not empty. The image below shows the download icon having the red star, which means that there are unfinished downloads. Similar indicator exists for the upload icon. This approach eliminates the message that has been shown before, in the case of downloads.

The merge, and the new icons bring a more streamlined interface.

As usual, any feedback is welcome.

There are maybe 2 more major features I want to add before releasing the first beta. The beta will mark the start of a thorough testing, hopefully with your help.

Enjoy

udy

A new build is available, with a fix for the broken image replacement.

It also adds Global Backprinting setting. This will be the default when the user creates an album (gallery).

jedi6

Os X
It seems to be working fine on OS X Snow Leopard.

A couple of things:
Is there any way to have it go to the next file to upload as soon as it says confirmation? I have it set to 4 uploads at a time and sometimes it will not be uploading anything because they all say confirmation.

I know you are in the process of working on this but so everyone knows that currently I could only find a way to upload to Other, other, other for title, cat, and subcat.
Also after I have added some files to upload I couldn't see a way to queue up more files to upload.

Anyway I am excited about this program and have been looking for something like this for quite a while. Keep up the great work!

udy

jedi6 wrote:

It seems to be working fine on OS X Snow Leopard.

A couple of things:
Is there any way to have it go to the next file to upload as soon as it says confirmation? I have it set to 4 uploads at a time and sometimes it will not be uploading anything because they all say confirmation.

I know you are in the process of working on this but so everyone knows that currently I could only find a way to upload to Other, other, other for title, cat, and subcat.
Also after I have added some files to upload I couldn't see a way to queue up more files to upload.

Anyway I am excited about this program and have been looking for something like this for quite a while. Keep up the great work!

Hello jedi6. It's the first confirmation of it working on OS X. So I thank you for the feedback.

About the confirmation thing, I will think about it, but currently, if you set 15 concurrent uploads, and that's the maximum number of concurrent uploads, and it happens to be so synchronous, as to have them all waiting for confirmation, that's it, because a confirmation is taking place in the corresponding started thread.

I'm not sure what you are trying to say about the "Other, other" stuff. Could you elaborate, please?

Thanks again about the feedback, and I'm waiting for some more.

udy

jedi6 wrote:

It seems to be working fine on OS X Snow Leopard.
Also after I have added some files to upload I couldn't see a way to queue up more files to upload.

What did you mean? Did you try to add files during the upload, or before starting it?

Thanks for you kind words.

SamirD

Wow, seems like I wasn't the only one busy this weekend. Downloading alpha 10...

SamirD

Whoops, make that 11...

SamirD

So here's some feedback.

Adding images to the queue takes quite a bit of time. For about 1700 files it took about 10 minutes on my hp dc5750 xpp, the fastest system I have. Probably comparable to the default SM uploader, but I don't really get why each file needs to be completely read before attempting to upload. (This happens in every uploader--why is that?)

As far as the 15 threads, all I can say is WOW! I have never been able to max out my bandwidth like this before so easily! This upload would normally take just under 2 hours for 7gb. It should finish in just over an hour because all the bandwidth can be used! Too bad I'm going to sleep.

Will test downloads tomorrow. Great work so far! You're already my number one uploader and you're not even into beta yet.

udy

SamirD wrote:

So here's some feedback.

Adding images to the queue takes quite a bit of time. For about 1700 files it took about 10 minutes on my hp dc5750 xpp, the fastest system I have. Probably comparable to the default SM uploader, but I don't really get why each file needs to be completely read before attempting to upload. (This happens in every uploader--why is that?)

As far as the 15 threads, all I can say is WOW! I have never been able to max out my bandwidth like this before so easily! This upload would normally take just under 2 hours for 7gb. It should finish in just over an hour because all the bandwidth can be used! Too bad I'm going to sleep.

Will test downloads tomorrow. Great work so far! You're already my number one uploader and you're not even into beta yet.

Thanks for your feedback, Samir! I'm very glad it worked for you!:D

Regarding the queuing process, I could disable md5sum calculation, which I think adds some goog chunk of time spent, and enable it only when the user wants duplicate verification (which isn't active yet; needs some more work). What do you think? Will you test just adding the images to the queue, if I'll create a private build? If you test, be sure to reset the database, or extract the build's archive's content to another place.

P.S. Also keep in mind the a lot of logging is taking place behind the scene, because it's an alpha. :-)

SamirD

udy wrote:

Thanks for your feedback, Samir! I'm very glad it worked for you!:D

Regarding the queuing process, I could disable md5sum calculation, which I think adds some goog chunk of time spent, and enable it only when the user wants duplicate verification (which isn't active yet; needs some more work). What do you think? Will you test just adding the images to the queue, if I'll create a private build? If you test, be sure to reset the database, or extract the build's archive's content to another place.

P.S. Also keep in mind the a lot of logging is taking place behind the scene, because it's an alpha. :-)

If you want to make a private beta, I'll definitely test it. I haven't found a faster uploader yet.

I actually like that the app is light and portable. I put it on my archive drives and run it directly off there on whichever system the drive is connected to. So far, it's run on xpp, xph, and even xpe (xp embedded). I think the CPU speed makes a big factor in the upload/download speeds (maybe related to the logging you mentioned). My Wyse v90 thin client was super-slow at downloading today even with just 4 threads. AlbumFetcher seems to be having similar speed issues, so it may not be a cpu or coding issue. When I set 15 threads, the Wyse thin client seemed a bit overloaded in trying to handle that many threads, but I'm going to try it again since I didn't have time to actually watch it.

Speaking of number of threads, each time I change the number of threads, I have to close and restart for it to take effect. Not sure what can be done about that. Also, the download directory needs to be re-selected each time because it doesn't remember the 'smugmug' part of the path. Not sure what would happen if you don't select it again. It might work fine. It's probably a bit of a tall order for an alpha release, but I'd love to see keyboard shortcuts for some of the common buttons like Download, Resume, Cancel, etc.

udy

SamirD wrote:

If you want to make a private beta, I'll definitely test it. I haven't found a faster uploader yet.

I actually like that the app is light and portable. I put it on my archive drives and run it directly off there on whichever system the drive is connected to. So far, it's run on xpp, xph, and even xpe (xp embedded). I think the CPU speed makes a big factor in the upload/download speeds (maybe related to the logging you mentioned). My Wyse v90 thin client was super-slow at downloading today even with just 4 threads. AlbumFetcher seems to be having similar speed issues, so it may not be a cpu or coding issue. When I set 15 threads, the Wyse thin client seemed a bit overloaded in trying to handle that many threads, but I'm going to try it again since I didn't have time to actually watch it.

Speaking of number of threads, each time I change the number of threads, I have to close and restart for it to take effect. Not sure what can be done about that. Also, the download directory needs to be re-selected each time because it doesn't remember the 'smugmug' part of the path. Not sure what would happen if you don't select it again. It might work fine. It's probably a bit of a tall order for an alpha release, but I'd love to see keyboard shortcuts for some of the common buttons like Download, Resume, Cancel, etc.

Thanks for the feedback.

I'm aware of the issues you mentioned, and they are in plan to be fixed, or implemented. But they are refinements, so they'll have to wait a bit. You'll have the private build, but I'm not sure how to send it to you. Send me an email, and I'll reply to you with a build attached.

udy

Alpha 12
The 12th alpha of SmugLoader 0.5 is available, and it brings some noticeable fixes, and new features:

• Added paged table on the uploads screen (see the screenshot below). You will notice a label that displays the number of entries on the current page. The paged table will bring with it a host of new features. Being a new feature there is a need for thorough testing. If testing, look for UI freezes, and if it happens, please reproduce the steps;
• And the possibility to hide images comes with it;
• And also a preview, using the operating system's viewer. Thumbnail preview of each image is in plans;
• A change to the max number of uploads (Application settings) is now reflected in the uploads queue;
• Fixed a bug with the downloads path.

Enjoy!

SamirD

udy wrote:

I'm aware of the issues you mentioned, and they are in plan to be fixed, or implemented. But they are refinements, so they'll have to wait a bit.

Good to know. I've sent you a private message on here with my email address.

udy

SamirD wrote:

Good to know. I've sent you a private message on here with my email address.

Have you seen my previous message?

SamirD

udy wrote:

Have you seen my previous message?

About alpha 12?

udy

SamirD wrote:

About alpha 12?

Yep

SamirD

udy wrote:

Yep

Sure did. I have to finish processing this weekend's photos before I can play with uploaders again. But I hope to be finished by this evening.

jedi6

udy wrote:

Hello jedi6. It's the first confirmation of it working on OS X. So I thank you for the feedback.

About the confirmation thing, I will think about it, but currently, if you set 15 concurrent uploads, and that's the maximum number of concurrent uploads, and it happens to be so synchronous, as to have them all waiting for confirmation, that's it, because a confirmation is taking place in the corresponding started thread.

I'm not sure what you are trying to say about the "Other, other" stuff. Could you elaborate, please?

Thanks again about the feedback, and I'm waiting for some more.

The Other, other stuff. What I meant was that I can only seem to upload to Category "Other" Sub-Cat "Other" and title as "Other" Am I doing something wrong? I can't see a way to upload or view where I want to upload files while I'm inside the upload screen. Here is the message I see which warns of this.



This is what I see when I go to upload photos. After I select a folder to upload it adds a submenu item called other under SM Root.



Also is there a way to delete photos from the queue?

udy

jedi6 wrote:

The Other, other stuff. What I meant was that I can only seem to upload to Category "Other" Sub-Cat "Other" and title as "Other" Am I doing something wrong? I can't see a way to upload or view where I want to upload files while I'm inside the upload screen. Here is the message I see which warns of this.

This is what I see when I go to upload photos. After I select a folder to upload it adds a submenu item called other under SM Root.

Have you added a folder that directly contains images? If read the message in the dialog box carefully, it's what happens when you do just that. The folder you add is the root under which your categories reside. If there are images under the root, it is treated as album, without category. Got it?

jedi6 wrote:

Also is there a way to delete photos from the queue?

There will be a way very soon (the next iteration?), since the paged table is in place.

Thanks for your feedback.

udy

Alpha 13
The neverending alphas strike back again with the 13th. This brings:

• Gapless uploads (No waiting until confirmation received, to start the next upload);
• Remove upload from queue.

This build needs serious tests, so go ahead.

Your feedback is welcome.

SamirD

I just tried a 380mb and 960mb upload using alpha 13. I also used 30 threads. I've never seen my modem utilization so high! Even the ones that normally are only hitting 85% were over 90%.

Now to test downloads with 30 threads.

SamirD

Wow. It seems whatever routines are being used for downloading just kill the cpu power. I don't think I even have 30 (I think it's 15), and this computer is almost to a standstill. Yet, this same system could handle 30 uploads no problem.

udy

SamirD wrote:

Wow. It seems whatever routines are being used for downloading just kill the cpu power. I don't think I even have 30 (I think it's 15), and this computer is almost to a standstill. Yet, this same system could handle 30 uploads no problem.

It could be an issue with the download code. It's the first experiment with SmugLoader, and it is differently written. So maybe it needs a rewrite on the grounds the uploader is written. I don't know exactly when it will be.

Was the test done on Wyse?

udy

SamirD wrote:

I just tried a 380mb and 960mb upload using alpha 13. I also used 30 threads. I've never seen my modem utilization so high! Even the ones that normally are only hitting 85% were over 90%.

Now to test downloads with 30 threads.

I'm glad that the upload code worked so well. Have you noticed the new gapless upload?

Thanks for your input.

udy

Andy wrote:

Does / will it work on Macs?

SmugLoader has been tested by one user so far, and it works.

SamirD

udy wrote:

It could be an issue with the download code. It's the first experiment with SmugLoader, and it is differently written. So maybe it needs a rewrite on the grounds the uploader is written. I don't know exactly when it will be.

Was the test done on Wyse?

Both tests were done on the xph system. 1.8ghz celeron and 768mb ram. It handled 30 thread uploads with absolutely no problem.

SamirD

udy wrote:

I'm glad that the upload code worked so well. Have you noticed the new gapless upload?

Thanks for your input.

I noticed it started new uploads while waiting for the previous uploads to confirm before removing them from the queue. I believe that's also what SM's default uploader does, so this will definitely improve speeds.

udy

SamirD wrote:

Both tests were done on the xph system. 1.8ghz celeron and 768mb ram. It handled 30 thread uploads with absolutely no problem.

Thanks.

Then it must be the different approach in the case of downloads. I don't promise that it will be changed for the release of 0.5 (beta is around the corner), but it will certainly be in the alphas of version 1.0

I'm concentrating on some basic synchronization issues for 0.5 before releasing the first beta.

udy

SamirD wrote:

I noticed it started new uploads while waiting for the previous uploads to confirm before removing them from the queue. I believe that's also what SM's default uploader does, so this will definitely improve speeds.

Yes, that's it.

tsk1979

Thanks!
I am on ubuntu, and will be doing some uploading in the second week of April.
I will test out the application during that time!
Thanks!