Multidec with Hauppauge dual tuner fails

[Lorry]

It wasn't dvb dream, it was progDVB. So it might work with DVBSBridge?

[Barsk]

As long as you start live tv on an encrypted channel, then it should be always on.

Ah? Can you please describe how and when the mdapi filter gets switched on and off. I had the impression the filter would be on only for encrypted channels and off for FTA?

Also, how does the filter work for multiple tuners? Is it associated only with one tuner at once? Or is it decoding for all active tuners simutaneously in some sort of global filtering?

If you enable transport stream logging by creating the following registry setting, and create a c:\temp directory, then it should create (large) c:\temp\psi.log file when you view live tv. Each time you change channels, you should see a mdAPI->ChaneChannel(...) message with the info it passes to the MDAPI filter. These messages will hopefully give you some clues to help track down the cause of your problem.

HKEY_LOCAL_MACHINE\Software\Devnz\LogPsiProcessing=2 (DWORD)

Ok, I'll look into that!

If you find some multidec filters work fine in another app, but not GB-PVR, then I'm pretty sure the bugs arent in GB-PVR, but rather in Agarwal's MDAPI filter. That said, the multidec stuff works 100% with me on my cable operators Irdeto2 DVB-C network (with Yankse plugin). I've never had a failed recording.

With a single tuner setup things are pretty stable. The problems arise when I try to get it to work with a multi tuner setup. I know that the original mdapi does not support multiple streams, but i tried to set it up so that one tuner should adressing all the encrypted channels only and the other the FTA channels only. But I cannot get it to be stable when I switch channels, or set one tuner to record. There will be a hickup somewhere, the question is only when.

One suggestion may be if one could associate mdapi with a dedicated tuner in the GBPVR configuration. I have three tuners in my HTPC now, so if mdapi goes with that tuner only and leaves the FTA channels to the other tuners, things could improve. Then I believe I could have the same stable and fast channel switching as without mdapi altogheter on the FTA channels. And have the mdapi filter when needed on one dedicated tuner.

[stefan]

One suggestion may be if one could associate mdapi with a dedicated tuner in the GBPVR configuration. I have three tuners in my HTPC now, so if mdapi goes with that tuner only and leaves the FTA channels to the other tuners, things could improve. Then I believe I could have the same stable and fast channel switching as without mdapi altogheter on the FTA channels. And have the mdapi filter when needed on one dedicated tuner.

You're saying it's not enough to just disable the encrypted channels on the two extra tuners?

[Barsk]

You're saying it's not enough to just disable the encrypted channels on the two extra tuners?

I am saying that, yes.
However the conclusions may be based on erroneous assumptions. My problems may not come from mdapi or GB-PVR bugs at all, they may be due to bad BDA drivers from Terratec. Who knows? The experiance when trying to find a stable setup was extremely erratic with hangups in different scenarios all the time. I could not find a common denominator to what was actually the root of all problems.

I may take another dive into this tonight.

/Barsk

[sub]

As long as you start live tv on an encrypted channel, then it should be always on.

Ah? Can you please describe how and when the mdapi filter gets switched on and off. I had the impression the filter would be on only for encrypted channels and off for FTA?

No, if you start live tv on an encrypted channel, then the multidec filter is part of the playback graph, and is updated with the new channel PIDs each time you change channels.

Also, how does the filter work for multiple tuners? Is it associated only with one tuner at once? Or is it decoding for all active tuners simutaneously in some sort of global filtering?

There are two processes in GB-PVR that access the device, and each is allowed a maximum of one instance of the multidec filter.

- One process is PVRX2.exe. There is never more than one tuner in use in PVRX2.exe since it is only used for live preview live tv (not recording). When it does live preview and starts on an encrypted channel, then multidec filter is added to the graph, and updated with the channel PIDs on each channel change,

- The other process is GBPVRRecordingService.exe which does the recordings. It has a maximum of one instance of the multidec filter that it can use. It will only add it to a graph when the recording is on an encrypted channel. If you schedule two recordings on encrypted channels, only the first will get the multidec filter.

