Tvheadend

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).

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

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'.

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.

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.

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

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

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.

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?

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

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.

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

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

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

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.

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.

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'.

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 :/

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.

It does not bring any light to this issue.

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.

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

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

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.

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?