One of the things I use Scrivener Projects for is compiling and referencing information and sources for genealogical research. I’ve not had any problems adding files, scans and images or accessing them previously - and tend to work in split editor mode with the person’s profile file that I’m editing in the left editor and whichever source I’m collating information from on the right.
Since the recent updates, however (not sure if the problem presented between the latest update and the bugfix that followed or after the latter), Scrivener is now failing to render about 10-20% of the uploaded files and images. The affected files won’t render in either pane of split editor mode or in full-width editor mode (no error message showing, just a blank editor window), and restarting Scrivener isn’t fixing the problem - the same files remain broken. I’ve had a look at file sizes of those working and not working, and there doesn’t seem to be much rhyme or reason. Plenty of my larger files are still opening consistently and without issue, and the ones that aren’t are a mix of sizes, but also won’t render when opened in quick reference or copy holder, but will still open when ‘open in external editor’ is selected.
I use a a lot of inline footnote notation-like hyperlinks to these source documents throughout all the files of my project, so if the only solution to this problem is likely to be locating and reuploading all of the sources that are now failing to render, quite aside from the scale and complexity of the task (and the risk they may fail again in the future), doing so will result in thousands of broken document links across the project. Can anyone help or suggest a less drastic solution to this problem?
This sounds like the kind of issue that we would need to see first hand in order to tell what is going on and either suggest a fix, or come up with a code fix on our end to handle whatever is happening.
If you create a simple little test project from “Blank” and drag one of this misbehaving resources into its binder, does the problem persist (I would check after a reload too)? If so, zip it up and send it to us so we can have a look, and let us know if this is something that we should see 100% of the time just by looking at it, or if it takes doing some intermediate steps to get there.
If that does not translate the problem over, it is at least a clue of where to look next in your main project, and we can know it’s definitely not a problem with the media itself.
I definitely understand your concern about not wanting to replace the original binder items. I would be very much in the same position if I had to replace even a single binder item in most of my projects. I’m confident we should be able to help you out without it coming to that—and I don’t really think that would be a solution anyway as the result of an import should be identical to the original. Scrivener is a passive viewer for research files, for the most part.
Thanks for the swift response Amber. Resources still misbehave dragged across to a new test project, including after a reload, and also misbehave if uploaded afresh. (Also tried one with a much shorter filename string as I know Scrivener doesn’t like and often auto-truncates the super long file names that a lot of the native files are kept in for easy sorting). I also dragged over one of the unbroken files which is also unbroken in the new test file. In the Scrivener files folder all of the docs are showing fine, just not in the project. Looks like its a problem with the media itself (not replicated in any other programmes that I can find so far - thumbnails showing in Windows Explorer, full files opening no issues in Windows Photos/Photo Viewer and Photoshop) or the way Scrivener is now parsing certain media files. Happens 100% of the time. Also tried dragging one of the broken images into a corkboard card - nothing happens, no error, but when I try to drag one onto the page in a new file I finally do get an error message Could not load project image: '\Research\Uploaded afresh 1999 Sept 24 Invoice and Receipt - Have zipped it up for you; where should I send it?
Just follow up - did a bit of further testing and I think it is related to file size/memory, though not consistently. Got a broken file that’s around 1600kb and an unbroken one at over 3000kb (included in the test file for you) but in general it is the larger file sizes (like the probate scans) that are breaking and none of the lower res downloaded from archive ones like censuses, which are all much smaller file sizes in general than the scanned documents.
Interesting, I wonder if it has more to do with scale than disk size, which would often correlate directly, but not always. The reason I speculate is that I wouldn’t consider either 1.6 or 3mb images to be that big. A bit on the chunky side and probably not compressed, but nothing like some of the things I’ve seen, like people putting their 30 megapixel images directly into the text editor and then wondering why the editor lags.
Yeah; there’s maybe a handful between 10,000 and 19,000kb (the probates and soldiers record books which are multi-page scans), all of which are now broken files, but everything else is below the 10k mark and all of them, probates etc included, had no trouble loading previously. The only thing all the files in the research binder slowed down was the backup save before closing, really. Will PM the file over shortly; thanks for picking this up!
I have two computers that I use for my writing. I added image files to a project in one of these computers, by creating a folder, then going to Add >> Existing Files. On Computer “A”, when I click on that folder, I see the previews for all the images in Scrivener, no problem.
When I open the same project on Computer “B”, only some of the images show up. If I try to recreate the process to add these files on Computer “B”, the newly added file continues to show up blank.
Both computers are running Windows 10 up to date, and Scrivener is up to the latest version in both.
All of the images open properly if I click “open in external editor”, even the ones that won’t preview properly within Scrivener.
I should add that the pixel dimensions of some of the problem images are quite large, and I do strongly suspect that the dimensions are the issue somehow; however, I find it odd that the issue should only present itself in one workstation. Due to the nature of my project, I’d forego inserting the images rather than having to resize them. Even if there is no solution, I would be very interested in finding out what is causing this issue to happen only in one computer. I tried resetting Scrivener’s options to default in the problem computer but this did not solve the issue.
I would greatly appreciate any assistance as I am at a loss. Many thanks to anyone who can help.
Edit: I just realized that, even though both versions of Scrivener were giving the “Scrivener is all up to date” message, my primary workstation is actually on Version: 3.1.2.0 (1812589) 64-bit - 18 Oct 2022. So, I am not sure why it is not prompting an update on that workstation, but that is why it still works properly there.
For the time being, I downgraded my other computer’s version to resolve the issue. With that said, is this a known bug? Is there any hope of it being addressed in a future update?
Yes, this is a known issue, as discovered in this thread I have merged your report into. We have this problem logged in our database and thoroughly understood, though it may be tricky to solve because it isn’t technically an issue with Scrivener itself, but the underlying toolkit. The newer frameworks have an upper cap on very large image sizes where it refuses to process them, whereas the older framework did not. Presumably this was changed to address memory issues, as no cap at all could lead to crashing. We do feel the current cap is a bit too small though given how people use Scrivener, so mainly we just need to research if there is a way to increase it.
Downgrading is one way to avoid the problem, as you have done, but another is to reduce the scale of the image to something closer to what you may need at a maximum. Since you mention that isn’t something you may be able to do for this particular case, you could consider scaling a “thumbnail” copy, which is what gets imported into Scrivener as a reference, and using the Bookmarks feature in the inspector to link to the original high-resolution image on the disk.
