That's likely because you have multiple CPU cores with multiple files being auto-converted simultaneously.

I've found the culprit: there was a http:// stream in the synced playlist (can't remember how it got into the archive).
So of course there wasn't enough space.

But the way MM handles this is confusing. I had to repeatedly press cancel (both at the message and the process since it halted) and restart Auto-sync until this track was left over.

Would be better to directly inform the user about the track that is too big when displaying the error message.

Was the drive full?

I have the same issue, seems it's not completely fixed yet.
MM 4.1.8.1751 is installed in portable mode on drive C. Empty space before Auto-Sync is 2.5GB. Auto-Conversion and Volume levelling are activated. Initial Auto-Sync via MTP to Android 5.0 (Samsung S5). After several hundred synced tracks the error message is shown that there is no more space in \MediaMonkey\Portable\Temp\MM_AutoConvertedTracks\.

I've run into the same: http://www.ventismedia.com/mantis/view.php?id=11278

I have an auto conversion rule for my device that re-encodes all my music to 192 kbps VBR. In my particular setup (and maybe this is also true of everyone else), the encoding happens much faster than the copying, so the "MM_AutoConvertedTracks" temporary directory slowly fills up with tracks that have been encoded but not copied yet. Last night, I set up a very large sync to run during the night, but due to some weird file system problem with my phone (which is unrelated to MediaMonkey), the copying operations stalled and got stuck on a single file. However, the encoding operations continued in the background, filling up my hard drive entirely, causing lots of issues with Windows when I tried to use my computer in the morning.

It would seem that there is no limit on how many encoded-but-not-yet-copied files there can be. Maybe it would make sense to set a limit? A few hundred MB?