High band does not (always) work (1 Viewer)

[emerich]

Missing Channels

Hi GregorV,

also thank you from my side for the work you did!

My only remark on this topic is, that I can scan & view all channels without changing configuration with the WINTV & the ProgDVB program (start scan on Mediaportal --> no channels, stop Mediaportal and start ProgDVB, do a scan and all channels are found). So I think it's more a combination of the driver and the Mediaportal software than a hardware problem.

best regards Christian

Hope I didn't missunderstand some of your arguments.

 

[GregorV]

Hi emerich,

you may be right. At least there is a strong hints, that this behavior can be caused by two separate components. Some people also had this problem with TransEdit or ProgDVB and here mostly the LNB or cable change helped. If I remember correct then reports about this problem with some specific software (also MediaPortal) did also mention LNBs but often this did not really help. It worked with TransEdit, but not with the software they wanted to use.

By the way - in the last days I found another interesting way to work around the problem.
In my case I needed several restarts from TVServer service but more reliable/faster is the following:
In TVSetup try to scan a high band channel - if it does not work (cannot build graph) then go to TVServers->Home and click the TV-card.
Check 'override default LNB frequencies' and enter the necessary values for the sat/country e.g. for Astra/Germany 9750,10600,11701 (11701, because it is different than it was before - correct is 11700). 11700 - 11718 can be used without changing anything for Astra 19.2.
Go back to TV-channels (takes some time due to internal reinitialization) and preview a high band channel - in most cases it will work immediately.

After a new restart, if it does not work just change 11701 to 11702 (or back to 11700) and when you go back to TV-Channels it will work.
In general: whenever a slight change is done in the card configuration the following reinit makes everything work.
This points to a initialization issue for the Hauppauge cards.

Gregor

 

[emerich]

Hi GregorV,

thanks for the hint

I did the manual LNB Setup (LOF1,LOF2,LNBSW) and I could scan for all channels.

Many thanks to you and your great work!

Best regards Christian

 

[GregorV]

please test this TVLibrary.dll

All, who experience issues when trying to tune high band channels with a Hauppauge card can try the attached dll.
It is build from the latest svn (19936) and I am quite sure it will not work with RC2 only, because there was a DB change meanwhile (preload). So update to the latest svn, before you try.

As told previously my NOVA has the problem, that it needs several restarts of TVService to come up in a working mode - to be more precise, it need several initializations (which also can be reached by changing e.g. LNB settings in TVSetup)

I suggested an initialisation issue for the Hauppauge card and played with the code and now for me the issue is gone.

First, make sure that in TVSetup->General Settings thes is at least a value of 3 for 'Delay in seconds before...' - otherwise I had not 100% success.

