TiVo actually works with Internet connection down (no BSC)

Advertisements

I don't know when this changed.

It used to be if your Internet connection was down, your TiVo would have all sorts of BSCs (Blue Spinning Circles) even when you tried to playback already recorded shows.

I used to have to disconnect the ethernet wire to get it to stop with the BSCs.

Today I happen to have Internet issues and my connection is down.

Surprisingly I can still playback shows with no BSCs. There is just a blank image for stuff it needs to download in real-time.

 

In the past I have tested pulling the wire from the broadband connection and had spinning circles, which is what led me to pull the ethernet from the unit itself which seems to timeout things much quicker since the interface is down.

I was surprised this time, I didn't even need to pull the ethernet cable from the unit. What you describe seems to indicate this change was in place for at least this year.

 

Advertisements

I wasn't commenting on trying to run TiVo with no Internet connection but rather how "tied" to the server the Real Time usage of the UI was. There was a time when you need to explicitly let TiVo know the Internet connection is down (to have a usable UI) by pulling the cable at the TiVo. Now it appears they keep track of whether your Internet connection is up or down automatically, so even if your broadband modem has no connection (but your TiVo still has ethernet connection) it won't try and access the servers.

Now if the TiVo servers are up, but not responding, then you'll still get BSCs, so it would be nice if they used the same mechanism that they use to tell the system the Internet connection is down (thus skip real time connections to TiVo servers) and trigger that if the servers time out so you get a couple of hours of reprieve from BSCs when the servers are up but not responding.

 

That's why you can just put a flag that says no response last time, don't bother checking for a few hours.

 

Nope, not shut down, pause the real-time queries for a few hours, spare the user from spinning circles while still allowing them to use their DVRs like we used to in series 2 and 3 when the UI didn't have real time queries to retrieve album covers and related meta data.

It isn't like there is anything critical happening with those real time queries. I'm sure if you did a poll, if TiVo's servers are down, would you prefer constant BSCs so that TiVo can immediately get you your album covers once the servers come back up, or would you prefer it pause queries for a few hours and just let you use the DVR as you normally do, with no BSCs, placing placeholders for data not currently available, most people would prefer the latter.

I'm currently using Quattro with no internet connection (not by design, but due to circumstance) and I can playback shows, I have skip mode (on all but the newest recorded shows), it records fine. If I didn't have some placeholder images, I wouldn't even have noticed my TiVo couldn't connect to the servers.

I remember how painful it was to use the UI when certain servers were up but not responding. I figure when that first happens, just set a flag that says servers didn't respond, don't check again until X hours later. Then for a few hours, it'll just behave like your Internet connection was down (like I describe above)

 

If you read, that is EXACTLY what I suggested.

It already CAN function today without getting all the graphics. That is the way it works when your Internet connection is down.

I am just suggesting it in a way that piggybacks on existing functionality rather than a more extensive re-write.

What you are experiencing with BSCs (when a server is up but not responding) is NOT that it can't work without the information. It is that they chose to continuously redo the query/timeout cycle. If they simply had a flag that said, last time I tried, this server didn't respond, don't try for another few hours then you could do playback, with no BSCs, and you would have placeholder's for images (like you do currently)

Whether this feature is optimized for a granularity per server type (so you have the minimal level of paused requests) or whether they optimize this feature only for servers that would cause BSCs in the UI, are implementation details.

They could probably make these non-essential BSC-inducing requests asynchronous and non-blocking vs synchronous blocking, but that would probably involve more significant code changes. What I am suggesting piggybacks on mechanisms the UI already supports.

 

They were nice enough to add Skip mode to Premieres even though they didn't need to and it added some cost to port over some ADA stuff.

That got them some goodwill from my standpoint even though it didn't affect me.