As you can see the case for Live TV is simpler. Basically it only ever deals with tuner, and if you start on an encrypted channel then the multidec filter is always used, and is updated with the channel PIDs on every channel change.

[Barsk]

No, if you start live tv on an encrypted channel, then the multidec filter is part of the playback graph, and is updated with the new channel PIDs each time you change channels.

There are two processes in GB-PVR that access the device, and each is allowed a maximum of one instance of the multidec filter.

- One process is PVRX2.exe. There is never more than one tuner in use in PVRX2.exe since it is only used for live preview live tv (not recording). When it does live preview and starts on an encrypted channel, then multidec filter is added to the graph, and updated with the channel PIDs on each channel change,

- The other process is GBPVRRecordingService.exe which does the recordings. It has a maximum of one instance of the multidec filter that it can use. It will only add it to a graph when the recording is on an encrypted channel. If you schedule two recordings on encrypted channels, only the first will get the multidec filter.

As you can see the case for Live TV is simpler. Basically it only ever deals with tuner, and if you start on an encrypted channel then the multidec filter is always used, and is updated with the channel PIDs on every channel change.

Thanx for the clearifications, Sub.

I understand better now.
I changed my setup at home yesterday to try get the most out of what we have, so I have set upt the Twinhan single tuner card to tune only encrypted channels. The two terratec tuners are set up to tune only FTA channels. It seems that things work well in this setup despite my previous findings - with the orginal Agarwal mdapi filter.
The problems I had before must have been with buggy mdapi implementations or beta BDA drivers for the terratec card.

However one question remains. If I tune to an encrypted channel in Live TV, then to an FTA which in my setup is on another device - I still have multidec in the graph for the PVRX2 process. Right?
This was the cause for my previous suggestion - to limit multidec support to one (or several) dedicated tuners. In that case (if it is possible to do - I don't know) a graph could be created per device. And the devices not tuning encrypted channels could skip the multidec filter, and as a result channel switching should be considerably faster.

The way it works now is that I can watch ONE encrypted channel live or via recording. If I try to watch another encrypted channel I get the message that no more tuners are available. So there can never be a crash due to several tuners wanting the mdapi filter simultaneously.
The other two tuners can watch/record TWO FTA channels simultaneously. I tried recording three programs at once and it worked fine. A testament to the quality of the GBPVR program :-)

Now, if I want to improve the functionality in the future when a better multidec filter arises that can deode several streams simultaneously, do we need support for that in GB-PVR? The limitation of one instance for each process may need to be raised to two or removed altogheter? One of the solutions for new mdapi was to have several instances running in parallel. I think I saw some setting in the config for this, is that correct? In that case I could try to get that to work with the newer mdapi filter. I believe this limit may be the cause of my previous problems when trying the new filter in GBPVR.

Another problem (OT) is that I get that "No signal detected" with a graph showing perfect quality and strength from time to time. Skipping to the menu and then back to Live TV solves it - but it is irritating. Any hints how to solve? I have set the Live TV delay to 750 ms to counter this and other problems with audio sync somewhat. Audio sync is also a source of problems sometimes in Live TV, never in recordings.

[sub]

If I tune to an encrypted channel in Live TV, then to an FTA which in my setup is on another device - I still have multidec in the graph for the PVRX2 process. Right?

Yes. It takes quite a while to stop the graph, remove the filter, reconnect it and restart the graph. Its easier just to leave it there.

