Project

General

Profile

Bug #4529

ATSC_C and DVB_C malfunction

Added by Pepe Suriano over 7 years ago. Updated almost 7 years ago.

Status:
Fixed
Priority:
Normal
Assignee:
-
Category:
Service Mapping
Target version:
-
Start date:
2016-07-22
Due date:
% Done:

100%

Estimated time:
(Total: 0.00 h)
Found in version:
All recent versions
Affected Versions:

Description

Hi people, I will like to discuss about an old issue with tvheadend and annex b networks. Actually I can tune dvb_c annex b with a tbs5881 via usb to a computer, with TBS drivers my dvb_c network was discovered as DVBC using the old parameter "annex b" that was available in old versions of TVH (it used to have annex a, annex b and annex c). Then the "annex combobox" was edited, leaving just DVBC and DVBC annex c, when this modification was made, using crazycat's driver TVH discovered my network as ATSC-C (it is a dvbc network), this was a problem because it causes slower zapping and it didn't load channel names, otherwise using scan-s2 it scanned all fine.

At this moment I placed this issue: http://tvheadend.org/issues/3907#change-19287 then crazycat modified his driver to solve my problem, here is a piece of our conversation at this moment:

"So DVB-C annex B scanned as ATSC PSI table - https://github.com/tvheadend/tvheadend/blob/master/src/input/mpegts/dvb_psi.c#L2674

And i decide make workaround in si2168 demod driver - force annex B if SR < 6000Ks
https://github.com/crazycat69/linux_media/commit/9c548b42b4fd335e4e9d010ccab5832d4e9954b2

So you can setup TVH as DVB-C annex A/C, but driver lock in annex B mode."

Looking at the code, I see that he hardcoded the frontend to make a temporal patch for this specific issue, but it justs solves the problem with tbs5881 and dvbc annex b, while the whole background problem with TVH is still present.

Now the same issue is present with KI STBs which uses AVL demods, they detect my network as ATSC-C and the same problem with zapping and channel names is present (as it was with tbs5881)

I asked libreelec community for help (https://forum.libreelec.tv/thread/9319-8-1-3-libreelec-8-2-for-s905-s905x/?postID=58511#post58511) and I get this answer from afl1:

"Tvheadend is different project, for principal issues you have to complain on tvheadend forum. But I had the same question on tvheadend forum and Jaroslav Kysela explain me: ATSC-C means DVB-C Annex B. BTW there is no standard ATSC-C, this is only introduced by tvheadend."

Source code for AVL driver is here: https://github.com/crazycat69/linux_media/commit/6275d078d972591b9e449c7bad0fa24ea7519380#diff-57be8964a5eb91a0bdc6b391f0a37aeb

I could just modify this section:

if (c->delivery_system == SYS_DVBC_ANNEX_A && c->symbol_rate < 6000000 ) {
+ c->delivery_system = SYS_DVBC_ANNEX_B;
+ c->bandwidth_hz = 6000000;
+ }

and force it to deliver 0x10 just as crazycat did with TBS5881 as workaround, but the problem with TVH will be still present and repeating at any different device with dvbc annex b networks.

I am not an expert of this topic, but I guess that when TVH discovers my network as ATSC-C it uses ATSC tables which are different from DVBC ones. Besides that my network modulate as ATSC-C, it uses DVBC tables.

Is it possible to solve this general problem adding back the "annex b" option in the DVBC scan process?

If you need any ts recording from KI STB (which fails) or with TBS5881 (which works) just tell me.

Thanks very much in advance

Files

dvbc.patch (1.06 KB) dvbc.patch Jaroslav Kysela, 2017-08-13 20:49
discovery.patch (408 Bytes) discovery.patch Jaroslav Kysela, 2017-08-16 13:40
trace.log (140 KB) trace.log Pepe Suriano, 2017-08-31 00:47
debug1.patch (1.1 KB) debug1.patch Jaroslav Kysela, 2017-08-31 16:18
trace.log (195 KB) trace.log Pepe Suriano, 2017-09-08 00:21
trace.log (194 KB) trace.log Pepe Suriano, 2017-09-08 00:22
trace.log (3.4 KB) trace.log Pepe Suriano, 2017-09-08 16:32
trace.log (12.1 KB) trace.log John King's, 2017-09-18 04:34
debug2.patch (779 Bytes) debug2.patch Jaroslav Kysela, 2017-09-18 14:13
tvh.log (1.08 MB) tvh.log John King's, 2017-09-20 04:23
log-noreboot.log (74.5 KB) log-noreboot.log Pepe Suriano, 2017-09-21 03:03
log-rebooted.log (24.3 MB) log-rebooted.log Pepe Suriano, 2017-09-21 03:04
output.log (6.36 KB) output.log Pepe Suriano, 2018-02-05 15:16

Subtasks

Bug #3907: Don't detect names of services from ATSC-CNew

Actions

History

#1

Updated by Jaroslav Kysela over 7 years ago

OK, so you want to say, that you have operator which uses 'DVB-C Annex B' modulation with ETSI DVB contents ? The original idea is that annex B is used only for North America (ATSC standard).

#2

Updated by Jaroslav Kysela over 7 years ago

Attaching a patch which should enable 'Annex B' for DVB-C network (with ETSI SI table parsing). Please, test.

#3

Updated by Pepe Suriano over 7 years ago

Jaroslav Kysela wrote:

Attaching a patch which should enable 'Annex B' for DVB-C network (with ETSI SI table parsing). Please, test.

Tested, it worked but some bugs were detected. When adding a mux, network discovery works fine (it founds all muxes), but it discovers all new muxes as dvbc instead of "atsc-c", when switching discovered muxes to atsc-c they scan fine, otherwise it fails.

BTW, it would be a good idea to change the name of "atsc-c" option in the combobox, perhaps "DVBC annex b" is a better choice.

Thanks for support and fast response

#4

Updated by Jaroslav Kysela over 7 years ago

I don't understand your requirement now. There are two things which are different for ETSI and ATSC standards for cable DVB:

1) modulation (annex A, annex B, annex C)
2) MPEG-TS SI tables contents (ETSI standard or ATSC standard)

