Originally posted by TPetersonShows ya how long it's been.
Well...NYPD Blue seems to play jus' fine--and Mike did say that "all" others he's tried have not had the long pause. (I don't know about FF/RW, since I don't need 'em after I've bleeped the commercials ) I have seen a long pause on some stripped SD subchannels from KQED (PBS) but it's not there with every one and I haven't figured out any system to it.
captures are from KGO (ABC in SF). They have, at various times, had 2 or 3 subchannels total. All of these Alias recordings play fine if you don't modify them. Stripping only nulls or stripping only unwanted sub-channels or both, all yield the "Long Pause" problem. This was especially a problem for me since they were stored on a media server. "Long" takes on new meaning when you're pulling 8GB through a 100Mbit net.
I also record and keep Smart Travels from KQED (PBS in SF). I've stripped them all and I've never had the Long Pause problem with those. However, they're from KQED's 1HD+1SD broadcast configuration. I've never intentionally recorded anything from KQED in the 4SD (daytime) configuration.
I did see the Long Pause problem on one other program from another channel (non-KGO) but now I can't remember what it was. I've never seen the FF/REW problem that wasn't fixable by trimming the first few seconds off the program.
After reading Cris' post above about removing the other non-program packets, I think maybe we should try keeping them.... Hmmm, maybe not. I used to use NPS and used to keep all the PIDs except the unwanted subs and nulls. For example, strip 0x20, 0x21, 0x24, 0x1fff and keep the rest. The way Cris has it set up in the beta, I think I end up keeping 0x10, 0x11, 0x14 and losing the rest. However, I haven't run it through NPS to get a packet count by PID after running it through 1.11 beta. I should probably do that...