The images in my document have disappeared

[acknak]

I have an alternative scenario to demonstrate the problem--the symptoms of the problem at least.

What I've done is to configure OO to use a temp file location that has limited space: there's enough temp space for the main document components but not enough for all the images. In this situation, OO appears to open the document cleanly, except that some of the images have the "Read error" place holder. If I try to save the document in this state (no more temp space), I get "General i/o error ... Can't save subdocument content.xml". If I then free up some temp space and save again, no error occurs and the resulting file has simply lost some of the images.

My guess is that this is unlikely to happen for current systems with large disks, so it's probably not the root cause, but it is at least conceivable that some systems could run short of temp space without the user realizing it. It could even be a transient shortage that happens to occur at the same time the document is being opened. It fits with a problem that's rare and difficult to reproduce.

Even if this is not the actual cause of the problem, I think this does demonstrate a flaw in the design of OO, that a serious, document-damaging error is not brought to the user's attention, allowing the document to be permanently damaged.

I believe this could be related to the image caching feature that was introduced into OO (sometime around v2, I think), where images are loaded independently from the main document. That's great if you need to load images from a slow network connection and you don't want to make the user wait until all the images have finished loading. But it seems that OO does not effectively deal with errors in loading the cached files.

Does anyone know how temp space is handled on Windows? I assume the temp space is just the free space on the C drive, right?

[BruceInduni]

Lost images.
On two different machines, same problem: Images replaced with placeholders while the file is open and then lost altogether when the file is closed and repoened.
Machine one: Samsung laptop/AMD dual core chip/ Windows 8/ 6meg ram
Machine two: HP Pavillion laptop/AMD dual core chip/Windows 7/6meg ram
I am editing a series of files that are between 10 and 150 pages of text with up to 60 images in each. The images are small jpgs (around 70k to 90k) Files are edited and saved in open office format. Add up all the separate files: 150+ Add up all the separate images: 1000+

Problem is not associated with shutting down the computer while AOO is still saving.
Problem on both machines only appeared after uprgading to 4.1.0, but this may be deceptive as file sizes and image numbers have been growing rapidly at the same time as I upgraded

I have tried all the fixes suggested.

I have also notice that AOO has started generating occasional 'recover unsaved work' alerts when there is no unsaved work to recover.

I am desperate...deadline looming. Any suggested clutched at as per drowning man/straw.

[John_Ha]

The problem seems to be a bug in AOO. When a user brings in an image, AOO seems to use far more memory than the image actually needs. If the user keeps on bringing in lots of images, eventually AOO crashes. So, any workarounds are based on minimising the memory used.

Read this specific post and those that follow it, particularly this post.

Workarounds to safeguard against its happening include

1 Go to Tools > Options > Load/Save > General and tick Always create backup copy and Save AutoRecovery information every 5? 10 minutes. The backup will be saved in the path specified in Tools > Options > OpenOffice > Paths.

2 Never bring in more than a dozen images without Edit > Save the document.

Now for some more drastic things

1 Minimise the size of your images.

While you are working on the draft document, re-sample the images to about 50 dpi, so an image appearing 3" wide on the page will be only 150 pixels wide. The images will be recognisable, but poor quality. Critically, they will be small in terms of the memory they use. Always use JPG for photos, and PNG for graphics, clip art etc, and never paste a photo into AOO - always use File > Insert > Picture for bringing in photos. (If you copy/paste a photo into AOO it is stored as a PNG which is much bigger than the equivalent JPG). Replace the images with full quality images before the final printing.

See the attached fred_1.odt in the Master Document.ZIP file. The picture in it was a 4,300 x 3,200 pixel JPG file from the camera which was 5.7 MBytes. When re-sampled to 150 pixels it is only 22KBytes, or 250x smaller.

For re-sampling, use an image editor software - I use the free IrfanView. Image > Resize/Resample > tick Preserve aspect ratio, and choose the new pixel count for the width.

2 Use a Master document.

