By default, Infuse will download and cache images (poster & fanart) for each title in your library. Disabling the ‘Pre-Cache Images’ option will prevent Infuse from downloading all artwork, and instead will load images on demand while browsing. This may be a good option if you want to reduce overall bandwidth usage by the app, but may result in a slight delay before artwork appears when browsing.
If streaming from a local server, having images cached would also allow you to have the full library experience when the local network is working, but internet access is not available (due to an outage).
This pre-caching of images is part of the library scanning process, and you can monitor the progress/status of this in Infuse > Settings > Library.
Then the bug is that this image caching is downloading all video files as well. Have a look on a bandwidth monitor or by using mitmproxy. You’ll see that it’s downloading MKV files. I mean just letting it open on the home screen will download all media files by 8-10 MB/s!
There is also a phase of the indexing process that will read a small portion of each file in order to display specs such as duration, resolution, codec, etc… The status for this can also be found in the Settings > Library section.
Furthermore, if you happen to have the ‘Embedded Metadata’ option enabled, Infuse will read details from within the video (including artwork). And if the ‘Metadata Fetching’ option is disabled, a few frames of each video will be read in order to generate a thumbnail image for each video (if no embedded artwork is present).
In order to minimize overall bandwidth usage, you can adjust these settings.
Look, there is definitely a bug in there. By running mitmproxy you’ll see that the GET requests have
This is basically a range request which is not a range request, it’s downloading the full file!
I don’t want to look into what switch is doing what, I’m reporting a serious bug in the app which is downloading full MKV files and destroying a user’s internet connection.
Luckily I’m not on a cellular connection (otherwise it’d have killed my monthly allowance already). Having a few MBs downloaded for the better experience is totally fine, so I’m not trying to save MBs.
That bug is almost saturating my internet connection though, so we are talking about 10s of GBs, not just a few MB.
Here is the command which allowed me to debug this issue:
We have looked into this, and confirmed the behavior is expected.
The Range: bytes=0- parameter isn’t actually an error. Depending on the video type, some videos may have metadata present at the front of the file, while others may have portions of it at the end, or in other areas. The exact location isn’t known until Infuse has a chance to examine the actual file, so having the ability to access the entire file is necessary in order to support the widest array of file types.
Please note that while Infuse may send a request for the full file, that doesn’t mean the app will read the entire file to the end. IE The entire file is not getting downloaded to your device during indexing.
Sometimes, getting metadata or thumbnails can put a bit of load on the network, but it isn’t specific to a single protocol type, and other connection types (such as SMB, NFS, FTP, etc…) will behave the same way.
In general, indexing is a one-time process and does not need to be repeated. Also, if you are using multiple devices, Infuse can use iCloud Sync to share these fetched details between devices to avoid having to rescan the same content more than once.
Left unchecked yes it would continue downloading until the file is fully downloaded, but the download is controlled by further logic within the app.
If you are seeing bandwidth decrease when disabling the ‘Pre-Cache Images’ option, then it is likely that most of the bandwidth is in fact artwork coming from TMDB.
For reference, each movie will have a poster, landscape fanart, and logo image. This may add up to a few MBs per title for movies, and potentially more for TV shows as there are unique images for each series, season, and episode.
Unfortunately that wasn’t the case. Neither turning off “Pre-Cache Images”, nor “Metadata Fetching” helps.
But I still don’t get it, Range: bytes=0- is the full file. If you are interested in the beginning and the end, then why don’t you just ask for the first and last 100 kB maybe?
OK, I reset the app using AppCleaner and re-added everything, everything is on default settings.
It stopped on one movie (80 our of 172), at that point I sent a diagnostic log email and re-started the processing.
This time it did complete, after about 30 minutes, consuming 3.23 GB of data. Also this time if I click on “Scan for Changes” or even “Refresh Metadata” it works correctly, it doesn’t consume any more bandwidth.
Yesterday it was definitely not working like this, it was just downloading and downloading 2-3 hours after starting. And even after finishing, every time I clicked “Scan for Changes” it re-started this hour long downloading.
I understand your points about the range requests, it indeed doesn’t load the full file, I guess you are terminating the request on client side.
