iPhone syncing issues with .mov files

Syncing an iPhone 12 mini (16.5.1) to a 14" M1 MBP (13.4.1) over USB. Whenever there are new photos to sync, I end up getting 3 errors that sound like this:

“B3219054-7500-4CBF-894F-7D9B53E777F0.mov” was not copied to the iPhone “Simon’s iPhone” because it cannot be played on this iPhone.
Some videos were not copied to the iPhone “Simon’s iPhone” because they cannot be played on this iPhone.

All I can do is select OK. But as long as I do not hit OK, the sync stalls.

Now I don’t have this iPhone set up to sync any video at all, just photos (regular syncing, not through iCloud). So I’m assuming these must be videos in some of my older photo albums.

Unfortunately, Finder search for any of that number salad quoted in the error message reveals nothing at all for either of the three .mov files sync is complaining about. If I search my Photos library for .mov it shows a bunch of files, but none with a name resembling the number salad from the error message. Oddly enough, that search for .mov also shows 3 .avi files. Perhaps it’s just a coincidence, but could those 3 be related to this error?

Any ideas how I can figure out from that error message which videos are holding up my sync?

I’ve seen this on occasion, usually when dealing with really old videos using CODECs that Apple no longer supports (e.g. that required the old 32-bit version of QuickTime to play).

I also see it today if I try to copy videos from my main Mac (running macOS 11 Big Sur) to my older Mac (running 10.12 Sierra). I assume these are HEVC files, which macOS only started supporting in 10.13 (High Sierra).

WRT trying to find the files presented in the error box, I spent some time investigating and I think I know how. The filename itself is an internally-generated name (looks like a UUID of some kind). Which is not presented in the Photos app. But the Photos database has the information you need to be able to find it.

The Photos database is an .sqlite file. It contains many many tables and is pretty inscrutable, but Apple has a command-line sqlite3 command that can be used to access it. In my case, I dumped its entire contents to an SQL text file and searched it with a text editor. If I knew more about SQL, I’m sure I could perform the search from within the sqlite3 utility, but I don’t know enough at this time.

To start, open a Terminal window and copy the Photos Library’s internal database to another location so you don’t damage it. For my example, the library’s name is Photos Library and is located in my Pictures folder. I’m going to copy the database file to a directory named tmp in my home directory:

> cd
> mkdir tmp
> cp 'Pictures/Photos Library.photoslibrary/database/Photos.sqlite' tmp

Now dump that sqlite file to a text file:

> cd tmp
> sqlite3 Photos.sqlite .dump > photosdb.txt

This will take several minutes and the resulting text file will be huge (mine was 420MB).

My analysis of that file shows that there are two SQL tables of interest. The first (where to begin the search) is:

    • This table has 103 fields per row. But we only care about two of them
    • The first field (named Z_PK) is the primary key. It is a number that Photos seems to use internally for cross-referencing all of its various tables together.
    • The 96th field (named ZFILENAME) is the filename of the image/video in question.

If you search for a row inserting data with your filename into the ZASSET table, you should get something like this. The filename in my example is one of my video files. I’ve inserted newlines and line numbers for readability, and cut out the middle of a large binary data field. If you run this yourself, you’ll find all the output appearing on one very long line.

> grep 'ZASSET .*B2532B6A-94CF-4E8C-8E5B-DE1495815675.mov' photosdb.txt 

 1: INSERT INTO ZASSET VALUES(7462,3,23,0,0,0,0,NULL,NULL,NULL,NULL,NULL,0,0,1,0,0,0,0,
 2: 18014621852762204,0,0,0,720,0,0,1,0,-1,1,10133313912176689,
 3: 1,7036900191633501,4,0,3,7895,0,0,0,0,0,0,1280,7021,NULL,
 6: 346963296.71562997631,NULL,654599600.47711094333,NULL,NULL,
 7: NULL,0.25,273863646,0.86666666666666678509,273863646,NULL,
 8: 0.019847328255649742345,NULL,-180.0,-180.0,654823468.66551699449,
 9: 0.38037109375,0.0,273863645.99999999391,NULL,NULL,NULL,NULL,
10: NULL,NULL,'B','B2532B6A-94CF-4E8C-8E5B-DE1495815675.mov',
11: NULL,NULL,NULL,'com.apple.quicktime-movie',
12: 'B2532B6A-94CF-4E8C-8E5B-DE1495815675',
13: X'0863...9000',

The most important thing you need from this is the first field. This value (7462, on line 1) is the primary key which references all data related to this asset. The filename appears on line 10. And you can also see the file type on line 11.

If you want to see the names for all 103 fields, you can search for the table’s CREATE command. Again, all this output shows up one one very long line. To avoid wasting space in this reply, I’m truncating the output I present to only the two fields we actually care about:

> grep 'CREATE TABLE ZASSET ' photosdb.txt

2: ...
4: ...);

If you want to see the remaining 101 fields, feel free to run the above command on your own.

Now that we know the primary key, the information we require is located in this table:

    • This table has 78 fields. We care about four of them:
    • The first field (named Z_PK) is the primary key. It is used to correlate this data with the data in the ZASSET table (and many many more tables).
    • The 62nd field (named ZORIGINALFILENAME is the original filename. That is, the name used by the source device (phone, camera, memory stick, etc.) before the image was imported.
    • The 69th field (named ZTIMEZONENAME) is a string representing the time zone used for the image’s timestamp. It may be useful to help remember where you took the photo, especially if it’s not your home time zone
    • The 70th field (named TITLE) is a string containing the title text presented by Photos in the GUI.

To search for your asset in this table, use the primary key you got from the ZASSET table (7462, in my example) and search for it. As before, I’ve inserted newlines into the data and added line numbers for reference:

grep 'ZADDITIONALASSETATTRIBUTES .*(7462,' photosdb.txt 

2: 0,0,0,0,0,0,0,0,0,0,5,-14400,0,4253939,3648,1,0,2736,0,0,0,
3: 0,0,1,51,0,0,1,-14400,0,0,0,0,0,0,7200,NULL,NULL,NULL,10742,
4: NULL,274156333,-1.0,NULL,273853983,NULL,NULL,NULL,NULL,NULL,
5: NULL,'CEBD2CEC-5E60-4ED7-BD1B-78AB4F322869','AdBUIN1gC9VWDyMG3QR22dTqvPT6',
8: 'GMT-0400','101_2325.JPG',X'01',NULL,X'6270...0181',NULL,

Looking through this, you can see that the original filename (101_2325.JPG, on line 6), the time zone (GMT-0400 on line 8) followed immediately by the title (101_2325.JPG - I didn’t bother to create a title for this video).

Armed with the original filename and the title, you should hopefully be able to search for them from within the Photos app and identify what they actually are and decide what you want to do with them.

As before, if you want to see all the field names for this table, you can search for its CREATE command. This all shows up one very long line, and I’m going to strip it down to just the definitions of the fields I mentioned above:


2: ...
4: ...
7: ...

If you want to see the remaining 74 fields, feel free to run the above command on your own.


That doesn’t really work though because the files being referenced by the Z_PK does not match the file type that’s a problem. The file that’s causing trouble is a .mov, yet it’s Z_PK is pointing to a .jpg that actually is included in the iPhone’s library and is syncing just fine.

I wonder if there may be some corruption in the library. Maybe make a backup and then try a library repair.

Also, try looking in the originals/* directories in the Photos library. In your case, since the file name begins with “B”, look for


If the file exists, you can copy it elsewhere and see what it is. If it doesn’t exist, well, there’s your corruption.