Processing seems to use quite a bit of temp storage on mac (m2 pro, sonoma or sequoia) which is totally fine, but it doesn’t seem clean up after itself.
A reboot doesn’t clean up what mac shows as “purgeable” data on its HD info screen.
Anyone know where it’s putting the temp files so I can manually clear it out?
I had this exact issue. I don’t know the exact location, however I simply manually purged in order to get stems to render. I followed a youtube tutorial for this. It becomes quite an issue if you internal ssd is small.
This is a pretty serious bug that crashed my OS. On the first try I processed about half my 45 gig music collection an it took about 500 Gigs of temp space an crashed my machine. Second try on a fresh OS install it used up another 587 gigs. There were only about 80 gigs of stems produced in total and “purgeable” is persisting.
Not sure it matters, but the music and stems are on an external drive, the temp space is on the local drive.
I have a setup almost identical. All my music is on external drives (nothing on my mac). And had the exact same problem except that my mac didn’t crash I kept on getting ‘system running out of application memory’ messages & error messages from Engine. 'Your system has run out of application memory' - #7 by crazycraig
I’ve had this issue too, but you might actually have hit upon what’s causing it; external HDDs. I hadn’t put two and two together if I’m honest. Something that Denon definitely need to look at though, almost writing within the process some script to keep purging as it’s going along (if that’s possible).
Are you using Time Machine per chance? if so, I’ve had this issue well before stems was even a term in the denon ecosystem. It’s pretty common.
I’m not. I’ve only seen this problem with engine dj stems so far.
It looks like the purgeable data cleaned itself up this time after a couple of days without me having to use the disk utility app.
Still a very big problem as it shouldn’t take over 1 TB of temp space to analyze 45 gigs of mp3s and create 80 gigs of stems data.
I am actually, to an external disk (unsurprisingly). It does go crazy when you are writing stems though, but I wonder if it is TM related?!?!
From my experience, purgeable space is often remnants of Time Machine keeping a local backup of files on your disk.
I have a 4TB internal SSD in my mac and each of my radio shows is about 350GB of video (4x streams of 4K @ 30fps, 1x stream of 1080p @ 30fps and the wav file). I keep a few of these around on my internal storage and when I need to clear them out, sometimes it takes a long time for the purgeable space to even get cleared after a backup has completed.
I’ve not done much w/ stems. It might be possible to exclude the temp dir from the time machine backups. That will help this issue from happening.
The only thing with that, is the drive isn’t TMable, as it’s ex-FAT, and TM won’t back that up. It might be tied into the process though, somehow.
I’m sorry – maybe i misread / misunderstood. Are you seeing “purgeable space” on an exFAT drive?
No - the tracks are on an external SSD which is ex-Fat, so can’t be backed up in Time Machine. It is however running at the same time as stems production, so I wonder if it is causing some bizarre quirk?
Nah, i don’t see that being an issue specifically. It’s just a quirk of MacOS. This purgeable space will be deleted by MacOS (most of the time) when space is being allocated by a process.
Stems are located in the ~/Music/Engine Library/ directory, even if the music is stored externally. (btw, I use an external SSD exclusively)
For speed, engine will use the host computer’s OS volume for temp file generation and this can be backed up, depending on where it is located and if the temp dir is in the exclusion list or not for Time Machine.
This is my current system as/is. Look at how much purgeable space there is.
That’s what limits the stems process, the issue’s the time between purging and filling. Sure the engineers can fix that somehow.
maybe. this is one of those “it’s outta our hands” type of situations that is unique to MacOS and perhaps unique to the process of creating stems for an entire library.
Maybe - there must be a way to code purging though, if DaisyDisk can do it.
I’m thinking more to prevent the complaints down the line, obviously we know what to do anyway.
Eh. DaisyDisk requires admin permissions.
Long story short, it’s complicated. XD