This was the cause for my previous suggestion - to limit multidec support to one (or several) dedicated tuners. In that case (if it is possible to do - I don't know) a graph could be created per device. And the devices not tuning encrypted channels could skip the multidec filter, and as a result channel switching should be considerably faster.

I probably wont do this because I have other plans in mind for multidec. Its just a matter of finding the time...

The way it works now is that I can watch ONE encrypted channel live or via recording. If I try to watch another encrypted channel I get the message that no more tuners are available. So there can never be a crash due to several tuners wanting the mdapi filter simultaneously.

The way it works now, you can watch one encrypted channel via live tv AND record one channel AT THE SAME TIME. You cant record more than one channel at the same time though. Recording and live tv run in two separate processes and each have access to one instance of the filter, and can use it whenever they want.

Now, if I want to improve the functionality in the future when a better multidec filter arises that can deode several streams simultaneously, do we need support for that in GB-PVR? The limitation of one instance for each process may need to be raised to two or removed altogheter? One of the solutions for new mdapi was to have several instances running in parallel. I think I saw some setting in the config for this, is that correct? In that case I could try to get that to work with the newer mdapi filter. I believe this limit may be the cause of my previous problems when trying the new filter in GBPVR.

I have a change in mind to enable mulitple encrypted recordings to occur, but I've got to find a bit more spare time before I can implement it.

That said, the current limit of one per-process is just limited by the <BDAMaxMultidecInstances> setting in config.xml. If you increase this value to 5, then it'll try to have up to 5 instance of it running, and will go through all the same motions it normally does for one instance. It was set to '1' though because the multidec filter was never able to handle more than one instance. If that limitation is resolved by the creators of the plugin, then you should able to just increase that number in the config.xml.

Another problem (OT) is that I get that "No signal detected" with a graph showing perfect quality and strength from time to time. Skipping to the menu and then back to Live TV solves it - but it is irritating. Any hints how to solve?

You can get this if your combination of device + directshow filters + multidec plugins takes longer than expected to start delivering a valid picture. Try increasing the <NoSignalPopupDelay> setting in config.xml.

[Barsk]

I probably wont do this because I have other plans in mind for multidec. Its just a matter of finding the time...

Ok, I still think limiting multidec support to dedicated tuners could be a great feature for people like me that have a mix of tuners and BDA drivers. The Terratec drivers are not fully compatible with the mdapi filter as it seems. The video gets a bit choppy, the sound is fine. The funny thing is that if I start timeshift - then video isn't choppy anymore... However I have deactivated the encrypted channels on the terratec tuners for now.

The way it works now, you can watch one encrypted channel via live tv AND record one channel AT THE SAME TIME. You cant record more than one channel at the same time though. Recording and live tv run in two separate processes and each have access to one instance of the filter, and can use it whenever they want.

Ok! I had a feeling this was the case as you explained the workings of the two processes, but now it is confirmed. And I have tested it also. It does indeed work!

However there needs to be a safety net that identifies a clash when you by mistake starts two instances in the same process. This is easily done if you for example have one encrypted channel recording and then have another channel in Live TV. If you suddenly decide to hit record on the other channel you are looking at (even timeshift?) then that channel will go into the recording process and a clash is a fact. However you will NOT notice this as there is no warning or error. The recording just silently fails. There were other ways to trigger this clash that I fell into yesterday, but I don't remember exactly now. The conclusion is that a safety net MUST be in place to hinder two instances to clash. My wife would never understand the limitations that one needs to have in mind if one is to enable this.

I have a change in mind to enable mulitple encrypted recordings to occur, but I've got to find a bit more spare time before I can implement it.

Ok, sounds great. Waiting impatiently already.. :-)

That said, the current limit of one per-process is just limited by the <BDAMaxMultidecInstances> setting in config.xml. If you increase this value to 5, then it'll try to have up to 5 instance of it running, and will go through all the same motions it normally does for one instance. It was set to '1' though because the multidec filter was never able to handle more than one instance. If that limitation is resolved by the creators of the plugin, then you should able to just increase that number in the config.xml.

Great. The newer versions of mdapi seems a little instable at the moment, but as soon as that stabilizes a little I will look into it. If your solution is not done before that of course.

[Lorry]

Has there been any more development to the problem with nova-t 500?

Does it work with any new mdapi?

[stefan]

I still haven't got it to work. There were, however, two separate problems. One being that the nova-t-500 is a dual tuner, and there were problems with decoding two streams at once. That problem, I think, has been taken care of.

The other problem was that the mdapi doesn't work well with the nova-t-500 for some reason. It decrypted stuff, but only like one frame every 20 seconds, if at all. I haven't heard of that problem being fixed. No one would be happier than me if it is fixed, though