DVBv5 tools version 0.0.1

ANNOUNCE Mauro Carvalho Chehab 3 participants 14 messages Jan 7, 2012 – Jan 16, 2012 Media (V4L/DVB)

Share & tools

Mauro Carvalho Chehab

author

2012-01-07 12:19 UTC #0 lore raw

As previously commented at the ML, I'm developing a set of tools using DVBv5 API. Instead of starting from something existing, I decided to start from scratch, in order to avoid polluting it with DVBv3 legacy stuff. Of course, I did some research inside the existing tools, in order to fill in the blanks, using the dvb-apps tzap as a reference for the first real application on it, but removing a large amount of code (file parsers, etc).

They're now on a good shape, at least for my own usage ;)

In order to test, you should use:

git clone git://linuxtv.org/mchehab/experimental-v4l-utils.git

And then run "make". the utils are inside utils/dvb.

I plan to do some cleanup at the patches later (basically, changing the patch descriptions), and add it inside the v4l-utils, in order to have the basic tools I use for testing media devices into the same place.

DVB TOOLS
=========

This is a series of tools written to help testing and working with DVB, using its latest V5 API. The tools can also work with the DVBv3 API.

The current tools are:

dvb-fe-tool - a simple test application, that reads from the frontend.
it also allows to change the default delivery system. In the future, it may be used to change any property via command line.

dvb-format-convert - converts from zap and scan "initial-tuning-data-file"

	      into the new format defined to work with DVBv5;

dvbv5-scan - a DVBv5 scan tool;

dvbv5-zap - a DVBv5 zap tool. It allow to tune into a DVB channel, and
to watch to a DVB service (e. g. receiving the video and audio streams, via another application using the dvr device).

Each application code is very small, as most of the code are on some generic code that will become a library in the future.

CONTENTS OF THE TREE
====================

parse_string.c/parse_string.h: MPEG-TS string decoder with charset translator

Used to decode NIT/SDT service name, network provider and provider name. It parses the charsets according with the DVB specs, converting them into UTF-8 (or other charset), using iconv library.

descriptors.c/descriptors.h: MPEG-TS descriptors parser

The code there is generig enough to decode the MPEG-TS descriptors, with the DVB and other Digital TV extensions.

libscan.c/libscan/h: DVBv5 scanning library

This library is used to retrieve DVB information from the MPEG TS headers, discovering the services associated to each DVB channel or transponder. The services information is the basic info that most DVB tools need to tune into a channel.

dvb-file.c/dvb-file.h: DVB file read/write library.

Allows parsing a DVB file (legacy or not) and to write data into a DVB file (new format only).

dvb-fe.c/dvb-fe.h: DVB frontend library.

Allows talking with a DVB frontend via DVBv5 or DVBv3 API.

dvb-zap-format.c/dvb-legacy-channel-format.c:

Contains the data structures required in order to read from the legacy formats (zap or scan "initial-tuning-data-file").

dvb_frontend.h: DVBv5 frontend API.

This is just a copy of the newest linux/dvb/frontend.h header. I opted to keep a copy there, in order to allow working with the tools without needing to copy the latest header into /usr/include.

dvb-v5.h/dvb-v5-std.h:

Ancillary files linked into dvb-fe code, used to parse DVB tables. The dvbv5.h is generated by a small perl util, from the DVB FE API file.

dvb-demux.c/dvb-demux.h: DVB demux library.

Used by the dvbv5-zap utility.

dvb-fe-tool.c, dvb-format-convert.c, dvbv5-zap.c, dvbv5-scan.c: tools code.

Basically, parses the options from userspace and calls the other code to do what was requested by the user.

CHANNEL/SERVICE FILE FORMAT
===========================

Instead of having two different files, one for services, and another for channels/transponders, I opted to use just one format for both. The format is:

[channel]
key1=value1
key2=value2
key3=value3
...
keyn=valuen

lines with # are discarted by the parsers. Also, whitespaces/tabs before the keys and before/after the equal sign.

Be careful: whitespace in the middle of the value are not discarded.

A typical service would be like:

[TV Brasil HD]
VCHANNEL = 2.2
SERVICE_ID = 16160
VIDEO_PID = 770
AUDIO_PID = 514 614
FREQUENCY = 479142857
MODULATION = QAM/AUTO
BANDWIDTH_HZ = 6000000
INVERSION = AUTO
CODE_RATE_HP = AUTO
CODE_RATE_LP = NONE
GUARD_INTERVAL = AUTO
TRANSMISSION_MODE = AUTO
HIERARCHY = NONE
ISDBT_LAYER_ENABLED = 7
ISDBT_PARTIAL_RECEPTION = 0
ISDBT_SOUND_BROADCASTING = 0
ISDBT_SB_SUBCHANNEL_ID = 0
ISDBT_SB_SEGMENT_IDX = 0
ISDBT_SB_SEGMENT_COUNT = 0
ISDBT_LAYERA_FEC = AUTO
ISDBT_LAYERA_MODULATION = QAM/AUTO
ISDBT_LAYERA_SEGMENT_COUNT = 0
ISDBT_LAYERA_TIME_INTERLEAVING = 0
ISDBT_LAYERB_FEC = AUTO
ISDBT_LAYERB_MODULATION = QAM/AUTO
ISDBT_LAYERB_SEGMENT_COUNT = 0
ISDBT_LAYERB_TIME_INTERLEAVING = 0
ISDBT_LAYERC_FEC = AUTO
ISDBT_LAYERC_MODULATION = QAM/AUTO
ISDBT_LAYERC_SEGMENT_COUNT = 0
ISDBT_LAYERC_TIME_INTERLEAVING = 0
DELIVERY_SYSTEM = ISDBT

Just the channel description for it would be:

[CHANNEL]
FREQUENCY = 479142857
MODULATION = QAM/AUTO
BANDWIDTH_HZ = 6000000
INVERSION = AUTO
CODE_RATE_HP = AUTO
CODE_RATE_LP = NONE
GUARD_INTERVAL = AUTO
TRANSMISSION_MODE = AUTO
HIERARCHY = NONE
ISDBT_LAYER_ENABLED = 7
ISDBT_PARTIAL_RECEPTION = 0
ISDBT_SOUND_BROADCASTING = 0
ISDBT_SB_SUBCHANNEL_ID = 0
ISDBT_SB_SEGMENT_IDX = 0
ISDBT_SB_SEGMENT_COUNT = 0
ISDBT_LAYERA_FEC = AUTO
ISDBT_LAYERA_MODULATION = QAM/AUTO
ISDBT_LAYERA_SEGMENT_COUNT = 0
ISDBT_LAYERA_TIME_INTERLEAVING = 0
ISDBT_LAYERB_FEC = AUTO
ISDBT_LAYERB_MODULATION = QAM/AUTO
ISDBT_LAYERB_SEGMENT_COUNT = 0
ISDBT_LAYERB_TIME_INTERLEAVING = 0
ISDBT_LAYERC_FEC = AUTO
ISDBT_LAYERC_MODULATION = QAM/AUTO
ISDBT_LAYERC_SEGMENT_COUNT = 0
ISDBT_LAYERC_TIME_INTERLEAVING = 0
DELIVERY_SYSTEM = ISDBT

CURRENT ISSUES
==============

The dvb-fe-tool and the dvb-format-convert are generic enough to work with all delivery systems. However, the other two tools need to do some diferent things, depending on the delivery system.

I'm currently with only ISDB-T signals here, so the other two tools were tested only with it.

The dvbv5-zap in general won't work with Satellite delivery systems. It lacks polarity settings, and it doesn't know anything about LNB or DISEqC. It shouldn't hard to port those things into it, but a DVB-S signal is needed to test. As I don't have it curently, I'm not working to add support for it at the moment.

Patches are welcome.

The dvbv5-scan also won't work with Satellite delivery systems due to the same reasons.

Patches are welcome.

The dvbv5-scan should likely work with the other standards, but the descriptor parser for NIT, PAT, PMT and SDT tables are fine-tuned for ISDB-T. Adding more parsed info there could help to improve the detected things, like virtual channels. Maybe some additional tables would need to be parsed for ATSC.

It also doesn't current look inside the network descriptors to get other transponders. So, on DVB-C, it will only get the channels at the main frequency. I should fix it in a near future.

It is very likely that it will work as-is for DVB-T.

If someone wants to patch the code to improve the tool, the descriptors parser is inside descriptors.c file. The scan code that uses it is at libscan.c. Finally, the data structure used by the scan parsing is at libscan.h. The procedure is basicallt to add a new data field inside the libscan.h structures, and then change the descriptors.c file to fill it.

The main structure is this one:

struct dvb_descriptors {
        int verbose;