TVH uses DVB-C name for ETSI MPEG-TS and ATSC-C for ATSC MPEG-TS.

My understanding is that your MPEG-TS stream follows ETSI, so DVB-C name is used.

ATSC spec: http://atsc.org/wp-content/uploads/2015/03/Program-System-Information-Protocol-for-Terrestrial-Broadcast-and-Cable.pdf

You can see, ATSC defines the PSIP tables for Terrestrial and Cable which are not in ETSI standards.

Your operator appearently broadcasts using the ETSI norm (MPEG-TS data) but the physical modulation follows modulation defined in 'Annex B'.

#5

Updated by Pepe Suriano over 7 years ago

Jaroslav Kysela wrote:

I don't understand your requirement now. There are two things which are different for ETSI and ATSC standards for cable DVB:

1) modulation (annex A, annex B, annex C)
2) MPEG-TS SI tables contents (ETSI standard or ATSC standard)

TVH uses DVB-C name for ETSI MPEG-TS and ATSC-C for ATSC MPEG-TS.

My understanding is that your MPEG-TS stream follows ETSI, so DVB-C name is used.

ATSC spec: http://atsc.org/wp-content/uploads/2015/03/Program-System-Information-Protocol-for-Terrestrial-Broadcast-and-Cable.pdf

You can see, ATSC defines the PSIP tables for Terrestrial and Cable which are not in ETSI standards.

Your operator appearently broadcasts using the ETSI norm (MPEG-TS data) but the physical modulation follows modulation defined in 'Annex B'.

Sorry for not being clear, I explain you with an example:

I create a mux for my dvbc network, I use "atsc-c" modulation when creating it. It scans fine

When original mux is scanned, network discovery finds a second mux, the second mux appears with "dvbc" modulation instead of "atsc-c" as the first mux has, so I have to switch it to atsc-c manually to scan it fine. This happens with all scanned muxes, they don't load with annex b modulation.

#6

Updated by Jaroslav Kysela over 7 years ago

Try this patch (on top of previous dvbc.patch):

#7

Updated by Pepe Suriano over 7 years ago

Jaroslav Kysela wrote:

Try this patch (on top of previous dvbc.patch):

Thanks for your answer, I tested it and now network discovery is just not working. I explain with example again:

I add a mux, this mux scans fine. And thats it, new muxes are not discovered and loaded, it is like having network discovery disabled.

#8

Updated by Jaroslav Kysela over 7 years ago

Have you tried to create TVH's DVB-C network with 'Annex B' modulation and add first mux there?

#9

Updated by Pepe Suriano over 7 years ago

Jaroslav Kysela wrote:

Have you tried to create TVH's DVB-C network with 'Annex B' modulation and add first mux there?

Yes, thats exacly what I have tried.

If you prefer we can look it together, just contact me and we take a look

#10

Updated by John King's about 7 years ago

Jaroslav Kysela wrote:

Try this patch (on top of previous dvbc.patch):

The first patch work but I can confirm the problem when scan network
The second patch doesn´t work for me.
If you want I can configure a STB with TVH to test prupourse and tell you the address, user and pass.

#11

Updated by Pepe Suriano about 7 years ago

John King's wrote:

Jaroslav Kysela wrote:

Try this patch (on top of previous dvbc.patch):

The first patch work but I can confirm the problem when scan network
The second patch doesn´t work for me.
If you want I can configure a STB with TVH to test prupourse and tell you the address, user and pass.

Hi people, any news?

#12

