What Is mediaanalysisd on Mac? The Same 193 Images, Hourly

My Mac mini has never opened Photos. Its photo library is empty, and the daemon's own log says so 308 times a day: PhotoLibrary <private> is empty; skipping. Even so, mediaanalysisd is the 14th-busiest of 688 processes on the machine. It has used 146 minutes of CPU time in 19 days and read 61 GB from disk. If you found mediaanalysisd in Activity Monitor and searched what it is, the short answer is below. The longer answer is what I found when I read its log: once an hour it runs text recognition on the same 193 small images, decides every one of them is too small to analyse, and ends with All fetched files are duplicated. Then it does the same thing an hour later.

The rig is a headless Mac16,10 (M4) on macOS 26.4.1 (25E253), booted 2026-09-28 and measured on 2026-10-17 without sudo. On the demand side, Google autocomplete for mediaanalysisd returned 105 completions that day. Stop mediaanalysisd and mediaanalysisd-access came first, ahead of mediaanalysisd high cpu time and what is mediaanalysisd on mac activity monitor.

What mediaanalysisd is

mediaanalysisd is the macOS daemon that analyses images and video on your Mac. It does the work behind Live Text, Visual Look Up, and searching Photos for "dog" or "receipt". It has no man page, and Apple's support documents describe the features, not the process. The launchd file is the best primary source, so here is the relevant part of /System/Library/LaunchAgents/com.apple.mediaanalysisd.plist:

$ plutil -p /System/Library/LaunchAgents/com.apple.mediaanalysisd.plist
  "RunAtLoad" => false
  "ProcessType" => "Adaptive"
  "com.apple.mediaanalysisd.background.scheduler" => {
    "Priority" => "Maintenance"
    "RepeatingTask" => { "Interval" => 3600, "MinDurationBetweenInstances" => 2900 }
    "RequiresUserInactivity" => true
    "RequiresExternalPower" => false
  }
  "MachServices" => { ...photos, ...homekit, ...realtime, ...embeddingstore, ...vuindex (10 total) }

Three things follow from that file. It's a LaunchAgent, so it runs as you, one copy per logged-in user, not as root (the split is explained in LaunchAgent vs LaunchDaemon). It doesn't start at login: launchd starts it the first time something calls one of its ten Mach services. And its background work is scheduled about once an hour, only while you're away from the keyboard. That last condition explains a pattern that comes up in the forum threads: "it only runs when I'm not using the Mac." That's how the schedule is written.

lsof on my copy shows what it holds open. It has Photos.sqlite open read-only for two libraries: ~/Pictures/Photos Library.photoslibrary and ~/Library/Photos/Libraries/Syndication.photoslibrary, the store for Shared with You items. It also keeps its own MediaAnalysis.sqlite and VUIndex.sqlite (the Visual Look Up index) inside each library, plus ~/Library/MediaAnalysis/MediaAnalysis.sqlite. Both libraries exist even though nobody has opened Photos on this machine, and both are empty: Removed 0 assets from the index and added 0, total is 0 assets.

What it costs on my Mac mini

Measure	This boot (19 days)	Per day
CPU time (ps)	146 min 20 s, rank 14 of 688	7.6 min
Disk read (proc_pid_rusage)	60,967 MB	3.2 GB
Disk written	323 MB	17 MB
Resident memory	231 MB (footprint 54–147 MB while I watched)
Previous boot, 18 days (saved 2026-09-19)	65 min 59 s, 48.39 GB read	3.7 min

7.6 minutes a day is 0.5% of one core. It won't slow down an M4, but it is more than double the previous boot's rate. For comparison, Spotlight's mds_stores came 28th on the same machine in September (mds_stores high CPU). The two related processes are small here: photoanalysisd has used 161 seconds and mediaanalysisd-access, the XPC helper that hands analysis results to apps, has used 46.

The hourly loop: 193 images, every hour

The log explains the CPU time. I pulled 24 hours of mediaanalysisd messages with /usr/bin/log show. That's 98,000 lines after removing two chatty subsystems; the /usr/bin/ prefix matters in zsh, see the log show guide. The background scheduler ran 22 times. Each run starts the same task list, and one task does the real work:

16:40:14.870  Running task VCPMADFilesystemProcessingTask (13687)
16:40:14.870  [Filesystem] Analyze all image/keyframe assets
              ... 193 x [VCPTransforms] image (width 200, height 100) smaller than minimum size 128
              ... 193 x [TextRecognition] documentOutputRegion ... image={w:200,h:100}
              ...   7 x Failed to decode image / invalid or too small dimensions (0x0)
