MDAPI support update

[varesino]

Hi Sub,
It should be nice if you can find some time to update the MDAPI support to a more recent version of the mdapifilter like the latest released in December by steve77.
I'm available to became a tester in case you need it

Many thanks for your wonderful software.

regards
Varesino

[sub]

I've been testing his december version for the last hour or so and it seems to be working fine for me. I didnt have to change anything in the application, but I did have to move the plugins since it now looks ".\MDPlugins\AV1" instead of ".\MDPlugins".

[varesino]

As you can see this new version loads and unloads itself dinamically every time a tv is started/stopped. On my pc I found this problem:

• Switch on the pc, start pvrx2 and tune a crypted channel
  
• Mdapi (new) creates its instance, load the plugin(s) and start its yob.
  
• The first channel tuned needs from 10 to 15 seconds to be displayed (old mdapi version needs only 1 or 2 seconds).
  
• Tune any other crypted channel works very fast (like old version).
  
• Stop live tv
  
• Reenter in live tv or start a manual record, pc freeze (sometime not the first time but surely the second).
  

It seems that after the first initialization your software "thinks" that mdapi is already loaded, but this is not true because the new mdapi version has unloaded by itself and then pc crashes.
Also the time needed to view the first crypted tuned channel is longer than expected and can lead to a timeout error using the timeshift (if the channel is not decrypted in 10 seconds a timeout message appaers, click OK and you go back to main menu)
Please let me know if you can reproduce it or it's only a my local problem, or if you need further detail about configuration, plugins, logs, etc.

Regards
Varesino

[sub]

Ok, when I double checked I found I was still using the old filter. Sorry.

I've made sure I'm using the correct filter now, and I'm seeing the slow channel startup you describe (10 - 15 seconds). I seem to be able to stop and re-enter live tv multiple times without the pc freeze you're seeing, but I dont seem to be able to do multiple sequential recordings (first works second fails).

GB-PVR always reuse the multidec filter instance because the old versions of it wouldnt shutdown cleanly, leading to crash the second time you use it. Based on your comments above, I've added an option in the config app so that you can tell it wether to reuse the filter. I've double checked this seems to function fine with this newer december version. I've been able to stop and reenter live tv numerous times, and I've done multiple short recordings without any problem.

The 10-15 second delay seems to be a bug in the multidec filter, and not something GB-PVR isnt going to be able to do much about. As with previous versions, GB-PVR is telling the filter within 50ms the formation it needs to know. This specific version just seems to take a very long time to get started. Have you seen any discussion about the cause of this delay?

[varesino]

I had not seen any discussion about the delay because everybody (developer included) are testing it only in Mediaportal and in this envinroment the problem seems to not appears.
I was the only one testing it in GBPVR and nobody answer to my comments
The only think I know is that this delay appeared with the version 2.05beta, the first released by Agarval as opensource and hosted on sourceforge.
All the following versions inherited this problem with GBPVR.

I'm happy to know that the other problems are solved, I hope new version will be released soon to test the new functionality.

Regards
Varesino

[sub]

I've had a good look into the cause of this delay today, and from what I can tell its seems GB-PVR has done everything it needs to almost immediately and the rest of the delays is waiting for the multidec filter to acquire the odd/even keys from the stream so it can start decrypting. I cant see how this is any faster in MP.

[sub]

Going by the code on sourceforge (which I dont think is as late as that december build), the delay seems to be caused by this function:

Code:

void Decrypter::setKeys(BYTE pBuffer[32])
{
    EnterCriticalSection(&m_csKeys);
    
    for(int i = 0; i < 4; i++)
    {
        m_keys[(pBuffer[4])*8+i*2+0] = pBuffer[6+i*2+1];
        m_keys[(pBuffer[4])*8+i*2+1] = pBuffer[6+i*2+0];
    }

    if(!(m_bOddFound && m_bEvenFound))
    {
        if(pBuffer[4] == 1)
        {
            m_bOddFound = true;
        }
        else
        {
            m_bEvenFound = true;
        }
    }
[b]    else
    {
    
        int result = 0;
        if(m_bOddFound && m_bEvenFound)
            result = m_dll.SetKey((unsigned char *)(&m_keys[0]), (unsigned char *)(&m_keys[8]), m_dll.keys);
    }[/b]

    LeaveCriticalSection(&m_csKeys);
}

If that "else" is changed to the following, then it starts significantly faster:

Code:

[b]    //else
    if (m_bOddFound && m_bEvenFound)
    {
    
        int result = 0;
        if(m_bOddFound && m_bEvenFound)
            result = m_dll.SetKey((unsigned char *)(&m_keys[0]), (unsigned char *)(&m_keys[8]), m_dll.keys);
    }[/b]

The reason this is problem is that even when the odd/even keys are finally known, it doesnt set them in the FFDecsa library until the next keys is received. When I made this change live tv is now starting in about 4 - 6 seconds.

Some broadcasters transmit the keys more often, so these delays may not be a problem for many of the user of this filter, which may explain why you havnt seen discussion about it.

The source code on source forge is not steve77's latest code, so I cant make a new build myself. This version of the code has other problems (like requiring the filter reuse etc).

[varesino]

First of all thank you very much for spending your time examining an external piece of software not directly related with your project.
If you agree I can post the modified code on dvbn, asking to one of the developers that keeps the latest version of the source code to integrate it and release a new version as soon as possible.
Let me know if you agree.

regards
Varesino

[sub]

Yeah, thats fine.

[sub]

There is another annoying problem with this filter. They've changed the definition of the IMDAPIFilter interface several times. This will lead to crashes if you have you use a version of filter that has a different IMDAPIFilter interface definition to that which the application using application was compiled for. Because of this, you cant just update the version of mdapifilter.ax and hope the application will continue to work unchanged. (so I have the choice of leaving it compiled for the old version of the interface, and having it work well with the old version of the filter, and not break existing setups with the next GB-PVR upgrade....or I can compile it for the new version of interface, works better for the new version of the filter, but breaks it for hundreds of people with existing GB-PVR multidec setups.... I cant win...)

They should have instead added additional versioned interfaces like IMDAPIFilter2 or IMDAPIFilterEx or something similiar. Then I could have handled it automagically. Its probably a little late to retrofit this now.