TBS6981 issues with both adaptors enabled.

Rob Hunter

I have spent the weekend trying to set up an XBMC / tvheadend system. A few problems, so I thought I'd share.

Server System:
Asus P5K Premium motherboard
Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz (NOT overclocked)
NVIDIA Corporation G84 [GeForce 8600 GT] (rev a1)
4GB RAM
Ubuntu 12.04.2 LTS x64
TBS6981
Sky minidish

Astra 28,2, Freesat.

TBS drivers used:
v121119
v130127

v130506

Tvheadend builds
3.2 patch 2 (stable)
3.4 (stable)

3.5.117

Clients:
XBMC on Windows 7.
XBMC on Ubuntu 12.04 x64.

TVHGuide on Galaxy Note, ICS.

Tvheadend appears to have issues when both adaptors are enabled on TBS6981. Manifests as:
-Some multiplexes on both adaptors become "Faint" or "No signal". Either after Initial Scan or later when idle scanning enabled.
-Service mapping does not map all mappable services.

-Failure to tune to a service

If one of the two adaptors is then disabled and Idle Scan is enabled on the other, all the multiplexes revert to "OK" on the enabled adaptor, service tuning is swift and painless and all mappable services will map without a problem. Once the second (either) adaptor is re-enabled with Idle Scan, both adaptors suffer a random multiplex quality degradation, failure to start services and mapping may fail..

Adaptor configuration: AdaptorConfiguration.jpg

Example images, based on 3.5.117, TBS v130506, of Multiplex status. Freshly rebooted system, tvheadend started and Initial Scan completed.

With both adaptors enabled:
Mux0-BothAdaptorsEnabled.JPG shows the state of Adaptor 0 multiplexes after initial scan with problems.

Mux1-BothAdaptorsEnabled.JPG shows the state of Adaptor 1 multiplexes after initial scan with problems.

Disable Adaptor 1 and wait 10 minutes (i.e. allow Idles Scan to cover all Mux):

Mux0-Adaptor0EnabledOnly.JPG shows that Adaptor 0 has recovered all Frontend Status to OK.

Disable Adaptor 0, Enable Adaptor 1 and wait 10 minutes (i.e. allow Idles Scan to cover all Mux):

Mux0-Adaptor0EnabledOnly.JPG shows that Adaptor 0 has recovered all Frontend Status to OK.

Re-enable Adaptor 0 and wait 10 minutes (i.e. allow Idles Scan to cover all Mux):
Mux0-BothAdaptorsReEnabled.JPG shows the state of Adaptor 0 multiplexes after idle scanning and problems have returned.

Mux1-BothAdaptorsReEnabled.JPG shows the state of Adaptor 1 multiplexes after idle scanning and problems have returned.

In the above procedure no services where accessed.

When accessing a service, failure to open the service occurs at random. The only sure thing appears to be accessing a service on a multiplex that is already having one of its services accessed.

Failure scenarios using one XMBC client or TVHGuide (In all cases both adaptors are enabled):
-Attempt to tune to a service, possible failure.
-Tune to a service, success. Tune to a second service, possible failure.

-Tune to a service, success. Tune to a second service, success. Return to the initial service, possible failure.

Failure scenarios using two clients, one XMBC and one TVHGuide, or 2 XBMCs (In all cases both adaptors are enabled):
-Attempt to tune to a service, failure.
-Tune to a service, success. Tune to a second service, failure.
-Tune first client to a service, success. Tune second client to a service on same multiplex, success.

-Tune first client to a service, success. Tune second client to a service on different multiplex, possible failure.

It should be noted that the service is irrelevant. In one session I can get, for example, BBC 1, and fail to get ITV. 10 minutes later it's vice versa.

With one adaptor enabled there are no issues - I can change to any service without problem.

When tvheadend is struggling to access a service, the Active Subscriptions table of the Status tab shows the service is "Testing" and then "Bad".

Example of Testing when one service is being accessed: SingleChannelTesting.jpg and SingleChannelBad.jpg

Example of Testing when a second is being accessed while another service is successfully accessed: SecondChannelTesting.jpg and SecondChannelBad.jpg (last not uploaded as used all slots, just extrapolate from the last 3)

