Nikolai,
I just purchased a copy of star*explorer, but I forgot to input my smugmug account. One problem is that I use two of them. Will I have to purchase two licenses?
Thanks,
Winn
Thank you very much!
Yes, all you have to do is you need is to purchase an extra license (which is only 50% of the full price).
When you do it, please specify both accounts and also specify whether you need two separate license files (in case you are going to use them on different computers) or a single "combined" license, which would allow you to switch between the accounts on any PC.
Just discovered a S*E feature that's somehow in my way while figuring out a new way to presort my pictures, so they appear in a non-alphabetical order in the gallery.
When you drag in some files, S*E seems to sort this list alphabetically instead of leaving the order as it is. This is obsolete in my view, because you can easily do it afterwards with the S*E GUI.
Can you reproduce this and at least make it optional in the next release?
Just discovered a S*E feature that's somehow in my way while figuring out a new way to presort my pictures, so they appear in a non-alphabetical order in the gallery.
When you drag in some files, S*E seems to sort this list alphabetically instead of leaving the order as it is. This is obsolete in my view, because you can easily do it afterwards with the S*E GUI.
Can you reproduce this and at least make it optional in the next release?
Thanks,
Sebastian
It's not possible. Windows drag and drop works as a black box and gives me (an application programmer) absolutely no way to know in which order the files being dropped were originally selected. They always come sorted by name
That's why S*E has a full sleuth of ways to change and fix that order.
As a workaround (which I use sometimes) is simply drop files one by one in the order you want. This way they will acquire proper position in the queue from the very beginning.
It's not possible. Windows drag and drop works as a black box and gives me (an application programmer) absolutely no way to know in which order the files being dropped were originally selected. They always come sorted by name
That's why S*E has a full sleuth of ways to change and fix that order.
As a workaround (which I use sometimes) is simply drop files one by one in the order you want. This way they will acquire proper position in the queue from the very beginning.
Other than that - it's beyond my reach
HTH
But it does seem to work for PS. How did the Adobe guys do it?
I'll have a look around the net and will see if I can dig something up for you.
If you're talking about filebrowser or bridge - then yes, they have total control.
But in windows explorer.. it's a different story :-(
If you find me wrong - I'll be very happy!
No, I dragged some files over from my database (IMatch) directly into PS6. I see that the Windows Explorer doesn't do this, but there the files are sorted by name. In my database there's a sort mode where I can sort the pictures manually to fit my needs (Lighttable). It doesn't matter in which order I selected the pics, but in which order the picturelist is. So when I sort the files in my database after size and drag a couple over to PS they are in exactly the same order.
I can't reproduce this in the Windows Explorer (use it never anyways), but for example TC (written in Delphi) is doing it the same way as IMatch by sorting the drag and drop list after the current sortpreset in TC.
No, I dragged some files over from my database (IMatch) directly into PS6. I see that the Windows Explorer doesn't do this, but there the files are sorted by name. In my database there's a sort mode where I can sort the pictures manually to fit my needs (Lighttable). It doesn't matter in which order I selected the pics, but in which order the picturelist is. So when I sort the files in my database after size and drag a couple over to PS they are in exactly the same order.
I can't reproduce this in the Windows Explorer (use it never anyways), but for example TC (written in Delphi) is doing it the same way as IMatch by sorting the drag and drop list after the current sortpreset in TC.
Hope this clears things up a bit,
Sebastian
The order of the items in a standard issue drag-n-drop message (which S*E uses) is controlled by the source app (in our case - windows explorer). There is also another, more advanced drag-n-drop protocol, called "OLE drag-n-drop", but its implementation and usage is way more complicated (as practically everything with OLE:-).
Sorry, buddy, I guess it's not in the (nearest) stars :-)
The order of the items in a standard issue drag-n-drop message (which S*E uses) is controlled by the source app (in our case - windows explorer). There is also another, more advanced drag-n-drop protocol, called "OLE drag-n-drop", but its implementation and usage is way more complicated (as practically everything with OLE:-).
Sorry, buddy, I guess it's not in the (nearest) stars :-)
Okay, I see your point. The whole thing isn't top priority, but it would be nice to have. It looks that TC is using OLE and so IMatch most certainly does it too.
What about a compromise by adding the possebility to drop listfiles on S*E which just contain the filenames in the desired order?!
From my non-programmers standpoint this should be easy to do? And I'm not asking for a csv-import feature - just a txt files with path+filename.
Okay, I see your point. The whole thing isn't top priority, but it would be nice to have. It looks that TC is using OLE and so IMatch most certainly does it too.
What about a compromise by adding the possebility to drop listfiles on S*E which just contain the filenames in the desired order?!
From my non-programmers standpoint this should be easy to do? And I'm not asking for a csv-import feature - just a txt files with path+filename.
S*E: new version 131 uploaded!
Apart from miscellaneous minor UI improvements, The Big Thing of this version is Image Info download. Now S*E can bring back such image data as:
caption
keywords
file name
original URL
file size
image width
image height
While there are other fields available for download, I reckoned that such data as Serial (number?) of MD5 hash value is not of any utter importance to a business user. (I can always add them later should the need arise..:-)
The primary pushers for this feature were the Pro users who had multiple photographers working for them, each photog uploading his images independently (BTW, I'd like to remind you pros that in this case you need to cover your employees with the extra S*E licenses:): ).
Since SM sales data carry practically no overhead, it was next to impossible for the account holder to analyze the sales information and figure out who sold what, even if the guys used captions (or file names, or keywords) to differentiate their own images from the rest of the site.
Now, with the Image Info download available in S*E since v. 131, this issue will cease to be a logistical nightmare and become a simple database report:-)
The data is downloaded automatically when a pro user saves sales data to the local database.
This action can be also invoked from the main menu, context menus or a toolbar. You can run it against the whole account, a category, a subcategory or a set of albums (including one:-).
The application is smart enough to not waste any time/bandwidth for the images it has processed before, although you can always force S*E to reprocess them again (in cases such as when you know that some data has been changed online outside S*E knowledge).
Once data is downloaded, you can run report off T_IMAGES table with the new fields.
Bad news: this feature is only available for Power and Pro S*E users, and Power license holders can only process one album at a time. But since the SM sales data is available only for SM Pro users anyway (and image meta data is not needed for any other practical purpose besides sales reporting), I figured this should go OK with everybody.
Good news: very soon (hopefully before this Xmas) S*E will be able to download images themselves (also designed as mostly Pro/Power feature) - anything from originals to "tinies", thus implementing Baldy's idea about "SM not being your regular roach hotel:-)"
Mhhhhmmm....sounds gooood. Especially the exporting the URL. This was done before by smugmug exporter, but maybe I manage it this time to merge the info with my photo database. I hope I'll find some time to figure this all out.
Thanks for the update and the corrosponding push for me to get this done!
Sebastian
Is it correct that the 'Update Sync Tree' option form the file menu is already availiable, but doesn't seem to do anything?
Also tried to figure out what the 'Get images' from the context menu is all about. Seems to be pretty dangerous when you don't know what you're doing?! As I see it the function attempts to move all images from the selected gallery to a gallery you have to specify by entering a number. It does so and it seemed to work, but the thing should be really better documentated and properly named.
After finishing moving the target (or was it the source) gallery is opened in the browser immediately. This doesn't make sense as I only moved 2 pictures and when the browser was launched only one had been moved already - imagine this with a standard gallery consisting of 20 pictures at minimum. I would recommend turning this browser launch off for the feature as the user would have to reload anyways. So let him do a double click on his own...this gives smugmug a littlebit more time to do the actual moving and let's the user deceide if he wants to view source or target.
Again - this all looks very promising and I'm looking forward to the image download thing,
Sebastian
Phew...still downloading individual image info...but I guess I made a mistake as I only selected to download imageinfo for files not currently in cache. So the info for all images I uploaded with S*E is not updated, because then it's already in the db? Hopefully I'm wrong.
Another thing - why S*E chews my whole CPU while doing this?? I have 2x 1,4GHz and S*E takes one whole CPU, even when minimized or when in mainscreen-view - isn't that a bit much?! And I thought the connection to SM is the bottleneck - in terms that only one or let's say 10 requests go out a time. How many are you sending at a time? (my connection can handle a lot being 6mbit/s down and 512kbit/s up)
This sounds good, but an absolutely critical element for me is the smugmug image ID. I know it would appear in the original URL, but I would need it all by itself.
But since the SM sales data is available only for SM Pro users anyway (and image meta data is not needed for any other practical purpose besides sales reporting), I figured this should go OK with everybody.
I don't need sales data at all, but I need image meta data to synchronize my image management database with smugmug. That's a pretty practical purpose, at least for me.
I don't need sales data at all, but I need image meta data to synchronize my image management database with smugmug. That's a pretty practical purpose, at least for me.
Don't worry! The imageID has been in S*E's database for some time. When opening the database you get the following fields for every image in the image table:
f_image_id (internal image id of S*E)
f_album_id (internal albumID --> real albumID in album table)
f_image_smid (smugmug imageID)
f_image_name (original path+filename (when uploaded with S*E))
f_time_stamp (date+time when imageinfo was downloaded from SM)
f_file_name (original filename from SM (no matter what you used to upload))
f_caption (image caption)
f_keywords (image keywords)
f_file_size (file size)
f_width (image width)
f_height (image height)
f_url_original ("smugmugID-O.extension", some files have a checksum instead - I don't know why e.g. "21090429-2c5750433d50065834bd4c3283a40539.jpg" ??)
Hope this helps,
Sebastian
EDIT: What I originally also wanted to ask you and therefore the image database-quote: What database you use to organize your photos?
I use iMatch which has a lot of scripting options and a unique way to dynamicly categorize pictures in a tree-form with theoreticly an unlimited amount of categories per picture.
f_album_id (internal albumID --> real albumID in album table)
f_image_smid (smugmug imageID)
f_image_name (original path+filename (when uploaded with S*E))
f_time_stamp : last time the record was updated locally. Same logic applies to this field in all the tables
f_file_name (original filename from SM (no matter what you used to upload))
f_caption (image caption)
f_keywords (image keywords)
f_file_size (file size)
f_width (image width)
f_height (image height)
f_url_original ("smugmugID-O.extension", some files have a checksum instead - I don't know why e.g. "21090429-2c5750433d50065834bd4c3283a40539.jpg" ??) NIK: I guess it's the url for the file that has been uploaded with the new md5-based method. Only the files that were uploaded before that method came to work would have -0 instead of the checksum.
f_url_original ("smugmugID-O.extension", some files have a checksum instead - I don't know why e.g. "21090429-2c5750433d50065834bd4c3283a40539.jpg" ??) NIK: I guess it's the url for the file that has been uploaded with the new md5-based method. Only the files that were uploaded before that method came to work would have -0 instead of the checksum.
Ah, that makes sense. I was confused with the appearing checksum, because you said that you didn't included this in the release.
Sebastian
PS: S*E's still working after 5h...now getting the data for every imageID - this process isn't that CPU intensive anymore.
Is it correct that the 'Update Sync Tree' option form the file menu is already availiable, but doesn't seem to do anything?....
Thanks for the prompt feedback! Allways appreciate your attention!
In this case: man, you need to remove /debug command line parameter - unless you want to step into something not yet tested to work (sideeffects include, but not limited to: hard drive formatting, BSOD, stealing your soul, etc.)
Mhhhhmmm....sounds gooood. Especially the exporting the URL. This was done before by smugmug exporter, but maybe I manage it this time to merge the info with my photo database. I hope I'll find some time to figure this all out.
As I said int he first post, pretty soon you'll be able to get back all the files, both originals and all the scaled down versions. Technically it can be done tonight, but I need a clear UI concept, which may take time...
In this case: man, you need to remove /debug command line parameter - unless you want to step into something not yet tested to work (sideeffects include, but not limited to: hard drive formatting, BSOD, stealing your soul, etc.)
:giggle - - seriously...never used this parameter as far as I know and it's definately not set now! I just started the exe from my desktop link without anything added.
Here's the md5 checksum of my exe version 1.0.0.131 (696.832 bytes):
0db7ea144a3ef757de07226efbb26513 *StarExplorer.exe
I downloaded the starexplorer_100_131.exe file at 12:50am GMT.
Was there a mix-up with your developer version maybe?
Can't restart S*E currently, as the image info still runs, but if it's ready is there anything I can do to figure out what's the matter?
Thanks,
Sebastian
EDIT: I just redownloaded both the full version and the self-extracting exe - both are identical to the one I got. So go on and try it for yourself. Or am I missing something?
Then I guess it's my Eastern Egg then:-).
Don't use them please.
I hope I'll upload the new version (with the file downloads) soon enough, so I would not worry about these two.
Oh, and btw, I will add the bandwidth control on the download, too. There has been one for upload for quite some time already, but now with the more stuff coming this direction S*E would need to control that, too:-)
Then I guess it's my Eastern Egg then:-).
Don't use them please.
[...]
Oh, and btw, I will add the bandwidth control on the download, too. There has been one for upload for quite some time already, but now with the more stuff coming this direction S*E would need to control that, too:-)
Don't need to use them anymore as I already tried everything new as I wrote before.
Yeah bandwith control for download will be definately useful to many people, but definately not for me as the line to Germany isn't that big as I've figured already - I can't remember having more than 20kb/s while using SM, but we'll see - just don't believe it's gonna blow up my 500kb/s
My database is now full of data! Looks good so far. Took me 8 hours for 8700 images in 115 albums.
Haven't tried anything with the database yet - just looked at the tables. Hopefully I'll get some more out of it soon.
I discovered one problem regarding the captions: During my post-processing at one step there's a IPTC-caption added which I don't know where it comes from:
" " (this is the caption without quotes)
At the time I didn't put a caption in IPTC this collection of spaces stayed in it and smugmug has read it into their database, but doesn't show it. Now S*E gets the data too, but it makes something else out of it:
"/string>"
This caption now is in the S*E database for every image that I edited without adding a caption afterwards. Maybe you can fix this. It's not very important, but still a weird behavior - which maybe could turn-up for other combinations as well.
If you need more info on this drop me a note.
Examples can be found here - the whole gallery should have these caption-spaces in IPTC...just have a look at the originals. You can upload one of those to your account and try it for yourself.
Don't need to use them anymore as I already tried everything new as I wrote before.
Yeah bandwith control for download will be definately useful to many people, but definately not for me as the line to Germany isn't that big as I've figured already - I can't remember having more than 20kb/s while using SM, but we'll see - just don't believe it's gonna blow up my 500kb/s
Keep up the great work,
Sebastian
Need to fine-tune it anyway, so I prolly make another release with those fixes, including bw cap, some performance boost for download, etc.
My database is now full of data! Looks good so far. Took me 8 hours for 8700 images in 115 albums.
Thanks for the benchmark!
I'll improve the speed, I forgot a few things:-)
I discovered one problem regarding the captions: During my post-processing at one step there's a IPTC-caption added which I don't know where it comes from:
" " (this is the caption without quotes)
At the time I didn't put a caption in IPTC this collection of spaces stayed in it and smugmug has read it into their database, but doesn't show it. Now S*E gets the data too, but it makes something else out of it:
"/string>"
Interesting..
Can you do me a favor?
Open S*E, turn on ALL the logging options you can, and then force it to read the info off this album.
Then send me the log to support@starexplorer.com
Thanks!
This caption now is in the S*E database for every image that I edited without adding a caption afterwards. Maybe you can fix this. It's not very important, but still a weird behavior - which maybe could turn-up for other combinations as well.
If you need more info on this drop me a note.
For now you can simply use access/sql commands to replace this text everywhere.
If you send me the log I asked above, Ill prolly fix it tonight..
If you send me the log I asked above, Ill prolly fix it tonight..
Send you the log, but I did sent it to your gmail - hope that's not a problem for you. If yes I can resent it to the other one.
I'm not bothered by the wrong entries in the db - it's just a drop in the water, but thanks for the proposal - will try it later. Have some trouble with the new openoffice I installed just now.
Send you the log, but I did sent it to your gmail - hope that's not a problem for you. If yes I can resent it to the other one.
I'm not bothered by the wrong entries in the db - it's just a drop in the water, but thanks for the proposal - will try it later. Have some trouble with the new openoffice I installed just now.
Another thing that just came to my mind. I came across some orphanized entries in the db. Any chance of introducing a cleaning-up function that removes all entries that haven't been updated at a certain point just because the images don't exist anymore?
Should be easy especially for those that haven't been downloaded at all.
Another thing that just came to my mind. I came across some orphanized entries in the db. Any chance of introducing a cleaning-up function that removes all entries that haven't been updated at a certain point just because the images don't exist anymore?
Should be easy especially for those that haven't been downloaded at all.
Sebastian
The whole reason I was cautios about caching image info locally was the high volatility of the latter substance. The only way for me to detect that some image (or album, or a category) is a ghost is to redownload the whole thing from scratch...
And while it's relatively easy up to an album level, with images it can get messy. You just spent 8 hours getting meta info... How often would you like to repeat that procedure just to avoid storing some ghost info...
You see, this is a perception problem. A person deletes/renames/moves an image from SM server and has a perception that S*E (or any similar client-side app) should have no problem to pick up this difference. Unfortunately, it's not that easy. To get an image properties I need to ask server specifically about this image. And if you have dozens of thousands of images - I have to make dozens of thousands of requests.
Of course there are tricks. I can get the list of images per album, and if my local copy does not exist in that list I can assume the image was deleted and remove it from cache. But what if image was not deleted, but simply moved to another location? This means that before deletion I need to get the list of all the images (hours!) and only then make executive decision about deletion/moving.
The whole would be much easier if SM would agree to "surface" its image database at least for readonly, highly purified and non-dangerous actions. But thus far Don's position on this issue was pretty solid "never"..
Therefore, unfortunately, local cache is doomed to get a bit messy along the course of time. But the good news is - if you don't go crazy online with shuffling images, albums and categories left and right, the amount of "ghost data" should be relatively small and shall not affect S*E activity in any way.
And if you do have a major site shuffle it maybe easier simply to drop the local cache and start populating it from scratch...
Thanks for the detailed explanation. Haven't thought about it in detail and also forgot the moving thing.
Let's see what you can get out of your speed optimizations - maybe it'll then only take half of the time to fetch all image data.
Comments
Thank you very much!
Yes, all you have to do is you need is to purchase an extra license (which is only 50% of the full price).
When you do it, please specify both accounts and also specify whether you need two separate license files (in case you are going to use them on different computers) or a single "combined" license, which would allow you to switch between the accounts on any PC.
HTH
When you drag in some files, S*E seems to sort this list alphabetically instead of leaving the order as it is. This is obsolete in my view, because you can easily do it afterwards with the S*E GUI.
Can you reproduce this and at least make it optional in the next release?
Thanks,
Sebastian
SmugMug Support Hero
It's not possible. Windows drag and drop works as a black box and gives me (an application programmer) absolutely no way to know in which order the files being dropped were originally selected. They always come sorted by name
That's why S*E has a full sleuth of ways to change and fix that order.
As a workaround (which I use sometimes) is simply drop files one by one in the order you want. This way they will acquire proper position in the queue from the very beginning.
Other than that - it's beyond my reach
HTH
I'll have a look around the net and will see if I can dig something up for you.
Sebastian
SmugMug Support Hero
If you're talking about filebrowser or bridge - then yes, they have total control.
But in windows explorer..
If you find me wrong - I'll be very happy!
I can't reproduce this in the Windows Explorer (use it never anyways), but for example TC (written in Delphi) is doing it the same way as IMatch by sorting the drag and drop list after the current sortpreset in TC.
Hope this clears things up a bit,
Sebastian
SmugMug Support Hero
The order of the items in a standard issue drag-n-drop message (which S*E uses) is controlled by the source app (in our case - windows explorer). There is also another, more advanced drag-n-drop protocol, called "OLE drag-n-drop", but its implementation and usage is way more complicated (as practically everything with OLE:-).
Sorry, buddy, I guess it's not in the (nearest) stars :-)
What about a compromise by adding the possebility to drop listfiles on S*E which just contain the filenames in the desired order?!
From my non-programmers standpoint this should be easy to do?
Thanks a lot,
Sebastian
SmugMug Support Hero
I see what I can do about it:-)
Apart from miscellaneous minor UI improvements, The Big Thing of this version is Image Info download. Now S*E can bring back such image data as:
- caption
- keywords
- file name
- original URL
- file size
- image width
- image height
While there are other fields available for download, I reckoned that such data as Serial (number?) of MD5 hash value is not of any utter importance to a business user.The primary pushers for this feature were the Pro users who had multiple photographers working for them, each photog uploading his images independently (BTW, I'd like to remind you pros that in this case you need to cover your employees with the extra S*E licenses:): ).
Since SM sales data carry practically no overhead, it was next to impossible for the account holder to analyze the sales information and figure out who sold what, even if the guys used captions (or file names, or keywords) to differentiate their own images from the rest of the site.
Now, with the Image Info download available in S*E since v. 131, this issue will cease to be a logistical nightmare and become a simple database report:-)
The data is downloaded automatically when a pro user saves sales data to the local database.
This action can be also invoked from the main menu, context menus or a toolbar. You can run it against the whole account, a category, a subcategory or a set of albums (including one:-).
The application is smart enough to not waste any time/bandwidth for the images it has processed before, although you can always force S*E to reprocess them again (in cases such as when you know that some data has been changed online outside S*E knowledge).
Once data is downloaded, you can run report off T_IMAGES table with the new fields.
Bad news: this feature is only available for Power and Pro S*E users, and Power license holders can only process one album at a time. But since the SM sales data is available only for SM Pro users anyway (and image meta data is not needed for any other practical purpose besides sales reporting), I figured this should go OK with everybody.
Good news: very soon (hopefully before this Xmas) S*E will be able to download images themselves (also designed as mostly Pro/Power feature) - anything from originals to "tinies", thus implementing Baldy's idea about "SM not being your regular roach hotel:-)"
Stay tuned!
Thanks for the update and the corrosponding push for me to get this done!
Sebastian
SmugMug Support Hero
Also tried to figure out what the 'Get images' from the context menu is all about. Seems to be pretty dangerous when you don't know what you're doing?! As I see it the function attempts to move all images from the selected gallery to a gallery you have to specify by entering a number. It does so and it seemed to work, but the thing should be really better documentated and properly named.
After finishing moving the target (or was it the source) gallery is opened in the browser immediately. This doesn't make sense as I only moved 2 pictures and when the browser was launched only one had been moved already - imagine this with a standard gallery consisting of 20 pictures at minimum. I would recommend turning this browser launch off for the feature as the user would have to reload anyways. So let him do a double click on his own...this gives smugmug a littlebit more time to do the actual moving and let's the user deceide if he wants to view source or target.
Again - this all looks very promising and I'm looking forward to the image download thing,
Sebastian
SmugMug Support Hero
Another thing - why S*E chews my whole CPU while doing this?? I have 2x 1,4GHz and S*E takes one whole CPU, even when minimized or when in mainscreen-view - isn't that a bit much?! And I thought the connection to SM is the bottleneck - in terms that only one or let's say 10 requests go out a time. How many are you sending at a time? (my connection can handle a lot being 6mbit/s down and 512kbit/s up)
Sebastian
SmugMug Support Hero
I'm very glad to hear that you've added this to S*E. Maybe I missed it, but can the data be exported to something like CSV easily?
This sounds good, but an absolutely critical element for me is the smugmug image ID. I know it would appear in the original URL, but I would need it all by itself.
I don't need sales data at all, but I need image meta data to synchronize my image management database with smugmug. That's a pretty practical purpose, at least for me.
- f_image_id (internal image id of S*E)
- f_album_id (internal albumID --> real albumID in album table)
- f_image_smid (smugmug imageID)
- f_image_name (original path+filename (when uploaded with S*E))
- f_time_stamp (date+time when imageinfo was downloaded from SM)
- f_file_name (original filename from SM (no matter what you used to upload))
- f_caption (image caption)
- f_keywords (image keywords)
- f_file_size (file size)
- f_width (image width)
- f_height (image height)
- f_url_original ("smugmugID-O.extension", some files have a checksum instead - I don't know why e.g. "21090429-2c5750433d50065834bd4c3283a40539.jpg" ??)
Hope this helps,Sebastian
EDIT: What I originally also wanted to ask you and therefore the image database-quote: What database you use to organize your photos?
I use iMatch which has a lot of scripting options and a unique way to dynamicly categorize pictures in a tree-form with theoreticly an unlimited amount of categories per picture.
SmugMug Support Hero
NIK: I guess it's the url for the file that has been uploaded with the new md5-based method. Only the files that were uploaded before that method came to work would have -0 instead of the checksum.
Sebastian
PS: S*E's still working after 5h...now getting the data for every imageID - this process isn't that CPU intensive anymore.
SmugMug Support Hero
Thanks for the prompt feedback! Allways appreciate your attention!
In this case: man, you need to remove /debug command line parameter
Cheers!
As I said int he first post, pretty soon you'll be able to get back all the files, both originals and all the scaled down versions. Technically it can be done tonight, but I need a clear UI concept, which may take time...
HTH
Here's the md5 checksum of my exe version 1.0.0.131 (696.832 bytes):
0db7ea144a3ef757de07226efbb26513 *StarExplorer.exe
I downloaded the starexplorer_100_131.exe file at 12:50am GMT.
Was there a mix-up with your developer version maybe?
Can't restart S*E currently, as the image info still runs, but if it's ready is there anything I can do to figure out what's the matter?
Thanks,
Sebastian
EDIT: I just redownloaded both the full version and the self-extracting exe - both are identical to the one I got. So go on and try it for yourself. Or am I missing something?
SmugMug Support Hero
Then I guess it's my Eastern Egg then:-).
Don't use them please.
I hope I'll upload the new version (with the file downloads) soon enough, so I would not worry about these two.
Oh, and btw, I will add the bandwidth control on the download, too. There has been one for upload for quite some time already, but now with the more stuff coming this direction S*E would need to control that, too:-)
Thanks, mate!
Yeah bandwith control for download will be definately useful to many people, but definately not for me as the line to Germany isn't that big as I've figured already - I can't remember having more than 20kb/s while using SM, but we'll see - just don't believe it's gonna blow up my 500kb/s
Keep up the great work,
Sebastian
SmugMug Support Hero
Haven't tried anything with the database yet - just looked at the tables. Hopefully I'll get some more out of it soon.
I discovered one problem regarding the captions: During my post-processing at one step there's a IPTC-caption added which I don't know where it comes from:
" " (this is the caption without quotes)
At the time I didn't put a caption in IPTC this collection of spaces stayed in it and smugmug has read it into their database, but doesn't show it. Now S*E gets the data too, but it makes something else out of it:
"/string>"
This caption now is in the S*E database for every image that I edited without adding a caption afterwards. Maybe you can fix this. It's not very important, but still a weird behavior - which maybe could turn-up for other combinations as well.
If you need more info on this drop me a note.
Examples can be found here - the whole gallery should have these caption-spaces in IPTC...just have a look at the originals. You can upload one of those to your account and try it for yourself.
Sebastian
SmugMug Support Hero
Need to fine-tune it anyway, so I prolly make another release with those fixes, including bw cap, some performance boost for download, etc.
Thanks for the benchmark!
I'll improve the speed, I forgot a few things:-)
Interesting..
Can you do me a favor?
Open S*E, turn on ALL the logging options you can, and then force it to read the info off this album.
Then send me the log to support@starexplorer.com
Thanks!
For now you can simply use access/sql commands to replace this text everywhere.
If you send me the log I asked above, Ill prolly fix it tonight..
Cheers!
I'm not bothered by the wrong entries in the db - it's just a drop in the water, but thanks for the proposal - will try it later. Have some trouble with the new openoffice I installed just now.
Sebastian
SmugMug Support Hero
Good luck with the OpenOffice!
Should be easy especially for those that haven't been downloaded at all.
Sebastian
SmugMug Support Hero
The whole reason I was cautios about caching image info locally was the high volatility of the latter substance. The only way for me to detect that some image (or album, or a category) is a ghost is to redownload the whole thing from scratch...
And while it's relatively easy up to an album level, with images it can get messy. You just spent 8 hours getting meta info... How often would you like to repeat that procedure just to avoid storing some ghost info...
You see, this is a perception problem. A person deletes/renames/moves an image from SM server and has a perception that S*E (or any similar client-side app) should have no problem to pick up this difference. Unfortunately, it's not that easy. To get an image properties I need to ask server specifically about this image. And if you have dozens of thousands of images - I have to make dozens of thousands of requests.
Of course there are tricks. I can get the list of images per album, and if my local copy does not exist in that list I can assume the image was deleted and remove it from cache. But what if image was not deleted, but simply moved to another location? This means that before deletion I need to get the list of all the images (hours!) and only then make executive decision about deletion/moving.
The whole would be much easier if SM would agree to "surface" its image database at least for readonly, highly purified and non-dangerous actions. But thus far Don's position on this issue was pretty solid "never"..
Therefore, unfortunately, local cache is doomed to get a bit messy along the course of time. But the good news is - if you don't go crazy online with shuffling images, albums and categories left and right, the amount of "ghost data" should be relatively small and shall not affect S*E activity in any way.
And if you do have a major site shuffle it maybe easier simply to drop the local cache and start populating it from scratch...
HTH
Let's see what you can get out of your speed optimizations - maybe it'll then only take half of the time to fetch all image data.
Sebastian
SmugMug Support Hero