Stop TVService, replace the TVLibrary.dll in TVService directory with the attached one and start TVService.
(Don't forget to save the original DLL)
Please tell me, if that works OK, or better, or worse, or not at all.

I am pretty sure the developer team will need some brainstorming until they find out why that works - I have no idea - I just can tell them what I did.
But first I need some results from you.....

Thanks

Gregor

 

[milagroso]

Hello GregorV,

I did a intense tryout today, also tested Your dll. I did not realize any change using Your dll (I copied it into C:\Programme\Team MediaPortal\MediaPortal TV Server replacing the dll which was there. Used the inidcated latest svn and set the timeout to 5 secs). However I had some interesting finidngs when testing the svn, maybe these help You and maybe You can even reproduce them. See in this thread: https://forum.team-mediaportal.com/...high-band-channels-nova-se2-42890/#post294998

Now I have to fallback to my old config and then go to sleep, tomorrow's a long working day...

regards from Stuttgart

 

[GregorV]

would have been too nice

yes, I can see on my systems meanwhile, that it does not always help. It is really strange - on my Intel machine with a NOVA-S PLUS I can scan high-band channels after each restart of TVService, but after reboot it still fails.
On my AMD machine with a NOVA-HD-2S I can scan high-band channels after each reboot (when TVService is automatically started) but when I manually restart TVService it still needs several restarts before I can tune any high-bands.
Before my change both machines behaved exactly the same way.

But at least I am apparently at the right place in the code, because it changed behavior on my systems.
I am pretty sure that it has to do with function calls to the DirectShow library:
This is, what I changed in the Hauppauge.cs module:

public Hauppauge(IBaseFilter tunerFilter, IBaseFilter analyzerFilter)
{
//IPin pin = DsFindPin.ByDirection(tunerFilter, PinDirection.Input, 0);
IPin pin = DsFindPin.ByName(tunerFilter, "Input0");
...

So it is just another method to find the Input pin for the Hauppauge tuner.
I'll try to come closer to that in the next days.
May be a developer could give some hints here, what could be tested.

Thanks,
Gregor

 

[blaudden]

Hi,

one thing that differs between the hauppauge "driver" compared to the other ones(for example twinhan.cs) is that it will get a reference _only_ to the KsPropertySet once in the constructor. Other drivers saves a reference to the "tunerFilter" and then asks for the KsPropertySet each time they want to send something to the card.

This may lead to the _propertySet variable that hauppage.cs has saved is not valid after the first calls to StopGraph + FreeAllSubChannels.

It could be worthwhile to rewrite the hauppauge.cs so it behaves like the others....

One quick "hack" to try is to just make the ConditionalAccess::allowedToStopGraph function return false, thus we would at least avoid the "StopGraph" call inbetween channel tunes.

/ Magnus

 

[blaudden]

ok, let's see what this patch + dll shows?

 

[GregorV]

Hi blaudden,

here my results:
copied your DLL and started TVService:
1. tune n-tv -> does not work
2. tune DW-TV -> works
3. tune n-tv -> still not working
4. do my initialization trick (change LNB settings from 11700 to 11701
5. tune n-tv -> works
Logs from this attached.

yesterday I could do some more tests. As mentioned earlier I can get much better results, if I exchange the function for finding the pin and I suspected Marshal.RealeaseComObject().
So I tried a self written function using method Filter.FindPin which can be written without the need to free something.
Indeed it found the correct pin, but the testing results were always no success.
Then I did something desperate - because I usually would expect that this cannot work.
I switched back to the DsFindPin.ByName and changed DsUtils.
Into the finally section of that function I added 'Marshal.ReleaseComObject(pPins[0]);' that it now looks like below:

public static IPin ByName(IBaseFilter vSource, string vPinName)
    {
...
      finally
      {
        Marshal.ReleaseComObject(pPins[0]);
        Marshal.ReleaseComObject(ppEnum);
      }
...

This would destroy the return value but surprisingly I get results better than ever !
Even on my other machine I can restart TVService as often as I want and always can tune high-bands.
Nevertheless this cannot be the final solution because the code is not correct. But it points to a somehow mystery behavior of Marshal.ReleaseComObject.

Also I still can get situations where this does not work - eg. after playing with different code the Hauppauge drivers or DS comes into a state where only low-bands can be tuned.
This situation then requires a reboot and then it's fine again.

Any ideas ?

Thanks
Gregor

 

[blaudden]

Hi,

that was quick testing, bur unfortunately still bad results.

Have some more ideas and I assume you can recompile and test these yourself.

1. Try to not send any diseqc command at all by commenting out the call to "_hauppauge.SendDiseqCommand(parameters, channel);". Then we'll hope that the card itself send "something" when it changes channel.


2. There might actually be a small bug when we send the diseqc command for AntennaNr 0 (as you have selected). You can see in 'Hauppauge:endDiseqCommand' hos we set one bit for hi/low band, one bit for hortizontal/vertical and finally two bits to tell which LNB to select.

The "formula" used is antennaNr-1 which becomes -1 and then << 2. Thus we get a value always of FC or FF and that might not be what we want. Altough the loop I have added in case we get no PMT will try all values, we might have to get it right the first time?

So maybe you can change the code from:
byte cmd = 0xf0;
cmd |= (byte)(hiBand ? 1 : 0);
cmd |= (byte)((isHorizontal) ? 2 : 0);
cmd |= (byte)((antennaNr - 1) << 2);
to something like:
byte cmd = 0xf0;
cmd |= (byte)(hiBand ? 1 : 0);
cmd |= (byte)((isHorizontal) ? 2 : 0);
if (antennaNr != 0){
cmd |= (byte)((antennaNr - 1) << 2);
}

Well, that doesn't really feel like it should change much. Having those two bits set to 00 actually means LNB 1

3. Another option is to tell that you only want to set the two bits that tell hi/low and horz/vert.

You do that by changing
byte cmd = 0xf0;
to :
byte cmd = 0x30;


4. Well, if that does not work there are other ways to talk to the LNB. It should be possible to reset it with another DiseqC command.
You can read the spec if you like
http://www.eutelsat.com/satellites/pdf/Diseqc/associated docs/applic_info_turner-receiver.pdf

Could you please tell me as much as possible about LNB and any switch you use.

BTW: The diseqc protocol is supposedly backward comaptible so it should send toneburst so that also older devices are switched fine.


/ Magnus

You see the comments here, descibing what that particular byte is called in the spec...

byte[] diseqc = new byte[4];
diseqc[0] = 0xe0; // FirstTransmission = 0xe0,
diseqc[1] = 0x10; // Any LNB, Switcher or SMATV (Master to all...)
diseqc[2] = 0x38; // Write to Port group 0 (Committed switches)
diseqc[3] = cmd;

Hmm, I see that all other "drivers" use the antennanr -1 trick, so it might not be a bug after all.