        struct pat_table pat_table;
        struct nit_table nit_table;
        struct sdt_table sdt_table;

        /* Used by descriptors to know where to update a PMT/Service/TS */
        unsigned cur_pmt;
        unsigned cur_service;
        unsigned cur_ts;
};

While parsing each table, the current item being parsed is pointed by one of those unsigned values: cur_pmt, cur_service, cur_ts. Use this to fill the data structure.

The dvb-file will likely need changes too, in order to write the parsed information inside the channels file.

Patches are welcome!

Regards,
Mauro

Honza Petrouš

2012-01-07 17:29 UTC #1 lore raw

Hi Mauro.

2012/1/7 Mauro Carvalho Chehab <[email protected]>:

Quoted 8 lines

As previously commented at the ML, I'm developing a set of tools using DVBv5 API. Instead of starting from something existing, I decided to start from scratch, in order to avoid polluting it with DVBv3 legacy stuff. Of course, I did some research inside the existing tools, in order to fill in the blanks, using the dvb-apps tzap as a reference for the first real application on it, but removing a large amount of code (file parsers, etc).

Quoted 8 lines

They're now on a good shape, at least for my own usage ;)
In order to test, you should use:
git clone git://linuxtv.org/mchehab/experimental-v4l-utils.git
And then run "make". the utils are inside utils/dvb.

Am I doing something wrong? After clone I can't find dvb subdirectory inside utils:

[hop@localhost experimental-v4l-utils (master)]$ ll utils/ celkem 48

drwxr-xr-x 2 hop hop 4096 led  7 18:21 decode_tm6000/
drwxr-xr-x 3 hop hop 4096 led  7 18:21 keytable/
drwxr-xr-x 2 hop hop 4096 led  7 18:21 libmedia_dev/
drwxr-xr-x 2 hop hop 4096 led  7 18:21 libv4l2util/
-rw-r--r-- 1 hop hop  947 led  7 18:21 Makefile
drwxr-xr-x 2 hop hop 4096 led  7 18:21 qv4l2/
drwxr-xr-x 2 hop hop 4096 led  7 18:21 rds/
drwxr-xr-x 2 hop hop 4096 led  7 18:21 v4l2-compliance/
drwxr-xr-x 2 hop hop 4096 led  7 18:21 v4l2-ctl/
drwxr-xr-x 2 hop hop 4096 led  7 18:21 v4l2-dbg/
drwxr-xr-x 2 hop hop 4096 led  7 18:21 v4l2-sysfs-path/
drwxr-xr-x 2 hop hop 4096 led  7 18:21 xc3028-firmware/

Honza

Mauro Carvalho Chehab

author

2012-01-07 20:05 UTC #2 lore raw

Quoted 15 lines · Honza Petrouš

Hi Mauro.
2012/1/7 Mauro Carvalho Chehab <[email protected]>:
Quoted 12 lines
As previously commented at the ML, I'm developing a set of tools using DVBv5 API. Instead of starting from something existing, I decided to start from scratch, in order to avoid polluting it with DVBv3 legacy stuff. Of course, I did some research inside the existing tools, in order to fill in the blanks, using the dvb-apps tzap as a reference for the first real application on it, but removing a large amount of code (file parsers, etc).
They're now on a good shape, at least for my own usage ;)
In order to test, you should use:

Quoted 7 lines

Quoted 4 lines
git clone git://linuxtv.org/mchehab/experimental-v4l-utils.git
And then run "make". the utils are inside utils/dvb.
Am I doing something wrong? After clone I can't find dvb subdirectory inside utils:

Huh... sorry, you need to specify the branch as well. The correct syntax would be:

git clone git://linuxtv.org/mchehab/experimental-v4l-utils.git dvbv5-0.0.1

it is likely that git clone has already fetched this branch as well, so, now that you've cloned it, you can do:

git remote update
git checkout origin/dvbv5-0.0.1

In order to build, you need to run "make" two times (the first one will run automake tools, and the second one will actually compile everything).

After running the first make, you can just go to utils/dvb and run make from there, if you don't want to compile everything.

Quoted 22 lines

[hop@localhost experimental-v4l-utils (master)]$ ll utils/ celkem 48

drwxr-xr-x 2 hop hop 4096 led  7 18:21 decode_tm6000/
drwxr-xr-x 3 hop hop 4096 led  7 18:21 keytable/
drwxr-xr-x 2 hop hop 4096 led  7 18:21 libmedia_dev/
drwxr-xr-x 2 hop hop 4096 led  7 18:21 libv4l2util/
-rw-r--r-- 1 hop hop  947 led  7 18:21 Makefile
drwxr-xr-x 2 hop hop 4096 led  7 18:21 qv4l2/
drwxr-xr-x 2 hop hop 4096 led  7 18:21 rds/
drwxr-xr-x 2 hop hop 4096 led  7 18:21 v4l2-compliance/
drwxr-xr-x 2 hop hop 4096 led  7 18:21 v4l2-ctl/
drwxr-xr-x 2 hop hop 4096 led  7 18:21 v4l2-dbg/
drwxr-xr-x 2 hop hop 4096 led  7 18:21 v4l2-sysfs-path/
drwxr-xr-x 2 hop hop 4096 led  7 18:21 xc3028-firmware/

Honza
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Mauro Carvalho Chehab

author

2012-01-08 01:52 UTC #3 lore raw

In reply to Mauro Carvalho Chehab

Quoted 199 lines · Mauro Carvalho Chehab

As previously commented at the ML, I'm developing a set of tools using DVBv5 API. Instead of starting from something existing, I decided to start from scratch, in order to avoid polluting it with DVBv3 legacy stuff. Of course, I did some research inside the existing tools, in order to fill in the blanks, using the dvb-apps tzap as a reference for the first real application on it, but removing a large amount of code (file parsers, etc).
They're now on a good shape, at least for my own usage ;)
In order to test, you should use:
git clone git://linuxtv.org/mchehab/experimental-v4l-utils.git
And then run "make". the utils are inside utils/dvb.
I plan to do some cleanup at the patches later (basically, changing the patch descriptions), and add it inside the v4l-utils, in order to have the basic tools I use for testing media devices into the same place.
DVB TOOLS
=========
This is a series of tools written to help testing and working with DVB, using its latest V5 API. The tools can also work with the DVBv3 API.
The current tools are:
dvb-fe-tool - a simple test application, that reads from the frontend.
it also allows to change the default delivery system. In the future, it may be used to change any property via command line.
dvb-format-convert - converts from zap and scan "initial-tuning-data-file"
	      into the new format defined to work with DVBv5;
