Originally Posted by udy Anytime I'm awake Can you elaborate on "I wish SL would handle better are errors". Maybe you have some useful ideas, I could use Thanks

I think I was really sleepy when I wrote that, lol. I think what I meant was if SL could detect when a error in transmission occurs, say after a long time without confirmation or an interruption in transfer. Then after a pre-set time, it will check to see if the file exists in the gallery and retry or cancel it accordingly. It would also be nice to have an "always replace" option to always replace the file after checking if the file exists when it has upload problems. I've seen files sometimes get 'stuck' or have other problems on SM's end with retried files or 99% uploaded files that look correct to the uploaders.

Another really great feature that no one currently has is a duplicate remover. It would have two modes, quick and regular. Here's how it would work--a gallery is scanned for files with the same name. If duplicates are found and quick mode is selected, the newer of the two (based on upload date) is deleted. If in regular mode, originals of both files are downloaded and compared before one being deleted. If the compare fails, the user is notified that the files aren't the same.

Originally Posted by udy The 2nd beta of SmugLoader-0.5 is here...

Downloading. I have a batch of 1.3gb I need to upload. This should be a good test.

Originally Posted by SamirD I think I was really sleepy when I wrote that, lol. I think what I meant was if SL could detect when a error in transmission occurs, say after a long time without confirmation or an interruption in transfer. Then after a pre-set time, it will check to see if the file exists in the gallery and retry or cancel it accordingly. It would also be nice to have an "always replace" option to always replace the file after checking if the file exists when it has upload problems. I've seen files sometimes get 'stuck' or have other problems on SM's end with retried files or 99% uploaded files that look correct to the uploaders. Another really great feature that no one currently has is a duplicate remover. It would have two modes, quick and regular. Here's how it would work--a gallery is scanned for files with the same name. If duplicates are found and quick mode is selected, the newer of the two (based on upload date) is deleted. If in regular mode, originals of both files are downloaded and compared before one being deleted. If the compare fails, the user is notified that the files aren't the same.

Well the citation is really abrupt. It sounds better in context.

Thanks for the ideas. I will think about them. Some or all of them will be implemented someday.

I can't promise you they will ALL be implemented in 0.5 though. 0.5 has some targets that are almost achieved. But if you will use SL, it will eventually have all that as is, or in another form.

I can't keep adding new features with 0.5 because it would never come out of beta You can think of 0.5 as the foundation for version 1.0

But keep coming back. The development will never halt :-)

Originally Posted by SamirD Downloading. I have a batch of 1.3gb I need to upload. This should be a good test.

Don't forget to give some feedback with the new browser

Thanks!

Originally Posted by udy Don't forget to give some feedback with the new browser Thanks!

I actually don't use the browser feature at all, so I won't be much help in this area. I just upload and download.

Originally Posted by SamirD I actually don't use the browser feature at all, so I won't be much help in this area. I just upload and download.

If you'll ever need to hide/show, or replace images, that's the place

I replaced the beta-2 archive with one having a few fixes.

As an example, when downloading n files residing in the same gallery (album), but having the same name, now the first file being downloaded keeps its name, the others will have their SmugMug ID appended to their names like this:

<filename>.jpg -> <filename>-<id>.jpg, where <filename> is the name of the file, and <id> is the SmugMug given ID.

Other bug fixes, and internal changes are in place.

Originally Posted by udy If you'll ever need to hide/show, or replace images, that's the place

I'll definitely keep that in mind. I usually do a lot of that processing inside SM, but hiding can be a pain, so I'll give it a try after this weekend.

Originally Posted by udy As an example, when downloading n files residing in the same gallery (album), but having the same name, now the first file being downloaded keeps its name, the others will have their SmugMug ID appended to their names like this: <filename>.jpg -> <filename>-<id>.jpg, where <filename> is the name of the file, and <id> is the SmugMug given ID.

I would suggest making this a user selectable option, something like:
[ ] Overwrite or [ ] Rename files with same name in gallery when downloading

I'm going to ask an unusual question--have you tried SL on win98se or win95?

Being a java based application, I could see it working, but I also know that there may be certain requirements on the version of java as well as possible operating system considerations.

I have to make a decision as to what laptops to take to my out of town event. One of them is a p3 running win95 from the factory. It works on most things, but of course can't run xp applications. I want to know if there's a chance SL will run on it. Otherwise, I may take a thin client and hook it up to the tv in the hotel room.

Originally Posted by SamirD I'm going to ask an unusual question--have you tried SL on win98se or win95? Being a java based application, I could see it working, but I also know that there may be certain requirements on the version of java as well as possible operating system considerations. I have to make a decision as to what laptops to take to my out of town event. One of them is a p3 running win95 from the factory. It works on most things, but of course can't run xp applications. I want to know if there's a chance SL will run on it. Otherwise, I may take a thin client and hook it up to the tv in the hotel room.

