WebDAV using far more bandwidth than file size

Streaming & Network
1

Has anyone seen Infuse on Apple TV/iPad pull way more WebDAV bandwidth than the actual file size / watched portion?

I’m using Infuse with TorBox WebDAV. TorBox counts outgoing WebDAV traffic, so I’ve been watching usage closely.

A few data points:

  • Mac Infuse test: I downloaded 10.5GB through Infuse, and TorBox increased from 834GB → 845GB. So basic WebDAV accounting seems correct.

  • Adding an 11GB cached folder to Infuse only increased usage by ~1GB, so merely adding cached content doesn’t seem to be the issue.

  • But on Apple TV, I watched about 1.5 episodes of TV via WebDAV. Each episode is ~1.1GB, so even if Infuse downloaded both full files, I’d expect ~2.2GB usage. Instead, TorBox went from 846GB → 872GB, a +26GB increase.

My Infuse settings are now conservative:

  • Auto Scan: Off

  • Pre-Cache Details: Off

  • Pre-Cache Artwork: Off

  • Smart Folders: Off

  • Streaming Cache: Limited

TorBox support shared backend logs showing large WebDAV transfers tied to the file hashes, so it looks like Infuse/Apple TV may actually be requesting far more data than expected.

Has anyone else seen Apple TV/iPad + WebDAV aggressively re-request chunks, buffer huge amounts, or generate bandwidth far above the file size? Any settings or debugging tips I should try?

2

I don’t have the answer to your question. Sorry

I’m just curious: why using TorBox directly with Infuse and not using a server like a Mac mini or something else?

Isn’t it better to have middleman to do maintenance or management of files?

3

My usage (according to TB) is also quite high. I’m trying not to worry about it, but I know I have not streamed nearly the amount showing on their website.

4

Hi Infuse Team,

I am writing to report a serious bandwidth waste issue I’ve observed during video playback when the streaming cache mode is set to ‘Auto’.

While streaming a 40-minute episode (approximately 2GB in size), my network packet capture revealed that Infuse ended up consuming a staggering 26GB of data.

Here is the exact behavior I observed:

  1. The entire video file is successfully cached within the first few minutes of playback.
  2. However, about 1 minute and 10 seconds after the initial caching is completely finished, Infuse initiates a new HTTP Range request.
  3. From that point on, roughly every 1 minute, Infuse starts a similar Range request that stays active for about 60 seconds before disconnecting.
  4. Each of these redundant requests downloads around 500MB of data, leading to the massive total traffic consumption.

This continuous loop creates an enormous and meaningless waste of network traffic. I have tested the exact same video environment with other media players, and they behave as expected: once the video is fully cached, they stop sending any further network requests.

Could you please investigate why Infuse keeps looping these Range requests even after the file is fully buffered? I hope this caching logic can be optimized in a future update.

Thank you for your time and assistance.

I saw a similar issue in a previous article because ‘tickling’ only requests a few bytes, but the request body I captured showed a different result:

Range: bytes=670498161- ,According to the HTTP specification, this means “returning from this position to the end of the file.” The playback node should only return the complete remaining length. However, in the current Infuse 8.4.8, some requests hold for approximately 60 seconds.

5

If you are able to send in a report from your device (and post the code here) we can look further into what may be going on here.

6

Of course, I have already uploaded the code GYZ08.

7

Today’s 8.5.1 update includes a number of improvements and optimizations for WebDAV streaming, so I’d definitely recommend installing the update and seeing how things work for you.