I am not sure if this will give any benefit but I think it will. Split your document into several parts fred_1.odt, fred_2.odt and fred_3.odt. Now File > New > Master document > type in a few words (these are mandatory as a Master document's page format is set by these few words) and save it as fred.odm. Open the Navigator and dock it to one side of the window. Now Insert > File and navigate to fred_1.odt etc.

You can drag the file titles up and down in Navigator to put them in a different order.

To edit fred_2.odt, just double click on its title - this automatically opens fred_2.odt. Edit it. To see the changes in the Master document, Update > Selection.

Now, each document is much smaller and less likely to run into problems. See the example in the ZIP file.

See Working With Master Documents

[John_Ha]

Does anyone know how temp space is handled on Windows? I assume the temp space is just the free space on the C drive, right?

I am pretty certain you are correct. Temp is just a path and the temp files are placed there. Empty disk space is the only limit (unless someone has done something extraordinary to place a quota limit on it).

There are many temp locations in Windows 7. The OS uses C:\Windows\Temp\.

Users have a working temp at C:\Users\John\AppData\Roaming\temp where I understand Roaming is that bit owned by the user which goes with him if he plugs in somewhere else on a network.

There is also C:\Users\John\AppData\Local\Temp which is where AOO holds its temporary document and image files in a folder typically called something like C:\Users\John\AppData\Local\Temp\sv2z9ag.tmp. The AOO files are xxxxx.tmp files in the folder, where some tmp files are the odt file, and some are image files not yet saved into the odt file.

[John_Ha]

I am desperate...deadline looming. Any suggested clutched at as per drowning man/straw.

Some other thoughts

1 If it's important, I always save an "end of the day" copy of the file(s) - eg take a copy of the folder ...\Fred and name it ...\Fred_2014_12_25. Name tomorrow's copy ...\Fred_2014_12_26. That way I can go back to any day in the backups and at most I will only ever lose 1 day's work.

2 If it gets very bad, you can choose between the devil of living with it; and the deep blue sea of upgrading to a nightly build of AOO 4.2 where the bug has been fixed - see Bill's post. The problem with this is that the nightly build is a test vehicle and has not been rigorously tested so you may find other problems. If you do go this route, download one build and stick with it unless it gives problems. In other words, if the one you download works, don't try to "fix" it with a "better" version!

[acknak]

... upgrading to a nightly build of AOO 4.2 where the bug has been fixed ...

Sorry, the newer version may be an improvement but I think it's too soon to say that this bug has been "fixed."

The problem is too old and it (apparently) happens silently, with no errors, warnings, crashes or other indications of a problem.

If there was a clear cause and effect, it would have been fixed long ago.

[BruceInduni]

Thanks to those who replied..
I have tried all the fixes and even got down to the level of paranoia of saving to CD every 10 minutes, but it hasn't made any difference. In fact it has got worse and images are now disappearing from files where there has been no image editing since they were opened. I thought it might be to do with autosaves, but turning autosave on and off has not had any effect.

I can't see any positive link between what I am doing and the disappearances.
I notice from other forums that the same problem has existed in Impress, but I have not experienced it (phew!) and it does not seem to be causing current comment.

My first reaction to the problem was to assume a hard drive malfunction, so may machine went in for repair under warranty. Samsung must be scratching their heads!

I am really sad. I love the look and feel of aoo. I love the idea of open source and I detest MS...add it all together and I will do anything I can to help sort this...Trouble is that's a brave offer, but its not worth much as I have no time/money, and no skill with code.

The really sad part...I've abandoned aoo and am using MS Word instead (probably a shocking enough admission to get me banned from the forum.

Good luck guys!

[acknak]

If your document is routinely losing images, would you be willing to share it so we could see if the problem occurs on systems other than yours?

If so, you can put the document on any file sharing site and leave a link here, or email it (the document or the link) privately.

[BruceInduni]

Currently in utter overload mode trying to recover lost work. When/if panic subsides, I will post the document for anyone who is interested.

[John_Ha]

Bruce

You might be able to recover a now-deleted temporary file which AOO created during the edit process. However, the more you use your PC, the more likely it is that these files will be deleted. Have a look at this post Re: Corrupt .ods File on Mac - Cannot Open for how to look for, and recover deleted temporary ODT files.

[John_Ha]

I have now installed A00 4.1.1 and I have re-run my tests from I can now create the "disappearing images" fault every time I test it.

The memory no longer grows and everything works without failing.

However, I get the feeling that Writer is now slower to render the pictures when I scroll through the file.

I now have 30 or so images in my 150 MBytes odt file and scrolling is very slow and the images show blanks before appearing. I have installed an SSD since doing the last tests so I would have thought rendering would be quick.,

Or am I imagining it?

[John_Ha]

I have raised this is a bug - see Issue 125490 - Writer 4.1.1 very slow with large images, locks up with zoom out on 2 page view

[HowardJ]

Not quite the same problem but I have found a solution that might be worth trying.

I edit a small wildflower magazine, multi-column with lots of embedded images. I have never had pictures vanish completely, but often the reload has the formating all confused with blank pages and partial columns etc.

I have found that I can almost always fix this by deleting one of the misplaced image (including frame) and then doing an "undo". Everything usually comes back where it was supposed to be.

I generally downsize my jpgs and set the dpi to fit the space when printed (higher than on the screen of course), and my total size is only 5 MB at most.

Just tested an old issue in 4.1.1 it behaves as above.

You can see pdfs pf the results at: http://epe.lac-bac.gc.ca/100/201/300/sarracenia/

[kivig]

Have this issue (disappearing images). Didn't have a problem until re-saved Ubuntu created document on windows.
Images inserted on windows.
Opened to rotate one image on Ubuntu, since on windows there for some reason is no rotate option.
Saved, opened on Windows, saved.
After opening on both Ubuntu or Windows some images are gone.
Not sure, but it seems that only the images that were time-wise inserted beginning with the rotated one have gone.
Occurred about three times in an hour. Once instead of images I had frames with red "read-error" in them. Those went missing on re-save.

[acknak]

Greetings and welcome to the community forum!

Sorry, I'm not sure I follow what you're doing. You're working in OO Writer, correct?

How are you rotating the image--what steps do you follow?

Also, I'm not sure what you mean here: "... time-wise inserted beginning with the rotated one ...". Do you mean images that were inserted in the document after the image that was rotated?

Can you produce a sample document with one or two images that shows the same problem? If so, please attach it here so we can try it as well.

[kivig]

Thanks.
Yes, Writer.
Well, the problem is - disappearance it's not consistent. I guess otherwise people would have found exact cause long ago
Time-wise - means images disappeared in order starting with newest inserted, however that seems to be coincidence.
After bit of trial it seems it might be a memory problem. I had a file opening with "read-error" boxes instead of images and once I closed all other programs, I was able to reload the file fine. However the last time I tried to save with those boxes, the images disappeared. Another point - and again - not sure, but it seems so - If I open a file and scroll to some images, then once I use up a bit of memory with, say, 10 tabs in browser (Chromium), then save, it's likely the images I had scrolled to will be saved fine, but most of the rest can disappear. I'll try to get more reliable info at a chance.
Edit: by rotate I mean Format->Rotate->rotate 90^left. Which seems to be present on linux, but not on windows. Thogh more likely I'm blind or something

[acknak]

... the last time I tried to save with those boxes, the images disappeared.

I think this is the core problem: some error occurs when Writer is loading the image, and once that happens, the image data are completely lost. If you save the resulting file, the data loss will be permanent.

The unfortunate part is, the problem may not be readily apparent if the error affects an image that isn't shown immediately. You'd have to scroll through the document and check each and every image to be sure it had loaded properly.

... Edit: by rotate I mean Format->Rotate->rotate 90^left. Which seems to be present on linux, but not on windows. ...

It may be a feature in LibreOffice but not in OpenOffice. Ubuntu ships with LibO instead of OO and LibO is mostly identical but has had some features added. The rotate feature is not present in the Linux build of OO--at least I can't find it.

[RoryOF]

There is a horizontal and/or vertical flip but no rotate that I can find.

[John_Ha]

You can rotate an image in Draw and bring it back to Writer.

Better still, rotate the image in an image editor like IrfanView - it is recommended to use an image editor for image processing, not the (rather crude) functions available in Writer.

[jrkrideau]

The really sad part...I've abandoned aoo and am using MS Word instead (probably a shocking enough admission to get me banned from the forum.

Good luck guys!

The High Priest of the Temple of the OpenSource is proclaiming anathema from the steps of the Temple as I type. There will be a symbolic breaking of the keyboard ceremony this afternoon.

Basically one uses the tools that get the job done. . We can hope that AOO gets the problem cured so that you can return to the fold.

[PaulKnight]

I had experienced this issue at random intervals running AOO 4.1.1, and upgraded to 4.1.2 earlier today, but it did not help.
It appeared to lose several images immediately after doing autosave for the first time on a fairly large document.
However, I increased memory cache settings, and so far (3-4 hours) have not experienced the image loss.
I posted images of before/after memory settings in a related topic here:
viewtopic.php?f=7&t=80253

Hope that may be useful. I did not do any major research on the memory settings, just bumped up most of the settings, although I actually reduced the per-image memory.. may not work for others.

[John_Ha]

I have just had a thought which could go towards explaining this.

If an image is anchored to a paragraph, say, and the anchor is placed a long distance from where the image is positioned, we then have lines of text between the anchor and the image. Writer then has a problem in laying out which goes something like place the text > not enough space below the text for the image > spill the image to the next page > this leaves a gap below the text > bring up the image to fill the gap > the image is too big for the gap so it spills the text - which spills the anchor to the next page > which pulls the image down to the next page > which leaves a gap on the previous page > which pulls up the text and anchor to fill the gap > which pulls up the image > which spills the text ... and so on, ad infinitum. It seems that Writer spends some time going round this loop and then terminates the loop, and the document is left with spaces because that is how the text and images were positioned when the loop was terminated. It is particularly noticeable on a Master document, with 30 or 40 sub-documents, each only 1/3 page long, where most sub-documents have images. It can take Writer 5 or 10 seconds to lay out the 15 pages and 20 images.

So, my thought is that in a document with many pictures, where this looping takes place as the pictures are brought it, could the looping be terminated before all the images have been brought in? Now, if the document is saved, it will be saved with only those images which were pulled in? This would explain why it is so apparently random. It would also explain acknak's comment that he prefers to use Anchor as character for images because the images seem to be more stable, albeit with fewer wrap options. With Anchor as character the image is treated as though it was a character, so the word zebra, with an image anchored as a character after the " b ", will always be written as "z e b [image] r a" and the image will never be placed on the page before the " b " or after the " r ".

[John_Ha]

I have done some more tests and I can now force the "My images have disappeared" fault. I am not sure if this is the reason for users' faults, but have a look at Re: Images disappeared again today - possible cause?

The advice to users I gave was:

Advice to users is therefore

1 Always work in and save Writer documents as .odt files

2 If you File > New ... and create a new document, save it earlier rather than later - once saved, you protect yourself even if you later lose the temporary files in the temp folder because Writer now treats your file as a .odt file.

3 Set the Graphics Cache options as below.

Edit: Another thought which needs more work. Note the Remove from memory after ... is set to only 10 minutes below. We now all have lots of memory so I think this should probably be set to a longer time - say 60 minutes. It should certainly be longer than the AutoSave time. Users should try to remember to save their file every "less than 60 minutes" so that image files never get removed from memory before being saved once. I wonder if this timer is set to zero at each Save? or if it continues running from when the document was first opened?

4 Set AutoSave to ON and Always Create a Backup Copy to ON (Tools > Options > LoadSave General). (But don't forget that highly_personal-bak will still be in the Backup folder long after you have deleted highly_personal.odt.)

5 Check if you are running any "disk clean" utilities to be sure they are not deleting files from ...\AppData\Local\Temp. Windows does not delete files from the ...\AppData\Local\Temp\ folder but many utilities do - for example, CCleaner does, but it only deletes files over 24 hours old.

Edit: It may also be sensible to use a different folder for temporary files rather than the default ...\AppData\Local\Temp which utilities may clear out. Tools > Options > OpenOffice > Paths > Temporary files ... Edit it to somewhere else - for example, create a folder in the Profile such as C:\Users\John\AppData\Roaming\OpenOffice\4\user\New temp. No utilities will know about it so files will be safe from being deleted.

[John_Ha]

{about 10 posts above} Time-wise - means images disappeared in order starting with newest inserted, however that seems to be coincidence ...

That may not be a coincidence. The first images inserted will be the first images flushed from memory after the Writer Keep in memory for x minutes limit expires. They will then be written to the Temp folder where, if my theory is correct, they may be deleted.

You are using Ubuntu Linux - how does the temporary folder get cleared in Linux? Are you running any disk cleaning utilities?

Another thought - anyone leaving a Writer document open for more than 24 hours rusn the risk of losing files in ...\AppData\Local\Temp as they will be over 24 hours old and any scheduled "disk clean" utility could delete them.