Tvheadend

I have exactly the same setup as you and i was also thinking the same thing.
Did you ever get the TBS6982 in the end and if so, any problems.
It wourld be great to finally have a fully working system again.

What is the problem you're seeing? I don't understand the "can only use on tuner with TBS driver" reference.

I've had a TBS 6981 for a couple of years and haven't experienced anything other than the Continuity Counter errors issue. I recently purchased a TBS 6985, which actually showed more continuity counter errors, but I've managed to resolve that with a kernel patch and a module option change to MSI interrupts.

I think he is referring to the problem mentioned here.
https://tvheadend.org/boards/5/topics/8524?r=8551#message-8551

p.s. I also think that he ment to say "can only use one tuner with TBS driver" as that the problem im having.

Oh yes, I certainly remember that issue and experienced it myself. I ended up making a TvHeadend patch that resolved the issue. It seemed to be a timing error when tuning the frontend.

I've recently returned to using TvHeadend (3.9x) after the DVB re-write and haven't experienced the problem. If the tuning problem persists, I can dig out the old patch that I had.

I might give TvHeadend (3.9x) a try out then. It will be great if that fixes it.

If you can't get it working, then let me know and I'll dig the patch out and see if I can also port it to 3.9x

Will do. Thanks

Nick Burrett wrote:

What is the problem you're seeing? I don't understand the "can only use on tuner with TBS driver" reference.

I've had a TBS 6981 for a couple of years and haven't experienced anything other than the Continuity Counter errors issue. I recently purchased a TBS 6985, which actually showed more continuity counter errors, but I've managed to resolve that with a kernel patch and a module option change to MSI interrupts.

Which patches are you using?

Nick Burrett wrote:

If you can't get it working, then let me know and I'll dig the patch out and see if I can also port it to 3.9x

Not looking good for 3.9x either. The problem still exists. I do like the changes that ware made for the 4.0 release alright.
I have switch back to 3.4 for now and will try out 3.9x again after christmas.

All,

I think this has already been spelt out several times, but I feel obliged to do it once again. The problem with the 6981 (and other TBS drivers) is reasonably well understood. The crux of the issue is a failure, in the driver, to protect key/shared resources. This causes tuning commands to overlap (become garbled) and ultimately results in only 1 tuner working most of the time.

I even provided TBS with a simple test program that could clearly demonstrate the fault without needing TVH in the loop. It did nothing fancy, just tuned both tuners one after the other. And it was easy to make the problem go away by adding a completely arbitrary delay between tuning operations. This is ofc possible within TVH, though I hate adding some kludges to fix broken drivers. And it would not work if I moved to a truly async programming model (which I eventually will for better performance), nor will it work if you happen to use the device in 2 different applications (like I do during testing).

