Script command to remove off-line files wanted.

[ubacher]

There should be a way to remove off-line (no longer existing on disk) files via a script command.

database.rescan does not do that.
It seems only a manual rescan does the removal.
That was no issue while I was doing manual indexing. Now I switched to automatic background indexing
and this nuisance (requiring a manual rescan anyway to remove off-line files) came up.

[Mario]

Off-line files only happen when you delete or rename files outside of IMatch. Or when you take a media off-line for a reason.

IMatch does not remove off-line files during a normal rescan (or a script rescan) for safety reasons. If a file/folder has been accidentally renamed/moved, it can be renamed/moved back or the relocate command can be used to fix the issue. Both ways avoid data loss.

I understand you need such a command for your scripts, but I don't see that many users will ever need such a function.
We'll let this sit here for a while and see how many votes it gets.

[ubacher]

Well - if you are concerned about accidentally deleting offline files:
If I do manual indexing it does remove them no question asked.
It is up to me to make sure I (re-)load the right folder.

Background: When running Camera Raw in photoshop one can delete files.
Since IM does not know about these deletes it marks them as off-line.
After the background indexing loads the newly generated files I have to manually
do a rescan to remove these files from the db. Since I run a script at this time anyway
it would be convenient to do this rescan from within the script.
It would be quite safe since the script has to specify the exact file name on the RESCAN command.
Also: The script can check first if a file is off-line and so assure it does not remove a file
accidentally.
My feature request is then:

The database.rescan command should also remove off-line files like a manual rescan.

[Carlo Didier]

+1

[JohnZeman]

-1
I would not want offline files to be removed during a database rescan.  For example if I have an external hard drive full of files contained in my database but that external hard drive isn't connected some of the time an inadvertent rescan with the external hard drive disconnected would remove all those files from my database.

Now a script to remove offline files might be ok.  Maybe some day when I have a little time I'll write a script that'll remove offline files, or more likely to assign them to a collection so I could manually remove offline files as needed.

[ubacher]

John says:

....r more likely to assign them to a collection so I could manually remove offline files as needed.

