Yellow triangles

[pmcabinet]

I have a smallish number of files showing the yellow warning triangle, and which refuse metadate write-back. Generally such files will be one or two out of a folder with images all shot at around the same time - so nothing unusual.

Most are from my phone camera, so I understand this could be a problem with the camera EXIF.

When I force a rescan, the ExifTool Output panel shows 'Warning: FPXR segment too small - D:\Users\pmcab\Pictures\2023-09-22\IMG_20230922_091346.jpg' and 'Error: Error reading ThumbnailImage data in IFD1 - D:/Users/pmcab/Pictures/2023-09-22/IMG_20230922_091346.jpg', as an instance.

What is the FPXR segment, and how can I make it bigger?!

[Mario]

You did not mention which file format you use.

FPXR is FlashPix data, which is a thing of the olden tags.
You cannot make it bigger, it is created when the file is created in the original application.

The error encountered reading the thumbnail image should not hinder ExifTool from writing data. Or something else is also wrong.

It would be more interesting to see the warnings reported by ExifTool after you attempt to write-back.
Point the mouse cursor at the yellow warning icon to see the error message.
And look at the data in the ExifTool output panel after the write-back or the IMatch log file.

It is not uncommon that you'll find some broken files in your collection.
IMatch users manage files created over 20, 30 or more years, with dozens of applications and devices, and broken metadata or file structures just happen.

See also The Warning Icon

[pmcabinet]

The file format is standard .jpg, and to take one example: the file was created in my phone camera only a few days ago so nothing 'legacy' about it (or the phone), and it is also in a folder of contemporary images all metadata of which were otherwise successfully written back - just this odd one has the triangle.

As I said, the ExifTool Output window, after attempting write back, showed Warning: FPXR segment too small - D:\Users\pmcab\Pictures\2023-09-22\IMG_20230922_091346.jpg
Error: Error reading ThumbnailImage data in IFD1 - D:/Users/pmcab/Pictures/2023-09-22/IMG_20230922_091346.jpg



The log file I think just states the same error warning as the ExifTool Output(?)imatch_log20230926.txt

I don't want to make a big thing of it, and if I have to live with the yellow triangle, then so be it - perhaps just a glitch on my phone? - the file is entirely usable in all (other) apps as an ordinary .jpg, but still a puzzle?

I forgot to add that I can remove the yellow triangle by clicking on it, leaving just the pen icon. Pointing to the latter gives the list of tags to write:



Clicking on the pen then causes the triangle to reappear.

[Mario]

ExifTool refuses to write to the file because it finds something that is not in order or some corrupted metadata.
Nothing I can do about this, sorry.

If these are fresh images and not some legacy image sample, either ExifTool or the camera vendor need to fix this.

Please provide a sample file that exhibits this behavior. You can upload it to your cloud space and post a link here, or send it to support email address with a link back to this topic.
If I have an image with this defect here, I can do some experiments and send Phil Harvey a copy when needed.

[pmcabinet]

Here are a couple of images that won't write back:

https://photos.app.goo.gl/FTRGumNSAAv3CC5k6

Each is from a folder of images shot at more or less the same time with the same camera. Other files in the folders all write back OK.

Thank you for your time Mario.

[Mario]

I have downloaded the two sample images provided today.
Added them to a database and gave the files a rating and added a title, a keyword, a headline and also changed the two XMP time stamps (to force a sync back into EXIF during write-back).

Write back successful for both files!

Using the IMatch Metadata Analyst on the unmodified files revelead many but minor metadata problems:

Code Select Expand

Warning: [XMP] [IFD0]:Orientation not mapped to [XMP-tiff]:Orientation (embedded).
Warning: [Detailed Validation] [minor] Odd offset for IFD0 tag 0x011a XResolution
Warning: [Detailed Validation] [minor] Odd offset for IFD0 tag 0x011b YResolution
Warning: [Detailed Validation] [minor] Odd offset for IFD0 tag 0x0131 Software
Warning: [Detailed Validation] Non-standard format (rational64s) for ExifIFD 0x829a ExposureTime
Warning: [Detailed Validation] [minor] Odd offset for ExifIFD tag 0x9291 SubSecTimeOriginal
Warning: [Detailed Validation] [minor] Unknown value for ExifIFD:SensingMethod
Warning: [Detailed Validation] Non-standard format (int8u) for ExifIFD 0xa301 SceneType
Warning: [Detailed Validation] [minor] Unknown value for ExifIFD:SceneType
Warning: [Detailed Validation] [minor] Odd offset for ExifIFD tag 0xa420 ImageUniqueID
Warning: [Detailed Validation] [minor] IFD0 tag 0x0100 ImageWidth is not allowed in JPEG
Warning: [Detailed Validation] [minor] IFD0 tag 0x0101 ImageHeight is not allowed in JPEG
Warning: [Detailed Validation] [minor] IFD0 tag 0x0212 YCbCrSubSampling is not allowed in JPEG
The metadata was written by Google Picasa, and that explains many of the metadata problems.

