SageTV data usage?

[MattHelm]

I have a friend I may be setting SageTV up for, but he has a VERY limited data plan.

Any idea how much data SageTV using SD guide data uses?

Do any of the other features use any data? (Movie pictures and channel logos???)

[reggie14]

How limited?

I don't know how much data it uses, but many years ago I used it on a dial-up modem, so it couldn't be using that much data.

[rkulagow]

Originally Posted by MattHelm

I have a friend I may be setting SageTV up for, but he has a VERY limited data plan.

Any idea how much data SageTV using SD guide data uses?

[I designed the JSON data service]

The amount of data on the initial download is going to be the worst in terms of data usage, because your local cache will be "cold".

Each time you connect to the JSON service, the grabber in SageTV (if it was written to take advantage of our published API spec) will only need to determine what has changed. If the schedule for a channel / date / time hasn't been updated, then the MD5 for that particular combo will be the same, (there's a special command that the grabber should send our servers requesting the MD5 for a channel / date so that it can compare its local copy to what's on the server) and Sage should be able to determine that it has "nothing to do".

That extends to the programs in each timeslot on each channel. If the MD5 is the same on the server and on the client, you don't need to download the details for that program, because SageTV already has them.

Finally, the data sent by the server is compressed (because it's all text, so highly compressible), so overall it's very bandwidth efficient.

But it's that first download which will take the longest, so you can either be selective in which channels you want data for and space it out over time, or just take the hit and realize that it's going to take a while.

[EnterNoEscape]

The integrated service does take advantage of the MD5 hashes and only downloads content/updates airings that have changed. The images are stored as URL's until asked for. Then they are downloaded and cached. If downloading images is of concern, a feature could be added to prevent the channels, shows and seriesinfo from returning images.

[MattHelm]

OK, he has a cell data plan, just wants to keep as much as he can. From all of your input, it sounds like he'll be OK. Thanks. I don't think the channel data would be an issue, I was more worried about the show/series.

[stuckless]

I would definately NOT install BMT/Phoenix/Gemstone... Fanart is likely the biggest data grabber.

[SomeWhatLost]

Originally Posted by stuckless

I would definately NOT install BMT/Phoenix/Gemstone... Fanart is likely the biggest data grabber.

but for me at least, BMT/Phoenix/Gemstone make sage, well sage... just would not be the same without them...
if you have a bunch of movies/stuff, I imagine the initial hit may be pretty bad...
but what about after that? does it really use that much on a day to day basis?

[MattHelm]

Originally Posted by EnterNoEscape

The integrated service does take advantage of the MD5 hashes and only downloads content/updates airings that have changed. The images are stored as URL's until asked for. Then they are downloaded and cached. If downloading images is of concern, a feature could be added to prevent the channels, shows and seriesinfo from returning images.

Had do I formally request this feature?

[EnterNoEscape]

Originally Posted by MattHelm

Had do I formally request this feature?

You would open a new issue on GitHub. It would probably be best implemented as a global feature and not just for Schedules Direct. In other words, flip this switch and all shows and channels will always report that they have no images regardless of it they actually could download images or not.

[MattHelm]

OK, my first ever GitHub post. Please don't slam me too hard for the wording.