Hazel not matching some rules -- Mojave and ScanSnap Home

Get help. Get answers. Let others lend you a hand.

Moderator: Mr_Noodle

This problem appears limited to Hazel on Mojave (running 10.14.2 beta, but also a problem with 10.14.1) and the ScanSnap Home software. The rule has the condition "Kind is Image" and the file is a jpeg created by the ScanSnap scanner. The rule fails to match unless I do something with the file first, like opening it with Preview. If I just leave the file in the folder it never gets processed by Hazel correctly (matching "Kind is Image") even if I force rescanning. Jpegs from other sources placed in the folder get seen by Hazel just fine. Note that if I use the Spotlight search in Finder for Kind:Image it sees the file.

I'm seeing other rules fail to match correctly, at random with this software/scanner combination as well, but the Image problem is consistent.
tomalmy
 
Posts: 7
Joined: Thu Nov 01, 2018 9:17 pm

If you select the file in Finder and do "Get Info", what is the "Kind" listed there? Also, are you comfortable running Terminal commands?
Mr_Noodle
Site Admin
 
Posts: 11196
Joined: Sun Sep 03, 2006 1:30 am
Location: New York City

In Get Info Kind is listed as "JPEG image". Yes I'm comfortable with Terminal.

In the Hazel rule if I change "Kind is Image" to "Kind is JPEG image" it matches! So for some reason a JPEG image is not seen as an Image? This is suspiciously looking like a bug in Mojave!
tomalmy
 
Posts: 7
Joined: Thu Nov 01, 2018 9:17 pm

That categorizations are provided by the OS as well as by any apps that handle those files. Try the 'mdls' command on the file and post the output.
Mr_Noodle
Site Admin
 
Posts: 11196
Joined: Sun Sep 03, 2006 1:30 am
Location: New York City

Code: Select all
 mdls 2018_03_18_HOME\ DEPOT.jpg
kMDItemFSContentChangeDate = (null)
kMDItemFSCreationDate      = (null)
kMDItemFSCreatorCode       = ""
kMDItemFSFinderFlags       = (null)
kMDItemFSHasCustomIcon     = (null)
kMDItemFSInvisible         = 0
kMDItemFSIsExtensionHidden = (null)
kMDItemFSIsStationery      = (null)
kMDItemFSLabel             = (null)
kMDItemFSName              = (null)
kMDItemFSNodeCount         = (null)
kMDItemFSOwnerGroupID      = (null)
kMDItemFSOwnerUserID       = (null)
kMDItemFSSize              = (null)
kMDItemFSTypeCode          = ""
tom9:SCAN tom$


So no information! I also see matches on content failing, possibly because Hazel can't look into a PDF file if it doesn't know it's a PDF?? Opening the file with preview and the fields populate and then Hazel will find a match. Now it looks like I need to blame Fujitsu.

============

Problem solved! And it is Fujitsu, but it can certainly affect anyone with a ScanSnap and ScanSnap Home software using Hazel to refile scanned documents. If the scan save destination folder is set to be anything other than the ScanSnap Home folder then the metadata is not saved. If it is desired to save to another folder, you still have to save to the ScanSnap Home folder, but then run the application "Verify and save" and set the destination from there.

Sorry for cluttering the Noodlesoft forum with a Fujitsu bug, but there is probably a good chance anyone else with this issue will check for solutions here.
tomalmy
 
Posts: 7
Joined: Thu Nov 01, 2018 9:17 pm

It's a Spotlight issue but maybe Fujitsu is exacerbating it. I'm not sure what the "Verify and save" function does, but you may also want to test whether there are issues with other apps saving to those folders.
Mr_Noodle
Site Admin
 
Posts: 11196
Joined: Sun Sep 03, 2006 1:30 am
Location: New York City

The issue only occurs with the new ScanSnap Home software, and as I said only if I try to set another destination folder other than the one treated as "ScanSnap Home". The Verify and Save option will cause a window to pop up where the scanned file can be viewed and a final destination selected, in a manner much like what the old ScanSnap Manager software used to do.

So as far as I'm concerned, only Fujitsu is to blame on this.
tomalmy
 
Posts: 7
Joined: Thu Nov 01, 2018 9:17 pm

I wrote before and still have difficulty with Hazel running on pdf scans, I had it set to a dropbox folder, which Hazel works sporadic on, changed it to Scansnap, then scansnap home and had same problem. I ended up running scan to searchable pdf, instead of save to folder and it works every time, it prolongs scanning and sometimes have to close the dialog box. Any suggestions? I think I'm going to try Vuescan, the Milo forum seems to give it rave reviews if it'll work with Mojave.
sdbarnes
 
Posts: 3
Joined: Wed Jul 20, 2016 6:13 pm

I was also having some difficulty with scansnap scanner and software after moving to Mojave. One problem was ordering of pages on a multipage scan. Since my software was quite old I looked into updating it and am now running Scansnap Home. It is overboard, in my opinion, on the managing of scans, but it does seem to have fixed my ordering problem. The one problem that I was struggling with is quality of the OCR when you just select for it to create a searchable PDF.

The original software seemed to use ABBYY in doing this function, but it seems that now if you want the ABBYY quality you need to send the scan to the ABBYY application to create a searchable PDF. After doing that as has been mentioned, my Hazel rules have no problem with matching. It is a bit annoying that there is a dialog box that comes up with warnings about small text, etc, but I can put up with that.
ddjurgensen
 
Posts: 1
Joined: Sun Dec 30, 2018 12:43 pm


Return to Support