16:40:28.018  [Filesystem] All fetched files are duplicated, end analysis

"Filesystem" means files on disk, not the Photos library. I counted every run in the 24-hour window:

• 22 runs, 4,270 text-recognition passes. Each run handled 193 or 196 images. Two hours had no run, which fits the "requires user inactivity" rule. The first run on record is at 18:39 the previous evening, because the log store on this machine only keeps these messages for about 22 hours. I can't tell from the log when the loop started.
• The same images each time. Comparing image dimensions between consecutive runs, 190 to 196 of the 193–196 matched.
• Every image was below the daemon's own minimum. 4,269 of 4,270 passes were preceded by smaller than minimum size 128. The most common sizes were 200×100 (1,183 passes), 16×16 (338) and 728×100 (308): icons, logos and banners, not photos.
• Nothing gets saved. Each image also logs Embedding version: 0 not supported, skip embedding publishing, and the run ends with "duplicated".

Each run takes about 13.4 seconds. I sampled the process every two seconds during the 16:40 run: CPU time went from 146:29.71 to 146:34.23, so 4.5 seconds, while it read 14 MB and its memory footprint grew from 54 MB to 147 MB and dropped back. That's about 100 CPU-seconds a day, roughly a fifth of the daily average. The rest goes to work I couldn't attribute, such as a 179 MB read burst at 16:32 that happened before my sampler started.

One more detail from each window: mediaanalysisd checked Apple Intelligence opt-in status 801 times in 2 minutes 42 seconds. Each check logged Device has no DSID, checking if device or previous user has toggle enabled. (no Apple Account is signed in here), then Device or previous Apple Account has opted-in. Returning true.

I also tested whether new files enter the loop. At 16:33 I wrote 24 PNGs into ~/work, 12 at 111×37 and 12 at 301×299. Spotlight indexed them within 20 seconds. The 16:40 run didn't touch them: it processed the same 193 images, and none of the new sizes appeared.

Finding the folder without sudo

The usual way to find what mediaanalysisd is reading is sudo fs_usage mediaanalysisd. I can't run that, because this account has no passwordless sudo. The log hides file paths as <private>, but it does print each image's dimensions, and Spotlight stores dimensions as metadata. So I searched for files with those exact sizes:

$ mdfind "kMDItemPixelWidth == 200 && kMDItemPixelHeight == 100" | wc -l
     100
$ mdfind "kMDItemPixelWidth == 200 && kMDItemPixelHeight == 100" | sed 's|/[^/]*$||' | sort | uniq -c
 100 /Users/sg-mini/work/slot-1330-qlmanage/outb
$ mdfind "kMDItemPixelWidth == 728 && kMDItemPixelHeight == 99"
.../node_modules/@supabase/phoenix/priv/static/phoenix.png        (8 copies, all node_modules)

All 100 of the 200×100 files on this disk are in one folder: renders I made for the qlmanage SVG to PNG test, rasterised SVGs with a few words of text on each. About 55 of them appear in every run. The 728×99 banners are the Phoenix logo, which the Supabase client library ships inside node_modules, copied into several web projects. That matches what Glyph reported in early 2025, quoted in Scott Macpherson's write-up: the files being rescanned were "the image resources attached to various Python installations". Matching by dimensions is circumstantial, since two files can share a size, so I tested it directly.

The fix test: one rename, next run

At 16:40:55, right after the 16:40 run, I renamed the folder from outb to outb.noindex. Spotlight skips folders whose names end in .noindex, and 30 seconds later mdfind found 0 files at 200×100. Nothing else changed. I didn't kill the daemon, reboot, or touch System Settings. The next run started at 17:38:52:

• 200×100 passes: 0. In the previous 23 runs there were 52 to 55 every time.
• The rest of the loop stayed. The 16×16 icons, 728×100 banners and 100×100 images were all still there. Those folders are still indexed.
• My 24 probe images showed up one run late. They appeared at 17:38 as 112×38 and 302×300 (the log rounds up by a pixel, like 728×99 becoming 728×100). That means mediaanalysisd collects new files between runs, not at the start of one. The 12 larger images didn't trigger the "smaller than minimum" message. Whether those 12 drop out of later runs while the 12 small ones stay is the next thing to check. I hadn't seen that by publication time. Update (2026-10-17, 18:38 run): all 12 of the 112×38 images were back and none of the 302×300 ones were, so the files mediaanalysisd keeps retrying are the undersized ones.

The total went from 193 to 170: 55 renders removed and 24 probe images added, which would make 162. I can't account for the other 8. The rename did exactly what the community workaround predicts, and it didn't need admin rights.

