# 20.3.8 update fixed my SDV issues (V53/V58)



## Philmatic (Sep 17, 2003)

*A little background*

I am a Cox Customer in Santa Barbara, CA. Cox has deployed Switched Digital Video (SDV) in my area, and as such it requires an Tuning Adapter to be attached to the TiVo to allow it to tune those specific channels that are SDV enabled. This, combined with a CableCard allows me to access all channels in Cox's channel lineup. Before the Roamio, I used to have the original two tuner TiVo Premiere. I never had a failed recording with SDV unless the box locked up, which happened maybe once a month, but other than that, I had no problems.

When I got the Roamio, it became pretty clear that having 6 full tuners along with SDV was causing an issue. I didn't realize it at first but after reading the reports on this forum, it became clear that I wasn't the only one. I didn't have an issue with the CableCard not being able to tune the 5th & 6th tuner, but a combination of that issue along with SDV was causing recordings to just fail midway through, or not record at all. Seeing V53 & V58 errors became commonplace.

In the main thread (Tuners 5 and 6 Not Authorized), it was suggested to disable the 5th & 6th tuners as a way of temporarily reducing the frequency of the tuning issues. So I did that, and the issue became less frequent, but it was still happening.

Then came 20.3.8, included was a blurb from Margret about how it will now "retry tuning requests after a Tuning Adapter fails to respond". I was skeptical, but I figured it couldn't hurt. Boy was I wrong, all of my tuning issues were resolved! Three days later I re-enabled tunerr 5 & 6 and it's been going great ever since.

I have attached a spreadsheet detailing about 38 days of recordings. The recording bitrates in red indicate a failed recording, green indicates a successful recording. Because of the way the SDV failure exhibits itself in a recording (The TiVo records an empty signal, so the duration is as if it was successful, but the actual size on the disk is reduced and the resulting bitrate is low), I know that a fully successful recording averages between 11.30mbps and 11.70mbps. So anything less than that is a failed recording, I spot checked about 20 of those *bad* recordings and they all had tuning failures at some point in the recording.

As you can see, disabling tuners 5 & 6 help a little bit, but did not resolve the issue. However, 20.3.8 completely resolved the issue and I am now running with all 6 tuners.

*Thanks to TiVo for solving this issue, and thank you to moyekj for the awesome kmttg software that gave me the information needed to verify this with hard data.*


----------



## CoxInPHX (Jan 14, 2011)

I concur, I have about 30 SDV recordings set-up everyday to test, and not one has failed since 20.3.8.


----------



## moyekj (Jan 24, 2006)

Was the fix specifically related to Cisco TAs? I haven't had trouble with my Moto TAs since early days of series 4 hardware. I was fearful that any tweaks to TA interaction would "break" my otherwise working setup but luckily that has not been the case and things are still working fine.


----------



## Philmatic (Sep 17, 2003)

I think it was a more generic: If SDV tuning fails, retry more aggressively. That seems to fix my issues, it was probably not trying to re-tune after the first failure.

The fix is similar to how SiliconDust resolved their issues.


----------



## crxssi (Apr 5, 2010)

Hasn't fixed my problems on Cox Hampton Roads. Just yesterday a recording failed (it recorded nothingness again) on a SciFi channel program. When I tried to tune it manually, it just says I am not authorized.

Power cycle the TA again and a few minutes later, things are back to normal until the next time this happens.... which is always without a pattern and without warning.

Extremely irritating.


----------



## HarperVision (May 14, 2007)

"not authorized" sounds more like a cablecard issue.


----------



## crxssi (Apr 5, 2010)

HarperVision said:


> "not authorized" sounds more like a cablecard issue.


Or it might have said "not available" or whatnot.

In any case, if it were the cable card, then why does power cycling the TA always fix it?


----------



## CrispyCritter (Feb 28, 2001)

crxssi said:


> Or it might have said "not available" or whatnot.
> 
> In any case, if it were the cable card, then why does power cycling the TA always fix it?


Perhaps the TiVo sends a re-initialize signal to the cablecard when it detects the TA becoming available? I believe the TiVo does that in other circumstances, too, for example when testing signal strength on individual channels, or testing channels within the cablecard setup. That's why those actions often "fix" the problem.


----------



## HarperVision (May 14, 2007)

crxssi said:


> Or it might have said "not available" or whatnot.
> 
> In any case, if it were the cable card, then why does power cycling the TA always fix it?


When the TA is attached, it takes control for the channel list, but when it's only a cablecard, that provides the channel list. That's why when you do "Test Channels" under the cablecard menu, it says "No Channels Available" and you have to perform that test under the TA menu when there is one installed for SDV systems.


----------



## crxssi (Apr 5, 2010)

CrispyCritter said:


> Perhaps the TiVo sends a re-initialize signal to the cablecard when it detects the TA becoming available? I believe the TiVo does that in other circumstances, too, for example when testing signal strength on individual channels, or testing channels within the cablecard setup. That's why those actions often "fix" the problem.


That sounds like a plausible explanation. However, I still believe the problem is the TA. I never have ANY problems using non SDV channels. That tends to point squarely at the TA.


----------



## crxssi (Apr 5, 2010)

HarperVision said:


> When the TA is attached, it takes control for the channel list, but when it's only a cablecard, that provides the channel list. That's why when you do "Test Channels" under the cablecard menu, it says "No Channels Available" and you have to perform that test under the TA menu when there is one installed for SDV systems.


I don't disagree with that you are saying, but can't quite fit it into the thread to explain how this is not my TA that is the main problem. For me, it doesn't explain anything further.... perhaps I am just dense tonight (has been a long day).


----------



## nooneuknow (Feb 5, 2011)

If this "fix" is "automatic", then why do all my "manual" attempts to tune force me to MANUALLY press the select button, in order to get it to tune? Is this "automatic" retry fix ONLY for scheduled (automated) tunes for recording?


----------



## jwbelcher (Nov 13, 2007)

crxssi said:


> I don't disagree with that you are saying, but can't quite fit it into the thread to explain how this is not my TA that is the main problem. For me, it doesn't explain anything further.... perhaps I am just dense tonight (has been a long day).


My understanding is when your TA goes away it forces all your channels to retune / reauthorize with the cablecard. Mainly because your TA is responsible for tuning all your channels -- even Broadcast channels. Unplugging your TA is effectively resetting the authorization across all tuners. When you plug your TA back in, the TA to has to tune the channels on your tuners yet again. Each time they're re-tuned, the Cablecard has to reauthorize / decrypt again. Maybe this is why things clear up for you.


----------



## moyekj (Jan 24, 2006)

jwbelcher said:


> My understanding is when your TA goes away it forces all your channels to retune / reauthorize with the cablecard. Mainly because your TA is responsible for tuning all your channels -- even Broadcast channels. Unplugging your TA is effectively resetting the authorization across all tuners. When you plug your TA back in, the TA to has to tune the channels on your tuners yet again. Each time they're re-tuned, the Cablecard has to reauthorize / decrypt again. Maybe this is why things clear up for you.


 To further the theory next time there's a problem then crxssi try pulling the CableCard and then putting it back in to see if it fixes things as well.


----------



## crxssi (Apr 5, 2010)

moyekj said:


> To further the theory next time there's a problem then crxssi try pulling the CableCard and then putting it back in to see if it fixes things as well.


Eeew, that is hard to get to. But I will try to remember to attempt it and then try to remember to post the results. Sounds like a good test.


----------



## jwbelcher (Nov 13, 2007)

crxssi said:


> Eeew, that is hard to get to. But I will try to remember to attempt it and then try to remember to post the results. Sounds like a good test.


LOL, it does sound like it has been a long day


----------

