Limit disk buffer size

Channels Apple TV Feature Requests
#1

Hi,

I’ve been tracking down an issue I’ve been having with Infuse occasionally losing its metadata and artwork on my AppleTV. It looks like it’s due to the playback buffer in Channels thanks to how the ATV works. The ATV only allows 500 KB of persistent storage that is not purgeable. What appears to be happening is that while Channels is recording the playback buffer it’s getting large enough that tvOS starts purging other app’s data. In my case, probably because it’s the largest, Infuse’s metadata cache is getting purged. I’ve been testing it this weekend while watching the NCAA tourney and every time I leave Channels running for a couple hours and then launch Infuse the metadata is gone and it starts indexing everything again. While not the end of the world it get a little annoying since there’s a bunch of manual corrections that have to be done each time.

Is there a way to limit the buffer size? If not I’d like to make a feature request for it. For how I use Channels and watch TV I don’t need a long rewind time. 10-15 minutes is more then sufficient for me since it’s mainly used when watching live sports. A quick replay or pausing while running to the bathroom is all I ever use it for.

Thanks

1 Like
#2

Yuck. It’s really unfortunate how tvOS’s storage is designed. This seems like a reasonable request- thanks for the details reasoning and use-case. We’ll have to see where we can fit it in…

#3

It’s weird that Infuse has to re-scan instead of re-sync. Doesn’t Infuse sync metadata with iCloud? Maybe that’s an option you have to select? Give that a look and maybe it will resolve some of the headaches for now.

#4

You have to have the Pro version to iCloud sync and I believe it is turned off by default.

#5

BTW, this could be one of the first use cases for the 64GB vs the 32GB version of the AppleTV. In this case the temporary storage for the Channels playback buffer is causing tvOS to purge persistent cached meta data for Infuse. I guess I go back to recommending the 64GB version to friends just to be safe.

#6

Infuse iCloud syncing is only for network shares, settings, manually corrected metadata, and file specific playback settings. The library parsed cache and the artwork are only stored locally. They don’t put them into iCloud due to how large it can be and users might only be on the free data tier.

snow66, it’s the first use case I’ve run into for the 64GB version. I have one in the bedroom that I’m going to swap out with the living room. When I moved I just set-up the first one I grabbed since it had never mattered before.

#7

Yeah, I’m a mac/iOS dev myself and I hate the way they implemented storage on the ATV. Having a little more protections for cases like this would be really nice. Unfortunately it’s not going to happen any time soon. Infuse had a radar for it that I duped. Apple closed out the Infuse one yesterday saying not a bug, working as intended.

#8

I wanted to renew this issue. I agree with the original poster that this is a contributing factor to Infuse's cached library being frequently deleted. Additionally, since this issue was first created, Apple Arcade was released, which significantly contributes to storage space consumption especially on 32GB model ATV4Ks.

Personally, I don't need a rewind buffer and only need a limited pause buffer. So, I would certainly appreciate a simple means to either disable or limit the size of Channels buffer.

#9

Just stumbled across this and it now makes sense why Infuse keeps dumping my metadata. I thought it was my Apple Arcade games even though I was only using 50% of the storage on my Apple TV 4K.

Infuse does have iCloud sync but it still takes about 3-5 minutes to pull this info when it gets dumped.

Is it possible to have an adjustable buffer that can be adjusted in the settings? My wife has a habit of pausing live tv and walking away for extended periods of time. I’m guessing that’s what’s causing the dump in Infuse.

#10

Or, a different approach entirely, perhaps.

Moving the buffer to the server would alleviate all of these problems, and allow for a larger buffer for space-constrained devices. This would also allow for shared buffers among clients, and also make possible multiple live buffers to facilitate PIP or quick channel flipping à la DirecTV's "DoublePlay" feature.

(Of course, this would be a huge refactoring of the program. It would also make Channels' dichotomy of allowing a live viewing program that streams directly from the tuner to exist with the DVR-centric approach that tuner sharing brings a much more difficult problem to tackle.)

#11

Fast tuning, fast seeking, and low disk space usage on streaming devices are all at odds with each other, unfortunately.

The reason why the Live TV buffer is on the client is because of the roots of the app as something that doesn't require a server component at all.

The reason why we have so far kept the Live TV buffer on the client is that there are a lot of benefits in responsiveness as well as a better experience in less than perfect network conditions.

It may be in the future that we develop techniques that can get over these hurtles, but at the moment there is not anything strait forward that we can do with the technologies we have in place that would not add multiple seconds of tuning latency for channel changes.

So far we have been prioritizing responsiveness of app playback and have been comfortable using any available disk space for our buffering if it means we have a better playback experience.

It's useful to know that people are running into issues with other apps by doing that, but it's also something that (as was discussed above) we have limited control over due to how tvOS works.

2 Likes
#12

@Eric, I appreciate your response but don't fully understand its technical dependencies.

Specifically, I don't understand why there can't be a maximum cache size for the Channels app, whether that's 250MB, 500MB or 1GB. Within that, prioritize whatever ATV storage space is needed for fast channel tuning. Then, current channel stream buffering for whatever remaining storage space is left.

As far as I can tell from my.hdhomerun.com, no channel is tuned in advance of me selecting one in the Channels guide. Therefore, there shouldn't be any video to pre-cache. After I have tuned to a particular channel, all I request is to limit the size of that cache. To the extent that a user leaves the program paused in excess of the size of the user-defined cache, discard video data FIFO.

1 Like
#13

I disagree with this as all the issues I have ever seen on all my devices are all caused by the buffer being on the client. That's my experience how I see it.

#14

Considering that Channels started out as a live TV program only with DVR component, originally there would have been no place but the client to store the buffer.

Also, since the original use was for streaming from an HDHR tuner, keep in mind that OTA HD content streamed from the device is about 2.5GB/30mins.

#15

It's not about the amount of data moved. I just have zero issues when I play from a recording on my DVR.

#16

The reference to file size was because of the live TV buffer. The Channels client app needs approximately 2.5GB of storage space in the device to hold a 30 minute buffer of OTA TV. While you may be fine only having a 3 minute pause buffer when watching live TV, but I prefer to have at least 15 minutes; 90 would be better.

#17

I'm ok with a large buffer and agree, I would just rather have the buffer on the DVR.

#18

Me too I hate having the DVR Buffer on the Client. That is why I do not watch LIVETV using channels DVR. I prefer using SageTV where I can keep the buffer as a recording on my SageTV DVR server from the point I started watching.

#19

Limiting the rewind buffer on Live TV to 6 or 15 minutes (the amount of time for buffers of OTA content of that size) would not be what most of our customers wanted or expected.

Again, there are certainly things that we could do to optimize for using less disk space, but as of today, that has not been a major concern for our customers. If we had spent effort on that, it would have been at the expense of features that have made a bigger positive impact for our customers.

#20

Based on my understanding of the codebases involved and the logs that I've seen, I don't agree with this assessment.