Updated by Jaroslav Kysela about 7 years ago

Provide '--trace tbl-base' when you add the first DVB-C / Annex B mux (with both patches applied). https://tvheadend.org/projects/tvheadend/wiki/Traces

#13

Updated by Pepe Suriano about 7 years ago

Jaroslav Kysela wrote:

Provide '--trace tbl-base' when you add the first DVB-C / Annex B mux (with both patches applied). https://tvheadend.org/projects/tvheadend/wiki/Traces

Here you go

#14

Updated by Jaroslav Kysela about 7 years ago

The cable delivery info is correctly extracted and passed to dvb_network_create_mux() in src/input/mpegts/mpegts_network_dvb.c , but there are probably ignored. I don't see a bug there on the first look. Perhaps, you can try to check this fcn.

#15

Updated by John King's about 7 years ago

Jaroslav Kysela wrote:

The cable delivery info is correctly extracted and passed to dvb_network_create_mux() in src/input/mpegts/mpegts_network_dvb.c , but there are probably ignored. I don't see a bug there on the first look. Perhaps, you can try to check this fcn.

Hello Jaroslav.
Then, we are needed another patch for another module?
Sorry but I´m not developer (I´m sysadmin) and I don´t understand correctly TVH scheme. What is the next step?
Now I understand both patches should be included in the source code, right?

Thanks

#16

Updated by Jaroslav Kysela about 7 years ago

Please, apply this debug1.patch (on top of all others) and provide '--trace tbl-base' again.

#17

Updated by Pepe Suriano about 7 years ago

Jaroslav Kysela wrote:

Please, apply this debug1.patch (on top of all others) and provide '--trace tbl-base' again.

Hope that helps

#18

Updated by Pepe Suriano about 7 years ago

Hope that helps

#19

Updated by Jaroslav Kysela about 7 years ago

I'm afraid, but it seems that the latest debug1.patch was not applied.

There should be warnings like 'create mux <address> discover <number> ...' .

#20

Updated by Pepe Suriano about 7 years ago

Jaroslav Kysela wrote:

I'm afraid, but it seems that the latest debug1.patch was not applied.

There should be warnings like 'create mux <address> discover <number> ...' .

It was, but not labeled under tbl-base subsystem, it was under mpegts.

#21

Updated by Jaroslav Kysela about 7 years ago

Please, always upload an unfiltered log.. There is also another debug line and I need to analyze all lines to have a picture what's going on.

#22

Updated by John King's about 7 years ago

Jaroslav Kysela wrote:

Please, always upload an unfiltered log.. There is also another debug line and I need to analyze all lines to have a picture what's going on.

I'm user of the some provider than Pepe and use KI Pro too.
With the latest patch (compiled by Afl1) I got signal as DVB-C, Delivery system ATSC-C and the channel names are OK but now directly it isn't able to do network discovery.
Here my log.

Thanks

#23

Updated by Jaroslav Kysela about 7 years ago

Attaching debug2.patch (replaces debug1.patch). Please, rerun with this patch.

Also, pls, provide full trace log: https://tvheadend.org/projects/tvheadend/wiki/Traces

It seems that there's some mismatch in this part of code in src/input/mpegts/mpegts_network_dvb.c:

    cls = dvb_network_mux_class((mpegts_network_t *)ln);
    save |= cls == &dvb_mux_dvbt_class && dmc->dmc_fe_type == DVB_TYPE_T;
    save |= cls == &dvb_mux_dvbc_class && dmc->dmc_fe_type == DVB_TYPE_C;
    save |= cls == &dvb_mux_dvbs_class && dmc->dmc_fe_type == DVB_TYPE_S;
    save |= cls == &dvb_mux_atsc_t_class && dmc->dmc_fe_type == DVB_TYPE_ATSC_T;
    save |= cls == &dvb_mux_atsc_c_class && dmc->dmc_fe_type == DVB_TYPE_ATSC_C;
    ... save == 0 here, but it should be non-zero ...
#24

Updated by John King's about 7 years ago

Jaroslav Kysela wrote:

Attaching debug2.patch (replaces debug1.patch). Please, rerun with this patch.

Also, pls, provide full trace log: https://tvheadend.org/projects/tvheadend/wiki/Traces

It seems that there's some mismatch in this part of code in src/input/mpegts/mpegts_network_dvb.c:

[...]

Here with the latest patch

#25

Updated by Jaroslav Kysela about 7 years ago

  • Status changed from New to Fixed
  • % Done changed from 0 to 100

Applied in changeset commit:tvheadend|2a1b74482442a254784e14256bc108c4e5cd9d7f.

#26

Updated by Jaroslav Kysela about 7 years ago

Fixed in v4.3-486-g2a1b74482 . The only problem might be with the predefined muxes, because there's no way to select the SI table type from the physical tuning parameters.

#27

