Recordings always have studder

[sub]

Is it possible the ATI MUX I'm using in GBPVR handles the errors better then the TS mux of NPVR? It appears to be the case. Is there any tuner card that has better error compensation capabilities? I have been recording with my Hauppauge for 3 years now using GBPVR, and I have never really been satisfied with recordings. Many recording cut off when there are errors on the line. The NPVR TS MUX never cuts off, but the stutter makes the recordings unwatchable.

No, the ATI MUX vs TS should make pretty much no difference. It's not going to correct errors in the stream. As you say though, if old GBPVR recordings were cutting off early, maybe those would also have had same problems but ATI mux never captured it.

Did you try playing the recording a player like VLC as I suggested?

You might need to supply a short sample recording so I can take a look.

[feilh]

The stutter is at the same place when viewing with VLC.

There is another difference between GBPVR and NPVR. GBPVR playback is using Microsoft MPEG2. NVPR is using its own TS player correct? Microsoft MPEG2 could be handling the errors more gracefully making things look better.

Its hard to provide a short clip because sometimes recordings go a long time without issues. I would have to get some good cutter software that wasn't effected by all the errors. The lack of issues sometimes is what led me to think it was a slow hard disk, or anti-virus, defender or something causing buffer overflows and lost data using NPVR. I don't understand why NPVR seems more resource intensive. I have also noticed its the channels that have less virtual channels (some channels transmit 4 sub channels 26.1, 26.2, 26.3, 26.4 and sub channels are just 5.1) so I assume more data are the biggest issue. But that could also just be a coincidence.

[sub]

There is another difference between GBPVR and NPVR. GBPVR playback is using Microsoft MPEG2. NVPR is using its own TS player correct? Microsoft MPEG2 could be handling the errors more gracefully making things look better.

.MPG shouldn't make any difference to this. With TS you can the unmanipulated bytes received from the broadcaster, with no changes what so ever made by NextPVR.

Its hard to provide a short clip because sometimes recordings go a long time without issues. I would have to get some good cutter software that wasn't effected by all the errors.

If you can supply a short sample, I'd probably be able to tell if their is missing packets. It's fairly manual, but you can use the cutchunk utility. It wont be bothered by errors in the transport stream, and they'll still be present in any smaller file you produce.

The lack of issues sometimes is what led me to think it was a slow hard disk, or anti-virus, defender or something causing buffer overflows and lost data using NPVR. I don't understand why NPVR seems more resource intensive.

When its recording, NextPVR should definitely be using less resources than GBPVR did. It's not remuxing data like GBPVR was, so is doing less.

It could certainly be something like antivirus or firewall software causing this issue though. Maybe try turning them off for a while.

[feilh]

If you can supply a short sample, I'd probably be able to tell if their is missing packets. It's fairly manual, but you can use the cutchunk utility.

Here is a link to the smallest I could make with cutchunk. I think it shows about one stutter.

http://www.divshare.com/download/18605759-508

Thanks Howard

[mvallevand]

That just look like a typical sample of a bad recording because of low signal. Are you using a three-way splitter to feed your TV and your two inputs? What happens if you take the splitter off and feed the "raw" cable feed to your PC?

Martin

[Reddwarf]

That just look like a typical sample of a bad recording because of low signal. Are you using a three-way splitter to feed your TV and your two inputs? What happens if you take the splitter off and feed the "raw" cable feed to your PC?

Martin

He said in post#7 that he tried that. I still suspect a low signal because I'v seen the same behaviour here, I have a good S/N ratio from the cable, but the overall signal strength is too low for my Technotrend card to lock up so I have to use an amplifier with four outouts instead of a splitter.

[mvallevand]

I know but I wasn't 100% sure from that post if he took out all the splitters or just the one feeding two leads into his capture card.

Martin

[feilh]

So why then do I get so much better recordings with the ATI mux and GBPVR?

[mvallevand]

It's possible that the mux could discard some of the crap caused by the bad packets, and that it appears visually like it is better recording. Instead you could end up holes in the broadcast and bad timelines that are other problems with mpeg files. If you are seeing this a lot I suspect DVR-MS with GBPVR would be a better container.

Martin

[feilh]

You may be right a preamp may help. I'm tempted to go buy one and see. I'm still a little perplexed at your theory. If I have a good SNR according to hauppauge that implies the signal strength is well above the noise floor of the receiver of the hauppauge. So a preamp wouldn't make much of a difference.

I don't know why but DVR-MS worked when my Vista image was new. Some decoders I installed over time somehow screwed up DVR-MS.

Howard