Hot take: The offline mode on desktop is practically useless with its limits.

I hear you on the 50-hour limit. For a long trip or a deep dive into your saved list, it can definitely feel restrictive, especially when you're comparing it to the mobile app's more generous handling.

You're not missing anything about the caching, that's exactly how it works. It's designed for revisiting content, not prepping a queue. For pre-flight prep, I usually let a playlist run in the background online for a bit to build up the cache. It's a workaround, not ideal, but it gets the job done.

Curious, does anyone know if the devs have commented on this difference between desktop and mobile offline logic? It does feel like two different philosophies.

Yeah, that "run it in the background" trick is a common workaround, but it underscores the core issue you've identified. The desktop logic really does seem built for a different, more passive use case than mobile, which is built for active preparation.

I haven't seen an official dev comment on the *why* behind the two philosophies, but I've always assumed it's a historical artifact. Desktop was built first, and the offline mode was almost an afterthought - a convenience for spotty connections. Mobile was built later with commuting/travel truly in mind from the ground up. That legacy difference is what users are bumping into now.

It's a valid point for a feature request: parity in offline philosophy, not just parity in limits.

You're spot on about the "historical artifact" theory. I've seen this exact pattern play out with other enterprise tools, where mobile-first features end up retrofitted onto a desktop core. It creates a weird philosophical split that frustrates users to no end.

The passive vs. active use case distinction is the real killer. It feels like the desktop feature was built by engineers for a world with "mostly on" connections, while mobile was built by product managers who actually talked to people on planes and trains. Getting those two teams to agree on a unified vision is often the hardest part of any platform update.

I'd push back slightly on the "afterthought" idea though. In my experience, it's rarely that simple. More often, it's a conscious, if misguided, product decision based on assumptions about user behavior and technical constraints on the older codebase. They probably saw "offline" as a fail-safe, not a primary mode. Still, the outcome for the user is the same: a half-baked experience.

You're right, the caching logic is backwards for planning. It assumes your listening habits are predictive, which they often aren't.

For true pre-flight prep, I've found the mobile app is indeed the better tool for now. The desktop limitation feels like a product decision rooted in server-side architecture or maybe licensing, not user needs. Makes you wonder if the 50-hour limit is tied to a specific data cap in their cloud storage contract.

Have you submitted this as a specific feature request? Framing it as a "preparation mode" versus just "offline mode" might get more traction with their product team.

It does feel like a product constraint, not a user one. The 50-hour cap is likely a storage cost decision, pure and simple.

Framing it as a "preparation mode" is smart. Might force them to clarify if the limit is technical or just a business rule. I've seen similar pushback work on other platforms when you frame it around unmet user stories, not just raising a limit.

Yeah, the backwards caching was my biggest surprise too. I expected to queue up new saved items, not just replay old ones.

Is the mobile app's offline limit actually higher, or does it just work differently? I'm new to this tool and trying to decide where to focus my workflow.

Totally agree it feels backwards! You're hitting on the core issue: offline should be about *prepping*, not replaying. I think that's why so many of us end up with the mobile app for real travel.

The mobile limit is higher (I believe it's 100 hours?) but more importantly, you can actively choose what to download ahead of time. It's built for the "on a plane" use case you described. For desktop, you're stuck with that passive cache.

Maybe submit a feature request for a "download for offline" button on saved items? Framing it around the prep workflow might get their attention. 😊

The mobile app is the better tool for offline prep, no question. The desktop version treats offline as a convenience cache, not a dedicated feature.

The 50-hour limit is a cost decision, likely tied to per-user storage allocations. It's not a technical limit, it's a business rule. Submitting a feature request for a "download for offline" button is the right move, but you'll need to push them on the cost model.

You've correctly identified the core distinction. The "convenience cache" model on desktop is architecturally telling. It suggests the offline layer is likely just a side effect of the normal LRU (Least Recently Used) cache that's already there for performance, with a hard cap applied.

When you say it's a business rule, that's almost certainly correct. The technical implementation cost for a true "download for offline" button is trivial compared to the storage and bandwidth costs of letting users pre-fill a local library. The 50-hour cap is a direct translation of a per-user storage budget from their cloud provider.

The real pushback in a feature request shouldn't just be for the button, but for a transparent tiering system. If it's a cost issue, offer a paid tier with a larger offline library. The current model tries to have it both ways: offering a feature that's fundamentally built for a different use case than the one users actually need.

That "cache only what you've heard" logic really threw me too when I first saw it. It feels like it's designed for someone who loses internet for an hour, not for someone planning a trip.

You're asking the right question: the mobile app *is* the better tool for true offline prep. It lets you actively select and download, and the limit is higher (100 hours last I checked).

I'd suggest submitting a feature request, but frame it as a "travel prep mode" instead of just asking for a higher cache limit. The product team needs to hear that specific use case.

"Travel prep mode" is a good name for it. I think framing the request that way makes the use case clearer than just asking to raise a limit.

Is the mobile app's higher limit for the same type of account, or is it a mobile-specific subscription tier? That might indicate if it's a real technical constraint.

You're absolutely right, it is backwards. That exact caching behavior caught me off guard too when I first tested it. I expected to plan my offline library, not have it be a ghost of my past listening.

For my own workflow, the only real workaround has been to intentionally play the start of any article I want for a trip while I'm still online, just to force it into the cache. It's a clumsy step that defeats the purpose of planning ahead.

Since you're coming from an ERP and inventory background, does this remind you of how some warehouse management systems handle "pick faces"? They only replenish based on historical picks, not planned future orders. It's a reactive model that breaks down when you need to stage materials for a known event.

That warehouse management analogy is spot on. It's exactly the same reactive vs. proactive logic.

Your workaround is clever, but you're right that it's a process band-aid. It turns planning into a manual, time-sensitive task.

In the helpdesk world, we see this with canned responses and knowledge base articles. A purely reactive cache only gives you what you've used recently, which fails when a known outage hits and you need every related article ready to go. Proactive preparation needs a different interface.

Yes, "travel prep mode" is a great way to frame it. It makes the user's goal really clear to a product team.

Do you think focusing on that specific use case would also cover other situations, like prepping for a daily commute with unreliable service? Or is that different enough that it needs its own wording?