Originally Posted by udy Thanks for your feedback, Samir! I'm very glad it worked for you! 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.

Originally Posted by SamirD 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.

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!

Originally Posted by udy 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.

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

Have you seen my previous message?

Originally Posted by udy Have you seen my previous message?

About alpha 12?

Originally Posted by SamirD About alpha 12?

Yep

Originally Posted by udy 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.

Originally Posted by udy 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?

Originally Posted by jedi6 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?

Originally Posted by jedi6 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.

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.

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.

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.

Originally Posted by 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.

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?

Originally Posted by 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.

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

Thanks for your input.

Originally Posted by Andy Does / will it work on Macs?

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

Originally Posted by udy 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.

Originally Posted by udy 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.

Originally Posted by SamirD 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.

Originally Posted by SamirD 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.