No need to do that - it is easy to see all the off-line files. It is the removing that is difficult:
You can not right-click and do a remove from database. That works for off-line folders but not for offline files.
( I'll put in a feature request for that)

To remove the files you have to go to each files folder and do a manual rescan of the folder. A pain if the files are spread
over many folders. Because of this I try to delete these files by doing a manual rescan soon after the files have been deleted.

The danger with accidentally deleting files which are merely off-line, from the db would actually be much less with a script - because
the script could do various "sanity" checks, prompt if uncertain etc.

( This came up because I do already run a script to do some tidying up and I wanted to do this removal at the same time.)

I don't understand why automatic removal on automatic rescan was never an issue with IM3.

[JohnZeman]

Erich I have to admit I've never tried to select some offline files assigned to a collection that are located in different folders.  Then to right click > Additional Functions > Remove files from Database but I know that works for online files.

A script sounds more practical to me then because as you say you could fine tune it for your own needs.

In regards to IM3 IM5 lives in a different world now.  A world where drives can appear and disappear on a regular basis.  Hard drives, flash drives, external hard drives, cloud services, DVDs, etc.  A rescan done while any of those drives are not present could have some unwanted results if that rescan removed offline files.

[ubacher]

I have to correct myself: right click->additional functions->remove file from database does work.

(Not sure why I had the impression that was grayed out for files - maybe under certain conditions only.)

[Mario]

(Not sure why I had the impression that was grayed out for files - maybe under certain conditions only.)

This command is always enabled, unless the database is read-only.

[Mario]

I have added the RemoveFile and RemoveFiles methods to the Database class. These methods allow you to remove files and all associated data from the database, but to keep the physical file on disk. These methods can also be used to remove off-line files from a within a script.

Release 5.3.16.

[Carlo Didier]

I have added the RemoveFile and RemoveFiles methods to the Database class. These methods allow you to remove files and all associated data from the database, but to keep the physical file on disk. These methods can also be used to remove off-line files from a within a script.

Release 5.3.16.

Great! I was badly missing that functionality! 

[ubacher]

Thank you. Much appreciated.
Imatch is very flexible but of course can not handle all possible user scenarios.
Users who can handle a bit of scripting can however customize Imatch to meet their needs exactly.
As we do this we encounter the occasional missing functionality in scripting - but thanks to Mario's
quick response - this is quickly solved!!!!!!

[Mario]

The problem with Basic scripting is: I would rather like move away from it, replace it.

The WinWrap basic engine is the most expensive part in IMatch these days. The annual license for it costs more than all my other developer tools + a professional Microsoft Developer Network subscription (which includes all development tools + all Windows licenses for testing + server licenses + Azure and whatnot). And when I one day migrate IMatch 5 to 64-Bit, the WinWrap engine needs to be upgraded. Which costs an upfront of about 5 annual licenses + the annual license. Several hundred licenses of IMatch have to be sold to cover that alone.

I evaluated several alternatives (e.g. Lua, Python) during the development of IMatch 5, but all free programming languages had no usable editor / development environment / debugger that I could include in IMatch in the way I have included the WinWrap Basic engine. The JavaScript/HTML App concept, which is rather unique and powerful, will get more attention by me in the future than the Basic programming language. It's not only more future proof than Basic, but also more powerful. All that's missing is an IDE. If Microsoft would finally allow the WebBrowser control to open the same developer environment as we have in the "real" IE, we would have everything that's needed. A debugger, editor combination which can be used to create, edit and debug JavaScript Apps in IMatch. That would be a thing...

[sinus]

The problem with Basic scripting is: I would rather like move away from it, replace it.

The WinWrap basic engine is the most expensive part in IMatch these days.

I love this Basic. Like ubacher wrote, a user who can a bit of scripting, can mostly solve his problem with scripting, if IMatch does not has a native solution.

I would pay also more for IMatch, since your program is not very expensive. But you must of course know, how important the money is.

Like: would you loose a lot of users, if you would make IM 10 or even 20 Dollars more expensive?
I personally can only say, I distinguish programs, if they are free of costs or if I have to pay.

If the program is good, and I want use it, it is for me not that important, if it costs 100 Dollar or 120 Dollars.

When I can afford it, I will buy it.
But if I do not need a program really, then I will not buy it (that is why I do not look after a program for bring my images from the cam into IMatch).

I think, the idea with two prices, IMatch with or with the scripting-possibilities is too complicated?

[Mario]

I agree. The comfort we get from the WinWrap Basic is very good. The edit is a bit aged by now, but still a comfortable and capable development environment.
There is currently no alternative. Most of the work, however, is done by the IMatch object model I have developed. And that can also be used by other programming languages. So I keep all my options open. I doubt that many users write scripts, but many use scripts written by me or others. For these 'user-users' the programming environment or language does not matter. They just run the script or the App.

Like: would you loose a lot of users, if you would make IM 10 or even 20 Dollars more expensive?

That's always a tricky point.
The product price for IMatch has to cover the cost for development, support, licenses, royalties, annual fees, server fees and all the time I donate to it. 9,000 posts since June 2014. 30 to 50 emails per day. About 40 updates shipped to my users. Countless hours of development. It's fun, true. But making a few bucks adds to the fun and allows me to continue support and development for the years to come.

Adobe now charges about 142€ (155 US$) per year (in Germany) for Photoshop/LR if you do the annual pre-paid plan. The software stops working when you don't pay anymore.

'Competing' DAM vendors with feature sets near to IMatch like Canto, FotoWare, Extensis either start at several hundred US$ for a single license (plus annual maintenance fees) or don't list prices at all (a consultant comes to your site to discuss things with you).

I agree with you that when I use a software and it helps me to achieve things or save time and effort, it is not important if it costs 20$ less or more. But many people shop by price tag out there, and even raising the price for IMatch from 69,99 (3) to 109,99 (5) (the first raise since 2006!) has generated quite some waves.

Just today I received an email from a user who asked for a discount to the 40% discount he already gets because he purchased IMatch 3.6 in 2008... I tried to explain why IMatch costs what it costs, and gave him some tips on how to find alternatives if he is really unable or unwilling to pay the upgrade fee.

I think that IMatch is reasonably priced (like that special car).
And Is also think that spending, say, 4-5 bucks a month on a software you use daily and for which you get real support is fair (assuming one paid upgrade of IMatch per year, at an assumed price of 50-60$).

I think that I give above average support by email and here in the community. And it's free. You don't even have to endure advertisements and neither do I sell your customer data and emails to make some extra money. Free support directly from the developer. If a dangerous bug is found, even overnight shipments of new releases. No holding back of new features until a new paid version is released (many other vendors do that to increase the pressure to buy the new upgrade).

And just look at the built-in help you get with IMatch! I've spent months writing all that information.
I'm always baffled at what other vendors get away with calling "help system". Often they explain just what you see for yourself on the screen. Like somebody has written the help by looking at the dialogs and describing what he/she saw - without any deeper knowledge of the product itself. Which is actually often the case, because help production is done by the cheapest external provider.

[sinus]

I think, the idea with two prices, IMatch with or with the scripting-possibilities is too complicated?

Thanks, Mario, for your extended point of view on this price-things.

To offer IMatch with and without the Scriptings-possibilities is not an alternative (means with two different prices)?

[Ger]

Thanks Mario for your insight on the scripting environment. When reading, I had the same thought as Sinus: would it be a solution to have a standard version without scripting possibilities and to have an advanced version (at 10 or 20 USD/EUR or so higher price) with the scripting capabilities?

On the WinWrap IDE: does somebody have some tips or links on how to customize the editor (font, tab setting etc)?

[Mario]

To offer IMatch with and without the Scriptings-possibilities is not an alternative (means with two different prices)?

This would mean rewriting several of the Import & Export modules which are based on scripts.
It would complicate support & distribution.
Always easier to have one price (with rebates for multi-license purchases).

I think that maybe 1 out of 200 users would buy the scripting edition - which would require a fairly high price tag.
Won't work.

If I decide to make a 64-Bit version of IMatch (which is not really needed, except for the few users who work with panorama files with tens of thousands of pixels in each dimension) I will bite the bullet and buy the 64-Bit version of WinWrap. The annual license fees are about the same as for the current version, only the big up-front payment is setting me back. And the potential of subtle bugs which may be introduced by switching to another product.

[Ger]

Mario,
I understand the additional work, but:

...maybe 1 out of 200 users would buy the scripting edition...

Are you serious? I have to admit that IM5 offers way more than IM3, but to accomodate workflow or specific things, the option of writing a dedicated script is quite valuable.

Could it be a poll in this forum? I would definitely be willing to pay a fee for the scripting engine.

Ger

[Mario]

I have no intentions to remove the scripting engine, not without an adequate replacement. I'm already saving up for the annual license payment, as it is.

1/200 is something that I said from experience, judging the number of script-related support emails and posts in the old user forum and here. Maybe it's 1/100, still not sufficient to make splitting versions, adding all the "no scripting" code to a script-free edition. Way too much work. Better have one version with scripting.

[Ferdinand]

There's a lot less need for scripting, but there are quite a few of us here that still have workflow scripts and other miscellaneous scripting odds and ends.

I dread the day when basic is dropped, and although it's probably some way off, I have no doubt it will arrive someday.  After all, IMatch 5 seemed a long way off for a long time and now it's here and we've all forgotten 3.6, even Markus.    I imagine we will grumble and then adapt.  But let's keep it a long way off for the time being.

[sinus]

After all, IMatch 5 seemed a long way off for a long time and now it's here and we've all forgotten 3.6, even Markus.     

Ferdinand, you are perfectly right!