That can't be improved much. The way the tuning adapter works is TiVo sends it a channel request via USB, it communicates with the head end over the coax, the head end responds via coax with the frequency, the TA reports the frequency to the TiVo over USB, the TiVo tunes the channel, and the video displays as soon as it hits the next available I frame. (usually only 1 I frame even 1/2 second or so)

Is the new Roamio any faster than the Premiere for channel surfing with a Tuning Adapter and CableCard?

Click to expand...

HD tuning will always take at least a few seconds per channel change. It is the nature of HD tuning for ALL devices. It is even worse when a tuning adapter is involved and it is a switched digital video channel. Not much TiVo can do about it.

HD tuning will always take at least a few seconds per channel change. It is the nature of HD tuning for ALL devices. It is even worse when a tuning adapter is involved and it is a switched digital video channel. Not much TiVo can do about it.

Click to expand...

I was curious as to how much of it was internal overhead in the TiVo. The TW DVRs are somewhat faster on SDV channels, so where is the time lost with the TA solution?

I was curious as to how much of it was internal overhead in the TiVo. The TW DVRs are somewhat faster on SDV channels, so where is the time lost with the TA solution?

Click to expand...

If it is an SDV channel, the TiVo has to REQUEST the channel through USB to the TA, which then has to talk to the CC headend servers, which then has to (possibly) allocate the channel, and then talk back... and THEN the TiVo can tune to the correct frequency.

That can't be improved much. The way the tuning adapter works is TiVo sends it a channel request via USB, it communicates with the head end over the coax, the head end responds via coax with the frequency, the TA reports the frequency to the TiVo over USB, the TiVo tunes the channel, and the video displays as soon as it hits the next available I frame. (usually only 1 I frame even 1/2 second or so)

That whole process takes time. It's not the hardware slowing it down.

Click to expand...

Even *without* the tuning adapter (I've never used one), you have to wait for a new I-frame to come along in the MPEG stream. Is my reading of the wikipedia article correct that there must be an i-Frame for each GOP, so:
Maximum frames per GOP: 18 (NTSC) / 15 (PAL), i.e. 0.6 seconds both

So you could theoretically have to wait .6 seconds to change channels? (This is why that other DVR mentioned recently has 2 extra tuners to tune above/below the 'current' channel.. it 'cheats' and as long as you pause a LITTLE bit, it ends up raising the EFFECTIVE channel change speed.)

That 18 frame limit only applies to DVDs. We regularly see broadcast stuff with 20+ GOPs. And for H.264 all bets are off. I've seen H.264 broadcasts out of Europe with I frames spaced 10 seconds apart.

That 18 frame limit only applies to DVDs. We regularly see broadcast stuff with 20+ GOPs. And for H.264 all bets are off. I've seen H.264 broadcasts out of Europe with I frames spaced 10 seconds apart.

Click to expand...

Yeah, I have tried jumping in the middle of an H264 video many times where it took seconds before it would snap to a corrected picture (with an I frame).

H.264 has no real limit. I've seen encodes from customers that have I frames 30 seconds apart. MPEG-2 I believe has a maximum GOP size if 132 frames and I've never actually seen one with GOPs longer then 50. So seeking and FF performance are a lot easier to accomplish with MPEG-2

Even *without* the tuning adapter (I've never used one), you have to wait for a new I-frame to come along in the MPEG stream. Is my reading of the wikipedia article correct that there must be an i-Frame for each GOP, so:
Maximum frames per GOP: 18 (NTSC) / 15 (PAL), i.e. 0.6 seconds both

So you could theoretically have to wait .6 seconds to change channels? (This is why that other DVR mentioned recently has 2 extra tuners to tune above/below the 'current' channel.. it 'cheats' and as long as you pause a LITTLE bit, it ends up raising the EFFECTIVE channel change speed.)

Click to expand...

And it gets worse the longer the data stream is (number of channels or services or other data in the stream) further delays the full frame's delivery to the STB, and as compression is increased, even fewer full frames in the stream to access, and this all takes TIME. Although turbo coding could keep things from getting much slower. I also believe that encryption also delays things as the STB may also be waiting for the KEY in the stream to authenticate access--Yup, even MORE time. However, the STB and the speed with which it handles things holding in memory while having other tasks to perform at the same time affects the time it takes to spit out the first image, and so the STB is also a part of the equation, but not as much as MPEG, length of digital stream, compression, and encryption. I think the days of really fast channel surfing are dead in the digital age, at least with the huge amount of data the MVPD's have to transport, but some new encoding or process in the future may change that.