DVB-S slow scanning when it can't find a signal

Latty Jordan

OK, this may be partly my fault for trying to get a rotor up and working on a day with really bad reception, but it's shown me that tvheadend spends what looks like far too long trying to tune in to poor signals. If It sees something then the log messages are thus:

2014-02-14 14:10:11.037 mpegts: 12034V - starting for 'initscan' (weight 2)
2014-02-14 14:10:11.037 mpegts: 12034V - tuning on Montage Technology DS3000 : DVB-S #0
2014-02-14 14:10:11.313 subscription: 'initscan' subscribing to mux, weight: 2, adapter: 'Montage Technology DS3000 : DVB-S #0', network: 'Hotbird', mux: '12034V'
2014-02-14 14:10:17.994 mpegts: 12034V - initial scan complete
2014-02-14 14:10:17.994 mpegts: 12034V - pmt complete
2014-02-14 14:10:17.994 mpegts: 12034V - pmt complete
2014-02-14 14:10:17.994 mpegts: 12034V - pmt complete
2014-02-14 14:10:17.994 mpegts: 12034V - pmt complete
2014-02-14 14:10:17.994 mpegts: 12034V - pmt complete
2014-02-14 14:10:17.994 mpegts: 12034V - pmt complete
2014-02-14 14:10:17.994 mpegts: 12034V - pmt complete
2014-02-14 14:10:17.994 mpegts: 12034V - pmt complete
2014-02-14 14:10:17.994 mpegts: 12034V - pmt complete
2014-02-14 14:10:17.994 mpegts: 12034V - pmt complete
2014-02-14 14:10:17.994 mpegts: 12034V - sdt complete
2014-02-14 14:10:17.994 mpegts: 12034V - nit complete
2014-02-14 14:10:17.994 mpegts: 12034V - cat complete
2014-02-14 14:10:17.994 mpegts: 12034V - pat complete

2014-02-14 14:10:17.995 subscription: "initscan" unsubscribing

i.e. it takes just 6-7 seconds to log all the streams and tables from a transponder. But if it can't find a signal then the sort of messages I'm getting are:

2014-02-14 14:03:33.529 mpegts: 11938H - starting for 'initscan' (weight 2)
2014-02-14 14:03:33.529 mpegts: 11938H - tuning on Montage Technology DS3000 : DVB-S #0
2014-02-14 14:03:33.803 subscription: 'initscan' subscribing to mux, weight: 2, adapter: 'Montage Technology DS3000 : DVB-S #0', network: 'Hotbird', mux: '11938H'
2014-02-14 14:05:43.000 mpegts: 11938H - initial scan no data, failed

2014-02-14 14:05:43.000 subscription: "initscan" unsubscribing

Or here's another example

2014-02-14 14:05:51.194 mpegts: 11976H - starting for 'initscan' (weight 2)
2014-02-14 14:05:51.194 mpegts: 11976H - tuning on Montage Technology DS3000 : DVB-S #0
2014-02-14 14:05:51.463 subscription: 'initscan' subscribing to mux, weight: 2, adapter: 'Montage Technology DS3000 : DVB-S #0', network: 'Hotbird', mux: '11976H'
2014-02-14 14:08:01.000 mpegts: 11976H - initial scan no data, failed

2014-02-14 14:08:01.000 subscription: "initscan" unsubscribing

where it seems to be consistently spending 2 minutes and 10 seconds staring in to space. Is there any way to make this a bit shorter? Even 20 seconds or so would be more than adequate.

And on a seperate issue, there don't seem to be any Pre-defined Muxes for Eutelsats 7E and 12.5W. How can I manually add a couple of transponders, or force TVheadend to scan where the Scan Q length is zero?

Gary Brown

Are you using USALS or GOTOX for the setup?

the 2 minutes is a hard coded wait that is in there to allow time for the motor to move, it currently needs to be written into a function to calculate the time it takes to shorten down the wait.