dvbv5-scan - a DVBv5 scan tool;
dvbv5-zap - a DVBv5 zap tool. It allow to tune into a DVB channel, and
to watch to a DVB service (e. g. receiving the video and audio streams, via another application using the dvr device).
Each application code is very small, as most of the code are on some generic code that will become a library in the future.
CONTENTS OF THE TREE
====================
parse_string.c/parse_string.h: MPEG-TS string decoder with charset translator
Used to decode NIT/SDT service name, network provider and provider name. It parses the charsets according with the DVB specs, converting them into UTF-8 (or other charset), using iconv library.
descriptors.c/descriptors.h: MPEG-TS descriptors parser
The code there is generig enough to decode the MPEG-TS descriptors, with the DVB and other Digital TV extensions.
libscan.c/libscan/h: DVBv5 scanning library
This library is used to retrieve DVB information from the MPEG TS headers, discovering the services associated to each DVB channel or transponder. The services information is the basic info that most DVB tools need to tune into a channel.
dvb-file.c/dvb-file.h: DVB file read/write library.
Allows parsing a DVB file (legacy or not) and to write data into a DVB file (new format only).
dvb-fe.c/dvb-fe.h: DVB frontend library.
Allows talking with a DVB frontend via DVBv5 or DVBv3 API.
dvb-zap-format.c/dvb-legacy-channel-format.c:
Contains the data structures required in order to read from the legacy formats (zap or scan "initial-tuning-data-file").
dvb_frontend.h: DVBv5 frontend API.
This is just a copy of the newest linux/dvb/frontend.h header. I opted to keep a copy there, in order to allow working with the tools without needing to copy the latest header into /usr/include.
dvb-v5.h/dvb-v5-std.h:
Ancillary files linked into dvb-fe code, used to parse DVB tables. The dvbv5.h is generated by a small perl util, from the DVB FE API file.
dvb-demux.c/dvb-demux.h: DVB demux library.
Used by the dvbv5-zap utility.
dvb-fe-tool.c, dvb-format-convert.c, dvbv5-zap.c, dvbv5-scan.c: tools code.
Basically, parses the options from userspace and calls the other code to do what was requested by the user.
CHANNEL/SERVICE FILE FORMAT
===========================
Instead of having two different files, one for services, and another for channels/transponders, I opted to use just one format for both. The format is:
[channel]
key1=value1
key2=value2
key3=value3
...
keyn=valuen
lines with # are discarted by the parsers. Also, whitespaces/tabs before the keys and before/after the equal sign.
Be careful: whitespace in the middle of the value are not discarded.
A typical service would be like:
[TV Brasil HD]
VCHANNEL = 2.2
SERVICE_ID = 16160
VIDEO_PID = 770
AUDIO_PID = 514 614
FREQUENCY = 479142857
MODULATION = QAM/AUTO
BANDWIDTH_HZ = 6000000
INVERSION = AUTO
CODE_RATE_HP = AUTO
CODE_RATE_LP = NONE
GUARD_INTERVAL = AUTO
TRANSMISSION_MODE = AUTO
HIERARCHY = NONE
ISDBT_LAYER_ENABLED = 7
ISDBT_PARTIAL_RECEPTION = 0
ISDBT_SOUND_BROADCASTING = 0
ISDBT_SB_SUBCHANNEL_ID = 0
ISDBT_SB_SEGMENT_IDX = 0
ISDBT_SB_SEGMENT_COUNT = 0
ISDBT_LAYERA_FEC = AUTO
ISDBT_LAYERA_MODULATION = QAM/AUTO
ISDBT_LAYERA_SEGMENT_COUNT = 0
ISDBT_LAYERA_TIME_INTERLEAVING = 0
ISDBT_LAYERB_FEC = AUTO
ISDBT_LAYERB_MODULATION = QAM/AUTO
ISDBT_LAYERB_SEGMENT_COUNT = 0
ISDBT_LAYERB_TIME_INTERLEAVING = 0
ISDBT_LAYERC_FEC = AUTO
ISDBT_LAYERC_MODULATION = QAM/AUTO
ISDBT_LAYERC_SEGMENT_COUNT = 0
ISDBT_LAYERC_TIME_INTERLEAVING = 0
DELIVERY_SYSTEM = ISDBT
Just the channel description for it would be:
[CHANNEL]
FREQUENCY = 479142857
MODULATION = QAM/AUTO
BANDWIDTH_HZ = 6000000
INVERSION = AUTO
CODE_RATE_HP = AUTO
CODE_RATE_LP = NONE
GUARD_INTERVAL = AUTO
TRANSMISSION_MODE = AUTO
HIERARCHY = NONE
ISDBT_LAYER_ENABLED = 7
ISDBT_PARTIAL_RECEPTION = 0
ISDBT_SOUND_BROADCASTING = 0
ISDBT_SB_SUBCHANNEL_ID = 0
ISDBT_SB_SEGMENT_IDX = 0
ISDBT_SB_SEGMENT_COUNT = 0
ISDBT_LAYERA_FEC = AUTO
ISDBT_LAYERA_MODULATION = QAM/AUTO
ISDBT_LAYERA_SEGMENT_COUNT = 0
ISDBT_LAYERA_TIME_INTERLEAVING = 0
ISDBT_LAYERB_FEC = AUTO
ISDBT_LAYERB_MODULATION = QAM/AUTO
ISDBT_LAYERB_SEGMENT_COUNT = 0
ISDBT_LAYERB_TIME_INTERLEAVING = 0
ISDBT_LAYERC_FEC = AUTO
ISDBT_LAYERC_MODULATION = QAM/AUTO
ISDBT_LAYERC_SEGMENT_COUNT = 0
ISDBT_LAYERC_TIME_INTERLEAVING = 0
DELIVERY_SYSTEM = ISDBT
CURRENT ISSUES
==============
The dvb-fe-tool and the dvb-format-convert are generic enough to work with all delivery systems. However, the other two tools need to do some diferent things, depending on the delivery system.
I'm currently with only ISDB-T signals here, so the other two tools were tested only with it.

Quoted 7 lines

The dvbv5-zap in general won't work with Satellite delivery systems. It lacks polarity settings, and it doesn't know anything about LNB or DISEqC. It shouldn't hard to port those things into it, but a DVB-S signal is needed to test. As I don't have it curently, I'm not working to add support for it at the moment.
Patches are welcome.

I decided to add support for DVB-S, even without signal for testing. This probably means that it likely will not work ;) Well, seriously, we need testers for it.

The current code should be doing the same that szap does, and should work with both dvbv5-zap and dvbv5-scan. The DISEqC code there is very simple, and there's no support for dishpro/bandstacking yet. It is probably not hard to add support for it.

There are still a few things missing there. For example, the current code will only use DISEqC satellite #0, as there's no code to change the satellite number yet.

Anyway, testing and patches are welcome!

Regards,
Mauro

Mauro Carvalho Chehab

author

2012-01-08 12:57 UTC #4 lore raw

dvbv5-tools update - was: Re: [ANNOUNCE] DVBv5 tools version 0.0.1

Quoted 9 lines · Mauro Carvalho Chehab

I decided to add support for DVB-S, even without signal for testing. This probably means that it likely will not work ;) Well, seriously, we need testers for it.
The current code should be doing the same that szap does, and should work with both dvbv5-zap and dvbv5-scan. The DISEqC code there is very simple, and there's no support for dishpro/bandstacking yet. It is probably not hard to add support for it.

Quoted 5 lines

There are still a few things missing there. For example, the current code will only use DISEqC satellite #0, as there's no code to change the satellite number yet.
Anyway, testing and patches are welcome!

I decided to rewrite the DISEqC code on it, in order to fix some bugs, and make the code clearer.

The updates are at the tree:
http://git.linuxtv.org/v4l-utils.git

Basically, additional parameters for satellite delivery systems are now added to the zap and scan tools:

- l <lnbf>
selects the LNBf type. Using an invalid value like "help" shows what's currently supported.

- S <sat_number>
Selects satellite number, between 0 to 3. If not specified, disables DISEqC. This actually changes the DISEqC "option" and "position" parameter. According with the specs, for position B, tone should be off, and tone burst should be miniA.

-W <extra time in ms>
The DISEqC logic will wait for 15 ms. If this parameter is specified, it will add the extra time to the 15ms delay.

For LNBf devices that use bandstacking (e. g. they use different LO frequrencies for V and H polarization), the code will always use 13 Volts and will disable tone/tone burst.

Currently, C-Band multi and DishPro bandstacking LNBf's are supported.

The code should now work with the following LNBfs:

UNIVERSAL
Europe
10800 to 11800 MHz and 11600 to 12700 MHz Dual LO, IF = lowband 9750 MHz, highband 10600 MHz

DBS

        Expressvu, North America
        12200 to 12700 MHz
        Single LO, IF = 11250 MHz

STANDARD

        Standard
        10945 to 11450 MHz
        Single LO, IF = 10000 MHz

ENHANCED
Astra
10700 to 11700 MHz
Single LO, IF = 9750 MHz

C-BAND
Big Dish - Monopoint LNBf
3700 to 4200 MHz
Single LO, IF = 5150 MHz

C-MULT
Big Dish - Multipoint LNBf
3700 to 4200 MHz
Dual LO, Bandstacking, LO POL_R 5150 MHZ, LO POL_L 5750 MHz

DISHPRO
DishPro LNBf
12200 to 12700 MHz
Dual LO, Bandstacking, LO POL_R 11250 MHZ, LO POL_L 14350 MHz

Tests are needed!

Regards,
Mauro

Antti Palosaari

2012-01-10 21:36 UTC #5 lore raw

In reply to Mauro Carvalho Chehab

Behaviour of new FE is strange for my eyes. Could you look and explain if it is intentional?

[crope@localhost dvb]$ ./dvb-fe-tool
Device Sony CXD2820R (DVB-T/T2) (/dev/dvb/adapter0/frontend0) capabilities:

	CAN_2G_MODULATION CAN_FEC_1_2 CAN_FEC_2_3 CAN_FEC_3_4 CAN_FEC_5_6

	CAN_2G_MODULATION CAN_FEC_1_2 CAN_FEC_2_3 CAN_FEC_3_4 CAN_FEC_5_6

	CAN_2G_MODULATION CAN_FEC_1_2 CAN_FEC_2_3 CAN_FEC_3_4 CAN_FEC_5_6

	CAN_2G_MODULATION CAN_FEC_1_2 CAN_FEC_2_3 CAN_FEC_3_4 CAN_FEC_5_6

	CAN_2G_MODULATION CAN_FEC_1_2 CAN_FEC_2_3 CAN_FEC_3_4 CAN_FEC_5_6

Signature · 1 line

http://palosaari.fi/

Mauro Carvalho Chehab

author

2012-01-10 22:01 UTC #6 lore raw

Quoted 13 lines · Antti Palosaari

