High disk writes?

[MasterRahool]

Heard the other day that OneDrive tears through SSDs so thought I'd check to see how much it was using on my system, only to be surprised that LSS was leading all apps. Is this normal?

[MasterRahool]

So fired up my laptop today and noticed I'm up to 80gb with the app running, and didnt even remember listening to music last night bh

watching the stats, I hit shuffle and noticed it bump up 80.04gb to 80.10 when the track started and then 80.13gb, where it stayed for the duration of the track, so 0.09GB written

hit shuffle again and my dac clicked, went up to 80.18GB briefly then 80.25GB, or 0.12GB. So the app is writing over 100MB per track, even when no switch occurs (next track was 44.1k and no switch, went from 80.25 to 80.45)

...is that excessive?

[vincentneo]

Refer to issue #28, issue has something to do with the detection method itself (OSLogStore), so no solutions thus far.

[ruangraung]

Hi everyone, just chiming in to report that I am experiencing this exact same issue, specifically on the 2.0-beta3 release. In my case, the logd process is writing a massive amount of data to the SSD—around 1 GB every 20 minutes (which translates to roughly 3 GB per hour) whenever Apple Music is playing and LosslessSwitcher is active.

I monitored this closely using Activity Monitor. The moment I quit LosslessSwitcher, the aggressive disk writes by logd stop completely. I understand this might be related to how OSLogStore is used to fetch the sample rate, but the amount of data being written in this beta version feels exceptionally high and is concerning for the SSD's TBW.

For context, here is my setup:

Mac Model: Macbook Air M4 2025 (16 GB RAM, 256 GB SSD)

macOS Version: macOS Tahoe 26.3

LosslessSwitcher Version: 2.0-beta3

Apple Music Version: 1.6.3.2

Hopefully, this additional data point helps highlight the severity of the issue in the current beta. Is there any workaround or command to reduce the debug logging verbosity in the meantime? Thank you.

[vincentneo]

Do you feel it is worse in beta 3 as compared to beta 2?

[ruangraung]

As far as I can remember, it is the same. The logd writes a massive amount of data every time I run LS, and it stops right away after I close LS. Sorry if it is OOT, but since you're here I want to ask you this: I don't know if you notice it, but there's fork of LS here by FantasticSkyBaby, I've tried it yesterday, it works flawlessly without "the logd issue" I experienced with the latest LS beta 2 and 3, but then after some thought I decide to uninstall it again because, I don't know, I just cannot trust the new fork from what seems to be "new developer". May I have your opinion on whether this fork of LS is safe to use? Thank you.

[vincentneo]

@ruangraung I am aware of the fork and its alternative approach to get the logs, though I have not checked the code in depth enough to give you an opinion on safety.

Might adapt their approach on log retrieval if proven safe, reliable and better than current approach, in the next version of LS :)