there is a known bug in the software (maybe just on the USALS side) that I have reported already that stops the use of my/a motorized setup. the only current solution is to use https://github.com/jsm174/tvheadend/tree/rotor-support-2 (pre dvb-rewrite so missing quite a lot of needed features such as limiting services/muxes to set amount per page) until the issue 1960 gets fixed (https://tvheadend.org/issues/1960)

ON the "missing" muxes you just need to add them in yourself. I cannot guide you as i'm not using the current version but it should run along the lines of do everything like you would for a one with set muxes but leave that option blank, then inside the muxes windows add a mux manually choosing the right satellite in the options.

Latty Jordan

D'oh, so the muxes window is an editable page. Sorry, I'm just getting used to the new version. For the benefit of anyone else reading I see that it wants the extra three zeros for the frequency, so 10721H has to be entered as 10721000, otherwise it appears on the mux list as 10H.

I'm using USALS, and this is the first time I've had TVHeadend driving the dish. The working old version with rotor support was something pretty old, and I preferred to drive my dish from something else then let TVH work out what was in sight and build whatever EPG it could. It actually worked pretty well.

One thing I'll note is that I was getting the two minute wait between every single transponder, even when scanning a single satellite, i.e. the motor hadn't turned so there was no need to wait for it.

Gary Brown

https://github.com/tvheadend/tvheadend/blob/master/src/input/mpegts/linuxdvb/linuxdvb_rotor.c#L244

thats why mate. it needs to work out how much the motor will move if it moves at all. it's set to 120 (seconds). can you answer some quick questions for me please.

1. what program your using to move it?
2. have you setup tvheadend as a Motorized setup or standard single satellite?
3. do you not experience the bug I've posted above if you use the motorized setup?

Latty Jordan

I've got TVHeadend running on a Pogoplug (similar to a Raspberry Pi, but arm5, 256M RAM, a built in PSU and USB hub all in a neat little box). Arch linux plus programs run from an old Sony 30 GB HD Walkman, recordings saved to a separate bigger HD that I can just unmount to get them, rather than pulling them over the network. Terrestrial TV from a little stick, sat from a Tevii S660. The S660 actually pulls no power from the pogoplug - it's got its own supply. And the AUR repository even has a script for building an installable pacman package direct from github.

I ran the pogoplug just for terrestrial TV for quite a while. For satellite I had an old Twinham PCI card on a box running Windows XP and AltDVB. Then last summer I bought the S660 for DVB-S2. It runs everything off a 7.5V wall wart, which seemed a bit puny to me, so I kept using AltDVB to drive the dish motor (unnecessarily cautious I guess, since I've recently found that the Diseqc spec means that it only has to supply 500mA to the motor). The Twinham card had an F-connector pass through socket, so that was no problem. When I started AltDVB that asserted priority over the sat cable, then stopping it handed it back. I was running TVH 3.5.241 as a single sat setup yet switching between 13E and 19.2E with no problems. OK there were 200+ transponders in the list, but the epg grabber just populated from those it could see at any time. As long as I had it pointing the right way at recording time then all was OK.

A few days ago I tried the latest version. There hadn't been any changes to the repository for a couple of weeks, so that should mean that it's stable-ish. I've been trying to get it working as a motorised setup. Have I seen your bug? Honest answer is that I'm not sure. I've been having a couple of motor problems in the last few days anyway. And even with two different PCI cards, two USB sat cards, some new cable and a couple of different motors that I can test without getting a ladder out, I've still not worked out where exactly the problem is. Yes, it's not moving as I expected, and yes, TVH adds random groups of transponders to the wrong satellite, so I've currently found 153 transponders on 13E and 158 on 19.2E (I think they've got 104/5 each), and it also seemed to reset a whole bunch on 13E to "Initial Scan Complete = false" earlier today.

But that aside, I don't see why TVH should need to send Diseqc move commands when switching between two transponders on the same satellite.