ExifTool has no problems writing the files and the data I've added ends up in the file.
Either your upload to Google Photos modified the files in some way or this is something specific with your PC?

I believe Google scans all uploaded files to feed their AI and monetize the data, but I don't think that uploading actually modifies the files in any way? Or converts them? Maybe upload the files again as a ZIP file to avoid any modifications?

[pmcabinet]

Well, that's very interesting Mario, because none of the files affected has been uploaded to Google Photos! 

I do use G Photos desktop very occasionally, for convenience in creating a shared album for certain images; otherwise, upload (from phone and desktop) is switched off since I don't trust Google at all.

I do however have a copy of Picasa 3 on my PC, although I haven't used it for a long time. If it is monitoring my images in the background (I wouldn't be surprised) then it is still odd that only a relatively small number of files is affected - which makes me feel that uninstalling it would not make a difference.

I have noted that despite the pen icon and yellow triangle showing that, for instance, '\DateTimeOriginal, \DateCreated, \CreateDate' tags are needing to be written, all those values are shown in the metadata browser, present and correct.

I don't suppose there is any way to tell iMatch to just ignore the problem (on a per file basis)? A few images shot this morning are showing this problem but they haven't been anywhere near Google, and those pens and triangles keep distracting me.

What is a bit of a puzzle to me is how you were able to add those now Googled images to your database with a successful write back - what is the difference for my database? Should I delete the images from my hard disk and download them from Google again - would that work? (I would copy the masters to an external HDD first.)

But many thanks Mario, anyway, for taking the trouble to look into this.

[Mario]

showing that, for instance, '\DateTimeOriginal, \DateCreated, \CreateDate' tags are needing to be written, all those values are shown in the metadata browser, present and correct.

This is to be expected. IMatch imports/sets these time stamps when ingesting a file as described in How IMatch uses Date and Time Information. And if this produces "updated" time stamps, they are flagged as pending for write-back. This is not a problem but just an indicator that IMatch has found some metadata values to update.

What is a bit of a puzzle to me is how you were able to add those now Googled images to your database with a successful write back - what is the difference for my database

No idea. It just worked as it normally works. Picasa did some damage, but nothing ExifTool and IMatch can't manage.
Wiring back the files once should fix all the problems.

[pmcabinet]

This will run I think Mario. I uploaded three files with yellow triangles to Google Photos and created a link to share, just as you did (having copied the originals to a USB stick, then deleted those originals files from iMatch).

I downloaded the zip file from Google and extracted the files to a folder in Windows Explorer. Since iMatch is set to file system monitoring I expected it to pick up the images automatically - but it didn't. So...

...In iMatch I drag and drop the folder into Media & Folders, when the dialogue opens and asks if I wish to add to the database.



I click yes, there is a brief screen flash - but nothing is imported. I have tried several methods to effect this import.

It's as if iMatch is not 'seeing' anything. What could have happened to the folder? The images open fine in Affinity, IrfanView, old Photoshop version, anything really.

