PDF Loader message after search?

A project searchs generally takes quite long, 10, 20 seconds or so. Why is that?

And at the end this is shown:

What does that mean? How could one do a usual search?

I’ve run into this before with password protected PDF files, but I suppose any kind of error that might cause a PDF to fail in text extraction (which would be needed for searching) could cause this.

You’re best bet is to go through your PDFs one by one and look for any errors like this. Once you find it, you’ll probably want to export and remove it (fully, with an emptied trash).

There does seem to be an issue where PDF files are being indexed too often. In theory that should only happen when they are first imported, and then never again unless you run the command to rebuild the index, or some activity necessitates doing so (like syncing with the iOS version).

Many thanks.

I do not have any passwords for PDFs.

You’re best bet is to go through your PDFs one by one and look for any errors like this.

Sorry, what errors? Going through all of my PDFs would be an extremely big effort / impossible, I guess.

There does seem to be an issue where PDF files are being indexed too often. In theory that should only happen when they are first imported, and then never again unless you run the command to rebuild the index, or some activity necessitates doing so (like syncing with the iOS version).

OK, so what do I have to do against it? Rebuild the index once? Making Scrivener not to do too often? How?

Yeah, one of the suggestions I made to them is that when the search process throws a PDF error it states the name of the item in the dialogue box. It’s kind of useless without that information.

Sorry, what errors? Going through all of my PDFs would be an extremely big effort / impossible, I guess.

Sure, it’s a choice then between living with this dialogue box and doing that. Or waiting for them to fix how searching can sometimes cause PDFs to be opened and scanned.

As for avoiding, it, as I say it’s a bug that it is scanning PDF content like this in the first place. I don’t think there is any way for you to stop the bug from happening, if that’s what you’re asking.

Yeah, one of the suggestions I made to them

To the programmers / people here making / selling Scrivener?

OK, actually I would not think there is a (real) choice but to live (or not) with that fancy dialogue box. So it means, I assume, the appearing of one error box shows the content of one (not more) pdf file is not serached, two boxes for two pdf files not being searched, etc.

So then I assume, there also is no option to not let Scrivner serch for content in PDFs.

Yup, there is a ticket for this and a few other issues with PDF indexing that has been filed with them.

So then I assume, there also is no option to not let Scrivner serch for content in PDFs.

There isn’t—because if everything was working correctly it wouldn’t really be a thing that anyone notices, and for the most part being able to find text in PDFs is something not many people would want to do without.

Sorry it’s a bit of a hassle right now.

No no, no reason to say sorry at all.

Thank you very much.

This is probably not it, but fwiw…

Is there any chance that the pdf is opened in another application? Perhaps one that did not exit correctly and that doesn’t appear to be running, but that is still holding on to the pdf file? Kind of a zombie process, findable in Task Manager or Process Explorer/Hacker?

I get the PDF Loader error before I’ve even started a search (and don’t have any password-protected PDFs, FWIW).

From my other post (now locked), secondary Qs around Project search:
–Is there any way to just have the Project search bar open all the time, the way it was in Scrivener 1 (over on the right side)? As is now, every work session, I have to reopen the Project search, with the attendant 5 error messages and hanging.

–Assigned keyboard shortcuts (Ctrl+G, Ctrl+S) for Project search don’t work. (They don’t even trigger the whole PDF Loader error.) Why would that be?

Thanks.

It was recently noticed that that was an omission on their part. There definitely should be an option to add a persistent search field to the toolbar if you so wish. That said so long as you don’t actually close the search field over the binder, it should stick during the course of a session.

I get the PDF Loader error before I’ve even started a search (and don’t have any password-protected PDFs, FWIW).

Yes, from what I have observed, PDFs are scanned even when just loading a project, and there may be other scenarios as well. I’ve bumped the priority on this ticket. Hopefully it is something they can look into for the next update. It’s a big liability in my opinion, to have anonymous error messages flying up frequently like this, and discourages one from using Scrivener to store PDFs.

Assigned keyboard shortcuts (Ctrl+G, Ctrl+S) for Project search don’t work. (They don’t even trigger the whole PDF Loader error.) Why would that be?

Not sure! I use a different shortcut (Ctrl+Shift+F) but it works fine for me. Maybe try changing it to something else in the Keyboard settings pane, and then back to what you prefer?

This is a combo shortcut, rather than two different options for shortcuts; could that be the confusion? To execute it, you should press and hold the Ctrl key, then press and release G, then press and release S, then release the Ctrl.

Ctrl+Shift+F opens Project search for me… I think that is the default.

I have found that combo shortcuts, such as [Ctrl+G, Ctrl+S] (though not necessarily that particular one), are still occasionally mentioned in the S3 manual, but that they do not actually work. Nor does it seem possible to assign these combo shortcuts with the S3 kb. But I recall them being quite common (and useful) in Scrivener 1.

Those kinds of chorded shortcuts have been phased out, since they are very unorthodox on Windows. I do like them, personally, because you can do so much more with them, but it seems they’ve tried to do more with the Win key this time around, to get a little extra out of the possible permutations, than the double-stroke method.

I think you can still set those, but it looks like you have to type it in yourself into the field, rather than “capturing” it. I just tried binding “Ctrl+G, Ctrl+S” to showing/hiding the toolbar, and it worked fine.