In an attempt to discount the fact that the issue exists at another level (hardware/driver/signal strength etc.) I have implemented the following scenarios:
-Windows 7 with 2 instances of DVB Dream, one on each adaptor.
-Ubuntu 12.04 x64. szap-s2 to different channels on each adaptor and view stream through mplayer.
-Ubuntu 12.04 x64. One instance of Kaffeine and one instance of me-tv on different adaptors.
-Ubuntu 12.04 x64. Installed and configured MythTV 26 (that was fun) and ran simultaneous clients.

-The old SKY+ HD box works fine.

In all the above cases (not SKY+ HD as only one channel with subscription) I was able to change channels independently in both instances within the same multiplex and across different multiplexes without issue, typically sticking to BBC, ITV, Channel 4, 5, E4 (SD) and BBC, ITV and Channel 4 (HD). From this I've concluded that tvheadend is probably the choke point!

Happy to provide further details and logs or run tests as required. Fairly technically capable so not averse to guided digging. Rather like the application so would like to help.

Regards
Rob

Anonymous

It look like I have the same problem. Just got it after updating to 3.4. I have the same DVB Card (TBS6981). Did you find any solution to the problem Rob Hunter.

Adam Sutton

I saw this back when I was using my TBS6981, though it appeared to stop at some point (I'm no longer using the adapter as I've upgraded). However I can confirm that there were definitely issues when you opened the various device handles in specific orders, unfortunately I never really got to the bottom of it. Since I was able to workaround it and then it appeared to go away.

Some things to make sure:

1. Enable IDLE scan
2. Disable close device handle when idle

3. Disable turn off LNB when idle

Point 1 makes 2 and 3 redundant really, however you may find that you can disable point 1. I'm not sure, some things have changed in 3.4 which may mean you MUST have idle scanning enabled to ensure stuff doesn't get closed (and thus trigger the problems I saw).

Adam

Rob Hunter

I've typically been configured with:
# Idle Scanning: Ticked
# Close device handle when idle: Unticked

# Turn off LNB when idle: Unticked

And when both frontends are enabled I get the problems.

So a bit of experimenting with those configuration items.............. (using 3.5.121, XBMC 12.2 on Win 7).

In all cases I'm starting with all the Multiplexes on both Frontends with a Frontend Status of "OK". I get to that state by leaving one adaptor enabled with Idle Scan, wait for al Multiplexes to reach OK, then disable the adaptor. Then repeat with the other adaptor. When ready to test I'll set the new configuration and enable both adaptors together. I'm only bothering to test with a single client as that is enough to trigger the problem.

I've tried with:
# Idle Scanning: Unticked
# Close device handle when idle: Unticked
# Turn off LNB when idle: Unticked

I access a service via XMBC, get 0, one or several successful services and then on service change I get the Testing/Bad status and the Multiplex associated with the service is marked either "Faint" or "No Signal". If I leave XMBC attempting to view the service after anything up to several minutes, tvheadend will report the service State as running, the Multiplex will revert to OK and XMBC will display a stream.

# Idle Scanning: Unticked
# Close device handle when idle: Ticked
# Turn off LNB when idle: Unticked

Ditto.

# Idle Scanning: Unticked
# Close device handle when idle: Unticked
# Turn off LNB when idle: Ticked

Ditto.

# Idle Scanning: Unticked
# Close device handle when idle: Ticked
# Turn off LNB when idle: Ticked

Ditto. But did seem to take the most services changes to get a Testing/Bad and then fairly regularly. Maybe just luck. First attempt at a second client resulted in Testing/Bad.

# Idle Scanning: Ticked
# Close device handle when idle: Ticked
# Turn off LNB when idle: Unticked

Ditto. + some multiplexes just degrade anyway as they are Idle Scanned.

# Idle Scanning: Ticked
# Close device handle when idle: Unticked
# Turn off LNB when idle: Ticked

Ditto. + some multiplexes just degrade anyway as they are Idle Scanned. + the Testing/Bad service did not come good, only by leaving and returning to the service was there a chance of it becoming "OK".

# Idle Scanning: Ticked
# Close device handle when idle: Ticked
# Turn off LNB when idle: Ticked

So it looks like Idle Scanning does indeed take precedence (i.e. the multiplexes degrade) and the other 2 options don't seem to do anything to correct the problem.

Again, happy to act as a testbed for any further ideas.

Adam, what adaptor did you "upgrade" to?

Rob

PS the "unwanted feature" that resolves itself is always rather pleasant. Even if it does leave a lingering, "Why?".

Adam Sutton

Rob,