Any ideas (again, I'm sorry!)?

[Mario]

When you drag files to a File Window, IMatch either copies or moves the files into the target folder.
You did not include a log file (see #logfile) so we don't learn much.

The screen shot shows a File Window with 3 images. One image shows a yellow warning indicator, which means that there was a problem when reading or writing metadata. Pointing the mouse cursor at that icon will tell you more about the problem.

When you select a folder in the Media & Folders tree on the left and you press <Shift>+<F5>, IMatch scans for new and modified files, removes no longer existing files and bring in new sub-folders and files.
While doing that, IMatch will log detailed information about the process to the log file, e.g. if and which new / modified / removed files were detected.

Switch IMatch to debug logging (Help menu > Support) and do this. Then ZIP and attach the log file.

[pmcabinet]

Sorry Mario, the screenshot was a bit misleading - it doesn't show the three files I was trying to import, just what happened to be in the background on screen at the time. Those three files, of course, (and the folder I created to contain them) are not in the iMatch database!

Are you saying iMatch will only drag & drop files, not folder(s)? I tried dragging one of the files from the newly created Explorer folder to its original place in a folder in iMatch - the same flash on screen and no result.

Then I moved the files from the Explorer new folder back into their original location (in Explorer). But rescanning this folder in iMatch did not add the files back.

Log file attached.

Thanks again for your forbearance.

[Mario]

You can drag folders to the Media & Folders View and files into File Windows.

The log file shows IMatch rescanning the folder D:\Users\...msgate\ (and sub-folders) but no modified or new files were detected.

Please check Edit menu > Preferences > Indexing and make sure the "Include sub-folders" option is enabled.

Try this:

1. Switch IMatch to debug logging (Help menu > Support)
2. Open the Documents folder in Windows Explorer
3. Create a new sub-folder in Documents, e.g. name it "IMatch"
4. Copy some images into that new folder
5. Drag the new folder into the Media & Folders View tree control on the left.
When IMatch asks if you want to add the folder to your database click "Yes".

Expected result: IMatch adds the folder to your database and index the files you have copied into this folder. You can see the folder and the files in IMatch.

If this does not work, please ZIP and attach the log file.

[pmcabinet]

I have followed your instructions and attempted to drag & drop 2 test folders into the folder view. But the same effect occurs: a screen flash (it's extremely brief, but looks as if it might be the 'do you want...' dialogue that is flashed up again) and no folders appear.

Attached log file after restart.

[As an aside, it is probably clear that I have no programming skills; however, curiosity has driven me to look into the FPXR Segment business. I understoood very little of what I found, but I did derive a hint that whichever bit of EXIF it relates to might just be deleted with the appropriate app. Is that ridiculous?]

Quick update: I tried the Update files and folders command route, importing directly from the USB drive to which I had copied the original images. Same screen flash, no result. This was after I had attached the log file so won't appear in it.

[Mario]

This log file shows only an IMatch start (it ends when IMatch finished loading the database). It is also not in debug logging mode (Help menu > Support) so the logged information is very basic.

No folder was added or rescanned in this IMatch session. IMatch would have logged the step that adds the folder to the database and that the dialog box with the prompt was open. No trace of that-

If drag & drop of folders does not work on your PC for some reason (I have no idea why, this was never reported before) you can add folders using the Using the Add or Update Folders Dialog

[pmcabinet]

Presumably I had the wrong log file for the wrong session - I'm a little confused about that.

Nonetheless, things are getting worse - I'm now unable to import any files or folders. Advanced file system monitoring is checked. I downloaded today a new set of images from my phone into a new Windows Explorer folder, expecting them to be picked up automatically, as has always happened up to now. But nothing happened, so I went the Add or Update Folders route; the now typical 'flash' occurred and again nothing was imported. 

[All other features of iMatch seem to be working as normal; I have not made any changes or updates to my PC. The yellow triangle problem only dates from May of this year - with the same camera I have used now for more than two years.]

I had enabled Debug logging, then closed iMatch and restarted, then copied the attached log file. I don't know if that is the correct sequence.

So something is definitely broken - would re-installing iMatch be of any use?  

[Mario]

This log file shows an IMatch start, not much more.

IMatch reports that the last session did not shut-down correctly. Did you shut down IMatch in Windows Task Manager or did IMatch crash? In the later case you should have good a "crash handler" message from IMatch.

The next operation is IMatch purging the cache. Apparently, one of the thresholds you have configured under Edit > Preferences > Cache has been hit and IMatch tries to free disk space by deleting cache images. But it cannot. IMatch logs:

RemoveCacheImage failed for C:\ProgramData\photools.com\IMatch6\previewcache\3B1DB56B-3356-4A04-87EC-53B989E81925\29\291479.jpg
RemoveCacheImage failed for C:\ProgramData\photools.com\IMatch6\previewcache\3B1DB56B-3356-4A04-87EC-53B989E81925\29\291484.jpg
...

When you open the cache folder in Windows Explorer ('C:\ProgramData\photools.com\IMatch6\previewcache\3B1DB56B-3356-4A04-87EC-53B989E81925\29') do these files exist? Can you delete them?
Or simple open a command prompt window and run:

Code Select Expand

del "C:\ProgramData\photools.com\IMatch6\previewcache\3B1DB56B-3356-4A04-87EC-53B989E81925\29\291484.jpg"
del "C:\ProgramData\photools.com\IMatch6\previewcache\3B1DB56B-3356-4A04-87EC-53B989E81925\29\291479.jpg"
does this work?

This is all. The log file is very short and ends after a few of these messages.
This is not a log file from a session where you've added new folders to your database.
Tip: Use Help menu > Support > Copy Log File to save a copy of the log file on disk right after you experienced the problem. Then ZIP this file and attach.

[pmcabinet]

I'm sorry it seems I've been messing up these log reports. I will try again. Debug logging is enabled for the session I am currently viewing while I write this.

I always shut down iMatch by clicking Database then Exit, then wait for the prompt to backup or skip.

I have never changed the Cache settings from default.

Windows says it cannot find 'C:\ProgramData\photools.com\IMatch6\previewcache\3B1DB56B-3356-4A04-87EC-53B989E81925\29'. See attached PowerShell result.

Meanwhile, another odd situation. iMatch reports 4 'Offline Folders Found'. I couldn't see them flagged in the Dashboard. When I found the folders (now showing a tiny unreadable blue icon on top of the folder icon) in Media & Folders panel, I could see that they had not been accessed recently and certainly not moved by me. Attempts to relocate failed.

I am now attempting to import the new folder referred to in a previous post, and trust the process will be recorded in the log. The import failed (screen flash as usual).

The yellow triangle issue of course remains unresolved, although I have not attempted to write back in this session so it won't appear in the current log.

I am now copying the log file and attaching it (I forgot to zip the file).

Let's hope you get some useful information from it. Note, despite the difficulty in using iMatch at present, I am not pointing the finger without acknowledging that it could be a Windows problem - but that I cannot determine, at least so far.  

[Mario]

The blue icon next to a folder indicates that IMatch has detected that the folder (or files within) has been modified and that the folder is scheduled for a rescan.
A yellow warning icon next to a folder indicates that the folder does no longer exist on the disk (or that IMatch is unable to access it for some other reason, like insufficient file system permissions).
See: Folder Icons in the IMatch Help.

IMatch reports that the folder/media H:\: is offline.
It should show a yellow off-line indicator icon in the Media & Folders View.
 See Off-line Folders and Files for information about offline folders and how to use the relocate command in IMatch to bring them back online. If H: is an external disk that is not connected, you can ignore this message. As soon as you plug the H: drive in again, IMatch detects that automatically.

In your screen shot I see two folders scheduled for rescan, but no offline folders. They are outside the view.
I see no yellow triangle anywhere.

Windows says it cannot find 'C:\ProgramData\photools.com\IMatch6\previewcache\3B1DB56B-3356-4A04-87EC-53B989E81925\29'.

Then the message is the log file seems to be correct. IMatch cannot delete the file because it does not exist. Strange.
When IMatch purges the cache, it determines the "oldest" cache files and then runs a loop.
The loop first checks if the file exists on disk using a Windows function and if that is the case, uses another Windows function to delete the fie.
Since we see the warning in the log, it seems that the "file exists" function returned "yes", but then delete failed. Or succeeded but returned an error code nevertheless. Strange.

In the log I can see that IMatch has identified several modified folders, starting with 'D:\Users\pmcab\' and scanned them. No new or modified files were found.

The only warning in the log is about some off-line folders. No errors.

I see a log entry OnFolderRescan  which is used when the user uses the Commands > Add or Update Folders command to add a new folder to the database. IMatch also executes AddOrUpdate folder, which is the core task that scans folders and finds new and updated files. It is called several times, recursing down into sub-folders.
According to the log, no new or updated files were found.
The method ran for almost a minute (showing a progress dialog).

This looks like you asked IMatch to add a folder, it processed the folder, but the folder was already in the database and all files were up-to-date.

The import failed (screen flash as usual).

When you you see this flash? Which command did you perform?
When you drop a folder or use Commands > Add or Update Folders for a folder already in the database, the progress dialog will show very briefly if there is nothing to do.

[pmcabinet]

There are no yellow triangles on any folder icons - only on individual files in the file window.

So the blue icons shown in my screenshot 'Offline Folders Found#2' indicate a rescan, not that they are offline (H:\ is an unfortunate confusion here - it simply relates to a usb thumb drive I used to try and re-import some yellow triangle files; it did not work. How come iMatch listed the drive in the folder tree but could/would not import the files?).

Rescanning the folders with blue icons does not remove the icons, whichever method I use to try. Add or Update Folders does not do what it says in this instance.

Even more to the point, [/iI repeat, I cannot add any files or folders to iMatch at all[/i]. You will see from the screenshot that the last folder successfully imported was 2023-10-14 (all my folders are now named by date). Windows Explorer shows two later folders waiting to be imported to iMatch. It is not picking them up (Advanced File System monitoring is enabled). Using the Add or Update Folders command instead, produces the now infamous (to me!) 'flash', a sort of blink of an eye, followed by - nothing. Note, these folders are [/inot/i] already in the database - a search confirms this.

With Debug logging enabled, I will now repeat the attempt to import the folders. Is the Adding and Updating Folders dialogue (screenshot) as you would expect to see it? So I press Start, the screen 'blinks' shall we say, then no result.

I can defer problems with yellow triangles, but if I cannot add or update any folders, well...that's a big problem. I'm not happy taking up your valuable time here, but maybe you will understand this is a critical issue for me.

Does the debug log file tell you anything useful - or have I got the thing wrong again? There seems to be a lot of purging and flushing going on, whatever that means.

 

[Mario]

The IMatch functions to add or update folders is called several times. But no files to add are found. No updated files either.
This looks like the folders are already in the database (IMatch does not call the functions to add a newly found folder) and what's recorded in the database perfectly matches what's in the file system.
What I see in the log is what I see when I ask IMatch to add or rescan a folder that's already in the database and current.
The AddOrUpdateFolders function is called, but no new or modified files are found.

Create a new database and add the folders to this database. Does this work.
Do you have any exclusions configured under Edit menu > Preferences > Indexing?

[pmcabinet]

Screenshot of preferences for what has been up till now my one database.

Now, it's interesting. As you suggested I created a new database and via 'Add or Update Folders' imported the two latest folders (ref previous post). They appeared, no problem. (But seemingly random files with yellow triangles 'FPXR segment too small' still, annoyingly, appearing. More on that later!)

So what can be wrong with my main database? The search function (set to folder name) draws a blank for the two folders under scrutiny - I am 100% certain they are not already in the database. How come iMatch thinks they are?

I don't want, or need, two databases, so where do I go from here?

I have attached a debug log for the present session. Maybe it's not required in this instance.

[Tveloso]

Maybe also try searching for one of the FileNames, from one of the folders in question, using the File Finder App...just to be sure the files are really not Indexed?

If the App does find the file, it would be interesting to see what path appears in the Status Bar when you focus the file's Thumbnail, and what Ctrl+G does...

[Mario]

(But seemingly random files with yellow triangles 'FPXR segment too small' still, annoyingly, appearing. More on that later!)

This just means that ExifTool has detected a serious problem in the metadata of the file. Re-saving it in the original application may fix the problem.

The search function (set to folder name) draws a blank for the two folders under scrutiny - I

Did you use the search bar in the File Window?
Please keep in mind that this only searches the current scope (what's loaded into the File Window).
Use the search function in the Media & Folders tree to quickly find folders: The Filter Tab

[pmcabinet]

The search function in Media & Folders tree does not find the folder(s) in question.

Taking Tveloso's suggestion to use the File Finder app (excellent - I didn't know about it) gives a blank for the test file I chose from one of the folders.

The fact is, the folders are not in the database; nor can I import any folder or file at all, irrespective of source.

The last folder imported was named by date: 2023-10-14. Nothing thereafter.

When I try to update the database, the screen 'blinks', then nothing happens - no errors or warnings - it's as if I have not even tried.

I might be a newcomer, but I think I can tell when something is broken (famous last words!). Why should it work with a new database but not this one? It doesn't make sense.

I'm always ready to accept that I have made a mistake, but I have tried everything and seem to have reached the bottom. My database must be knocking at Windows' door, but Windows is not answering - is that what it is? Or is iMatch running away for some reason? What could have caused the sudden hiatus?

Further thoughts, please, before I play the Chinese porter (see 'For A Few Dollars More' - and you should!) and run away myself!

[Mario]

Let's see:

You cannot add / rescan folders in your original database.
From the log I can see that the folder scan operation is performed. But IMatch does not add the folder to the database and the scan, while being successful, does not find new or updated files.

The ScanFolder operation takes time (20 seconds, when I recall), so IMatch actually does some work. If there would be a file system permission issue or virus checker interference, it would either log warnings or return immediately...
The log looks exactly as a log would look when the user tries to add a folder to the database and that folder already is in the database and up-to-date.

You cannot see the folder in the Media & Folders View and searching for file names that should be in that folder is also a negative.

Adding the same folder to a new database works fine.

No unusual warnings in the log file. Nothing that gives a clue.
I frankly have no idea. I'm quite sure something similar was never reported before.

[Tveloso]

Does Database Diagnosis report any errors?

[pmcabinet]

No errors reported in Database Diagnostics.

Once again, I'll try to illustrate in the two screenshots: in the first I have called up the Add or Update Folders dialogue which shows a selected folder, not already in the database, from Explorer. I pressed Start. The dialogue disappears. Nothing happens. For the second screenshot, I waited about five minutes after the first; it shows the Dashboard with no recently added folders after 2023-10-14.

Now it seems pointless to keep sending logs if they do not show any errors or failed processes. The question is, why is the database falling between these two stools?

I accept that you are unable to answer that, but it doesn't leave me in a good place, eh?

The log looks exactly as a log would look when the user tries to add a folder to the database and that folder already is in the database and up-to-date.

Then I have to assume the log is not doing its job? The database can't have it both ways: if the folder is not in the database but the log thinks it is...

So I have one new default database with recent folders in it, and a second, with all my preferences, keywords and customisations now frozen in time at 14 October 2023.

What now?

 

[Mario]

Please upload the database to your cloud space (OneDrive, Dropbox, Google Drive, ...) and send a link to support email address.
Include a link back to this topic.

If the database works here and accepts new folders, we know that this is something that happens only on your computer.
If the database fails to accept a new folder, I can analyze what the problem is.

Since this particular problem was never reported before and the log shows no trace of a problem, this is the next step.

[pmcabinet]

OK Mario, thank you. I am aware the problem could reside with my PC (W10 Pro), but please remember that the 'new' database I created works fine; it contains all my folders post <2023-10-14>.

I have uploaded the ('old') database to Google Drive. I hope I have given the correct permissions!

[Mario]

Very good. Please allow for a couple of days.
My "Please analyze this database / file for ..." is always well filled.

[Mario]

Thanks for sending the database.
Please open the database, go to Edit > Preferences > Indexing and empty the value for skip these folders.
Currently it shows:



which means skip all folders. This is surely not your intention.
By emptying the mask, you allow IMatch to add and update folders again.
See Indexing for more information of this option.

[thrinn]

which means skip all folders. This is surely not your intention.

I would never have thought of that...

[Mario]

I would never have thought of that...

I've learned something from this particular issue. When this happens again, I hopefully remember to ask the user to show the Indexing settings he uses. It's not totally uncommon that users accidentally make changes in settings and then wonder why something does no longer work or differently.

Which is why I've hidden many options and settings behind the expert mode and "additional options".

[pmcabinet]

That's fantastic Mario; I was on the point of giving up. I'm sorry to have given you a hard time for a simple error.

Now, forgive me, but I must return to those vexing yellow triangles - and my original question.

I've been looking into the whole business of EXIF but I'm not much wiser:

1. In your opinion, is the metadata problem solely down to a random (I can't find a pattern - only the odd file is affected) metadata error on my OnePlus phone camera?

2. Can EXIF data be edited?

3. Can the 'FPXR segment too small' tag be deleted/ignored (and the yellow triangle with it)?

[Mario]

I cannot say more or provide more tips than I've already have above.
You sent me samples of these files and IMatch had no problem to write them.

Can EXIF data be edited? 

Sure. IMatch does that during write-back to synchronize EXIF with XMP data.
If you know what you are doing, you can edit EXIF metadata in the Metadata Panel manually too.

Can the 'FPXR segment too small' tag be deleted/ignored

Ignore. Flash Pix data is a thing of the past and Apple and others created a huge mess over the years when it was actively used.

Select some of the files in a File Window, press Shift+Ctrl+F5 and then choose "Force Update". Warning icon still there?
If not, change the rating and write back. Warning icon shows? Files corrupted. Open the files in the original application and rewrite them to fix the problem.

[pmcabinet]

Open the files in the original application and rewrite them to fix the problem

The original application is my OnePlus 8T phone camera. How would I rewrite the files?

[mopperle]

By saving/exporting under a different name or whatever your smartphone allows you?

[pmcabinet]

That was a good suggestion - but no luck. I renamed the file on my phone and emailed it to myself; saved the image to the relevant folder in iMatch. Yellow triangle still sticking!