Multidec with Hauppauge dual tuner fails

[Barsk]

Can you try setting <BDASubmitTuningRequestTwiceOnLivePreview>true</BDASubmitTuningRequestTwiceOnLivePreview> in config.xml, then reproduce the problem and repost the logs?

Sure, here it is. The setting improved getting the channels to tune in on the first Live TV entry (on FTA). I usually get No signal detected at first, tuning to the next channel and so on is no problem, just the first. But with this setting to true, it seems to be fixed...

But, sorry to say, no change in MDAPI performance, but I think that was expected. A note, I have seen that the video is actually decoded, but appears as a still. So decoding takes place, just terribly slow. CPU usage is normal around 10%. MDAPI log windows gives 70 calls per second and for the ffdecxxx part gives about 180.
Talked to Agarwal on DVBN on this, and he said those numbers are way off.

[sub]

Sure, here it is. The setting improved getting the channels to tune in on the first Live TV entry (on FTA). I usually get No signal detected at first, tuning to the next channel and so on is no problem, just the first. But with this setting to true, it seems to be fixed...

Good

But, sorry to say, no change in MDAPI performance, but I think that was expected. A note, I have seen that the video is actually decoded, but appears as a still. So decoding takes place, just terribly slow. CPU usage is normal around 10%. MDAPI log windows gives 70 calls per second and for the ffdecxxx part gives about 180.
Talked to Agarwal on DVBN on this, and he said those numbers are way off.

To be honest, I'm not really sure what to advise. GB-PVR doesnt really play much of a part in this. It just connects the mdapi filter to the output of the BDA filters, then tells the filter the channel PIDs it is interested in, then the filter takes care of the rest (receiving transport stream packets from the device, passing to multidec plugins to determine decryption keys, decrypting audio/video streams etc).

Unfortunately we'd probably need Agarwal to add additional logging to the mdapi filter to get more insight into what exactly is happening. This filter gets first look at the data after it comes from the capture device. It'd be nice if it logged info about the packets it was receiving.

[sub]

Now you have that config.xml setting in place, does it make any difference if you start on a channel that is encrypted?

[Barsk]

Now you have that config.xml setting in place, does it make any difference if you start on a channel that is encrypted?

No difference.

[Barsk]

Good

To be honest, I'm not really sure what to advise. GB-PVR doesnt really play much of a part in this. It just connects the mdapi filter to the output of the BDA filters, then tells the filter the channel PIDs it is interested in, then the filter takes care of the rest (receiving transport stream packets from the device, passing to multidec plugins to determine decryption keys, decrypting audio/video streams etc).

Unfortunately we'd probably need Agarwal to add additional logging to the mdapi filter to get more insight into what exactly is happening. This filter gets first look at the data after it comes from the capture device. It'd be nice if it logged info about the packets it was receiving.

Ok. Thanx for your time and effort though.

Do you know if for example Pinnacles dual tuner card suffers from the same problems, or if this is exclusive to Hauppauge? I will have to look for a replacement. If you have any recommendations I would be happy to get them.
Also, if skipping the Hauppauge altogether with that nice remote integration, what other remotes would you recommend? A plain MCE remote?

Regards
Barsk

[sub]

Do you know if for example Pinnacles dual tuner card suffers from the same problems, or if this is exclusive to Hauppauge?

I dont know. We dont have DVB-T yet, so I've not personally tested either of these. I've heard very little about this problem. The reports of seen are in the threads by you and Stefan.

Also, if skipping the Hauppauge altogether with that nice remote integration, what other remotes would you recommend? A plain MCE remote?

The MCE remotes work well with GB-PVR.

[Barsk]

I dont know. We dont have DVB-T yet, so I've not personally tested either of these. I've heard very little about this problem. The reports of seen are in the threads by you and Stefan.

The MCE remotes work well with GB-PVR.

Ok, thanx a lot for all your help. I will have to try out some alternatives. I could give you a hint later if it worked or not...

/Barsk

[Barsk]

Got his message from Agarwal:

barsk: well the problem is clear to me; the filter is not processing enough TS packets in each pass. What I don't understand is that packets are supposed to be buffered until a certain number has been reached, but it seems it's not working in your case. I'll try to take a look at the buffering code this week.

Don't know if this is of any value to you, Sub? It sounds like an MDAPI internal thingie.

[stefan]

Sounds like there could be hope, then

[sub]

barsk: well the problem is clear to me; the filter is not processing enough TS packets in each pass. What I don't understand is that packets are supposed to be buffered until a certain number has been reached, but it seems it's not working in your case. I'll try to take a look at the buffering code this week.

Don't know if this is of any value to you, Sub? It sounds like an MDAPI internal thingie.

Not really. The card's BDA driver is connected directly to the MDAPI filter, so it gets first look at anything coming from the card. There are no GB-PVR components sitting in front of it, so GB-PVR has no opportunity to effect this, or to monitor it.

Its possible the card isnt delivering enough TS packets, but I think its more likely the MDAPI filter isnt handling the chunk sizes those TS packets are delivered in from this card, or something similiar.