"Empty downloaded file" when caching songs

Issue description:

When caching tracks from my Jellyfin server, roughly one in ten downloads fails with a “Empty downloaded file” error.
Usually upon retrying once or twice it can download the track successfully, but sometimes it breaks and the track seems cached but does not actually play when offline.

Logs:

Note: I’ve redacted my Jellyfin server’s address. Let me know if this is a problem.
debug.log (773.6 KB)

Screenshots:

Additional information:

  • Jellyfin 10.8.8 (in Docker), behind Caddy 2.6.2 reverse proxy
  • Symphonium 3.2.0
  • motorola edge 30 pro, Android 12

From the logs seems your server sometimes just does not send data.

Symfonium is relatively aggressive with downloads, check Jellyfin/Caddy logs for errors or security triggering.

Every time the download fails, I get an error like this in Caddy’s logs.

Jan 23 12:29:15 lion caddy[3441]: {"level":"error","ts":1674487755.2051756,"logger":"http.handlers.reverse_proxy","msg":"aborting with incomplete response","error":"http2: stream closed"}

Ok so check Jellyfin side that is probably the source in that case.

There doesn’t seem to be any errors in Jellyfin’s logs other than the odd “Slow HTTP response” warning, but they’re not very constant.

Even within my local network now, connecting directly without the reverse proxy, the error crops up.

Can you provide new logs when on the local case ?

I log every possible errors this makes no sense. If there’s still no error in the new logs that Caddy may have hidden, I’ll try to send you a build that force HTTP/1.1 to test.

Here’s new logs, connecting directly to Jellyfin in my local network.
log_cut.log (2.3 MB)

Ok thanks so again no error :frowning: Will send you a test APK by PM later today or tomorrow with a setting to disable http2 and limit to 1 concurrent download to see.

Got it, thanks for all the help so far.

Just in case you do not have some optimizer tools on your device that could run and delete the temporary file?

I do have SD Maid but it only runs on demand, not in the background, and I haven’t used it in well over a week.

With HTTP/2 and concurrent downloads disabled, I was able to download 3 large albums with no issues so far. I’ll keep downloading more to be sure but I feel like I would have run into issues by now.

It’s definitely a lot slower, but I’ll take reliability over speed.

Well yes 1 by 1 and slower protocol version. But this confirms a server side issue :frowning:

Anyway the workaround is added as an option and will stay starting next release.

Just to be thorough, I redownloaded a relatively big playlist, and it seems to have gone without a hitch, here’s the log file for that.

debug-20230124_145406.zip (2.4 MB)

Yeah, unfortunately it seems it’s a weird server side problem but, I don’t mind the slower speeds much, I just wanted the downloads to be more reliable.

Thanks for all the help.

1 Like