Slashdot Mirror

← Back to Stories (view on slashdot.org)

Spotify Is Writing Massive Amounts of Junk Data To Storage Drives (arstechnica.com)

Posted by BeauHD on from the junk-data dept.

An anonymous reader quotes a report from Ars Technica: For almost five months -- possibly longer -- the Spotify music streaming app has been assaulting users' storage devices with enough data to potentially take years off their expected lifespans. Reports of tens or in some cases hundreds of gigabytes being written in an hour aren't uncommon, and occasionally the recorded amounts are measured in terabytes. The overload happens even when Spotify is idle and isn't storing any songs locally. The behavior poses an unnecessary burden on users' storage devices, particularly solid state drives, which come with a finite amount of write capacity. Continuously writing hundreds of gigabytes of needless data to a drive every day for months or years on end has the potential to cause an SSD to die years earlier than it otherwise would. And yet, Spotify apps for Windows, Mac, and Linux have engaged in this data assault since at least the middle of June, when multiple users reported the problem in the company's official support forum. Three Ars reporters who ran Spotify on Macs and PCs had no trouble reproducing the problem reported not only in the above-mentioned Spotify forum but also on Reddit, Hacker News, and elsewhere. Typically, the app wrote from 5 to 10 GB of data in less than an hour on Ars reporters' machines, even when the app was idle. Leaving Spotify running for periods longer than a day resulted in amounts as high as 700 GB. According to comments left in the Spotify forum in the past 24 hours, the bug has been fixed in version 1.0.42, which is in the process of being rolled out.

6 of 196 comments (clear)

  1. Typical of today's programmer by rfengr · · Score: 5, Insightful

    Bandwidth, memory, clock cycles....don't matter. Use more shitty layers of abstraction over layers built into high level languages, then kick it out the door.

    1. Re:Typical of today's programmer by Anonymous Coward · · Score: 5, Insightful

      If you can't differentiate between bad programming and high-level programming with abstractions, you're part of the problem.

      PS lots of great software is written in higher level languages than you're probably capable of ever reading.

    2. Re:Typical of today's programmer by jareth-0205 · · Score: 3, Insightful

      Bandwidth, memory, clock cycles....don't matter. Use more shitty layers of abstraction over layers built into high level languages, then kick it out the door.

      Well, what do you expect? Everyone expects client programmers to support more devices, more user for less money, cheaper / free apps. The last 3 places I've worked at had no QA department whatsoever.

      I know it's fashionable to shake the fist at 'lazy' programmers, but the fact is we expect more functionality from less dev time, requiring abstractions, libraries that aren't completely controlled or understood, testing skipped, etc. Programmers aren't the problem, relentless competition is.

    3. Re:Typical of today's programmer by Anonymous Coward · · Score: 2, Insightful

      Well, what do you expect? Everyone expects client programmers to support more devices, more user for less money, cheaper / free apps. The last 3 places I've worked at had no QA department whatsoever.

      I know it's fashionable to shake the fist at 'lazy' programmers, but the fact is we expect more functionality from less dev time, requiring abstractions, libraries that aren't completely controlled or understood, testing skipped, etc. Programmers aren't the problem, relentless competition is.

      I certainly expect better. Open source delivers quality - again and again. Any organization with an actual budget ought to do better. And please note that the competition is on quality, not on prettyness, and not on delivery date either.

      Also, this can't be a bug resulting from sloppy programming. Sloppy/quick programming results in apps that crash "occationally" and a lot of corner cases that aren't quite right. This MASSIVE writing is something else entirely. Fortunately, spotify is not necessary. In my case, it lost to the "relentless competition": Buying CDs and ripping them myself "just works". No io at all, except during playback or ripping. And then it is merely measured in kB/s. . .

  2. Re:Do not store songs locally by Rockoon · · Score: 4, Insightful

    Im not sure its a problem solved by that.

    I think the gist of it is that for every small change to the data they store on your device, they are re-writing the entirety of the dataset they are keeping. So for instance they are logging a record that says "didnt play music this minute" but are re-writing the entire multi-year log.

    I blame XML and other formats that are used for the stupid reason that "we already have XML routines so lets use it for everything"

    --
    "His name was James Damore."
  3. Re:Do not store songs locally by Hognoxious · · Score: 4, Insightful

    Rust spinners wear out too. This can be a particular problem if it's constantly bringing the drive out of power-down.

    --
    Confucius say, "Find worm in apple - bad. Find half a worm - worse."