hmmm you’re right! If you type them in letter by letter, rather than “capturing” as live commands, they seem to work just fine. I should have tried that myself!

I like those “chorded” or “combo” short cuts too. I believe I’d seen them on Windows before Scrivener, but don’t quite recall where. As you say, they’re not too common.

And the Win key is pretty cool, too!

And so is AHK… but that’s a whole nother thing altogether. :upside_down_face:

A very good thought, but it is very unlikely. I will look for it the next time anyway. Thank you.

FWIW (not much), I’d never store a pdf in Scrivener in the first place. I’d bookmark a link to it. Ditto for anything larger than a breadbox. I Compile $img external images and do my research in Notion or Evernote. I don’t get why putting tons of research inside a project is a good idea given the sync issues, etc, users tend to have.

I totally agree with you on that, @drmajorbob.

I brought a pdf into a project for the first time yesterday, and wasn’t certain how it would be handled. It was nice being able to see it inside the project, but not at the cost of carrying the full weight of the pdf file in the project. For actually accessing the pdf, using a link to an “external” file isn’t much less direct than having the pdf itself in the binder, and you get to view it in a dedicated window, which would often be preferable.

But (I hope this isn’t too off topic) referencing files located outside of the project’s .scriv folders does raise questions around how to manage the greater “project” to which the .scriv structure itself belongs. Similar questions come up around sync folders, and how to organize them on the drive so they are related to yet fully separate from the .scriv system. Backup locations are another appendage of the beast, or beasts, as they do seem to multiply. But there shouldn’t be any need to access the .scriv folders once you create shortcuts to the scrivx file, or open projects from inside the program. So .scriv folders can be more off the beaten path than other things, even though they run the whole show. Or that’s what seems to be taking shape for me.

This is all rather off topic, but my thought is that it is certainly a matter of taste, and I wouldn’t wish to downplay anyone’s benefits for having research right within the same interface as everything else you’re working on. Juggling specialist software windows has its benefits, but is also obviously less elegant than a tool that allows you to page up/down the PDF in an automatically scaled split to the right of your editor, while you write.

And that’s not even getting into the shared metadata pool, ability to outline around them (for example storing your notes as an outline, potentially fleshed out with text) collapsed beneath the PDF node in the binder, et cetera et cetera. Scrivener’s freeform outline model, which works no matter what the resource is at the file level, is a really interesting and fairly unique approach to organising materials. In what other tool can you take an excerpt of 5 pages from some documentation that you tend to look up frequently, and import it as a sub-document beneath the PDF?

Setting aside that not everyone uses sync, I’ve never seen a direct correlation between storing research in a project and sync issues. What sync issues are we talking about? 99% of sync-related problems have to do with colliding edits between systems, which isn’t generally going to be a problem with PDF–and is a problem that extends to all software and file usage.

It’s certainly not unique to Scrivener, or whether a directory structure is used to store data with PDF binary blobs somewhere within it. If one’s sync service is going to struggle with having PDF files in folders, then it’s probably best to look for some other vendors!

Now as to that specifically, I don’t feel that is a major pro or con to either approach thanks to one feature: so long as cross-platform isn’t an issue, then go for shortcuts. You can drag them straight into the binder if you want (I think), but there is also a convenience command in File ▸ Import that makes shortcuts for you. No need to store the PDF or any other heavy-weight research inside the project, in order to gain all of the benefits listed above.

The downside of course is that one’s research and writing materials are more machine dependent, as shortcuts and such tend not to survive trips between systems.

While on the one hand not having static documents like PDFs in your regular backups seems like a boon—it may also be simpler for some people to have all of their material encapsulated safely like that. 15 years from now, are you going to have all of your research in the same place you did right now? If you pull an old project from the archive, will your binder be full of dead links and dead ends?

There are many things to consider I think, when making a choice between avoiding Scrivener entirely for research, using linkages of one form or another, or keeping materials in a single portable container—and blends between them all. Maybe you use shortcuts during the initial writing phase, so you can back up constantly, keeping 25 zips in the rotation without fearing for bloat, but in the end when you pack things up for long-term archival, you gather everything together into the project and zip it up.

Whatever the case, and to return to the matter at hand, whether PDFs are never used at all, or stored elsewhere or embedded in the software—in no circumstances should they be pestering us with error messages during reindexing and so forth, and reindexing should not be happening whenever we search or open the project. Even if there are failures, it is such a minor failure that it is surely worth failing silently. So pointing out that bug as a reason to avoid Scrivener’s research management potential is maybe a bit off the mark.

1 Like

Ohhhhh, thank you! I never would have guessed that from the way it’s written – though I did wonder why there were two options! Yes, the combo does work.

OK, just scrubbed my project of all its PDFs, and I don’t get the error anymore. (FWIW, I do like the feature of importing PDFs, but I had stopped doing it a while ago, as it made the overall project size too huge.)

In the process, it did bring up another problem: the project search options reset every time the search bar is reopened. (I was trying to exclude items in the trash, to avoid having to really delete everything.)

But maybe this is the way it has always worked? And I never noticed because I always used had the persistent search field in the toolbar in Scriv 1.

Anyway, thanks for ID’ing the problem with PDFs – and I learned about the combo shortcuts in the process!

And yes, to confirm: please reinstate the persistent search field in the toolbar! Thank you.