I have considered adding an option in the code for a user configurable delay (and even a default if TBS device is detected, though it doesn't affect all device/driver combinations) just because I know how annoying it is. The problem is it's masking a more serious fault in the driver which all TBS customers should really be bugging TBS to fix, its not like the problem is not well understood and clearly demonstrable and indeed Luis' specifically wrote the open source driver to overcome the limitations and funnily enough his driver doesn't suffer from any of these (apparently TVH related) issues!

And if you're after an entertaining read, please see the blog post I made of our email thread with TBS' driver maintainer, http://tvheadend.wordpress.com/2013/07/11/tbs-6981-debacle/.

Adam

Thanks for that great reply and sorry for bringing it up again. Very interesting blog post alright.
Unfortunately I think I will have to retire my 6981 and get the 6982 and hope that it will not have the same problem.
And from what I have read it most likely won't. Its a real pitty I can't use the open source driver as
I would love too, if only I didn't have the 6280.

P.S Great work with the new update by the way.

I have the I thing similar problem with my DD Cine S2 (ddbridge driver 0.9.9). I get really lot of these errors in the 3.9.11:

...
Jan  2 11:59:07 tvhe tvheadend[2338]: TS: 12070H/Prima COOL: MPEG2VIDEO @ #3185: Continuity counter error
Jan  2 11:59:07 tvhe tvheadend[2338]: TS: 12070H/Prima COOL: TELETEXT @ #3187: Continuity counter error
Jan  2 11:59:50 tvhe tvheadend[2338]: TS: 12070H/Prima COOL: MPEG2VIDEO @ #3185: Continuity counter error
Jan  2 11:59:50 tvhe tvheadend[2338]: TS: 12070H/Prima COOL: MPEG2AUDIO @ #3186: Continuity counter error
...

I was previously running VDR 1.7 without such issues at all. These errors are really annoying inside the recordings or during the live-tv. Is there a way how to temporary disable the epg grab to see whenever this is the issue?

on the debugging console I do see, it will be very simmilar problem for my DD Cine S2 V 6.5 card... the Continuity error really happens between tuning commands of one of the other adapters, but not always...

(recording on /dev/dvb/adapter0)

2014-01-03 11:38:50.626 [   INFO]:mpegts: 10743H - tuning on /dev/dvb/adapter2/frontend0
2014-01-03 11:38:51.699 [WARNING]:TS: 12070H/Prima COOL: MPEG2VIDEO @ #3185: Continuity counter error
2014-01-03 11:38:51.699 [WARNING]:TS: 12070H/Prima COOL: MPEG2AUDIO @ #3186: Continuity counter error
2014-01-03 11:38:51.699 [WARNING]:TS: 12070H/Prima COOL: TELETEXT @ #3187: Continuity counter error
2014-01-03 11:38:51.902 [  DEBUG]:linuxdvb: /dev/dvb/adapter2/frontend0 - starting 10743H
...

2014-01-03 11:43:37.542 [   INFO]:mpegts: 12109H - starting for 'epggrab' (weight 1)
2014-01-03 11:43:37.542 [   INFO]:mpegts: 12109H - tuning on /dev/dvb/adapter3/frontend0
2014-01-03 11:43:38.601 [WARNING]:TS: 12070H/Prima COOL: MPEG2VIDEO @ #3185: Continuity counter error
2014-01-03 11:43:39.070 [  DEBUG]:linuxdvb: /dev/dvb/adapter3/frontend0 - starting 12109H
...

2014-01-03 11:46:26.682 [   INFO]:mpegts: 10802H - tuning on /dev/dvb/adapter2/frontend0
2014-01-03 11:46:27.219 [WARNING]:TS: 12070H/Prima COOL: MPEG2VIDEO @ #3185: Continuity counter error
2014-01-03 11:46:27.490 [  DEBUG]:linuxdvb: /dev/dvb/adapter2/frontend0 - starting 10802H
.
2014-01-03 11:46:26.682 [   INFO]:mpegts: 10802H - tuning on /dev/dvb/adapter2/frontend0
2014-01-03 11:46:28.579 [WARNING]:TS: 12070H/Prima COOL: MPEG2VIDEO @ #3185: Continuity counter error, 1 duplicate log lines suppressed
2014-01-03 11:46:28.579 [WARNING]:TS: 12070H/Prima COOL: MPEG2AUDIO @ #3186: Continuity counter error
2014-01-03 11:46:28.632 [WARNING]:TS: 12070H/Prima COOL: CA @ #112: Continuity counter error
2014-01-03 11:46:28.632 [WARNING]:TS: 12070H/Prima COOL: CA @ #108: Continuity counter error
2014-01-03 11:46:29.286 [  DEBUG]:linuxdvb: /dev/dvb/adapter3/frontend0 - starting 12603H
...

I will have to test it outside of kvm

Mikael Persson wrote:

Nick Burrett wrote:

What is the problem you're seeing? I don't understand the "can only use on tuner with TBS driver" reference.

I've had a TBS 6981 for a couple of years and haven't experienced anything other than the Continuity Counter errors issue. I recently purchased a TBS 6985, which actually showed more continuity counter errors, but I've managed to resolve that with a kernel patch and a module option change to MSI interrupts.

Which patches are you using?

Apply the continuity-counter-fix.patch to the TBS driver tree (backport from latest kernel). This will reduce the number of CC errors that tvheadend receives.

I additionally applied tsmdemux-cc-ignore.patch to the tvheadend tree for two reasons:
- extra logging to tell me what the received continuity counter was and what is expected. Normally if there's corruption, the counters will be more than off by one.
- do not set the error bit if a continuity counter error is detected. This leaves the possible error as something the player client would deal with and helps fix issues with seeking backwards through .ts streams with mplayer and playing back recordings with XBMC which can just stop for no reason.

Nick Burrett wrote:

If you can't get it working, then let me know and I'll dig the patch out and see if I can also port it to 3.9x

I applied tvheadend-dvb-fe.patch to make both tuners on the TBS 6981 work in tvheadend. I had used it successfully for a few months. The patch is against trunk from 25 June 2013.

Hi TBS6982 owners,

Soon I will provide an open source driver for the TBS6982SE.
I'm not sure what are the major differences between the TBS6982 and TBS6982SE but at least we can give it a try.

Please follow this topic for more updated on the open source driver:
https://github.com/ljalves/linux_media/issues/10

PS: I would provide more open source drivers for all TBS cards, but that requires me to have the real hardware (mostly to do a lot of i2c sniffing).

Regards,
Luis

Nick Burrett wrote:

Mikael Persson wrote:

Nick Burrett wrote:

What is the problem you're seeing? I don't understand the "can only use on tuner with TBS driver" reference.

I've had a TBS 6981 for a couple of years and haven't experienced anything other than the Continuity Counter errors issue. I recently purchased a TBS 6985, which actually showed more continuity counter errors, but I've managed to resolve that with a kernel patch and a module option change to MSI interrupts.

Which patches are you using?

Apply the continuity-counter-fix.patch to the TBS driver tree (backport from latest kernel). This will reduce the number of CC errors that tvheadend receives.

I additionally applied tsmdemux-cc-ignore.patch to the tvheadend tree for two reasons:
- extra logging to tell me what the received continuity counter was and what is expected. Normally if there's corruption, the counters will be more than off by one.
- do not set the error bit if a continuity counter error is detected. This leaves the possible error as something the player client would deal with and helps fix issues with seeking backwards through .ts streams with mplayer and playing back recordings with XBMC which can just stop for no reason.

I have a TBS6985 so then it would be enough to add this two patches? The tvheadend-dvb-fe.patch are for TBS6981 or?

BR,
Micke

Be aware that the only part of that patch that does anything useful is the usleep(1000000) or sleep(1). And as we clearly demonstrated, you only really need do usleep(50000) to make the probability (and I can't stress that enough, no amount of sleeping will ever make it 100% with this driver, but near enough not to notice) ~100%. And this is all because of a total failure of the driver to properly protect it's shared resources. If you're unlucky enough to be using 2 sep. DVB apps (or 2 instances of TVH, like I do during dev) and they happen to try and tune both tuners at the same time (admittedly a less likely event) then your outta luck, it'll fail!

Adam

Mikael Persson wrote:

Nick Burrett wrote:

Mikael Persson wrote:

Nick Burrett wrote:

What is the problem you're seeing? I don't understand the "can only use on tuner with TBS driver" reference.

I've had a TBS 6981 for a couple of years and haven't experienced anything other than the Continuity Counter errors issue. I recently purchased a TBS 6985, which actually showed more continuity counter errors, but I've managed to resolve that with a kernel patch and a module option change to MSI interrupts.

Which patches are you using?

Apply the continuity-counter-fix.patch to the TBS driver tree (backport from latest kernel). This will reduce the number of CC errors that tvheadend receives.

I additionally applied tsmdemux-cc-ignore.patch to the tvheadend tree for two reasons:
- extra logging to tell me what the received continuity counter was and what is expected. Normally if there's corruption, the counters will be more than off by one.
- do not set the error bit if a continuity counter error is detected. This leaves the possible error as something the player client would deal with and helps fix issues with seeking backwards through .ts streams with mplayer and playing back recordings with XBMC which can just stop for no reason.

I have a TBS6985 so then it would be enough to add this two patches? The tvheadend-dvb-fe.patch are for TBS6981 or?

Yes, for the TBS6985 (which is what I use these days), it is enough to apply both patches continuity-counter-fix.patch and tsdemux-cc-ignore.patch. The tsdemux-cc-ignore.patch isn't strictly necessary, but I happened to use that before fixing the kernel and like the additional debug info.

I have run with both patches for a month and have significantly fewer picture artifacts (most now are due to the satellite dish being shifted by the storms that have continuously passed over Ireland for the past month, preventing me from getting on the roof to re-align the dish).

I also set this in /etc/modprobe.d/dvb.conf to stop the "IRQ 16 .. nobody cared" kernel oops by changing the interrupts to MSI:

options saa716x_tbs-dvb int_type=1

Regards,

Nick

I'm not aware of any patches required to make the 6985 work, I've been running mine successfully for over a year with the bog standard TBS drivers (probably been updated once in that period, I don't have much faith in the author so no point updating when things appear to already work!). Looking forward to Luis providing a driver for the 6985 (which he thinks may be possible).

That TVH patch doesn't appear to change anything functional, just adds some extra debug (could be useful).

Adam

Adam Sutton wrote:

I'm not aware of any patches required to make the 6985 work, I've been running mine successfully for over a year with the bog standard TBS drivers (probably been updated once in that period, I don't have much faith in the author so no point updating when things appear to already work!). Looking forward to Luis providing a driver for the 6985 (which he thinks may be possible).

That TVH patch doesn't appear to change anything functional, just adds some extra debug (could be useful).

The TVH patch disables the setting of the error flag when there's a continuity counter mismatch and as such leaves it up to the media player to deal with such issues itself. Without the change, I find that seeking backwards through a stream with mplayer, where that stream had reported CC errors, would often stick at the point in time where the CC error occurred. Or normal playing of the stream would often cause mplayer to hang when the part of the programme where the CC error occurred was encounted.

With the patch, mplayer deals with the stream just fine.

Hi,

When I use the default driver I get a lot of "Continuity counter errors". You have no problem with that?

I have released an open source driver for the TBS6982SE (working good).

Need testers for the TBS6982 (non-SE)

https://github.com/ljalves/linux_media/wiki

Regards!

Luis Alves wrote:

I have released an open source driver for the TBS6982SE (working good).

Need testers for the TBS6982 (non-SE)

https://github.com/ljalves/linux_media/wiki

Regards!

I saw that driver for TBS6985 is available. How is the status, is it time for testing? Do you have to remove the old TBS6985 "original" driver somehow?

Well, I just tried this driver on the TBS6985. The adapters are correctly detected and attach. I can tune to a channel with szap-s2, but after configuring them in TvHeadend:

Jan 18 14:38:50 satellite tvheadend¹²⁶³: subscription: 'initscan' subscribing to mux, weight: 2, adapter: 'Tmax TAS2101 : DVB-S #2', network: 'Sky', mux: '11798H'
Jan 18 14:38:50 satellite tvheadend¹²⁶³: mpegts: 11390H - initial scan no data, failed
Jan 18 14:38:50 satellite tvheadend¹²⁶³: subscription: "initscan" unsubscribing
Jan 18 14:38:50 satellite tvheadend¹²⁶³: mpegts: 11565V - starting for 'initscan' (weight 2)
Jan 18 14:38:50 satellite tvheadend¹²⁶³: mpegts: 11565V - tuning on Tmax TAS2101 : DVB-S #1
Jan 18 14:38:50 satellite tvheadend¹²⁶³: subscription: 'initscan' subscribing to mux, weight: 2, adapter: 'Tmax TAS2101 : DVB-S #1', network: 'Sky', mux: '11565V'
Jan 18 14:38:50 satellite tvheadend¹²⁶³: mpegts: 12460H - initial scan no data, failed
Jan 18 14:38:50 satellite tvheadend¹²⁶³: subscription: "initscan" unsubscribing
Jan 18 14:38:50 satellite tvheadend¹²⁶³: mpegts: 12629V - starting for 'initscan' (weight 2)
Jan 18 14:38:50 satellite tvheadend¹²⁶³: mpegts: 12629V - tuning on Tmax TAS2101 : DVB-S #0
Jan 18 14:38:50 satellite tvheadend¹²⁶³: subscription: 'initscan' subscribing to mux, weight: 2, adapter: 'Tmax TAS2101 : DVB-S #0', network: 'Sky', mux: '12629V'

Similarly, tuning and setting up the dvr0 device via szap-s2, yields no output when using mplayer, or simply cat /dev/dvb/adapter4/dvr0 >out.ts

dvbtraffic shows this when tuned to BBC 1 NI HD:

PID--FREQ-----BANDWIDTH-BANDWIDTH
0fff 6 p/s 1 kb/s 10 kbit
1e43 8 p/s 1 kb/s 13 kbit
1fff 66023 p/s 12121 kb/s 99299 kbit
2000 66039 p/s 12124 kb/s 99323 kbit
PID--FREQ-----BANDWIDTH-BANDWIDTH
03ff 20 p/s 3 kb/s 31 kbit
1f03 17 p/s 3 kb/s 26 kbit
1f88 38 p/s 6 kb/s 58 kbit
1fff 66217 p/s 12157 kb/s 99590 kbit
2000 66294 p/s 12171 kb/s 99707 kbit
PID--FREQ-----BANDWIDTH-BANDWIDTH
02ff 2 p/s 0 kb/s 4 kbit
1fff 66291 p/s 12170 kb/s 99702 kbit
2000 66294 p/s 12171 kb/s 99707 kbit
PID--FREQ-----BANDWIDTH-BANDWIDTH
1f01 12 p/s 2 kb/s 19 kbit
1fff 66026 p/s 12121 kb/s 99304 kbit
2000 66039 p/s 12124 kb/s 99323 kbit
PID--FREQ-----BANDWIDTH-BANDWIDTH

Nick