What other people found

The loop isn't specific to this machine. The most-viewed Ask Different question, "Why is the mediaanalysisd taking a lot of CPU on macOS?", has 14,679 views. It was asked by a new M4 Mac mini owner who leaves the machine on overnight, as I do. Its four answers cover four different situations. One user found that macOS 15.3 fixed it, going from 16 hours of CPU in 36 hours to minutes. One found mediaanalysisd running inside an iPhone simulator. A 2026 answer from an Intel MacBook Pro on Tahoe 26.4.1, the same version I'm running, describes the loop: the same several dozen files in one directory, over and over. That user stopped it by excluding the directory from Spotlight.

The answer links to "mediaanalysisd has gone rogue", Scott Macpherson's June 2025 post from macOS 15.5. His case was far worse than mine: about 20% CPU around the clock, and 1,641,196 log lines in three hours, 60% of them errors. The files had been on disk for months. On my 26.4.1 machine, the background task's hourly limit keeps the loop to 13 seconds an hour. That's the bounded version of the same bug.

Other people kill the process instead. maKiller is a small tool that watches the process list and kills mediaanalysisd as soon as it starts. Its README says disabling the daemon properly would require turning off System Integrity Protection. Its stated motive is privacy, not CPU: it objects to the daemon running OCR and recognition on images on your disk. Hacker News has only two stories with mediaanalysisd in the title, maKiller and a two-point "Can Apple fix the mediaanalysisd CPU hog?", so most of the discussion happens in forums instead.

Should you stop mediaanalysisd?

Usually not. Killing it doesn't last: it's an on-demand LaunchAgent, so the next Live Text or Photos request starts it again, and the hourly task asks for it anyway. Disabling it removes Live Text and photo search. If it's costing you real CPU, the order I'd follow is:

1. Check whether it's looping. Run /usr/bin/log show --last 2h --predicate 'process == "mediaanalysisd"' | grep -c "smaller than minimum size". A count in the hundreds that repeats every hour is the loop. Zero means the work is something else, such as a newly imported photo library, which ends on its own.
2. Find the folder. Use sudo fs_usage if you have admin rights. If you don't, take the image dimensions from the log and search for them with mdfind as shown above.
3. Take the folder out of Spotlight. Rename it to end in .noindex (no admin rights needed), or add it under Spotlight's privacy list. Build output and node_modules trees are good candidates. They're also what mdfind showed Spotlight indexing on this machine.

FAQ

What is mediaanalysisd on Mac?

mediaanalysisd is the macOS process that analyses images and video for Live Text, Visual Look Up and content search in Photos. It runs as a per-user LaunchAgent, starts when an app requests analysis, and schedules background work roughly once an hour while the Mac is idle. It also scans image files outside the Photos library.

Why is mediaanalysisd using so much CPU?

Either it is analysing a large new photo library, which finishes on its own, or it is stuck re-processing the same files. On a Mac mini running macOS 26.4.1, it ran text recognition on the same 193 small images every hour, all below its 128-pixel minimum, and saved nothing. Its log shows this as repeated "smaller than minimum size" lines followed by "All fetched files are duplicated".

How do I stop mediaanalysisd?

Killing it doesn't last, because launchd restarts it on demand, and disabling it turns off Live Text and photo search. If it is looping over the same files, find the folder those files are in and exclude it from Spotlight, either by renaming the folder to end in .noindex or by adding it to Spotlight's privacy list in System Settings.

photoanalysisd is the consumer of this work. Its plist makes the six-hourly backgroundanalysis task wait for mediaanalysisd's face pass to finish. On this same empty library it also runs a daily Apple Intelligence prompt-suggestion pass at 13:28, checking 24 templates against 0 photos. The schedule and the log lines are in what is photoanalysisd on Mac.

Measured on 2026-10-17 on one headless Mac mini (Mac16,10, M4, macOS 26.4.1 build 25E253, booted 2026-09-28), without sudo. CPU time is from ps, disk bytes from proc_pid_rusage on my own copy of the process, and the previous-boot figures are from a ps listing saved on 2026-09-19. Loop statistics come from 24 hours of /usr/bin/log show output (22 runs) plus a two-second CPU sample across the 16:40 run. File locations were matched by image dimensions using mdfind, not fs_usage, and confirmed with the .noindex rename described above. Community figures are from the linked Ask Different question (Stack Exchange API, 2026-10-17), Scott Macpherson's post and the maKiller README. Demand figures are Google autocomplete completions, not search volume.