I upgraded to a TBS6985, though it wasn't due to any problem with the 6981, it was a donation from TBS to give me a bit more resource (so I don't have to disrupt normal TV usage to dev etc...). The 6981 was only retired because my machine only has the 1 PCIe slot.

One other thing I'd suggest is disable all the signal quality monitoring stuff, its known to have issues and generally isn't as useful as originally intended. Personally I never have it enabled.

Can you provide a full debug log doing the following:

# Enable "skip initial scan" (this really should be default, this will be gone in next version)
# Disable "monitor signal quality"
# Get everything configured/scanned etc...
# Disable BOTH adapters (and save)
# Enable adapter0 only
# See how it performs, do you get any problems selecting channels etc...
# Disable adapter0 and then enable adapter1 (make sure its that order)
# See how it performs again.
# Enable adapter0
# See how it performs
# If you find its not working see which adapter its trying to use first, and disable the mux on that adapter
# See if that changes anything
# ELSE
# Try disabling the mux on the adapter that worked

# See if that changes anything

Adam

Rob Hunter

Adam,

An attempt at fulfilling your request. Got a bit iffy towards the end.

I already have a stable and scanned configuration with all Multiplexes OK and all (usable) Services mapped OK. They are the same multiplexes as used in the first post and the full list is visible in the screenshots there. Configuration of both adaptors is in attached screen shot Trial01AdaptorConfig.jpg, i.e. nothing ticked!

I'm starting the system with that configuration and the debug log enabled. I'm assuming it is OK to start from Step 5 given the above configuration.

I'm using XBMC local to the tvheadend server as client 1 and a remote (internet) XBMC on windows as client 2.

5. Enable adapter0 only

Adaptor enabled.

6. See how it performs, do you get any problems selecting channels etc...

Changing channels. No issues with 20+ changes.

7. Disable adapter0 ....

Adaptor 0 disabled, server stopped and log collected as 01Adaptor0Debug.log.

7. .....and then enable adapter1 (make sure its that order)

Server started, adaptor 1 enabled.

8. See how it performs again.

Changing channels. No issues with 20+ changes. Adaptor 1 then disabled and server stopped. Log collected as 02Adaptor1Debug.log.

9. Enable adapter0

Server started, adaptor 1 enabled, adaptor 0 enabled.

10. See how it performs
Changing channels, no issues with 20+ changes. System chose to use adaptor (Frontend) 1.
Added second client which started to use adaptor 0. On second channel change of second client (to ITV +1) Testing/Bad occured. Recovered after a minute or so. On third channel change of second client, brief Testing on frontend 0 then OK. On fourth channel change of second client to ETV2 extended Testing/Bad on frontend 0 with associated multiplex for that adaptor showing No Signal. Disabled mux on frontend 1. Stopped Live TV on client 1, which released frontend 1, which client 2 then automatically received with a functioning ETV2. Continuing channel changes on client 2 work OK (still using frontend 0).
Restart Live TV on client 1 and first channel selected gives Testing/Bad. It then looks like for the next channel change client 1 stole frontend 1 from client 2 (was watching Film 4) and left client 2 with frontend 0 which reverted to Testing/Bad. Associated multiplex on frontend 0 now "Faint". Disabled this multiplex on the functioning frontend 1. On frontend 0 the "Faint" multiplex is now "OK" and the channel is now streaming.

I'll stop the log there as I'm getting a bit bloody confused! Details in 03BothAdaptorsDebug.log.

11. If you find its not working see which adapter its trying to use first, and disable the mux on that adapter
12 .See if that changes anything
13. ELSE
14. Try disabling the mux on the adapter that worked

15. See if that changes anything

Unfortunately I couldn't keep an eye on both clients, the multiplex list and the tvheadend status at all times.

Hope the logs help.

Rob

Adam Sutton

This does sound like the same problem that I experienced, though stopping

it closing the dev fds definitely solved it for me.

So you can definitely use both adapters independently without issue. Its

only when using the together that problems occur.

I always suspected this was a bug in the firmware/driver, though couldn't
prove it. What was even weirder was I think that using 2 tvh instances 1

per adapter and things were fine.

It might be worth a query to tbs, as even if its tvh doing something wrong,
they might be able to suggest a solution. If they're not forthcoming let me

know and I'll try and bug them. I'm just pressed for time at the moment.

Adam

On May 17, 2013 3:09 PM, wrote:

> Tvheadend - General: RE: TBS6981 issues with both adaptors enabled.
>Rob Hunter >
> Adam,
>
> An attempt at fulfilling your request. Got a bit iffy towards the end.
>
> I already have a stable and scanned configuration with all Multiplexes OK
> and all (usable) Services mapped OK. They are the same multiplexes as used
> in the first post and the full list is visible in the screenshots there.
> Configuration of both adaptors is in attached screen shot
> Trial01AdaptorConfig.jpg, i.e. nothing ticked!
>
> I'm starting the system with that configuration and the debug log enabled.
> I'm assuming it is OK to start from Step 5 given the above configuration.
>
> I'm using XBMC local to the tvheadend server as client 1 and a remote
> (internet) XBMC on windows as client 2.
>
> 5. Enable adapter0 only
> Adaptor enabled.
>
> 6. See how it performs, do you get any problems selecting channels etc...
> Changing channels. No issues with 20+ changes.
>
> 7. Disable adapter0 ....
> Adaptor 0 disabled, server stopped and log collected as
> 01Adaptor0Debug.log.
>
> 7. .....and then enable adapter1 (make sure its that order)
> Server started, adaptor 1 enabled.
>
> 8. See how it performs again.
> Changing channels. No issues with 20+ changes. Adaptor 1 then disabled and
> server stopped. Log collected as 02Adaptor1Debug.log.
>
> 9. Enable adapter0
> Server started, adaptor 1 enabled, adaptor 0 enabled.
>
> 10. See how it performs
> Changing channels, no issues with 20+ changes. System chose to use adaptor
> (Frontend) 1.
> Added second client which started to use adaptor 0. On second channel
> change of second client (to ITV +1) Testing/Bad occured. Recovered after a
> minute or so. On third channel change of second client, brief Testing on
> frontend 0 then OK. On fourth channel change of second client to ETV2
> extended Testing/Bad on frontend 0 with associated multiplex for that
> adaptor showing No Signal. Disabled mux on frontend 1. Stopped Live TV on
> client 1, which released frontend 1, which client 2 then automatically
> received with a functioning ETV2. Continuing channel changes on client 2
> work OK (still using frontend 0).
> Restart Live TV on client 1 and first channel selected gives Testing/Bad.
> It then looks like for the next channel change client 1 stole frontend 1
> from client 2 (was watching Film 4) and left client 2 with frontend 0 which
> reverted to Testing/Bad. Associated multiplex on frontend 0 now "Faint".
> Disabled this multiplex on the functioning frontend 1. On frontend 0 the
> "Faint" multiplex is now "OK" and the channel is now streaming.
> I'll stop the log there as I'm getting a bit bloody confused! Details in
> 03BothAdaptorsDebug.log.
>
> 11. If you find its not working see which adapter its trying to use first,
> and disable the mux on that adapter
> 12 .See if that changes anything
> 13. ELSE
> 14. Try disabling the mux on the adapter that worked
> 15. See if that changes anything
>
> Unfortunately I couldn't keep an eye on both clients, the multiplex list
> and the tvheadend status at all times.
>
> Hope the logs help.
>
> Rob
> ------------------------------
>
> You have received this notification because you have either subscribed to
> it, or are involved in it.
> To change your notification preferences, please click here:
> https://tvheadend.org/my/account >

Rob Hunter

Adam,

It certainly is an issue with one instance controlling both frontends - I've also run 2 instances, one on each frontend, without an issue.

I've also set-up vdr on the same system and it's working fine managing both frontends so I assume tvheadend and vdr are doing something different at the application - driver interface.

So if there is a "gotcha" in the TBS 6981 driver the vdr developers have created a workaround.

I'll raise a question with TBS asking if there is anything that needs to be considered with the 6981, referencing this thread, and emphasising that tvheadend handles other multi port dvb-s2 cards, including other TBS cards fine but appears to stumble with the 6981.

Rob

Anonymous

New to all this, only signed up because I was going to post a thread asking for help with exactly this! Will try everything in this thread when I get chance and report back.

Rob, did you contact TBS in regards to this? Wish I had paid a bit extra for a different card now!

Cheers,

Luke.

Rob Hunter

Hi Luke,

I have (somewhat tardily) got in touch with TBS support.

I'm putting a post in the recommended hardware thread to inform prospective users of this situation.

But I'm hoping it gets resolved.

Rob

Anonymous

This is driving me insane now :/ Heard anything back from TBS?

