Since the latest update a Shortcut I use to retrieve a record by date/name has stopped working.
This was a problem that seemed to have been fixed a few months ago but has returned.
In my case all the record names in this database are formatted yyyymmdd hh:mm and the shortcut looks for the date in the name with an asterisk added at the end.
I just tried doing a search by date name in DTTG and it won’t retrieve the most recent record (today’s record) but it will get records from previous days.
Screenshots:
- You should be using a name: search prefix if you’re seaching by name.
- Have you tried quoting the search string?
The question for me is what has changed in this latest update?
I get the same results with quotes around “20230720” and no difference using name:
More information:
In DDTG it was not finding anything after 20230720, no matter what form the search took (name:, quotes, with/without the * wildcard)
I have been travelling and hadn’t synced (or powered on) DT(3.9.2) on MBP (M2 Max, 13.4.1) since 20230717.
I powered on the MBP and did a sync this morning via Dropbox. Searching in DT works fine but DTTG(3.7.3) on XR (iOS 16.5.1) doesn’t find anything after 20230720.
Quit all apps and cold restarted the MBP. Sync - no change
Force quit DTTG on Xr - restart DTTG - Sync - no change
Force quit DTTG on Xr, shutdown Xr. - restart Xr and DTTG - Sync - search works, even with no name prefix, quotes, or wildcards.
Because I was travelling I know I was on basic data on the 19th and 20th so the most recent update to DTTG wouldn’t have downloaded until at least the 20th. I hope this is helpful.
NB
I know it’s cannon that DTTG and DT are different apps and have different code bases but there is a quirk worth noting regarding the DTTG search bar. On DTTG if there is no space between the colon and the first character of the search term, the search won’t work
As I’ve mentioned recently, there are changes in the next maintenance release affecting search.
I missed that. Good to hear. Thanks
FYI
The recent update hasn’t improved on this search issue.
We aren’t seeing any specific issue like you’re referring to, so it must be specific to your device/databases.
On DEVONthink To Go’s databases screen, select ? > Contact Us to start a support ticket.
This seems to have resolved itself. Searches in the group or from the top level find the most recently created journal within 5 minutes (approx) of it being created.
No difference between “20231021” “name:20231021”.
thanks
Sidenote:
There is an interesting but difficult to catch (on a screen recording) behaviour where immediately after creating a new markdown doc, you can search for it by exact name and it will be in the results right up until you hit enter then it disappears. If you go back and delete a digit form the search term it won’t show up again until you quite the search and re-enter the search term afresh. This is just something I noticed when troubleshooting the shortcut that pulls up todays journal entry based on the naming format yyyyMMdd.
This cropped up again earlier this week.
There’s something I didn’t notice before. The folder where the new .md docs are being created has the wrong number of items in the item count.
yet there are definitely 24 files in that folder.( Yes I counted them, there aren’t any missing)
The 19th is roughly when I noticed the Shortcut not finding the days journal entry.
Does this shed any light on the issue?
Did you create those journal entries via Shortcuts? There’s an issue with DEVONthink To Go 3.7.8 which affects searching for entries created from Shortcuts (a workaround for low-memory conditions in the Files app integration backfiring).
I did create them via Shortcuts.
Is there a way to convert a shortcut created doc to a “normal” one? Other than of course cutting and pasting content from one to the other?
Maybe this is the time to come up with a workaround to pull up the day’s journal that doesn’t involve searching for the date in the name.
Thanks for the response. Let us know when the Apple boffins see fit to fix this.
In the last few years Apple has not increased the 20 MB (yes, MB, not GB) memory limit for file provider extensions. So it is unlikely to see a fix coming from Cupertino. However, the next release of DEVONthink To Go will fix this issue by modifying our workaround.
1 Like
By the way, it’s not a good idea to put colons in a filename. I would suggest you remove them and use an anither approach. Even a space would be better.
3 Likes
I’ll work on a method to replace the old ones with underscore and adjust the way they’re created.
Does this mean any docs created via shortcut while using 3.7.8 would never be searchable? Or just markdown docs? or just searchable by name?
Could you clarify what is actually happening?
I’ve had this problem off and on for a quite a while, it would be good to know how much of my daily workflow I should consider adjusting to allow for Apple’s intransigence.
Documents created with Shortcuts are not findable using a group as a scope. Searching globally or just in a database works. It’s one Internet used property that is not correctly set from the extension but should have been adjusted when you open the app.
The next release sets this property correctly when being used from the intents extension (which can use a whopping 30 MB of RAM) but postpones it when being used from the file provider extension. It also corrects the property of items created with an earlier version.
1 Like
I was hoping that modifying, within DTTG, the names of the shortcut created docs (see underscore issue from above) would change something in the search results but it didn’t.
BUT, changing the shortcut to just searching for the name format from within all databases works.
Good to know.
In all my troubleshooting of this issue I never bothered to consider if the scope of the search would affect the outcome. I mean, why should it? There’s a lesson in here somewhere for making unacknowledged assumptions.
I do find it unusual that how a document is created affects how that same document shows up in searches unrelated to any shortcut. It’s a level of software that is beyond my ken.
To make searches fast, database systems use all kinds of optimizations and store additional variants of properties for fast lookups of otherwise less easily reachable data — like an item’s parents and their parents. This was one of those.
Actually, moving the item created by Shortcut to another group and back should fix the issue.