Tvheadend

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.

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

1. Idle Scanning: Ticked
2. Close device handle when idle: Unticked
3. 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.

1. Idle Scanning: Unticked
2. Close device handle when idle: Unticked
3. 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.

1. Idle Scanning: Unticked
2. Close device handle when idle: Ticked
3. Turn off LNB when idle: Unticked
   Ditto.

1. Idle Scanning: Unticked
2. Close device handle when idle: Unticked
3. Turn off LNB when idle: Ticked
   Ditto.

1. Idle Scanning: Unticked
2. Close device handle when idle: Ticked
3. 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.

1. Idle Scanning: Ticked
2. Close device handle when idle: Ticked
3. Turn off LNB when idle: Unticked
   Ditto. + some multiplexes just degrade anyway as they are Idle Scanned.

1. Idle Scanning: Ticked
2. Close device handle when idle: Unticked
3. 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".

1. Idle Scanning: Ticked
2. Close device handle when idle: Ticked
3. 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".

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?".

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:

1. Enable "skip initial scan" (this really should be default, this will be gone in next version)
2. Disable "monitor signal quality"
3. Get everything configured/scanned etc...
4. Disable BOTH adapters (and save)
5. Enable adapter0 only
6. See how it performs, do you get any problems selecting channels etc...
7. Disable adapter0 and then enable adapter1 (make sure its that order)
8. See how it performs again.
9. Enable adapter0
10. See how it performs
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

Adam

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

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

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

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.

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

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.

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

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 [email protected]: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

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.

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.

Hi,

You need to switch branch:

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

or

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.

Thanks for that, I was close

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

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

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

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

Thanks Andreas H

No new news I'm afraid.

I'll take the opportunity to prod TBS again.

It's a hard one to know what to do. On the one hand TBS are selling a product so should provide support. On the other hand the card works fine with vdr and other software, so the problem may be with tvheadend. As it's open source that means either fix it yourself or persuade someone who knows how to!

If I could return the TBS6981 I'd so and find something that works (see the device compatibility thread). I've had mine for too long so, as I don't possess the skills or the time to try and fix it, I'll probably switch to vdr when my system goes production over the next couple of weeks. Not my preferred solution but, hey, it works. Can't complain as I've nothing invested in tvheadend!

Rob

hummm. Sad to hear :-(

I like TVH wery much and not want to stop using it.

I think i will use only one tuner and maybe buy an extra card so i have 2 tuners.

Thanks anyway Andreas H

Guys,
Same thing happening to me with a TBS6981. Only one adapter can be used at any time. As soon as I stop playing from one adapter, the other one starts working fine.

Happy to provide logs if I can...

By the way, I just updated to the latest driver version, (130506) and the issue persist, as noted on the first post. I'll try the latest git.

I don't remember having this issue on v3.2, but to be honest, raspmbc didn't support live tv at that time

Hi all,

Driven by the frustration of this issue, I have developed an open source driver for the tbs6981: [[https://github.com/ljalves/linux_media/wiki]]
I expect to get it included in the mainline kernel tree soon.

If you find any issue, please fill the form in github: [[https://github.com/ljalves/linux_media/issues]]

Thanks and Regards,
Luis

I'd like to take a look this issue. A short while ago, can't remember which version of TVH it was, but I had six instances of XBMC running with three HD & 3 SD channels running but, speech was was only active in the first instance of XBMC. Now, with the most recent TVH it says something like both tuners are already active and won't provide any other XBMX instances with a stream. Now as I understand it the TBS6981 is good for several channel multiplex streaming. TBS say so on their site, beside I've seen it. What I wanted to prove to myself was that the 6981 could do mult-channel recording.

Now what I'm after is the Conexant CX23885-13Z full data sheet and if possible the programmers guide because without the register set info I'm stuck and I don't really want to guess what TBS's driver code is doing.

So, if anybody has a copy they could put my way or give me a link to the same it would be another pair eyes working on the issues.

Thanks one and all. Mac