You can find below the relevant page for Java version 6:
http://java.sun.com/javase/6/webnote...gurations.html

As you can see, the supported Windows versions are 7/XP/Vista/2000/2003/2008.

If I would have a Win 98, I would give it a try, but I think I wouldn't go back to Win95.

I hope it helps.

Originally Posted by BeachBill I would suggest making this a user selectable option, something like: [ ] Overwrite or [ ] Rename files with same name in gallery when downloading

I don't know if that is the appropriate solution. Think about 2 different photos landed in the same album, but having the same name. The user uploaded those 2 knowing that SmugMug wouldn't overwrite. The application should at least try to detect if the files are really duplicates (same MD5Sum?), before overwriting.

How would you decide which file is to be kept from n files with the same name?

I have chosen to play on the safe side. But I'll think about it.

If you have any other ideas, please put them here.

Thanks

Originally Posted by udy You can find below the relevant page for Java version 6: http://java.sun.com/javase/6/webnote...gurations.html As you can see, the supported Windows versions are 7/XP/Vista/2000/2003/2008. If I would have a Win 98, I would give it a try, but I think I wouldn't go back to Win95. I hope it helps.

Thank you very much for the feedback. The hotel I'm at doesn't have high speed Internet (it's only about 800k), so I'm just going to take a second system for backup only. I'll probably actually use the built-in SM uploader since it should max out the bandwidth no problem.

I replaced the beta-2 archive again, with some bug fixes, mainly about UI scenarios. Some of them could give the user some trouble , like unexpectedly stopping actions.

The home page of SmugLoader has moved to http://sl.bulcu.ro

I've just uploaded the 3rd beta of SmugLoader-0.5.

Here are the changes:

• I decided to modify the upload procedure, in order to avoid scanning for files twice. Now the user can't set the albums privacy until a scan of the files will have been done. Here are the steps:
  1. Add root directories (collections) to be scanned. The new entries in the list of directories will be displayed in red, indicating that they have to be scanned.
  2. Scan the root directories. The user can repeat 1-2. As soon as the scan finishes, the red entries are painted back in black (usually, but it's system dependent);
  3. Change albums privacy;
  4. Change files privacy, or remove some of them from the upload list;
  5. Initiate the upload process, by clicking the Upload button. Before the upload itself begins, the structure of categories/subcategories/albums is created.
• The application will check every 10 seconds (subject to parametrization, in future build) to see if there are failed uploads, and will try to upload them again. There is no limit to how many times will try that;
• There were certain situations (errors during upload, etc) in which the upload queue was not using the number of concurrent threads set by the user. Tried to cover most of the scenarios.
• Deleting of entire custom category, with its subcategories, and albums now hopefully works;
• Fixed some issues with scenarios involving the Anonymous access, in alternation with the normal access;
• Fixed the Empty SmugMug account action. Although I've never tried it out, I reinspected the code, and found a bug.
• Other fixes.

Known issues:

• There could be the situation when the network connection goes down, and some responses don't arrive to the application. The files could be on the server, but the application doesn't know that. Or in the same situation, the structure of categories, subcategories, and albums would not be completely created. These 2 issues can be solved by restarting the application, which will detect the troubled uploads, and take some measures (re-upload files if you want; complete the structure creation automatically)

Due to the changes I made to the upload process, there might be other bugs I haven't found yet. As always, your input is welcome.

There might be necessary to squeeze in one more beta, before the first release candidate of SmugLoader 0.5

I hope you'll enjoy this release.

Originally Posted by udy I've just uploaded the 3rd beta of SmugLoader-0.5.

Just in time! I just got home and am very sleepy. Will set up an upload session using beta 3 and then go to sleep.

Originally Posted by SamirD Just in time! I just got home and am very sleepy. Will set up an upload session using beta 3 and then go to sleep.

Keep me posted, please.

Originally Posted by udy Keep me posted, please.

I used 30 upload streams and it uploaded everything except two files. I used the standard SM uploader web uploader to finish the upload, but somehow there's a duplicate file because one of the files that didn't transfer was a 800mb video that shouldn't transfer. The number of images in the gallery is one more than it should be.

Originally Posted by SamirD I used 30 upload streams and it uploaded everything except two files. I used the standard SM uploader web uploader to finish the upload, but somehow there's a duplicate file because one of the files that didn't transfer was a 800mb video that shouldn't transfer. The number of images in the gallery is one more than it should be.

OK. Here are some questions:

1. Is the other file (smaller), that didn't transfer, the duplicated one? I ask you this because it could be one of the known issues I wrote about (Have you read the known issues section?).
2. Can you tell me what was the status of the smaller file?
3. If you used the SM uploader, did you select the check for duplicates option?
4. Have you tried to re-upload the failed one using SL?

I didn't announce duplicate detection in SmugLoader. :-P

I can't do anything unless I have detailed information about such situations.

Thanks.