Project

General

Profile

Anyone got TBS 6984 working after ver 3.3.110 ?

Added by Kjell A. Stormo about 12 years ago

Hello, does anyone got the TBS 6984 or TBS 6981 working with the latest tvheadend versions
(git ver abowe 3.3.110)
I really would like some guiding if anyone have got this working.


Replies (6)

RE: Anyone got TBS 6984 working after ver 3.3.110 ? - Added by nicolas Hovnanian about 12 years ago

https://www.lonelycoder.com/redmine/boards/5/topics/6050

need use 3.2, problem when you map With TBS 6984 or other with same processor for moment

RE: Anyone got TBS 6984 working after ver 3.3.110 ? - Added by Kjell A. Stormo about 12 years ago

Thank you for the update, it looks better now.
I still have some problem with some streams just stopping, but this i think is another problem.
it's not the same channel that stopps each time, so i have to find a pattern her before i know what to report.
Thanks for great work.

Kjell A.

RE: Anyone got TBS 6984 working after ver 3.3.110 ? - Added by Kjell A. Stormo about 12 years ago

Have tested the update for some houurs now, the TBS card can receive signals, but i do now get about 4 times the amount of continuity code error, then i used to in 2.99 and 3.3.78.

I also sometimes get some of these:
Nov 05 20:50:35 dvb: "_dev_dvb_adapter1_TurboSight_TBS_6984_DVBS_S2_frontend" read() EOVERFLOW
This one is new ???

Kjell A.

RE: Anyone got TBS 6984 working after ver 3.3.110 ? - Added by Adam Sutton about 12 years ago

It may be that the slight increase in processing overhead is having an effect when it comes to dealing with something like a quad tuner? I don't see this with my 6981, I do get the occasional one off on channel zap and then very (and I mean very) rare ones during normal operation.

The EOVERFLOW error is what was causing all the problems before. Previously the code treated this as an unknown/fatal error and silently (naughty) exited the DVB stream input thread (which is why stuff simply stopped). This in fact a non-fatal error and is basically the kernels way of saying that we missed some data because its internal buffers overflowed (i.e. we didn't read quick enough).

This seems to happen pretty much everytime with my 6981 (and I'm guessing your 6984) on channel zap, after which I don't see it again. But maybe again loading with 4 tuners means its a bit more likely (and I've not really stressed both of my tuners since the update). It is non-fatal and the system will mostly carry on (just the same a as CC error etc..)

I'm not sure how much TVH can do about it, but any input on the relative frequency between levels of errors in filtered and raw mode (you can now use my adapter config option to disable raw mode) might be useful to help us understand whether we do need to change things.

Adam

RE: Anyone got TBS 6984 working after ver 3.3.110 ? - Added by Kjell A. Stormo about 12 years ago

Have tested the 3.3.137 version, this morning when i checked, the machine had frosen comlpetly, FATAL ERROR,
and now i get some No signal error again, av set all adapters to Full mux on.
Less CC error, more No signal error
Think i might have to revert back to 3.3.126 it was at least up for 24 hours :-)

Can you please walk me trough the settings page for the adapter, an tell me what the check bokses does?

Use SID as channel number during mapping: ?
Full mux reception:
Disable PMT monitoring:
Original Network ID:
Extra priority:
DiSEqC repeats:

What will most effect on my cards?
remind i have 2x4 adapters running.

Have removed the obvious boxes :-)

Kjell

RE: Anyone got TBS 6984 working after ver 3.3.110 ? - Added by Adam Sutton about 12 years ago

SID chan num map - Ignore this, its only really relevant to a select number of US users (basically it uses the service ID as channel number in initial mapping if no other channel number is provided).

Full mux RX - this will allow TVH to do software table processing rather than using HW filters. This has some benefits, but isn't critical and if you see problems with full mux RX (default for PCI cards) disable it.

PMT monitoring - this was added to reduce number of PID filters (not relevant if you have full mux RX enabled) for cards that allow limited HW filters. Yours is unaffected.

ONID - this is to do with network management and for the most part is redundant in master these days, it will eventually be removed I think.

Extra prio - this allows you to prioritise which card/adapter is used. Useful if you get the same channel on diff tuners and have reason to prefer one over another (better cabling, better dish, better tuner, etc...)

DiSEqC repeats - re-tx of switch commands, not relevant unless you have DiSEqC hardware.

Adam

    (1-6/6)