On Bazzite 43 and 44, I’ve noticed Haruna constantly writes a small amount of data to the boot drive whenever it’s actively decoding audio or video. The writes end slightly before playback does.
Does anyone know what’s up with this, and if it’s a bug? This behavior isn’t ideal on an SSD.
Currently happening on Haruna version 1.7.1; unsure which previous versions I might have seen it happening on as well.
Do you also see the same spikes in your network graph, in other words, is this data also been sent out of the computer?
Think you answered your own question. Sounds like Haruna may be decoding in real time.
i’m no programmer, but shouldn’t it be using ram for that?
One would think so. Is there a way I can test this out cause my roommate has this program?
I don’t think the SSD argument holds anymore. Given the numbers and modern SSD drive, you are looking multiple decades of 24/7 use before reaching the ratings (and that doesn’t mean dead disk). But sure, it’s cumulative over all other usage as well. It’s just bit outdated concern in any standard desktop use. Nothing wrong being curious tho!
No visible change in the network graph when Haruna is running or when it’s actively playing.
With wear leveling, yeah this should be true. My concern was that it’s rewriting the same small file somewhere over and over continuously, but firmware wear leveling would prevent that from depleting the write cycles of a particular set of cells.
This is still bothering me. Why is it doing that? What is it writing and to where? Is it using the disk as memory for no reason?
If I’m not mistaken Haruna uses a database (think SQLite) for storing the current position of the video you are watching. That could explain the writes you are seeing.
Horrible if true. No reason to update that on disk constantly instead of occasionally.
But also that wouldn’t explain why the writes stop before playback does, unless that’s just the threshold where it considers playback “done”?
Maybe submit a feature request to have an option to disable in Settings or just save the position on quitting.
For now you could maybe adjust the ‘If duration longer than x minutes’ and ‘Save position every x seconds’ under Settings > Playback.
I haven’t tested this but I’m assuming a large value in the duration field should effectively stop it from saving the position.