DishPro Bandstack LNB support?

[dennit]

Also check your config.xml in the gbpvr directory for this setting

Code:

<BDATwinhanDiseqcMethod>2</BDATwinhanDiseqcMethod>

should be either 2 or possibly 0.

Interesting fact I discovered yesterday:

I'm using a DishPro Twin LNBF with two ports and an integrated DiSEqC A/B switch.

I can reliably DiSEqC switch with my 1020a using BDATwinhanDiseqcMethod=2 only when I have an extra receiver connected to one port and the 1020a connected to the other port. That's what I've been doing. OTOH, I've just realized I can reliably DiSEqC switch with my 1020a using BDATwinhanDiseqcMethod=0 without (or with) extra power on the second port. I don't need the extra power, although the card gets warmer if the internal DC-DC power source is in use (I've modified it to allow an external power source to supply power and tell me the current draw).

If I'm using BDATwinhanDiseqcMethod=2, and do not have extra power on port 2 connected, all frequencies on sat 1 will tune and some frequencies on sat 2 will tune, while others on sat 2 will not. It seems repeatable as to those that will or won't tune on sat 2. For a freq. on sat 2 that I cannot tune, an attempt to tune causes about 250 ma current draw steady to see the black screen as it tries to switch. For channels it can tune, the current draw is far less than that (IIRC, below 50 ma.)

[observer_11]

Interesting fact I discovered yesterday:

I'm using a DishPro Twin LNBF with two ports and an integrated DiSEqC A/B switch.

I can reliably DiSEqC switch with my 1020a using BDATwinhanDiseqcMethod=2 only when I have an extra receiver connected to one port and the 1020a connected to the other port. That's what I've been doing. OTOH, I've just realized I can reliably DiSEqC switch with my 1020a using BDATwinhanDiseqcMethod=0 without (or with) extra power on the second port.

Thank you, you just solved a longstanding mystery with my 1020a I could never explain. Your results now make total sense with why I had to change BDATwinhanDiseqcMethod between 2 and 0 on my setup.

Now you got me wondering if the 1020a will switch reliably if BDATwinhanDiseqcMethod=0 AND there is another power source connected to the second DiSEqC port? I got a feeling it will not...

[dennit]

Thank you, you just solved a longstanding mystery with my 1020a I could never explain. Your results now make total sense with why I had to change BDATwinhanDiseqcMethod between 2 and 0 on my setup.

Now you got me wondering if the 1020a will switch reliably if BDATwinhanDiseqcMethod=0 AND there is another power source connected to the second DiSEqC port? I got a feeling it will not...

My tests resulted in good switching with BDATwinhanDiseqcMethod=0 regardless of whether I had the extra power connected to the second port. However, I did not test all channels.

I should thank you, as it was your comment that you had to switch to BDATwinhanDiseqcMethod=0 from BDATwinhanDiseqcMethod=2 that caused me to try the new setting.

Another interesting point is that when wandering through the logs resolving another issue I noticed that one of those 2 settings produces a log entry stating that it is sending raw diseqc commands and the raw commands being sent are listed in the logs. (I think it's the "0" setting, but don't quote me.)

[observer_11]

Also strange that BDATwinhanDiseqcMethod=0 setting is deprecated according to Twinhan (if I recall correctly). :confused:

[dennit]

My tests resulted in good switching with BDATwinhanDiseqcMethod=0 regardless of whether I had the extra power connected to the second port. However, I did not test all channels.

I should thank you, as it was your comment that you had to switch to BDATwinhanDiseqcMethod=0 from BDATwinhanDiseqcMethod=2 that caused me to try the new setting.

I'm currently having strange problems in this area, so I thought I'd post what I'm seeing. Perhaps it will help me think of an answer or someone will be able to suggest one to me.

First the problem - I'm running 1.2.13 and no longer can scan sats in config. It looks like it's scanning, but it sometimes fails to find any channels, or it may find channels on the wrong sat (fails to switch) or it may find some channels, but fail to see entire transponders. The odd thing is that it works perfectly within GBPVR to tune between the two sats, switching reliably with DiSEqc switching A/B between two sats using the internal DishPro LNBF switch. Using previously scanned tuning_request data stored in the gbpvr.db3 database works great. I never would have noticed a problem if I hadn't tried to scan sats again in config.

As indicated in the thread above, I initially had lots of trouble scanning and tuning sats with my Twinhan. Ultimately, I succeeded. Summarizing - my solution (I thought) was to run a second cable to the DishPro LNBF and connect an old tuner that supplied voltage. I set BDATwinhanDiseqcMethod=2. This produced good scans in config and I still use the data produced by those scans.

Later, I modified the 1020a card to add a switch between the voltage regulator and the internal DC-DC voltage boosting circuit. The switch allowed an external power supply to be connected. This reduced heat and supposedly provided less noise on the line during DiSEqC switching. I subsequently changed to BDATwinhanDiseqcMethod=0 and found that GBPVR reliably switched channels regardless of either auxiliary power connection described above.

However, I'm not sure what effect all the changes above had on scanning in config since it worked great inside PVRX2 and I was concentrating on guide data issues.

After getting guide data issues mostly solved, I tried installing 1.3.x and later went back to 1.2.13. Then, recently, I decided to try another scan to see if any channels had changed. That's when I noticed I couldn't scan correctly anymore inside config. I can't figure out how to get back to where I was when I could scan. I've tried all possible combinations of BDATwinhanDiseqcMethod=0 or 2 and the external power via the two methods. Nothing seems to solve it. At this point, I can't seem to get a complete scan of either sat. Typically, I get some transponders, but not others or I get the same channels identified for several different transponders, but those channels are really only on one of the transponders, or I get no results at all.

Remember, however, that everything is working perfectly inside gbpvr - I can watch all channels, record them, etc. It is only the scan inside config to produce scan.cache files that fail.

One thing I know that has changed relates to emunation and MDAPI - new versions. I was under the impression that this has nothing to do with scanning/mapping, but I'm not sure. If I have a valid prior scan.cache file in place when I go to map channels inside config, the MDAPI/emunation kicks in and I see the first channel listed during the prior scan in the video window.

If I've deleted the corresponding scan I don't see the emunation/MDAPI window. I'm not getting crashes inside config during scanning (or at least not often) It's also possible that I may have brought something from the 1.3.x installs over, possibly in config.xml.

I've checked the BDA ini files carefully and tried some alternatives. I'm certain they are correct. I guess what I'm wondering is how DiSEqC switching and tuning varies between config and pvrx2 and whether MDAPI and the plugins affect scanning. At one point I tried DVBDream or a similar program and in retrospect, I'm wondering if my good scans occurred after running that program.

After this long post, I suppose I should add logs, but I don't really have any. I'll look at them next time I do some tests, particularly if anyone thinks they might throw some light on this.
Thanks in advance for any comments.

Merry Christmas to all.

[sub]

I'm running 1.2.13 and no longer can scan sats in config

Post the config.exe.log and config.exe-native.log and I'll see if anything stands out.

[dennit]

Post the config.exe.log and config.exe-native.log and I'll see if anything stands out.

Thanks. I'll be happy when Christmas arrives so the wife stops recording Christmas movies (or the 1TB drive fills up with them - which it nearly has) As soon as I get access to try this again, I'll run some scans to get some clean logs.

[observer_11]

MDAPI ver 2.2 works good for me - perhaps give that a try when you get a chance.

[dennit]

MDAPI ver 2.2 works good for me - perhaps give that a try when you get a chance.

Thanks for the suggestion. I'm not sure of my current MDAPI version, and that was part of my question -whether it makes any difference to the scanning process. Remember, whatever my current MDAPI version is, it works for all normal video watching and recording.

From some things I've read, I've believed that the TS packet headers are completely unencrypted and consequently should be scannable regardless of whether Multidec is enabled or not. I've tried scanning with it disabled, but have had no more luck. Clearly something has changed on my system, but I have no idea what.