Behaviour of new FE is strange for my eyes. Could you look and explain if it is intentional?
[crope@localhost dvb]$ ./dvb-fe-tool
Device Sony CXD2820R (DVB-T/T2) (/dev/dvb/adapter0/frontend0) capabilities:
CAN_2G_MODULATION CAN_FEC_1_2 CAN_FEC_2_3 CAN_FEC_3_4 CAN_FEC_5_6 CAN_FEC_7_8 CAN_FEC_AUTO CAN_GUARD_INTERVAL_AUTO CAN_HIERARCHY_AUTO CAN_INVERSION_AUTO CAN_MUTE_TS CAN_QAM_16 CAN_QAM_64 CAN_QAM_256 CAN_QAM_AUTO CAN_QPSK CAN_TRANSMISSION_MODE_AUTO
DVB API Version 5.5, Current v5 delivery system: DVBT
Supported delivery systems: [DVBT] DVBT2 DVBC/ANNEX_A
[crope@localhost dvb]$ czap "MTV3 "
using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0'
reading channels from file '/home/crope/.czap/channels.conf'
11 MTV3 :330000000:INVERSION_AUTO:6875000:FEC_NONE:QAM_128:305:561:3
11 MTV3 : f 330000000, s 6875000, i 2, fec 0, qam 4, v 0x131, a 0x231, s 0x3
ERROR: frontend device is not a QAM (DVB-C) device

The selected delivery system is DVB-T. As czap doesn't have any code to force it to DVB-C, this is expected.

Basically, czap needs a patch like this one:

	http://linuxtv.org/hg/dvb-apps/rev/0c9932885287

(I've made the patch for scan just as an example, but I'll hardly have enough time to fix it everything inside dvb-apps)

Quoted 9 lines

[crope@localhost dvb]$ ./dvb-fe-tool --set-delsys=DVBC/ANNEX_A
Device Sony CXD2820R (DVB-T/T2) (/dev/dvb/adapter0/frontend0) capabilities:
CAN_2G_MODULATION CAN_FEC_1_2 CAN_FEC_2_3 CAN_FEC_3_4 CAN_FEC_5_6 CAN_FEC_7_8 CAN_FEC_AUTO CAN_GUARD_INTERVAL_AUTO CAN_HIERARCHY_AUTO CAN_INVERSION_AUTO CAN_MUTE_TS CAN_QAM_16 CAN_QAM_64 CAN_QAM_256 CAN_QAM_AUTO CAN_QPSK CAN_TRANSMISSION_MODE_AUTO
DVB API Version 5.5, Current v5 delivery system: DVBT
Supported delivery systems: [DVBT] DVBT2 DVBC/ANNEX_A
Changing delivery system to: DVBC/ANNEX_A
[crope@localhost dvb]$ ./dvb-fe-tool
Device Sony CXD2820R (DVB-T/T2) (/dev/dvb/adapter0/frontend0) capabilities:
CAN_2G_MODULATION CAN_FEC_1_2 CAN_FEC_2_3 CAN_FEC_3_4 CAN_FEC_5_6 CAN_FEC_7_8 CAN_FEC_AUTO CAN_GUARD_INTERVAL_AUTO CAN_HIERARCHY_AUTO CAN_INVERSION_AUTO CAN_MUTE_TS CAN_QAM_16 CAN_QAM_64 CAN_QAM_256 CAN_QAM_AUTO CAN_QPSK CAN_TRANSMISSION_MODE_AUTO

Quoted 8 lines

DVB API Version 5.5, Current v5 delivery system: DVBC/ANNEX_A Supported delivery systems: DVBT DVBT2 [DVBC/ANNEX_A] [crope@localhost dvb]$ czap "MTV3 "
using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' reading channels from file '/home/crope/.czap/channels.conf'
11 MTV3 :330000000:INVERSION_AUTO:6875000:FEC_NONE:QAM_128:305:561:3 11 MTV3 : f 330000000, s 6875000, i 2, fec 0, qam 4, v 0x131, a 0x231, s 0x3
status 00 | signal ffff | snr 00c6 | ber 00000000 | unc 00000000 |

Ok, it worked.

Quoted 5 lines

[crope@localhost dvb]$ ./dvb-fe-tool
Device Sony CXD2820R (DVB-T/T2) (/dev/dvb/adapter0/frontend0) capabilities:
CAN_2G_MODULATION CAN_FEC_1_2 CAN_FEC_2_3 CAN_FEC_3_4 CAN_FEC_5_6 CAN_FEC_7_8 CAN_FEC_AUTO CAN_GUARD_INTERVAL_AUTO CAN_HIERARCHY_AUTO CAN_INVERSION_AUTO CAN_MUTE_TS CAN_QAM_16 CAN_QAM_64 CAN_QAM_256 CAN_QAM_AUTO CAN_QPSK CAN_TRANSMISSION_MODE_AUTO
DVB API Version 5.5, Current v5 delivery system: DVBT
Supported delivery systems: [DVBT] DVBT2 DVBC/ANNEX_A

That's weird. The dvb_frontend_clear_cache() returns the delivery system to its original state.

The enclosed patch will likely fix this issue.

-
[PATCH] don't reset the delivery system on DTV_CLEAR

Signed-off-by Mauro Carvalho Chehab <[email protected]>

drivers/media/dvb/dvb-core/dvb_frontend.c +2 -1

index a904793..4ff4b43 100644
@@ -909,7 +909,6 @@ static int dvb_frontend_clear_cache(struct dvb_frontend *fe)
 
 	c->state = DTV_CLEAR;
 
-	c->delivery_system = fe->ops.delsys[0];
 	dprintk("%s() Clearing cache for delivery system %d\n", __func__,
 		c->delivery_system);

