Opened 12 years ago

Closed 12 years ago

Last modified 12 years ago

#3529 closed defect (invalid)

Does not switch satellites on channel change

Reported by: anonymous Owned by: danielk
Priority: minor Milestone: unknown
Component: dvb Version: head
Severity: medium Keywords: diseqc, toggleinputs
Cc: Ticket locked: no

Description

Fails to switch satellites on a channel change. This problem affects both live tv and scheduled recordings. Pressing "C" to toggle inputs successfully switches satellites. Channel scans also work fine.

Problem is worse in branch 0.20 as scans don't work either. In 0.20 satellite stays stuck at the first "input" created in "Input Connections". The only way to scan the other satellite is to delete and recreate the card and create the other input first.

My setup is as follows:

LNBF: DishPro? Twin LNBF
Card: Hauppauge WinTV Nova-S
Satellites: Echostar at 119W and 110W
Operating System: Ubuntu Feisty Fawn x86_64

Change History (10)

comment:1 in reply to:  description Changed 12 years ago by panachoi@…

Replying to anonymous:

Fails to switch satellites on a channel change. This problem affects both live tv and scheduled recordings. Pressing "C" to toggle inputs successfully switches satellites. Channel scans also work fine.

Problem is worse in branch 0.20 as scans don't work either. In 0.20 satellite stays stuck at the first "input" created in "Input Connections". The only way to scan the other satellite is to delete and recreate the card and create the other input first.

My setup is as follows:

LNBF: DishPro? Twin LNBF
Card: Hauppauge WinTV Nova-S
Satellites: Echostar at 119W and 110W
Operating System: Ubuntu Feisty Fawn x86_64

I can confirm this bug. Its a show-stopper here in Europe, where its quite common to have multiple LNBs connected to DiSEqC switches. Here's a log of what happens on the backend when switching channels from 1 satellite (Hotbird 13E, Port 1) to another (Astra 19.2E, Port 2):

2007-06-25 12:16:57.181 DVBChan(0): Opening DVB channel

2007-06-25 12:16:57.184 DVBChan(0): SetChannelByString?(28522):

2007-06-25 12:16:57.191 DVBChan(0): 11778000 qpsk a auto auto a a auto a v

2007-06-25 12:16:57.192 DiSEqCDevTree: Changing LNB voltage to 13V

2007-06-25 12:16:57.211 DiSEqCDevTree: Changing to DiSEqC switch port 1/2

2007-06-25 12:16:57.212 DiSEqCDevTree: Sending DiSEqC Command: e0 10 38 f1

2007-06-25 12:16:57.534 DVBChan(0): Old Params: 11565740 qpsk a auto auto a a auto a h

DVBChan(0): New Params: 11778000 qpsk a auto auto a a auto a v

2007-06-25 12:16:57.535 DVBChan(0): Tune(): Tuning to 1178000kHz

2007-06-25 12:16:57.587 dvbchannel.cpp:wait_for_backend: Status: Signal,

2007-06-25 12:16:57.588 DVBChan(0): Tune(): Frequency tuning successful.

2007-06-25 12:16:57.589 DVBChan(0): SetChannelByString?(28522): Tuned to frequency.

comment:2 Changed 12 years ago by linux@…

Hello,

I also live in Europe (Netherlands), and have the same problem... I have a nice WaveFrontier? with 8 LNBs and I can only watch TV through 1 LNB. So, this is my biggest problem with MythTV.

So, I would really like to help debugging this problem.

(P.S. I was already thinking to buy a Dreambox 8000 when it becomes regular, because I thought this was a hardware related problem bound to my 2 Skystar 1 CI cards...)

Remy Bohmer

comment:3 Changed 12 years ago by linux@…

BTW, I also tested the C button, but even that does not help on my system to change from LNB.

Remy Böhmer

comment:4 Changed 12 years ago by nihao

Hello,

I've seend an older bug (3255) that describes the same thing. I wish this bug is fixed in the next time.

Detlef Jockheck

http://svn.mythtv.org/trac/ticket/3255

comment:5 Changed 12 years ago by anonymous

Any fixes or workarounds in works? I guess I could always roll back to .19 or .18 as it worked there from what I have read but that seems wrong.

Any ideas?

comment:6 Changed 12 years ago by anonymous

I've spent a little time with the channel code (trunk latest) to see if I understand the problem. Maybe someone else can elaborate more. It looks like the tv_rec code simply calls the dvbchannel.initchannel to set the the input to the default input (from capturecard sql table). I could not find anywhere where it tries to figure out what the correct input to use based on the channel selected.

comment:7 Changed 12 years ago by anonymous

I can confirm this on 0.20.2-3 OpenSuSE 10.2 Packman rpms. I would sugest a higher priority on this one. It's really a show-stopper here in Europe as said earlier. /Andreas

comment:8 Changed 12 years ago by anonymous

I am the original reporter of this bug. My problem was fixed by a simple change in mythtv-setup. Perhaps others who have "replicated" this bug have a different and more genuine problem.

My problem was that I was attaching the same "video source" to all my satellites. This seemed logical at the time as I was using the same (internet) source to get all my program schedules. After browsing through the database I figured out that channels were mapped to hardware/input through sourceid, and sourceid was directly related to "video source". Without a separate video source for each input, the database simply could not relate channels to their hardware/inputs.

In short, I fixed my problem by assigning a separate "video source" to each input/satellite.

comment:9 Changed 12 years ago by danielk

Resolution: invalid
Status: newclosed

Anon, as you've discovered each satellite needs it's own "video source". Would you mind adding some notes on the wiki where you looked for solutions to your problem explaining how to set things up correctly? If someone starts it I'm sure it will get refined..

comment:10 Changed 12 years ago by panachoi@…

When I saw this, I thought that this problem was solved. So I went ahead and started again from scratch, setting up 2 video sources, 1 for each satellite. Now the results are only "slightly" better. The scanning the LNB on port 1 (Hotbird) works; scanning the LNB on port 2 (Astra) only works for 1 or 2 transponders, the rest bring "NIT no tables" or "No Lock/Signal? Timeout" The monoblock itself works, since the 2 other receivers attached to it work without problems.

Note: See TracTickets for help on using tickets.