Bug #3454
With TBS6905, tuners, mux scan fails yet card works if mux scanned successfully by different card
0%
Description
Several weeks ago I added a TBS6905 quad DVB-S2 satellite tuner card to a system that already had a TBS6985 quad tuner card. What I have found is that if I try to scan a valid mux on the TBS6985 card it works fine and once scanned, the channels in the mux can be tuned in and viewed with either tuner (I have LNBs with dual outputs and in a couple cases have one output connected to the TBS6905 and the other connected to the TBS6985 card). However if I initially scan the mux with the TBS6905, it fails even if the mux is valid. The message I see looks like this:
2015-12-30 02:41:29.814 mpegts: 4160H in Satellite 1 - tuning on TurboSight TBS 6905 DVBS/S2 frontend : DVB-S #0:B
2015-12-30 02:41:29.818 subscription: 0048: "scan" subscribing to mux "4160H", weight: 6, adapter: "TurboSight TBS 6905 DVBS/S2 frontend : DVB-S #0:B", network: "Satellite 1", service: "Raw PID Subscription"
2015-12-30 02:41:30.719 linuxdvb: TurboSight TBS 6905 DVBS/S2 frontend : DVB-S #0:B - poll TIMEOUT
2015-12-30 02:41:30.948 linuxdvb: TurboSight TBS 6905 DVBS/S2 frontend : DVB-S #0:B - retune nodata
2015-12-30 02:41:38.378 linuxdvb: TurboSight TBS 6905 DVBS/S2 frontend : DVB-S #0:B - poll TIMEOUT
2015-12-30 02:41:39.002 linuxdvb: TurboSight TBS 6905 DVBS/S2 frontend : DVB-S #0:B - retune nodata
2015-12-30 02:41:39.100 mpegts: 4160H in Satellite 1 - scan no data, failed
2015-12-30 02:41:39.100 subscription: 0048: "scan" unsubscribing
Again, if I let the other tuner scan the card and the scan is successful, then the TBS6905 will tune the channels in the same mux with no problem, although I have to set the "Skip Initial Bytes" value for that tuner to something rather high - I normally use 18800000 - if I don't then I get recordings with bad timings. Setting the "Skip Initial Bytes" value is something I don't need to do with the TBS6985. I wonder if perhaps when it tries to do the scan on the TBS6905 it is simply giving up too quickly, before the signal can actually be acquired, but when actually tuning a channel it will wait longer for the channel data to arrive? Does it even honor the "Skip Initial Bytes" value when doing the scan of the mux?
I'm running HTS Tvheadend 4.0.8, if this has already been fixed in the development version I apologize but I want to stick with the stable versions, because I feel like I barely know what I am doing with Linux (PLEASE do not ask me to compile a special version of TVHeadEnd or anything like that; if I ever attempted that I'm sure all I would do is totally screw up my mostly working system). But I did want to report this in case you are not aware of it. Also, in case you are not aware, the TBS6905 is a successor to the TBS6985, but I have read that the two cards use different demodulators - on another site I read that the TBS6905 uses the stv0910B demodulator, if that means anything to you (it does not to me). So if there is better support for that demodulator in the development version or the next stable version, it may fix this issue.
(I set the category to "Service Mapping" which was my best guess from among the choices, please change it if there's a better category for this).
History
Updated by K Shea almost 9 years ago
Transposed digits in the card model in the subject line, it is the TBS 6905, not 6095. Sorry.
Updated by Mark Clarkstone almost 9 years ago
- Subject changed from With TBS6095 tuners, mux scan fails yet card works if mux scanned successfully by different card to With TBS6905, tuners, mux scan fails yet card works if mux scanned successfully by different card
Updated title.
"poll TIMEOUT / retune nodata" usually means the card failed to send anything even after trying again nothing was received.
You having to set the skip initial bytes quite high suggests that the tuner/driver is sending old data at the start of every tune.
You also may want to try increasing the status period value to something like 2000.
Updated by Jaroslav Kysela almost 9 years ago
I don't see the purpose of this bug report. It's 100% the driver issue.