@@ -2377,6 +2376,8 @@ int dvb_register_frontend(struct dvb_adapter* dvb,
 	 * Initialize the cache to the proper values according with the
 	 * first supported delivery system (ops->delsys[0])
 	 */
+
+	c->delivery_system = fe->ops.delsys[0];
 	dvb_frontend_clear_cache(fe);
 
 	mutex_unlock(&frontend_mutex);

Antti Palosaari

2012-01-15 18:37 UTC #7 lore raw

Quoted 2 lines · Mauro Carvalho Chehab

Quoted 1 line · Antti Palosaari
Behaviour of new FE is strange for my eyes. Could you look and explain if it is intentional?

I still see that it changes delivery system automatically to the DVB-T.

That is the latest commit:

commit 149709f5b8a4a8678401facb5c670119751f6087

Author: Mauro Carvalho Chehab <[email protected]>
Date:   Fri Jan 13 11:46:36 2012 -0200

[media] dvb-core: preserve the delivery system at cache clear

The changeset 240ab508aa is incomplete, as the first thing that happens at cache clear is to do a memset with 0 to the cache.

So, the delivery system needs to be explicitly preserved there.

Signed-off-by Mauro Carvalho Chehab <[email protected]>

And here is log:

[crope@localhost code]$ ./tmp/v4l-utils/utils/dvb/dvb-fe-tool --set-delsys=DVBC/ANNEX_A Device Sony CXD2820R (DVB-T/T2) (/dev/dvb/adapter0/frontend0) capabilities:

	CAN_2G_MODULATION CAN_FEC_1_2 CAN_FEC_2_3 CAN_FEC_3_4 CAN_FEC_5_6

CAN_FEC_7_8 CAN_FEC_AUTO CAN_GUARD_INTERVAL_AUTO CAN_HIERARCHY_AUTO CAN_INVERSION_AUTO CAN_MUTE_TS CAN_QAM_16 CAN_QAM_64 CAN_QAM_256 CAN_QAM_AUTO CAN_QPSK CAN_TRANSMISSION_MODE_AUTO DVB API Version 5.5, Current v5 delivery system: DVBT
Supported delivery systems: [DVBT] DVBT2 DVBC/ANNEX_A
Changing delivery system to: DVBC/ANNEX_A
[crope@localhost code]$ scan ../fi-Oulu-c
scanning ../fi-Oulu-c
using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0'
initial transponder 330000000 6875000 0 4
initial transponder 370000000 6875000 0 4
initial transponder 362000000 6875000 0 4
initial transponder 354000000 6875000 0 4
initial transponder 346000000 6875000 0 4
initial transponder 338000000 6875000 0 4
initial transponder 322000000 6875000 0 4
initial transponder 314000000 6875000 0 4
initial transponder 378000000 6875000 0 4
initial transponder 306000000 6875000 0 4
initial transponder 298000000 6875000 0 4
initial transponder 290000000 6875000 0 5
initial transponder 274000000 6875000 0 5
initial transponder 266000000 6875000 0 5
initial transponder 258000000 6875000 0 5
initial transponder 250000000 6875000 0 5
initial transponder 242000000 6875000 0 5

Quoted 1 line

Quoted 1 line
Quoted 1 line
tune to: 330000000:INVERSION_AUTO:6875000:FEC_NONE:QAM_128

^CERROR: interrupted by SIGINT, dumping partial result...
dumping lists (0 services)
Done.
[crope@localhost code]$ scan ../fi-Oulu-c
scanning ../fi-Oulu-c
using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' initial transponder 330000000 6875000 0 4
initial transponder 370000000 6875000 0 4
initial transponder 362000000 6875000 0 4
initial transponder 354000000 6875000 0 4
initial transponder 346000000 6875000 0 4
initial transponder 338000000 6875000 0 4
initial transponder 322000000 6875000 0 4
initial transponder 314000000 6875000 0 4
initial transponder 378000000 6875000 0 4
initial transponder 306000000 6875000 0 4
initial transponder 298000000 6875000 0 4
initial transponder 290000000 6875000 0 5
initial transponder 274000000 6875000 0 5
initial transponder 266000000 6875000 0 5
initial transponder 258000000 6875000 0 5
initial transponder 250000000 6875000 0 5
initial transponder 242000000 6875000 0 5
WARNING: frontend type (OFDM) is not compatible with requested tuning type (QAM)
WARNING: frontend type (OFDM) is not compatible with requested tuning type (QAM)
WARNING: frontend type (OFDM) is not compatible with requested tuning type (QAM)
WARNING: frontend type (OFDM) is not compatible with requested tuning type (QAM)
WARNING: frontend type (OFDM) is not compatible with requested tuning type (QAM)
WARNING: frontend type (OFDM) is not compatible with requested tuning type (QAM)
WARNING: frontend type (OFDM) is not compatible with requested tuning type (QAM)
WARNING: frontend type (OFDM) is not compatible with requested tuning type (QAM)
WARNING: frontend type (OFDM) is not compatible with requested tuning type (QAM)
WARNING: frontend type (OFDM) is not compatible with requested tuning type (QAM)
WARNING: frontend type (OFDM) is not compatible with requested tuning type (QAM)
WARNING: frontend type (OFDM) is not compatible with requested tuning type (QAM)
WARNING: frontend type (OFDM) is not compatible with requested tuning type (QAM)
WARNING: frontend type (OFDM) is not compatible with requested tuning type (QAM)
WARNING: frontend type (OFDM) is not compatible with requested tuning type (QAM)
WARNING: frontend type (OFDM) is not compatible with requested tuning type (QAM)
WARNING: frontend type (OFDM) is not compatible with requested tuning type (QAM)
ERROR: initial tuning failed
dumping lists (0 services)
Done.
[crope@localhost code]$ ./tmp/v4l-utils/utils/dvb/dvb-fe-tool --set-delsys=DVBC/ANNEX_A Device Sony CXD2820R (DVB-T/T2) (/dev/dvb/adapter0/frontend0) capabilities:

	CAN_2G_MODULATION CAN_FEC_1_2 CAN_FEC_2_3 CAN_FEC_3_4 CAN_FEC_5_6

regards
Antti

Signature · 1 line

http://palosaari.fi/

Antti Palosaari

2012-01-15 20:03 UTC #8 lore raw

Quoted 120 lines · Antti Palosaari

Quoted 3 lines · Mauro Carvalho Chehab
Quoted 2 lines · Antti Palosaari
Behaviour of new FE is strange for my eyes. Could you look and explain if it is intentional?
I still see that it changes delivery system automatically to the DVB-T.
That is the latest commit:
commit 149709f5b8a4a8678401facb5c670119751f6087
Author: Mauro Carvalho Chehab <[email protected]>
Date: Fri Jan 13 11:46:36 2012 -0200
[media] dvb-core: preserve the delivery system at cache clear
The changeset 240ab508aa is incomplete, as the first thing that happens at cache clear is to do a memset with 0 to the cache.
So, the delivery system needs to be explicitly preserved there.
Signed-off-by Mauro Carvalho Chehab <[email protected]>
And here is log:
[crope@localhost code]$ ./tmp/v4l-utils/utils/dvb/dvb-fe-tool --set-delsys=DVBC/ANNEX_A
Device Sony CXD2820R (DVB-T/T2) (/dev/dvb/adapter0/frontend0) capabilities:
CAN_2G_MODULATION CAN_FEC_1_2 CAN_FEC_2_3 CAN_FEC_3_4 CAN_FEC_5_6 CAN_FEC_7_8 CAN_FEC_AUTO CAN_GUARD_INTERVAL_AUTO CAN_HIERARCHY_AUTO CAN_INVERSION_AUTO CAN_MUTE_TS CAN_QAM_16 CAN_QAM_64 CAN_QAM_256 CAN_QAM_AUTO CAN_QPSK CAN_TRANSMISSION_MODE_AUTO
DVB API Version 5.5, Current v5 delivery system: DVBT
Supported delivery systems: [DVBT] DVBT2 DVBC/ANNEX_A
Changing delivery system to: DVBC/ANNEX_A
[crope@localhost code]$ scan ../fi-Oulu-c
scanning ../fi-Oulu-c
using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' initial transponder 330000000 6875000 0 4
initial transponder 370000000 6875000 0 4
initial transponder 362000000 6875000 0 4
initial transponder 354000000 6875000 0 4
initial transponder 346000000 6875000 0 4
initial transponder 338000000 6875000 0 4
initial transponder 322000000 6875000 0 4
initial transponder 314000000 6875000 0 4
initial transponder 378000000 6875000 0 4
initial transponder 306000000 6875000 0 4
initial transponder 298000000 6875000 0 4
initial transponder 290000000 6875000 0 5
initial transponder 274000000 6875000 0 5
initial transponder 266000000 6875000 0 5
initial transponder 258000000 6875000 0 5
initial transponder 250000000 6875000 0 5
initial transponder 242000000 6875000 0 5
Quoted 1 line
Quoted 1 line
Quoted 1 line
tune to: 330000000:INVERSION_AUTO:6875000:FEC_NONE:QAM_128
^CERROR: interrupted by SIGINT, dumping partial result... dumping lists (0 services)
Done.
[crope@localhost code]$ scan ../fi-Oulu-c
scanning ../fi-Oulu-c
using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' initial transponder 330000000 6875000 0 4
initial transponder 370000000 6875000 0 4
initial transponder 362000000 6875000 0 4
initial transponder 354000000 6875000 0 4
initial transponder 346000000 6875000 0 4
initial transponder 338000000 6875000 0 4
initial transponder 322000000 6875000 0 4
initial transponder 314000000 6875000 0 4
initial transponder 378000000 6875000 0 4
initial transponder 306000000 6875000 0 4
initial transponder 298000000 6875000 0 4
initial transponder 290000000 6875000 0 5
initial transponder 274000000 6875000 0 5
initial transponder 266000000 6875000 0 5
initial transponder 258000000 6875000 0 5
initial transponder 250000000 6875000 0 5
initial transponder 242000000 6875000 0 5
WARNING: frontend type (OFDM) is not compatible with requested tuning type (QAM)
WARNING: frontend type (OFDM) is not compatible with requested tuning type (QAM)
WARNING: frontend type (OFDM) is not compatible with requested tuning type (QAM)
WARNING: frontend type (OFDM) is not compatible with requested tuning type (QAM)
WARNING: frontend type (OFDM) is not compatible with requested tuning type (QAM)
WARNING: frontend type (OFDM) is not compatible with requested tuning type (QAM)
WARNING: frontend type (OFDM) is not compatible with requested tuning type (QAM)
WARNING: frontend type (OFDM) is not compatible with requested tuning type (QAM)
WARNING: frontend type (OFDM) is not compatible with requested tuning type (QAM)
WARNING: frontend type (OFDM) is not compatible with requested tuning type (QAM)
WARNING: frontend type (OFDM) is not compatible with requested tuning type (QAM)
WARNING: frontend type (OFDM) is not compatible with requested tuning type (QAM)
WARNING: frontend type (OFDM) is not compatible with requested tuning type (QAM)
WARNING: frontend type (OFDM) is not compatible with requested tuning type (QAM)
WARNING: frontend type (OFDM) is not compatible with requested tuning type (QAM)
WARNING: frontend type (OFDM) is not compatible with requested tuning type (QAM)
WARNING: frontend type (OFDM) is not compatible with requested tuning type (QAM)
ERROR: initial tuning failed
dumping lists (0 services)
Done.
[crope@localhost code]$ ./tmp/v4l-utils/utils/dvb/dvb-fe-tool --set-delsys=DVBC/ANNEX_A
Device Sony CXD2820R (DVB-T/T2) (/dev/dvb/adapter0/frontend0) capabilities:

Quoted 8 lines

CAN_2G_MODULATION CAN_FEC_1_2 CAN_FEC_2_3 CAN_FEC_3_4 CAN_FEC_5_6 CAN_FEC_7_8 CAN_FEC_AUTO CAN_GUARD_INTERVAL_AUTO CAN_HIERARCHY_AUTO CAN_INVERSION_AUTO CAN_MUTE_TS CAN_QAM_16 CAN_QAM_64 CAN_QAM_256 CAN_QAM_AUTO CAN_QPSK CAN_TRANSMISSION_MODE_AUTO
DVB API Version 5.5, Current v5 delivery system: DVBT Supported delivery systems: [DVBT] DVBT2 DVBC/ANNEX_A Changing delivery system to: DVBC/ANNEX_A [crope@localhost code]$

That seems to be due to cxd2820r bug introduced by multi-frontend to single-frontend change.

But now I got that error:
[crope@localhost code]$ ./tmp/v4l-utils/utils/dvb/dvb-fe-tool --set-delsys=DVBC/ANNEX_A Device or resource busy while opening /dev/dvb/adapter0/frontend0 Changing delivery system to: DVBC/ANNEX_A
Segmentation fault (core dumped)
[crope@localhost code]$

I opened device using VLC and then try to switch it to correct mode. But it crash and no picture.

Antti

Signature · 1 line

http://palosaari.fi/

Mauro Carvalho Chehab

author

2012-01-15 21:08 UTC #9 lore raw

Em 15-01-2012 18:03, Antti Palosaari escreveu:

Quoted 130 lines · Antti Palosaari

Quoted 120 lines · Mauro Carvalho Chehab
Quoted 3 lines · Antti Palosaari
Quoted 2 lines
Behaviour of new FE is strange for my eyes. Could you look and explain if it is intentional?
I still see that it changes delivery system automatically to the DVB-T.
That is the latest commit:
commit 149709f5b8a4a8678401facb5c670119751f6087
Author: Mauro Carvalho Chehab <[email protected]>
Date: Fri Jan 13 11:46:36 2012 -0200
[media] dvb-core: preserve the delivery system at cache clear
The changeset 240ab508aa is incomplete, as the first thing that happens at cache clear is to do a memset with 0 to the cache.
So, the delivery system needs to be explicitly preserved there.
Signed-off-by Mauro Carvalho Chehab <[email protected]>
And here is log:
[crope@localhost code]$ ./tmp/v4l-utils/utils/dvb/dvb-fe-tool --set-delsys=DVBC/ANNEX_A
Device Sony CXD2820R (DVB-T/T2) (/dev/dvb/adapter0/frontend0) capabilities:
CAN_2G_MODULATION CAN_FEC_1_2 CAN_FEC_2_3 CAN_FEC_3_4 CAN_FEC_5_6 CAN_FEC_7_8 CAN_FEC_AUTO CAN_GUARD_INTERVAL_AUTO CAN_HIERARCHY_AUTO CAN_INVERSION_AUTO CAN_MUTE_TS CAN_QAM_16 CAN_QAM_64 CAN_QAM_256 CAN_QAM_AUTO CAN_QPSK CAN_TRANSMISSION_MODE_AUTO
DVB API Version 5.5, Current v5 delivery system: DVBT
Supported delivery systems: [DVBT] DVBT2 DVBC/ANNEX_A
Changing delivery system to: DVBC/ANNEX_A
[crope@localhost code]$ scan ../fi-Oulu-c
scanning ../fi-Oulu-c
using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' initial transponder 330000000 6875000 0 4
initial transponder 370000000 6875000 0 4
initial transponder 362000000 6875000 0 4
initial transponder 354000000 6875000 0 4
initial transponder 346000000 6875000 0 4
initial transponder 338000000 6875000 0 4
initial transponder 322000000 6875000 0 4
initial transponder 314000000 6875000 0 4
initial transponder 378000000 6875000 0 4
initial transponder 306000000 6875000 0 4
initial transponder 298000000 6875000 0 4
initial transponder 290000000 6875000 0 5
initial transponder 274000000 6875000 0 5
initial transponder 266000000 6875000 0 5
initial transponder 258000000 6875000 0 5
initial transponder 250000000 6875000 0 5
initial transponder 242000000 6875000 0 5
Quoted 1 line
Quoted 1 line
Quoted 1 line
tune to: 330000000:INVERSION_AUTO:6875000:FEC_NONE:QAM_128
^CERROR: interrupted by SIGINT, dumping partial result... dumping lists (0 services)
Done.
[crope@localhost code]$ scan ../fi-Oulu-c
scanning ../fi-Oulu-c
using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' initial transponder 330000000 6875000 0 4
initial transponder 370000000 6875000 0 4
initial transponder 362000000 6875000 0 4
initial transponder 354000000 6875000 0 4
initial transponder 346000000 6875000 0 4
initial transponder 338000000 6875000 0 4
initial transponder 322000000 6875000 0 4
initial transponder 314000000 6875000 0 4
initial transponder 378000000 6875000 0 4
initial transponder 306000000 6875000 0 4
initial transponder 298000000 6875000 0 4
initial transponder 290000000 6875000 0 5
initial transponder 274000000 6875000 0 5
initial transponder 266000000 6875000 0 5
initial transponder 258000000 6875000 0 5
initial transponder 250000000 6875000 0 5
initial transponder 242000000 6875000 0 5
WARNING: frontend type (OFDM) is not compatible with requested tuning type (QAM)
WARNING: frontend type (OFDM) is not compatible with requested tuning type (QAM)
WARNING: frontend type (OFDM) is not compatible with requested tuning type (QAM)
WARNING: frontend type (OFDM) is not compatible with requested tuning type (QAM)
WARNING: frontend type (OFDM) is not compatible with requested tuning type (QAM)
WARNING: frontend type (OFDM) is not compatible with requested tuning type (QAM)
WARNING: frontend type (OFDM) is not compatible with requested tuning type (QAM)
WARNING: frontend type (OFDM) is not compatible with requested tuning type (QAM)
WARNING: frontend type (OFDM) is not compatible with requested tuning type (QAM)
WARNING: frontend type (OFDM) is not compatible with requested tuning type (QAM)
WARNING: frontend type (OFDM) is not compatible with requested tuning type (QAM)
WARNING: frontend type (OFDM) is not compatible with requested tuning type (QAM)
WARNING: frontend type (OFDM) is not compatible with requested tuning type (QAM)
WARNING: frontend type (OFDM) is not compatible with requested tuning type (QAM)
WARNING: frontend type (OFDM) is not compatible with requested tuning type (QAM)
WARNING: frontend type (OFDM) is not compatible with requested tuning type (QAM)
WARNING: frontend type (OFDM) is not compatible with requested tuning type (QAM)
ERROR: initial tuning failed
dumping lists (0 services)
Done.
[crope@localhost code]$ ./tmp/v4l-utils/utils/dvb/dvb-fe-tool --set-delsys=DVBC/ANNEX_A
Device Sony CXD2820R (DVB-T/T2) (/dev/dvb/adapter0/frontend0) capabilities:
Quoted 8 lines
CAN_2G_MODULATION CAN_FEC_1_2 CAN_FEC_2_3 CAN_FEC_3_4 CAN_FEC_5_6 CAN_FEC_7_8 CAN_FEC_AUTO CAN_GUARD_INTERVAL_AUTO CAN_HIERARCHY_AUTO CAN_INVERSION_AUTO CAN_MUTE_TS CAN_QAM_16 CAN_QAM_64 CAN_QAM_256 CAN_QAM_AUTO CAN_QPSK CAN_TRANSMISSION_MODE_AUTO
DVB API Version 5.5, Current v5 delivery system: DVBT Supported delivery systems: [DVBT] DVBT2 DVBC/ANNEX_A Changing delivery system to: DVBC/ANNEX_A [crope@localhost code]$

Quoted 1 line

That seems to be due to cxd2820r bug introduced by multi-frontend to single-frontend change.

Ok. Could you please fix it and send us a patch?

Quoted 5 lines

But now I got that error:
[crope@localhost code]$ ./tmp/v4l-utils/utils/dvb/dvb-fe-tool --set-delsys=DVBC/ANNEX_A Device or resource busy while opening /dev/dvb/adapter0/frontend0 Changing delivery system to: DVBC/ANNEX_A
Segmentation fault (core dumped)

There was a bug at the error code handling on dvb-fe-tool: basically, if it can't open a device, it were using a NULL pointer. It was likely fixed by this commit:

http://git.linuxtv.org/v4l-utils.git/commit/1f669eed5433d17df4d8fb1fa43d2886f99d3991

Quoted 7 lines

[crope@localhost code]$
I opened device using VLC and then try to switch it to correct mode. But it crash and no picture.
Antti

Regards,
Mauro

Antti Palosaari

2012-01-15 21:14 UTC #10 lore raw

Quoted 8 lines · Mauro Carvalho Chehab

Em 15-01-2012 18:03, Antti Palosaari escreveu:
Quoted 5 lines · Antti Palosaari
Quoted 2 lines · Mauro Carvalho Chehab
Quoted 1 line · Antti Palosaari
That seems to be due to cxd2820r bug introduced by multi-frontend to single-frontend change.
Ok. Could you please fix it and send us a patch?

I already sent it and few others too. CXD2820R is still missing HAS_LOCK bit in DVB-C mode... This change introduces too many bugs as I have been fixing those whole day and not even found all yet.

Quoted 10 lines

Quoted 5 lines
But now I got that error:
[crope@localhost code]$ ./tmp/v4l-utils/utils/dvb/dvb-fe-tool --set-delsys=DVBC/ANNEX_A Device or resource busy while opening /dev/dvb/adapter0/frontend0 Changing delivery system to: DVBC/ANNEX_A
Segmentation fault (core dumped)
There was a bug at the error code handling on dvb-fe-tool: basically, if it can't open a device, it were using a NULL pointer. It was likely fixed by this commit:
http://git.linuxtv.org/v4l-utils.git/commit/1f669eed5433d17df4d8fb1fa43d2886f99d3991

OK, will try.

Thanks
Antti

Signature · 1 line

http://palosaari.fi/

Antti Palosaari

2012-01-15 21:47 UTC #11 lore raw

In reply to Mauro Carvalho Chehab

Quoted 4 lines · Mauro Carvalho Chehab

There was a bug at the error code handling on dvb-fe-tool: basically, if it can't open a device, it were using a NULL pointer. It was likely fixed by this commit:
http://git.linuxtv.org/v4l-utils.git/commit/1f669eed5433d17df4d8fb1fa43d2886f99d3991

That bug was fixed as I tested.

But could you tell why dvb-fe-tool --set-delsys=DVBC/ANNEX_A calls get_frontent() ?

That will cause this kind of calls in demod driver:
init()
get_frontend()
get_frontend()
sleep()

My guess is that it resolves current delivery system. But as demod is usually sleeping (not tuned) at that phase it does not know frontend settings asked, like modulation etc. In case of cxd2820r those are available after set_frontend() call. I think I will add check and return -EINVAL in that case.

regards
Antti

Signature · 1 line

http://palosaari.fi/

Mauro Carvalho Chehab

author

2012-01-16 00:16 UTC #12 lore raw

Em 15-01-2012 19:47, Antti Palosaari escreveu:

Quoted 9 lines · Mauro Carvalho Chehab

Quoted 4 lines
There was a bug at the error code handling on dvb-fe-tool: basically, if it can't open a device, it were using a NULL pointer. It was likely fixed by this commit:
http://git.linuxtv.org/v4l-utils.git/commit/1f669eed5433d17df4d8fb1fa43d2886f99d3991
That bug was fixed as I tested.
But could you tell why dvb-fe-tool --set-delsys=DVBC/ANNEX_A calls get_frontent() ?

That's what happens here, at the application level:

$ strace dvb-fe-tool -d DVBC/ANNEX_A

open("/dev/dvb/adapter0/frontend0", O_RDWR) = 3
ioctl(3, FE_GET_INFO, 0xb070c4) = 0
fstat(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 2), ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f37922be000
write(1, "Device DRXK DVB-C DVB-T (/dev/dv"..., 68Device DRXK DVB-C DVB-T (/dev/dvb/adapter0/frontend0) capabilities:
) = 68
write(1, "\tCAN_FEC_1_2 CAN_FEC_2_3 CAN_FEC"..., 245 CAN_FEC_1_2 CAN_FEC_2_3 CAN_FEC_3_4 CAN_FEC_5_6 CAN_FEC_7_8 CAN_FEC_AUTO CAN_GUARD_INTERVAL_AUTO CAN_HIERARCHY_AUTO CAN_INVERSION_AUTO CAN_MUTE_TS CAN_QAM_16 CAN_QAM_32 CAN_QAM_64 CAN_QAM_128 CAN_QAM_256 CAN_RECOVER CAN_TRANSMISSION_MODE_AUTO
) = 245
ioctl(3, FE_GET_PROPERTY, 0x7fff326ce310) = 0
write(1, "DVB API Version 5.5, Current v5 "..., 54DVB API Version 5.5, Current v5 delivery system: DVBT ) = 54
ioctl(3, FE_GET_PROPERTY, 0x7fff326ce310) = 0
write(1, "Supported delivery systems: DVBC"..., 62Supported delivery systems: DVBC/ANNEX_A DVBC/ANNEX_C [DVBT] ) = 62
write(1, "Changing delivery system to: DVB"..., 42Changing delivery system to: DVBC/ANNEX_A
) = 42
ioctl(3, FE_SET_PROPERTY, 0x7fff326ce340) = 0
close(3) = 0
exit_group(0) = ?

The first FE_GET_PROPERTY reads the DVB API version and the current delivery system:

	parms->dvb_prop[0].cmd = DTV_API_VERSION;
	parms->dvb_prop[1].cmd = DTV_DELIVERY_SYSTEM;

	dtv_prop.num = 2;
	dtv_prop.props = parms->dvb_prop;

	/* Detect a DVBv3 device */
	if (ioctl(fd, FE_GET_PROPERTY, &dtv_prop) == -1) {
		parms->dvb_prop[0].u.data = 0x300;
		parms->dvb_prop[1].u.data = SYS_UNDEFINED;
	}
	parms->version = parms->dvb_prop[0].u.data;
	parms->current_sys = parms->dvb_prop[1].u.data;

The second FE_GET_PROPERTY is used only if DVB API v5.5 or upper is detected, and does:

		parms->dvb_prop[0].cmd = DTV_ENUM_DELSYS;
		parms->n_props = 1;
		dtv_prop.num = 1;
		dtv_prop.props = parms->dvb_prop;
		if (ioctl(fd, FE_GET_PROPERTY, &dtv_prop) == -1) {
			perror("FE_GET_PROPERTY");
			dvb_v5_free(parms);
			close(fd);
			return NULL;
		}

Both were called inside dvb_fe_open().

The FE_SET_PROPERTY changes the property inside the DVBv5 cache, at dvb_set_sys():

		dvb_prop[0].cmd = DTV_DELIVERY_SYSTEM;
		dvb_prop[0].u.data = sys;
		prop.num = 1;
		prop.props = dvb_prop;

		if (ioctl(parms->fd, FE_SET_PROPERTY, &prop) == -1) {
			perror("Set delivery system");
			return errno;
		}

The FE_SET_PROPERTY doesn't call a DTV_TUNE, so it shouldn't be calling the set frontend methods inside the driver.

So, from the userspace applications standpoint, I'm not seeing anything wrong.

Quoted 7 lines

That will cause this kind of calls in demod driver:
init()
get_frontend()
get_frontend()
sleep()
My guess is that it resolves current delivery system. But as demod is usually sleeping (not tuned) at that phase it does not know frontend settings asked, like modulation etc. In case of cxd2820r those are available after set_frontend() call. I think I will add check and return -EINVAL in that case.

What seems to be happening at dvb-core/dvb_frontend.h is due to this code:

if(cmd == FE_GET_PROPERTY) {
...

                /*
                 * Fills the cache out struct with the cache contents, plus
                 * the data retrieved from get_frontend.
                 */
                dtv_get_frontend(fe, NULL);
                for (i = 0; i < tvps->num; i++) {
                        err = dtv_property_process_get(fe, c, tvp + i, file);
                        if (err < 0)
                                goto out;
                        (tvp + i)->result = err;
                }

E. g. even if the FE_GET_PROPERTY is only reading the DVB version and calling DTV_ENUM_DELSYS, it is calling the dtv_get_frontend() to retrieve more data.

What it can be done is to do something like:

static bool need_get_frontend()
{
...

	for (i = 0; i < tvps->num; i++)

...
}

		if (need_get_frontend(tvps))
	                dtv_get_frontend(fe, NULL);
                for (i = 0; i < tvps->num; i++) {
                        err = dtv_property_process_get(fe, c, tvp + i, file);
                        if (err < 0)
                                goto out;
                        (tvp + i)->result = err;
                }

And add some logic inside need_get_frontend() to return false if the FE_GET_PROPERTY only wants static info, like DTV_ENUM_DELSYS, DTV_VERSION and DTV_DELIVERY_SYSTEM.

Regards,
Mauro.

Mauro Carvalho Chehab

author

2012-01-16 02:57 UTC #13 lore raw

Em 15-01-2012 22:16, Mauro Carvalho Chehab escreveu:

Quoted 133 lines

Em 15-01-2012 19:47, Antti Palosaari escreveu:
Quoted 9 lines · Mauro Carvalho Chehab
Quoted 4 lines
There was a bug at the error code handling on dvb-fe-tool: basically, if it can't open a device, it were using a NULL pointer. It was likely fixed by this commit:
http://git.linuxtv.org/v4l-utils.git/commit/1f669eed5433d17df4d8fb1fa43d2886f99d3991
That bug was fixed as I tested.
But could you tell why dvb-fe-tool --set-delsys=DVBC/ANNEX_A calls get_frontent() ?
That's what happens here, at the application level:
$ strace dvb-fe-tool -d DVBC/ANNEX_A
open("/dev/dvb/adapter0/frontend0", O_RDWR) = 3
ioctl(3, FE_GET_INFO, 0xb070c4) = 0
fstat(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 2), ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f37922be000
write(1, "Device DRXK DVB-C DVB-T (/dev/dv"..., 68Device DRXK DVB-C DVB-T (/dev/dvb/adapter0/frontend0) capabilities:
) = 68
write(1, "\tCAN_FEC_1_2 CAN_FEC_2_3 CAN_FEC"..., 245 CAN_FEC_1_2 CAN_FEC_2_3 CAN_FEC_3_4 CAN_FEC_5_6 CAN_FEC_7_8 CAN_FEC_AUTO CAN_GUARD_INTERVAL_AUTO CAN_HIERARCHY_AUTO CAN_INVERSION_AUTO CAN_MUTE_TS CAN_QAM_16 CAN_QAM_32 CAN_QAM_64 CAN_QAM_128 CAN_QAM_256 CAN_RECOVER CAN_TRANSMISSION_MODE_AUTO
) = 245
ioctl(3, FE_GET_PROPERTY, 0x7fff326ce310) = 0
write(1, "DVB API Version 5.5, Current v5 "..., 54DVB API Version 5.5, Current v5 delivery system: DVBT ) = 54
ioctl(3, FE_GET_PROPERTY, 0x7fff326ce310) = 0
write(1, "Supported delivery systems: DVBC"..., 62Supported delivery systems: DVBC/ANNEX_A DVBC/ANNEX_C [DVBT] ) = 62
write(1, "Changing delivery system to: DVB"..., 42Changing delivery system to: DVBC/ANNEX_A
) = 42
ioctl(3, FE_SET_PROPERTY, 0x7fff326ce340) = 0
close(3) = 0
exit_group(0) = ?
The first FE_GET_PROPERTY reads the DVB API version and the current delivery system:
	parms->dvb_prop[0].cmd = DTV_API_VERSION;
	parms->dvb_prop[1].cmd = DTV_DELIVERY_SYSTEM;

	dtv_prop.num = 2;
	dtv_prop.props = parms->dvb_prop;

	/* Detect a DVBv3 device */
	if (ioctl(fd, FE_GET_PROPERTY, &dtv_prop) == -1) {
		parms->dvb_prop[0].u.data = 0x300;
		parms->dvb_prop[1].u.data = SYS_UNDEFINED;
	}
	parms->version = parms->dvb_prop[0].u.data;
	parms->current_sys = parms->dvb_prop[1].u.data;
The second FE_GET_PROPERTY is used only if DVB API v5.5 or upper is detected, and does:
		parms->dvb_prop[0].cmd = DTV_ENUM_DELSYS;
		parms->n_props = 1;
		dtv_prop.num = 1;
		dtv_prop.props = parms->dvb_prop;
		if (ioctl(fd, FE_GET_PROPERTY, &dtv_prop) == -1) {
			perror("FE_GET_PROPERTY");
			dvb_v5_free(parms);
			close(fd);
			return NULL;
		}
Both were called inside dvb_fe_open().
The FE_SET_PROPERTY changes the property inside the DVBv5 cache, at dvb_set_sys():
		dvb_prop[0].cmd = DTV_DELIVERY_SYSTEM;
		dvb_prop[0].u.data = sys;
		prop.num = 1;
		prop.props = dvb_prop;

		if (ioctl(parms->fd, FE_SET_PROPERTY, &prop) == -1) {
			perror("Set delivery system");
			return errno;
		}
The FE_SET_PROPERTY doesn't call a DTV_TUNE, so it shouldn't be calling the set frontend methods inside the driver.
So, from the userspace applications standpoint, I'm not seeing anything wrong.
Quoted 7 lines
That will cause this kind of calls in demod driver:
init()
get_frontend()
get_frontend()
sleep()
My guess is that it resolves current delivery system. But as demod is usually sleeping (not tuned) at that phase it does not know frontend settings asked, like modulation etc. In case of cxd2820r those are available after set_frontend() call. I think I will add check and return -EINVAL in that case.
What seems to be happening at dvb-core/dvb_frontend.h is due to this code:
if(cmd == FE_GET_PROPERTY) {
...
                /*
                 * Fills the cache out struct with the cache contents, plus
                 * the data retrieved from get_frontend.
                 */
                dtv_get_frontend(fe, NULL);
                for (i = 0; i < tvps->num; i++) {
                        err = dtv_property_process_get(fe, c, tvp + i, file);
                        if (err < 0)
                                goto out;
                        (tvp + i)->result = err;
                }
E. g. even if the FE_GET_PROPERTY is only reading the DVB version and calling DTV_ENUM_DELSYS, it is calling the dtv_get_frontend() to retrieve more data.
What it can be done is to do something like:
static bool need_get_frontend()
{
...
	for (i = 0; i < tvps->num; i++)
...
}
		if (need_get_frontend(tvps))
	                dtv_get_frontend(fe, NULL);
                for (i = 0; i < tvps->num; i++) {
                        err = dtv_property_process_get(fe, c, tvp + i, file);
                        if (err < 0)
                                goto out;
                        (tvp + i)->result = err;
                }

Quoted 3 lines

And add some logic inside need_get_frontend() to return false if the FE_GET_PROPERTY only wants static info, like DTV_ENUM_DELSYS, DTV_VERSION and DTV_DELIVERY_SYSTEM.

The enclosed patch should do the trick

-
[PATCH RFC] Don't call get_frontend() if not needed

If the frontend is in idle state, or a FE_GET_PROPERTY is called for reading the enumsys, api version or delivery system, don't call the frontend, as it is not needed.

Signed-off-by Mauro Carvalho Chehab <[email protected]>

PS.: There's one extra printk here for test purposes. Of course, this should be removed at the final version.

drivers/media/dvb/dvb-core/dvb_frontend.c +27 -1

index f5fa7aa..3c80c92 100644
@@ -1234,6 +1234,8 @@ static int dtv_get_frontend(struct dvb_frontend *fe,
 {
 	int r;
 
+printk("%s()\n", __func__);
+
 	if (fe->ops.get_frontend) {
 		r = fe->ops.get_frontend(fe);
 		if (unlikely(r < 0))

@@ -1739,12 +1741,35 @@ static int dvb_frontend_ioctl(struct file *file,
 	return err;
 }
 
+static bool need_get_frontend_call(struct dtv_properties *tvps,
+				   struct dtv_property *tvp)
+{
+	int i;
+
+	/*
+	 * If the DTV command is just informational or cache read,
+	 * don't bother to call the frontend to handle.
+	 */
+	for (i = 0; i < tvps->num; i++) {
+		switch(tvp->cmd) {
+		case DTV_ENUM_DELSYS:
+	        case DTV_DELIVERY_SYSTEM:
+		case DTV_API_VERSION:
+			break;
+		default:
+			return true;
+		}
+	}
+	return false;
+}
+
 static int dvb_frontend_ioctl_properties(struct file *file,
 			unsigned int cmd, void *parg)
 {
 	struct dvb_device *dvbdev = file->private_data;
 	struct dvb_frontend *fe = dvbdev->priv;
 	struct dtv_frontend_properties *c = &fe->dtv_property_cache;
+	struct dvb_frontend_private *fepriv = fe->frontend_priv;
 	int err = 0;
 
 	struct dtv_properties *tvps = NULL;

@@ -1812,7 +1837,8 @@ static int dvb_frontend_ioctl_properties(struct file *file,
 		 * Fills the cache out struct with the cache contents, plus
 		 * the data retrieved from get_frontend.
 		 */
-		dtv_get_frontend(fe, NULL);
+		if (need_get_frontend_call(tvps, tvp) && fepriv->state != FESTATE_IDLE)
+			dtv_get_frontend(fe, NULL);
 		for (i = 0; i < tvps->num; i++) {
 			err = dtv_property_process_get(fe, c, tvp + i, file);
 			if (err < 0)