I'm just about ready to buy a new card, anyone got any recommendations? Need a dual tuner pci-e 1x card that is fully compatible with tvheadend (record 1 + watch 1) under ubuntu server.

Cheers.

Rob Hunter

Hi Luke,

I emailed TBS 10/06. Adam and Konstantin from TBS had an email exchange well over my head but I haven't heard anything since 11/06. I'll fire off an email and see if there is anything I can test. Still hopeful based on how quickly the initial response was.

Rob

Luis Alves

Hi all,

I have/had (more or less) this same issue.

When switching channels, occasionally the higher priority adapter (adapter0 in my case) will get stuck in a "Testing->Bad->Testing-Bad->..." loop until, a few minutes later, it eventually starts to work.

While waiting for a driver fix from TBS I've done a simple change in tvheadend code that until now is behaving quite well.

If you would like to try it, use this branch from my git:
https://github.com/ljalves/tvheadend/tree/lja

(git clone git@github.com:ljalves/tvheadend.git -b lja)

Basically, I disable and re-enable the adapter whenever I get a "Bad" status. To make the recovery faster I also reduced the grace period in each adapter to 2 seconds (although 3 seconds should be safer).

This has proven to work for me 99% of the times.

1% of the times I still get 2 Bad's in a row!

Please give feedback if it helps! I really need to know if my problem is the same as yours.

Using:
TBS drivers 20130506

Ubuntu server 12.04 64bit

Regards,
Luis Alves

Anonymous

Think I've done this correctly?

git clone git://github.com/ljalves/tvheadend.git
cd tvheadend
sudo apt-get install pkg-config libssl-dev
./configure --disable-avahi
sudo service tvheadend stop
sudo make install

sudo service tvheadend start

Only thing I'm slightly confused about from googline is the /etc/init.d/tvheadend script. It seems that the directory that tvheadend runs from may have changed at some point in the past, and people are saying to update the startup script? It doesn't seem applicable anymore?

Cheers.

Anonymous

I don't think I have done it correctly.. It doesn't work at the moment but if I go and manually disable/re-enable the adapter it does.

Luis Alves

Hi,

You need to switch branch:

> git clone git://github.com/ljalves/tvheadend.git -b lja

> cd tvheadend

> git clone git://github.com/ljalves/tvheadend.git
> cd tvheadend

> git checkout lja

then:

> ./configure (your options)

> make

then you don't need to install in order to test:
stop you current tvheadend:
> sudo service tvheadend stop

Run your freshly build:

> ./build.linux/tvheadend

To run with a different user:

> su htpc -c "./build.linux/tvheadend"

(replace htpc with any username)

By the way, I just noticed that if I have my second frontend (adapter1) running it will take longer to exit the testing->bad loop.

So please test it. If it works I can push a commit that adds an option to the webui where you can enable / disable this 'feature'.

EDIT: I have updated my branch to add a new option in the adapter config tab. The option is called "Recycle ..." located at the bottom.

Anonymous

Thanks for that, I was close :D

This is definitely better, I seem to sometimes get 3 or 4 bad's in a row but it does start playing within 10 seconds (grace period is set to 2). I can cope with this and at least 2 recording should work now.

Good job :)

Rob Hunter

Hi Luis,

I've built and tried it out.

I can definetly see it cycling through the Testing/Bad more quickly and it does seem to recover the channel change sometimes. However it still fails sometimes. The issue is probably somewhere quite deep in the Tvheadend/TBS code, but good attempt at a workaround to at least improve reliability for now!

In the meantime TBS have been looking at the issue. I have tried out a test driver set but saw no improvement. I'm feeding back to TBS my observations so hopefully something else will be forthcoming. In addition Adam from Tvheadend is continuing to look at the issue and communicating with TBS.

Fingers continue to be crossed.

Rob

Luis Alves

Hi,

Thanks for testing it out.

I really thought it was better, but definitively not perfect. I'll try to find a way to make it better...

Lets just hope that this issue is not an hardware issue due to some poor pcb layout. I already noticed that the crosstalk from the 2 tuner inputs is very high (not sure if this is normal in this kind of boards).

Adam says that his 6985 does not suffer from this issue and it has the same tuner and demodulator chips.

I still didn't try those new drivers but if you say they have the same issue then I'll just skip them.

So, not much to do unless to wait for TBS driver updates.

Luis

Andreas Henriksson

I have exactly the same problem, any news about this from TBS ???

Thanks Andreas H