Category: Technology

There is a particular kind of frustration that comes from a problem you cannot see, cannot touch, and cannot fix — but know with absolute certainty is real. For several months, my music kept stopping. Not constantly, not predictably, but often enough that every morning listening session carried a low-grade dread: is it going to skip today?

I’m going to tell you what I found. Some of it involves network diagnostics and log files; I’ll translate all of that into plain language. But the short version is this: I proved — with data — that the problem was never on my end. And then I cancelled my Qobuz subscription.

The Setup

Bear With Me, Non-Audiophiles

First, some context. Music matters to me. I’ve been playing piano for about a half century, and guitar for most of that time too. I grew up listening to high end audio equipment my father built. These days, I spend real money on my own audio equipment. My current listening chain runs from a Roon Server — essentially a dedicated music computer — through a Bluesound NODE, into my main system. Roon fetches hi-res audio from Qobuz, a streaming service that specializes in high-fidelity music files, and delivers it without any quality compromise.

Hi-res audio from Qobuz — think 24-bit, 192,000 samples per second — requires a reasonably fast and stable internet connection to stream properly. Not extraordinary, but consistent. A rough analogy: it’s like streaming a 4K movie. You don’t need a fiber connection, but you need one that doesn’t randomly drop to dial-up speeds for ten seconds at a time.

That is exactly what was happening.

The Clues

Roon keeps detailed logs of everything it does, including exactly how fast it’s downloading audio from the streaming service at any given moment. When the download speed falls below what’s needed to play a track without interruption, it logs a warning. When I started pulling those warnings out of my logs, the picture was striking.

March 28 – April 6, 2026

I began my first systematic analysis. Twenty log files. Thousands of streaming events. The pattern that emerged was so clean it almost looked manufactured.

One log file covering over eight hours of overnight streaming — tens of thousands of audio data requests — recorded zero errors. The log file from the following afternoon recorded over a hundred. The server hadn’t changed. The internet connection hadn’t changed. The only variable was the clock on the wall.

In the IT world, this is called a time-of-day pattern, and it almost always means one thing: peak-hour congestion somewhere on the delivery network.

Writing to Qobuz

April 7, 2026

I wrote Qobuz a detailed support email — not a “my music keeps stopping please help” complaint, but a technical brief. I had run network path analysis, checked DNS resolution, verified my firewall and security configuration, and ruled out every local cause. I told them exactly what I had found: the problem was consistent with peak-hour congestion on the Miami-area Akamai server that delivers audio to Florida customers.

“Analysis of 20 Roon log files covering March 28th through April 6th reveals a clear and consistent pattern: sessions running overnight — approximately 1:00–9:00 AM ET — recorded zero streaming errors despite tens of thousands of active Qobuz CDN requests. Sessions running during daytime and evening hours recorded hundreds of failures each.”

— from my April 7th email to Qobuz Support

I also asked them to investigate the specific Akamai edge server — I had identified it by name: a1094.dscv.akamai.net, serving out of Miami — and to look at its performance during daytime peak hours for Florida customers.

April 11, 2026

Qobuz replied. They acknowledged the problem and gave me an explanation I found credible: a caching anomaly in their content delivery network. In some cases, certain servers were delivering incomplete or corrupted audio files. They said they’d performed a cache purge — essentially clearing the bad data from their servers so fresh copies would be fetched — and asked if things had improved.

“Our teams have identified the source of the problem. It is related to a caching anomaly within our content delivery network (CDN). In some cases, certain servers may temporarily deliver incomplete or corrupted audio files.”

— from Qobuz Support

April 12, 2026

A follow-up arrived. Jesse told me the ticket had been marked closed but that he was personally monitoring it and would follow up once the team had more information. He asked if I’d be willing to do another log analysis to see whether things had improved.

I said yes. I would run another analysis and report back.

That was the last I heard from Qobuz.

The Second Investigation

April 17 – May 10, 2026

I analyzed 21 additional log files covering 23 days of listening — approximately 130 megabytes of data, around 450,000 lines of logs. The findings were not encouraging.

The time-of-day pattern from my first investigation had not improved — it had, if anything, sharpened. Nearly three-quarters of all failures occurred in the morning window between 7 and 11 AM. The cache purge had not fixed the underlying problem.

How bad were the drops?

To play 24-bit hi-res audio without interruption, Roon needs a sustained download speed from Qobuz’s servers. Think of it as a floor the connection needs to stay above. Here’s what I was actually receiving:

For Non-Audiophiles

To put those percentages in context: if you ordered a glass of water and received a thimble, the restaurant would be delivering roughly the same proportion of what you asked for. 84 individual events across 23 days showed throughput under 200 kbps. Some of these lasted five to ten minutes at a stretch.

The Smoking Gun

Good detectives don’t just collect evidence of the crime — they find the comparison that makes the evidence undeniable. Here’s mine.

Around the time of my second analysis, I added TIDAL as a secondary streaming service alongside Qobuz. TIDAL also offers hi-res audio. Same Roon Server. Same internet connection. Same Bluesound NODE. Same house, same morning, same cup of coffee.

Both services were streaming 24-bit hi-res audio to the same device, over the same connection, through the same firewall. The sole difference was the company delivering the audio.

This comparison eliminates every possible local explanation — my router, my ISP, my Roon configuration, my Bluesound endpoint — all in one stroke. If any of those were the cause, TIDAL would suffer the same failures. It doesn’t. The only thing that differs is whose servers are delivering the audio. Qobuz uses Akamai. TIDAL uses its own infrastructure. Akamai struggles in my region during morning hours. TIDAL does not.

Why it Matters – and Why I’m Sharing It

If you’re a normal person who just wants music to play, none of the kilobits-per-second stuff matters to you directly. What matters is this: your streaming service may be failing you, and you’d never know it unless you investigated. The music just… stops. Or skips. And the easiest explanation — the one you’re most likely to assume — is that your internet connection had a hiccup. Maybe it did. But maybe it didn’t.

If you’re a Qobuz subscriber in Florida, or anywhere in the southeastern United States, and you’ve been experiencing morning skips and dropouts: it’s worth knowing that this was a documented, ongoing infrastructure problem with Qobuz’s Akamai CDN. It wassn’t your router. It wasn’t your ISP. It wasn’t your streaming app.

And if you’re an audiophile wondering whether TIDAL’s hi-res tier holds up under real-world conditions: in my experience, measured over dozens of sessions on the same hardware, it absolutely does. The contrast could not have been more stark.

As for me — I’ve moved on. The music plays now, every morning, without drama. Sometimes the best diagnostic result is knowing exactly which variable to change.

Steve Haney is a Sarasota-based IT consultant, and reluctant audiophile who apparently reads server logs for fun. His Roon server runs on Ubuntu 24.04. The Bluesound NODE has no idea how closely it’s being monitored.