Updated by Pepe Suriano about 7 years ago

Jaroslav Kysela wrote:

Fixed in v4.3-486-g2a1b74482 . The only problem might be with the predefined muxes, because there's no way to select the SI table type from the physical tuning parameters.

Hi, I have various things detected. First, network discovery is working fine (cool!), now there are some details that appeared:

1- It scans most muxes fine (when having not any mux scanned before), but usually a couple of muxes fail (random muxes). Scanning manually them works fine, but it is not the idea.

2- When having muxes previously added/deleted, new scans always fail, reboot is needed to get a proper scan again (with details mentioned before)

I send you 2 logs to check it out, one is scanning without rebooting and one is adding mux after reboot. Hope that helps.

Thanks for support!

#28

Updated by Jaroslav Kysela about 7 years ago

It seems like a driver issue. Look for 'linuxdvb: Availink avl6862 #0 : DVB-C #0 - status' lines. When things does not work, the driver reports 'no lock'.

#29

Updated by Pepe Suriano about 7 years ago

Jaroslav Kysela wrote:

It seems like a driver issue. Look for 'linuxdvb: Availink avl6862 #0 : DVB-C #0 - status' lines. When things does not work, the driver reports 'no lock'.

Just restarting tvheadend service solves the problem (systemctl restart service.tvheadend42.service), if one mux fails and I restart t he service, it scans fine after restarting, so it seems that we still have some issues present :/

#30

Updated by Jaroslav Kysela about 7 years ago

I'm sorry, I cannot help you much. It appears that DVB device open/close helps, but it's really the driver issue. You are using an ancient kernel or wrongly compiled tvh (with old dvbapi - lower than DVBv5), so I cannot check, if the tuning parameters are same for both requests.

#31

Updated by Pepe Suriano almost 7 years ago

Jaroslav Kysela wrote:

I'm sorry, I cannot help you much. It appears that DVB device open/close helps, but it's really the driver issue. You are using an ancient kernel or wrongly compiled tvh (with old dvbapi - lower than DVBv5), so I cannot check, if the tuning parameters are same for both requests.

Hi, there are new issues scanning here, now just scanning a simple mux fails, there have been changes related to this topic? Logs are attached

#32

Updated by Jaroslav Kysela almost 7 years ago

It does not bring any light to this issue.

#33

Updated by Mark Clarkstone almost 7 years ago

Availink tuners are horrible - they're used in these boxes for a reason - they're cheap, last time I dealt with one they don't do full mux receive & the driver isn't great, very buggy.

#34

Updated by Pepe Suriano almost 7 years ago

Mark Clarkstone wrote:

Availink tuners are horrible - they're used in these boxes for a reason - they're cheap, last time I dealt with one they don't do full mux receive & the driver isn't great, very buggy.

It was working almost in a perfect way as seen in previous comments, but now something changed and I cannot identify the reason

How can I collect a more detailed log for this case? I found different ways, but I cannot identify the most suitable

#35

Updated by Pepe Suriano almost 7 years ago

Mark Clarkstone wrote:

Availink tuners are horrible - they're used in these boxes for a reason - they're cheap, last time I dealt with one they don't do full mux receive & the driver isn't great, very buggy.

Just another point to consider, this demods are getting any day more extended and more commonly found in amlogic bodes (broadly extended), it isn't a good idea to give it a good support from the project to enforce the community? If you people like to go on, I will be glad to help us, just tell me what logs to extract

#36

Updated by John King's almost 7 years ago

Hi, I have been using tvheadend with two KI Pro and a KIII Pro since the patch was issued. Let me make my contribution:

It does scan "fine" just like it started to do when the patch was applied, the issue is that when scanning goes through muxes with low signal, next muxes to them fail them all. But if you scan manually after restarting tvheadend service they scan fine (all the others which have not the low signal)

It fails always after scanning a low signal mux.

I agree that avl6882 is very buggy, but I also agree that this boxes are getting famous and it still does the job. I have no problems playing channels after scanning muxes manually, if this can be fixed, it will work like a charm for such a cheap demod.

#37

Updated by Mark Clarkstone almost 7 years ago

John King's wrote:

Hi, I have been using tvheadend with two KI Pro and a KIII Pro since the patch was issued. Let me make my contribution:

It does scan "fine" just like it started to do when the patch was applied, the issue is that when scanning goes through muxes with low signal, next muxes to them fail them all. But if you scan manually after restarting tvheadend service they scan fine (all the others which have not the low signal)

It fails always after scanning a low signal mux.

I agree that avl6882 is very buggy, but I also agree that this boxes are getting famous and it still does the job. I have no problems playing channels after scanning muxes manually, if this can be fixed, it will work like a charm for such a cheap demod.

Maybe using "Tune repeats" and increasing "Skip initial bytes" might help?

Also available in: Atom PDF