[PATCH 0/2] v4l-utils build instruction and dvbv5 format

[PATCH 0/2] v4l-utils build instruction and dvbv5 format

[Markus Heiser]

From: Markus Heiser <markus.heiser@darmarIT.de>

Hi Mauro,

today I send you a small patch series for the v4l-utils project.

 -- Markus --

Heiser, Markus (2):
  v4l-utils: add comments to the build instructions
  v4l-utils: fixed dvbv5 vdr format

 README                        |  8 +++++++-
 lib/libdvbv5/dvb-vdr-format.c | 45 +++++++++++++++++++++++++++++--------------
 2 files changed, 38 insertions(+), 15 deletions(-)

-- 
2.7.4

[PATCH 1/2] v4l-utils: add comments to the build instructions

[Markus Heiser]

From: Markus Heiser <markus.heiser@darmarIT.de>

From: Heiser, Markus <markus.heiser@darmarIT.de>

On Debian derivated distributions (ubuntu 16.04) the package
'autoconf-archive' is required.

Signed-off-by: Markus Heiser <markus.heiser@darmarIT.de>
---
 README | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/README b/README
index 1dd5108..172bed0 100644
--- a/README
+++ b/README
@@ -22,7 +22,8 @@ each distro.
 
 On Debian and derivated distributions, you need to install the following
 packages with apt-get or aptitude:
-	debhelper dh-autoreconf autotools-dev doxygen graphviz libasound2-dev
+	debhelper dh-autoreconf autotools-dev autoconf-archive
+        doxygen graphviz libasound2-dev
 	libtool libjpeg-dev libqt4-dev libqt4-opengl-dev libudev-dev libx11-dev
 	pkg-config udev make gcc git
 
@@ -47,6 +48,11 @@ After downloading and installing the needed packages, you should run:
 	./configure
 	make
 
+If ./configure exit with some errors try::
+
+	autoreconf -i --force
+	./configure
+
 And, to install on your system:
 	sudo make install
 
-- 
2.7.4

[PATCH 2/2] v4l-utils: fixed dvbv5 vdr format

[Markus Heiser]

From: Markus Heiser <markus.heiser@darmarIT.de>

From: Heiser, Markus <markus.heiser@darmarIT.de>

The vdr format was broken, I got '(null)' entries

HD:11494:S1HC23I0M5N1O35:S:(null):22000:5101:5102,5103,5106,5108:0:0:10301:0:0:0:
0-:1----:2--------------:3:4-----:

refering to the VDR Wikis ...

* LinuxTV: http://www.linuxtv.org/vdrwiki/index.php/Syntax_of_channels.conf
* german comunity Wiki: http://www.vdr-wiki.de/wiki/index.php/Channels.conf#Parameter_ab_VDR-1.7.4

There is no field at position 4 / in between "Source" and "SRate" which
might have a value. I suppose the '(null):' is the result of pointing
to *nothing*.

An other mistake is the ending colon (":") at the line. It is not
explicit specified but adding an collon to the end of an channel entry
will prevent players (like mpv or mplayer) from parsing the line (they
will ignore these lines).

At least: generating a channel list with

  dvbv5-scan --output-format=vdr ...

will result in the same defective channel entry, containing "(null):"
and the leading collon ":".

Signed-off-by: Markus Heiser <markus.heiser@darmarIT.de>
---
 lib/libdvbv5/dvb-vdr-format.c | 45 +++++++++++++++++++++++++++++--------------
 1 file changed, 31 insertions(+), 14 deletions(-)

diff --git a/lib/libdvbv5/dvb-vdr-format.c b/lib/libdvbv5/dvb-vdr-format.c
index a4bd26b..ab0e5cf 100644
--- a/lib/libdvbv5/dvb-vdr-format.c
+++ b/lib/libdvbv5/dvb-vdr-format.c
@@ -309,13 +309,14 @@ int dvb_write_format_vdr(const char *fname,
 		fprintf(fp, "%s", entry->channel);
 		if (entry->vchannel)
 			fprintf(fp, ",%s", entry->vchannel);
+		fprintf(fp, ":");
 
 		/*
 		 * Output frequency:
 		 *	in kHz for terrestrial/cable
 		 *	in MHz for satellite
 		 */
-		fprintf(fp, ":%i:", freq / 1000);
+		fprintf(fp, "%i:", freq / 1000);
 
 		/* Output modulation parameters */
 		fmt = &formats[i];
@@ -349,20 +350,30 @@ int dvb_write_format_vdr(const char *fname,
 
 			fprintf(fp, "%s", table->table[data]);
 		}
-
-		/* Output format type */
-		fprintf(fp, ":%s:", id);
+		fprintf(fp, ":");
 
 		/*
-		 * Output satellite location
-		 * FIXME: probably require some adjustments to match the
-		 *	  format expected by VDR.
+		 * Output sources configuration for VDR
+		 *
+		 *   S (satellite) xy.z (orbital position in degrees) E or W (east or west)
+		 *
+		 *   FIXME: in case of ATSC we use "A", this is what w_scan does
 		 */
-		switch(delsys) {
-		case SYS_DVBS:
-		case SYS_DVBS2:
-			fprintf(fp, "%s:", entry->location);
+
+		if (entry->location) {
+			switch(delsys) {
+			case SYS_DVBS:
+			case SYS_DVBS2:
+				fprintf(fp, "%s", entry->location);
+				break;
+			default:
+				fprintf(fp, "%s", id);
+				break;
+			}
+		} else {
+			fprintf(fp, "%s", id);
 		}
+		fprintf(fp, ":");
 
 		/* Output symbol rate */
 		srate = 27500000;
@@ -407,10 +418,16 @@ int dvb_write_format_vdr(const char *fname,
 		/* Output Service ID */
 		fprintf(fp, "%d:", entry->service_id);
 
-		/* Output SID, NID, TID and RID */
-		fprintf(fp, "0:0:0:");
+		/* Output Network ID */
+		fprintf(fp, "0:");
 
-		fprintf(fp, "\n");
+		/* Output Transport Stream ID */
+		fprintf(fp, "0:");
+
+		/* Output Radio ID
+		 * this is the last entry, tagged bei a new line (not a colon!)
+		 */
+		fprintf(fp, "0\n");
 		line++;
 	};
 	fclose (fp);
-- 
2.7.4

Re: [PATCH 2/2] v4l-utils: fixed dvbv5 vdr format

[Markus Heiser]

Am 10.08.2016 um 11:52 schrieb Markus Heiser <markus.heiser@darmarIT.de>:

> The vdr format was broken, I got '(null)' entries
> 
> HD:11494:S1HC23I0M5N1O35:S:(null):22000:5101:5102,5103,5106,5108:0:0:10301:0:0:0:
> 0-:1----:2--------------:3:4-----:
> 
> refering to the VDR Wikis ...
> 
> * LinuxTV: http://www.linuxtv.org/vdrwiki/index.php/Syntax_of_channels.conf
> * german comunity Wiki: http://www.vdr-wiki.de/wiki/index.php/Channels.conf#Parameter_ab_VDR-1.7.4
> 
> There is no field at position 4 / in between "Source" and "SRate" which
> might have a value. I suppose the '(null):' is the result of pointing
> to *nothing*.
> 
> An other mistake is the ending colon (":") at the line. It is not
> explicit specified but adding an collon to the end of an channel entry
> will prevent players (like mpv or mplayer) from parsing the line (they
> will ignore these lines).
> 
> At least: generating a channel list with
> 
>  dvbv5-scan --output-format=vdr ...
> 
> will result in the same defective channel entry, containing "(null):"
> and the leading collon ":".
> 

Hi,

please apply this patch or give me at least some feedback / thanks.

-- Markus 

Re: [PATCH 2/2] v4l-utils: fixed dvbv5 vdr format

[Markus Heiser]

Am 16.08.2016 um 09:10 schrieb Markus Heiser <markus.heiser@darmarIT.de>:

> Am 10.08.2016 um 11:52 schrieb Markus Heiser <markus.heiser@darmarIT.de>:
> 
>> The vdr format was broken, I got '(null)' entries
>> 
>> HD:11494:S1HC23I0M5N1O35:S:(null):22000:5101:5102,5103,5106,5108:0:0:10301:0:0:0:
>> 0-:1----:2--------------:3:4-----:
>> 
>> refering to the VDR Wikis ...
>> 
>> * LinuxTV: http://www.linuxtv.org/vdrwiki/index.php/Syntax_of_channels.conf
>> * german comunity Wiki: http://www.vdr-wiki.de/wiki/index.php/Channels.conf#Parameter_ab_VDR-1.7.4
>> 
>> There is no field at position 4 / in between "Source" and "SRate" which
>> might have a value. I suppose the '(null):' is the result of pointing
>> to *nothing*.
>> 
>> An other mistake is the ending colon (":") at the line. It is not
>> explicit specified but adding an collon to the end of an channel entry
>> will prevent players (like mpv or mplayer) from parsing the line (they
>> will ignore these lines).
>> 
>> At least: generating a channel list with
>> 
>> dvbv5-scan --output-format=vdr ...
>> 
>> will result in the same defective channel entry, containing "(null):"
>> and the leading collon ":".
>> 
> 
> Hi,
> 
> please apply this patch or give me at least some feedback / thanks.
> 
> -- Markus ----

Sorry for bumping ... but, since there is no reaction on the ML
I have to bump :-(

Please, please, please ...  apply this patch. The VDR format of
the libdvbv5 is definitely broken!

 https://patchwork.linuxtv.org/patch/36293/

-- Markus 

Re: [PATCH 2/2] v4l-utils: fixed dvbv5 vdr format

[Mauro Carvalho Chehab]

Hi Markus,

Em Wed, 10 Aug 2016 11:52:19 +0200
Markus Heiser <markus.heiser@darmarit.de> escreveu:

> From: Markus Heiser <markus.heiser@darmarIT.de>
> 
> From: Heiser, Markus <markus.heiser@darmarIT.de>
> 
> The vdr format was broken, I got '(null)' entries
> 
> HD:11494:S1HC23I0M5N1O35:S:(null):22000:5101:5102,5103,5106,5108:0:0:10301:0:0:0:
> 0-:1----:2--------------:3:4-----:
> 
> refering to the VDR Wikis ...
> 
> * LinuxTV: http://www.linuxtv.org/vdrwiki/index.php/Syntax_of_channels.conf
> * german comunity Wiki: http://www.vdr-wiki.de/wiki/index.php/Channels.conf#Parameter_ab_VDR-1.7.4
> 
> There is no field at position 4 / in between "Source" and "SRate" which
> might have a value. I suppose the '(null):' is the result of pointing
> to *nothing*.
> 
> An other mistake is the ending colon (":") at the line. It is not
> explicit specified but adding an collon to the end of an channel entry
> will prevent players (like mpv or mplayer) from parsing the line (they
> will ignore these lines).
> 
> At least: generating a channel list with
> 
>   dvbv5-scan --output-format=vdr ...
> 
> will result in the same defective channel entry, containing "(null):"
> and the leading collon ":".

Sorry for taking too long to handle that. I usually stop handling
patches one week before the merge window, returning to merge only
after -rc1. This time, it took a little more time, due to the Sphinx
changes, as I was needing some patches to be merged upstream, in order
to change my handling scripts to work with the new way.

Anyway, with regards to this patch, not sure if you saw, but
Chris Mayo sent us a different fix for it:

	https://patchwork.linuxtv.org/patch/35803/

With is meant to support VDR format as used on version 2.2. Not sure
if this format is backward-compatible with versions 1.x, but usually
VDR just adds new parameters to the lines.

So, I'm inclined to merge Chris patch instead of yours.

So, could you please test if his patch does what's needed?

Thanks!
Mauro


> 
> Signed-off-by: Markus Heiser <markus.heiser@darmarIT.de>
> ---
>  lib/libdvbv5/dvb-vdr-format.c | 45 +++++++++++++++++++++++++++++--------------
>  1 file changed, 31 insertions(+), 14 deletions(-)
> 
> diff --git a/lib/libdvbv5/dvb-vdr-format.c b/lib/libdvbv5/dvb-vdr-format.c
> index a4bd26b..ab0e5cf 100644
> --- a/lib/libdvbv5/dvb-vdr-format.c
> +++ b/lib/libdvbv5/dvb-vdr-format.c
> @@ -309,13 +309,14 @@ int dvb_write_format_vdr(const char *fname,
>  		fprintf(fp, "%s", entry->channel);
>  		if (entry->vchannel)
>  			fprintf(fp, ",%s", entry->vchannel);
> +		fprintf(fp, ":");
>  
>  		/*
>  		 * Output frequency:
>  		 *	in kHz for terrestrial/cable
>  		 *	in MHz for satellite
>  		 */
> -		fprintf(fp, ":%i:", freq / 1000);
> +		fprintf(fp, "%i:", freq / 1000);
>  
>  		/* Output modulation parameters */
>  		fmt = &formats[i];
> @@ -349,20 +350,30 @@ int dvb_write_format_vdr(const char *fname,
>  
>  			fprintf(fp, "%s", table->table[data]);
>  		}
> -
> -		/* Output format type */
> -		fprintf(fp, ":%s:", id);
> +		fprintf(fp, ":");
>  
>  		/*
> -		 * Output satellite location
> -		 * FIXME: probably require some adjustments to match the
> -		 *	  format expected by VDR.
> +		 * Output sources configuration for VDR
> +		 *
> +		 *   S (satellite) xy.z (orbital position in degrees) E or W (east or west)
> +		 *
> +		 *   FIXME: in case of ATSC we use "A", this is what w_scan does
>  		 */
> -		switch(delsys) {
> -		case SYS_DVBS:
> -		case SYS_DVBS2:
> -			fprintf(fp, "%s:", entry->location);
> +
> +		if (entry->location) {
> +			switch(delsys) {
> +			case SYS_DVBS:
> +			case SYS_DVBS2:
> +				fprintf(fp, "%s", entry->location);
> +				break;
> +			default:
> +				fprintf(fp, "%s", id);
> +				break;
> +			}
> +		} else {
> +			fprintf(fp, "%s", id);
>  		}
> +		fprintf(fp, ":");
>  
>  		/* Output symbol rate */
>  		srate = 27500000;
> @@ -407,10 +418,16 @@ int dvb_write_format_vdr(const char *fname,
>  		/* Output Service ID */
>  		fprintf(fp, "%d:", entry->service_id);
>  
> -		/* Output SID, NID, TID and RID */
> -		fprintf(fp, "0:0:0:");
> +		/* Output Network ID */
> +		fprintf(fp, "0:");
>  
> -		fprintf(fp, "\n");
> +		/* Output Transport Stream ID */
> +		fprintf(fp, "0:");
> +
> +		/* Output Radio ID
> +		 * this is the last entry, tagged bei a new line (not a colon!)
> +		 */
> +		fprintf(fp, "0\n");
>  		line++;
>  	};
>  	fclose (fp);



Thanks,
Mauro

Re: [PATCH 2/2] v4l-utils: fixed dvbv5 vdr format

[Mauro Carvalho Chehab]

Em Wed, 24 Aug 2016 11:49:27 -0300
Mauro Carvalho Chehab <mchehab@s-opensource.com> escreveu:

> Hi Markus,
> 
> Em Wed, 10 Aug 2016 11:52:19 +0200
> Markus Heiser <markus.heiser@darmarit.de> escreveu:
> 
> > From: Markus Heiser <markus.heiser@darmarIT.de>
> > 
> > From: Heiser, Markus <markus.heiser@darmarIT.de>
> > 
> > The vdr format was broken, I got '(null)' entries
> > 
> > HD:11494:S1HC23I0M5N1O35:S:(null):22000:5101:5102,5103,5106,5108:0:0:10301:0:0:0:
> > 0-:1----:2--------------:3:4-----:
> > 
> > refering to the VDR Wikis ...
> > 
> > * LinuxTV: http://www.linuxtv.org/vdrwiki/index.php/Syntax_of_channels.conf
> > * german comunity Wiki: http://www.vdr-wiki.de/wiki/index.php/Channels.conf#Parameter_ab_VDR-1.7.4
> > 
> > There is no field at position 4 / in between "Source" and "SRate" which
> > might have a value. I suppose the '(null):' is the result of pointing
> > to *nothing*.
> > 
> > An other mistake is the ending colon (":") at the line. It is not
> > explicit specified but adding an collon to the end of an channel entry
> > will prevent players (like mpv or mplayer) from parsing the line (they
> > will ignore these lines).
> > 
> > At least: generating a channel list with
> > 
> >   dvbv5-scan --output-format=vdr ...
> > 
> > will result in the same defective channel entry, containing "(null):"
> > and the leading collon ":".  
> 
> Sorry for taking too long to handle that. I usually stop handling
> patches one week before the merge window, returning to merge only
> after -rc1. This time, it took a little more time, due to the Sphinx
> changes, as I was needing some patches to be merged upstream, in order
> to change my handling scripts to work with the new way.
> 
> Anyway, with regards to this patch, not sure if you saw, but
> Chris Mayo sent us a different fix for it:
> 
> 	https://patchwork.linuxtv.org/patch/35803/
> 
> With is meant to support VDR format as used on version 2.2. Not sure
> if this format is backward-compatible with versions 1.x, but usually
> VDR just adds new parameters to the lines.
> 
> So, I'm inclined to merge Chris patch instead of yours.
> 
> So, could you please test if his patch does what's needed?

PS.: If the formats for v 1.x are not compatible with the ones for
v2.x, then the best would be to change the code to add a new format
for vdr v2.x, while keep supporting vdr v1.x.



Thanks,
Mauro

Re: [PATCH 2/2] v4l-utils: fixed dvbv5 vdr format

[Markus Heiser]

Hi Mauro, (Hi Chris)

sorry for my late reply. I test the v4-utils on my HTPC,
where I'am not often have time for experimentation ;-)

Am 24.08.2016 um 16:52 schrieb Mauro Carvalho Chehab <mchehab@s-opensource.com>:

> Em Wed, 24 Aug 2016 11:49:27 -0300
> Mauro Carvalho Chehab <mchehab@s-opensource.com> escreveu:
> 
>> Hi Markus,
>> 
>> Em Wed, 10 Aug 2016 11:52:19 +0200
>> Markus Heiser <markus.heiser@darmarit.de> escreveu:
>> 
>>> From: Markus Heiser <markus.heiser@darmarIT.de>
>>> 
>>> From: Heiser, Markus <markus.heiser@darmarIT.de>
>>> 
>>> The vdr format was broken, I got '(null)' entries
>>> 
>>> HD:11494:S1HC23I0M5N1O35:S:(null):22000:5101:5102,5103,5106,5108:0:0:10301:0:0:0:
>>> 0-:1----:2--------------:3:4-----:
>>> 
>>> refering to the VDR Wikis ...
>>> 
>>> * LinuxTV: http://www.linuxtv.org/vdrwiki/index.php/Syntax_of_channels.conf
>>> * german comunity Wiki: http://www.vdr-wiki.de/wiki/index.php/Channels.conf#Parameter_ab_VDR-1.7.4
>>> 
>>> There is no field at position 4 / in between "Source" and "SRate" which
>>> might have a value. I suppose the '(null):' is the result of pointing
>>> to *nothing*.
>>> 
>>> An other mistake is the ending colon (":") at the line. It is not
>>> explicit specified but adding an collon to the end of an channel entry
>>> will prevent players (like mpv or mplayer) from parsing the line (they
>>> will ignore these lines).
>>> 
>>> At least: generating a channel list with
>>> 
>>>  dvbv5-scan --output-format=vdr ...
>>> 
>>> will result in the same defective channel entry, containing "(null):"
>>> and the leading collon ":".  
>> 
>> Sorry for taking too long to handle that. I usually stop handling
>> patches one week before the merge window, returning to merge only
>> after -rc1. This time, it took a little more time, due to the Sphinx
>> changes, as I was needing some patches to be merged upstream, in order
>> to change my handling scripts to work with the new way.
>> 
>> Anyway, with regards to this patch, not sure if you saw, but
>> Chris Mayo sent us a different fix for it:
>> 
>> 	https://patchwork.linuxtv.org/patch/35803/
>> 
>> With is meant to support VDR format as used on version 2.2. Not sure
>> if this format is backward-compatible with versions 1.x, but usually
>> VDR just adds new parameters to the lines.
>> 
>> So, I'm inclined to merge Chris patch instead of yours.
>> 
>> So, could you please test if his patch does what's needed?
> 
> PS.: If the formats for v 1.x are not compatible with the ones for
> v2.x, then the best would be to change the code to add a new format
> for vdr v2.x, while keep supporting vdr v1.x.

Hmm, I'am a bit confused about vdr's channel.conf v1.x and v2.x.

I can't find any documentation on this and since there is no
version control system for vdr it is hard to dig the history.

As far as I can see, Chris fixes an issue with DVB-T and the
issue with the leading ":".

My patch fixes an issue with DVB-S/2 entry-location (and the
issue with the leading ":").

I will give it a try to merge my changes on top of Chris's
patch and test DVB-T & DVB-S2 on my HTPC with an vdr server.


-- Markus --

> 
> 
> 
> Thanks,
> Mauro

Re: [PATCH 2/2] v4l-utils: fixed dvbv5 vdr format

[Mauro Carvalho Chehab]

Em Mon, 5 Sep 2016 15:13:04 +0200
Markus Heiser <markus.heiser@darmarit.de> escreveu:

> Hi Mauro, (Hi Chris)
> 
> sorry for my late reply. I test the v4-utils on my HTPC,
> where I'am not often have time for experimentation ;-)
> 
> Am 24.08.2016 um 16:52 schrieb Mauro Carvalho Chehab <mchehab@s-opensource.com>:
> 
> > Em Wed, 24 Aug 2016 11:49:27 -0300
> > Mauro Carvalho Chehab <mchehab@s-opensource.com> escreveu:
> >   
> >> Hi Markus,
> >> 
> >> Em Wed, 10 Aug 2016 11:52:19 +0200
> >> Markus Heiser <markus.heiser@darmarit.de> escreveu:
> >>   
> >>> From: Markus Heiser <markus.heiser@darmarIT.de>
> >>> 
> >>> From: Heiser, Markus <markus.heiser@darmarIT.de>
> >>> 
> >>> The vdr format was broken, I got '(null)' entries
> >>> 
> >>> HD:11494:S1HC23I0M5N1O35:S:(null):22000:5101:5102,5103,5106,5108:0:0:10301:0:0:0:
> >>> 0-:1----:2--------------:3:4-----:
> >>> 
> >>> refering to the VDR Wikis ...
> >>> 
> >>> * LinuxTV: http://www.linuxtv.org/vdrwiki/index.php/Syntax_of_channels.conf
> >>> * german comunity Wiki: http://www.vdr-wiki.de/wiki/index.php/Channels.conf#Parameter_ab_VDR-1.7.4
> >>> 
> >>> There is no field at position 4 / in between "Source" and "SRate" which
> >>> might have a value. I suppose the '(null):' is the result of pointing
> >>> to *nothing*.
> >>> 
> >>> An other mistake is the ending colon (":") at the line. It is not
> >>> explicit specified but adding an collon to the end of an channel entry
> >>> will prevent players (like mpv or mplayer) from parsing the line (they
> >>> will ignore these lines).
> >>> 
> >>> At least: generating a channel list with
> >>> 
> >>>  dvbv5-scan --output-format=vdr ...
> >>> 
> >>> will result in the same defective channel entry, containing "(null):"
> >>> and the leading collon ":".    
> >> 
> >> Sorry for taking too long to handle that. I usually stop handling
> >> patches one week before the merge window, returning to merge only
> >> after -rc1. This time, it took a little more time, due to the Sphinx
> >> changes, as I was needing some patches to be merged upstream, in order
> >> to change my handling scripts to work with the new way.
> >> 
> >> Anyway, with regards to this patch, not sure if you saw, but
> >> Chris Mayo sent us a different fix for it:
> >> 
> >> 	https://patchwork.linuxtv.org/patch/35803/
> >> 
> >> With is meant to support VDR format as used on version 2.2. Not sure
> >> if this format is backward-compatible with versions 1.x, but usually
> >> VDR just adds new parameters to the lines.
> >> 
> >> So, I'm inclined to merge Chris patch instead of yours.
> >> 
> >> So, could you please test if his patch does what's needed?  
> > 
> > PS.: If the formats for v 1.x are not compatible with the ones for
> > v2.x, then the best would be to change the code to add a new format
> > for vdr v2.x, while keep supporting vdr v1.x.  
> 
> Hmm, I'am a bit confused about vdr's channel.conf v1.x and v2.x.
> 
> I can't find any documentation on this and since there is no
> version control system for vdr it is hard to dig the history.

Yeah, I see your pain.

> As far as I can see, Chris fixes an issue with DVB-T and the
> issue with the leading ":".
> 
> My patch fixes an issue with DVB-S/2 entry-location (and the
> issue with the leading ":").
> 
> I will give it a try to merge my changes on top of Chris's
> patch and test DVB-T & DVB-S2 on my HTPC with an vdr server.

Ok, that would be great! it would also be good if either of you could
take a look on how to allow libdvbv5 to support both VDR versions 1.x and
2.x. I don't use VDR here (afaikt, it doesn't support ISDB-T - and nowadays
I only have DVB/ATSC via my RF test generators), but, IMHO, being able to
provide output on both formats can be useful for other VDR users.

Regards,
Mauro

Re: [PATCH 2/2] v4l-utils: fixed dvbv5 vdr format

[Chris Mayo]

On 05/09/16 14:25, Mauro Carvalho Chehab wrote:
> Em Mon, 5 Sep 2016 15:13:04 +0200
> Markus Heiser <markus.heiser@darmarit.de> escreveu:
> 
>> Hi Mauro, (Hi Chris)
>>
>> sorry for my late reply. I test the v4-utils on my HTPC,
>> where I'am not often have time for experimentation ;-)
>>
>> Am 24.08.2016 um 16:52 schrieb Mauro Carvalho Chehab <mchehab@s-opensource.com>:
>>
>>> Em Wed, 24 Aug 2016 11:49:27 -0300
>>> Mauro Carvalho Chehab <mchehab@s-opensource.com> escreveu:
>>>   
>>>> Hi Markus,
>>>>
>>>> Em Wed, 10 Aug 2016 11:52:19 +0200
>>>> Markus Heiser <markus.heiser@darmarit.de> escreveu:
>>>>   
>>>>> From: Markus Heiser <markus.heiser@darmarIT.de>
>>>>>
>>>>> From: Heiser, Markus <markus.heiser@darmarIT.de>
>>>>>
>>>>> The vdr format was broken, I got '(null)' entries
>>>>>
>>>>> HD:11494:S1HC23I0M5N1O35:S:(null):22000:5101:5102,5103,5106,5108:0:0:10301:0:0:0:
>>>>> 0-:1----:2--------------:3:4-----:
>>>>>
>>>>> refering to the VDR Wikis ...
>>>>>
>>>>> * LinuxTV: http://www.linuxtv.org/vdrwiki/index.php/Syntax_of_channels.conf
>>>>> * german comunity Wiki: http://www.vdr-wiki.de/wiki/index.php/Channels.conf#Parameter_ab_VDR-1.7.4
>>>>>
>>>>> There is no field at position 4 / in between "Source" and "SRate" which
>>>>> might have a value. I suppose the '(null):' is the result of pointing
>>>>> to *nothing*.
>>>>>
>>>>> An other mistake is the ending colon (":") at the line. It is not
>>>>> explicit specified but adding an collon to the end of an channel entry
>>>>> will prevent players (like mpv or mplayer) from parsing the line (they
>>>>> will ignore these lines).
>>>>>
>>>>> At least: generating a channel list with
>>>>>
>>>>>  dvbv5-scan --output-format=vdr ...
>>>>>
>>>>> will result in the same defective channel entry, containing "(null):"
>>>>> and the leading collon ":".    
>>>>
>>>> Sorry for taking too long to handle that. I usually stop handling
>>>> patches one week before the merge window, returning to merge only
>>>> after -rc1. This time, it took a little more time, due to the Sphinx
>>>> changes, as I was needing some patches to be merged upstream, in order
>>>> to change my handling scripts to work with the new way.
>>>>
>>>> Anyway, with regards to this patch, not sure if you saw, but
>>>> Chris Mayo sent us a different fix for it:
>>>>
>>>> 	https://patchwork.linuxtv.org/patch/35803/
>>>>
>>>> With is meant to support VDR format as used on version 2.2. Not sure
>>>> if this format is backward-compatible with versions 1.x, but usually
>>>> VDR just adds new parameters to the lines.
>>>>
>>>> So, I'm inclined to merge Chris patch instead of yours.
>>>>
>>>> So, could you please test if his patch does what's needed?  
>>>
>>> PS.: If the formats for v 1.x are not compatible with the ones for
>>> v2.x, then the best would be to change the code to add a new format
>>> for vdr v2.x, while keep supporting vdr v1.x.  
>>
>> Hmm, I'am a bit confused about vdr's channel.conf v1.x and v2.x.
>>
>> I can't find any documentation on this and since there is no
>> version control system for vdr it is hard to dig the history.
> 
> Yeah, I see your pain.
> 
>> As far as I can see, Chris fixes an issue with DVB-T and the
>> issue with the leading ":".
>>
>> My patch fixes an issue with DVB-S/2 entry-location (and the
>> issue with the leading ":").
>>
>> I will give it a try to merge my changes on top of Chris's
>> patch and test DVB-T & DVB-S2 on my HTPC with an vdr server.

Thanks. I can't test DVB-S(2) so I decided to leave that part alone.

> 
> Ok, that would be great! it would also be good if either of you could
> take a look on how to allow libdvbv5 to support both VDR versions 1.x and
> 2.x. I don't use VDR here (afaikt, it doesn't support ISDB-T - and nowadays
> I only have DVB/ATSC via my RF test generators), but, IMHO, being able to
> provide output on both formats can be useful for other VDR users.
> 

Is supporting vdr v1.x necessary?

I believe v1.7.x were developer releases leading up to v2.0.
Last stable v1.x was 2012-02-14: Version 1.6.0-3. With v1.6.0 being from 2008!

Looks like v2.2.0 added parameters N, Q and X for S2 and T2. But libdvbv5 does
not currently appear to output these (at least Q and X for T2).

Chris

Re: [PATCH 2/2] v4l-utils: fixed dvbv5 vdr format

[Mauro Carvalho Chehab]

Em Mon, 5 Sep 2016 20:01:22 +0100
Chris Mayo <aklhfex@gmail.com> escreveu:

> On 05/09/16 14:25, Mauro Carvalho Chehab wrote:
> > Em Mon, 5 Sep 2016 15:13:04 +0200
> > Markus Heiser <markus.heiser@darmarit.de> escreveu:
> >   
> >> Hi Mauro, (Hi Chris)
> >>
> >> sorry for my late reply. I test the v4-utils on my HTPC,
> >> where I'am not often have time for experimentation ;-)
> >>
> >> Am 24.08.2016 um 16:52 schrieb Mauro Carvalho Chehab <mchehab@s-opensource.com>:
> >>  
> >>> Em Wed, 24 Aug 2016 11:49:27 -0300
> >>> Mauro Carvalho Chehab <mchehab@s-opensource.com> escreveu:
> >>>     
> >>>> Hi Markus,
> >>>>
> >>>> Em Wed, 10 Aug 2016 11:52:19 +0200
> >>>> Markus Heiser <markus.heiser@darmarit.de> escreveu:
> >>>>     
> >>>>> From: Markus Heiser <markus.heiser@darmarIT.de>
> >>>>>
> >>>>> From: Heiser, Markus <markus.heiser@darmarIT.de>
> >>>>>
> >>>>> The vdr format was broken, I got '(null)' entries
> >>>>>
> >>>>> HD:11494:S1HC23I0M5N1O35:S:(null):22000:5101:5102,5103,5106,5108:0:0:10301:0:0:0:
> >>>>> 0-:1----:2--------------:3:4-----:
> >>>>>
> >>>>> refering to the VDR Wikis ...
> >>>>>
> >>>>> * LinuxTV: http://www.linuxtv.org/vdrwiki/index.php/Syntax_of_channels.conf
> >>>>> * german comunity Wiki: http://www.vdr-wiki.de/wiki/index.php/Channels.conf#Parameter_ab_VDR-1.7.4
> >>>>>
> >>>>> There is no field at position 4 / in between "Source" and "SRate" which
> >>>>> might have a value. I suppose the '(null):' is the result of pointing
> >>>>> to *nothing*.
> >>>>>
> >>>>> An other mistake is the ending colon (":") at the line. It is not
> >>>>> explicit specified but adding an collon to the end of an channel entry
> >>>>> will prevent players (like mpv or mplayer) from parsing the line (they
> >>>>> will ignore these lines).
> >>>>>
> >>>>> At least: generating a channel list with
> >>>>>
> >>>>>  dvbv5-scan --output-format=vdr ...
> >>>>>
> >>>>> will result in the same defective channel entry, containing "(null):"
> >>>>> and the leading collon ":".      
> >>>>
> >>>> Sorry for taking too long to handle that. I usually stop handling
> >>>> patches one week before the merge window, returning to merge only
> >>>> after -rc1. This time, it took a little more time, due to the Sphinx
> >>>> changes, as I was needing some patches to be merged upstream, in order
> >>>> to change my handling scripts to work with the new way.
> >>>>
> >>>> Anyway, with regards to this patch, not sure if you saw, but
> >>>> Chris Mayo sent us a different fix for it:
> >>>>
> >>>> 	https://patchwork.linuxtv.org/patch/35803/
> >>>>
> >>>> With is meant to support VDR format as used on version 2.2. Not sure
> >>>> if this format is backward-compatible with versions 1.x, but usually
> >>>> VDR just adds new parameters to the lines.
> >>>>
> >>>> So, I'm inclined to merge Chris patch instead of yours.
> >>>>
> >>>> So, could you please test if his patch does what's needed?    
> >>>
> >>> PS.: If the formats for v 1.x are not compatible with the ones for
> >>> v2.x, then the best would be to change the code to add a new format
> >>> for vdr v2.x, while keep supporting vdr v1.x.    
> >>
> >> Hmm, I'am a bit confused about vdr's channel.conf v1.x and v2.x.
> >>
> >> I can't find any documentation on this and since there is no
> >> version control system for vdr it is hard to dig the history.  
> > 
> > Yeah, I see your pain.
> >   
> >> As far as I can see, Chris fixes an issue with DVB-T and the
> >> issue with the leading ":".
> >>
> >> My patch fixes an issue with DVB-S/2 entry-location (and the
> >> issue with the leading ":").
> >>
> >> I will give it a try to merge my changes on top of Chris's
> >> patch and test DVB-T & DVB-S2 on my HTPC with an vdr server.  
> 
> Thanks. I can't test DVB-S(2) so I decided to leave that part alone.
> 
> > 
> > Ok, that would be great! it would also be good if either of you could
> > take a look on how to allow libdvbv5 to support both VDR versions 1.x and
> > 2.x. I don't use VDR here (afaikt, it doesn't support ISDB-T - and nowadays
> > I only have DVB/ATSC via my RF test generators), but, IMHO, being able to
> > provide output on both formats can be useful for other VDR users.
> >   
> 
> Is supporting vdr v1.x necessary?

That is a good question. I don't have a strong opinion here.

> 
> I believe v1.7.x were developer releases leading up to v2.0.
> Last stable v1.x was 2012-02-14: Version 1.6.0-3. With v1.6.0 being from 2008!

Hmm... 4 years ago... LTS distros usually lasts 5 years. So, it is possible
that someone might have a LTS version shipped with it. On the other hand,
it sounds unlikely that someone would be running vdr from LTS while using
the latest v4l-utils version (except if there are some VDR extensions people
would need that only runs on 1.x versions).

> Looks like v2.2.0 added parameters N, Q and X for S2 and T2. But libdvbv5 does
> not currently appear to output these (at least Q and X for T2).

I guess the latest version at the time I added support at libdvbv5 was v2.1.
According with the git logs, support was added in 2014 and aimed support
for version 2.1.6:

commit 67a718b3f1c8edb47f052cfa1e34c2234bb3dad5
Author: Mauro Carvalho Chehab <m.chehab@samsung.com>
Date:   Sat Sep 13 12:25:36 2014 -0300

    Add support for VDR format (only for output)
    
    VDR has its own special format, that doesn't fit into the normal
    oneline parsers. So, it requires its own code to parse.
    
    Add support for it, as used on vdr 2.1.6.
    
    Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>

My goal on that time were just to provide this extra output format in
order to provide an alternative for VDR users that were relying on
the old dvbscan tool (with used to provide VDR support for even older
versions). I remember I set a test bench on that time to be sure that
VDR were recognizing the output format and filling the blanks. I didn't 
bother to write a VDR input file format (with could be useful for file
format conversions).

I don't mind if someone would add support for those 3 newer parameters at
the library, provided that we keep it backward-compatible to what's there,
and even add support for those extra fields at the libdvbv5 format too.

I guess older VDR 2.x versions are capable of working with files with those
extra parameters, as it should silently ignore them. So, if we move to
version 2.2.x, we should not have backward compatible problems, I guess.

Regards,
Mauro

Re: [PATCH 2/2] v4l-utils: fixed dvbv5 vdr format

[VDR User]

I can tell you that people do still use VDR-1.6.0-3. It would be
unwise (and unnecessary) to break backwards compatible, which would be
grounds for NACK if you ask me. Knowingly causing breakage has always
been an unpopular thing in the VDR community, and this sounds like
it's going beyond fixing a small issue to fixing it til it breaks.

Re: [PATCH 2/2] v4l-utils: fixed dvbv5 vdr format

[Mauro Carvalho Chehab]

Em Tue, 6 Sep 2016 08:16:22 -0700
VDR User <user.vdr@gmail.com> escreveu:

> I can tell you that people do still use VDR-1.6.0-3. It would be
> unwise (and unnecessary) to break backwards compatible, which would be
> grounds for NACK if you ask me. Knowingly causing breakage has always
> been an unpopular thing in the VDR community, and this sounds like
> it's going beyond fixing a small issue to fixing it til it breaks.

Well, the libdvbv5 VDR output support was written aiming VDR version 2.1.6.
I've no idea if it works with VDR 1.6.0. Don't remember if I tested support
for such version when I wrote the code.

Also, as it seems that VDR 1.6.0 was released in 2008, it probably won't
support DVB-T2 (with was added in 2011) and may not support DVB-S2
(added in 2008, but support for DTV_STREAM_ID seems to be added only
in 2012).

So, at least for DVB-T2/DVB-S2, people likely need some version newer
than VDR 1.6.0 for full support. If so, the changes proposed by Markus
and Chris won't be disruptive for 1.6, as they seem to be touching only
on DVB-T2 and DVB-S2 support, right?

Please correct me if I'm wrong.

Thanks,
Mauro

Re: [PATCH 2/2] v4l-utils: fixed dvbv5 vdr format

[Markus Heiser]

Am 06.09.2016 um 17:47 schrieb Mauro Carvalho Chehab <mchehab@s-opensource.com>:

> Em Tue, 6 Sep 2016 08:16:22 -0700
> VDR User <user.vdr@gmail.com> escreveu:
> 
>> I can tell you that people do still use VDR-1.6.0-3. It would be
>> unwise (and unnecessary) to break backwards compatible, which would be
>> grounds for NACK if you ask me. Knowingly causing breakage has always
>> been an unpopular thing in the VDR community,

not only in the VDR community

>> and this sounds like
>> it's going beyond fixing a small issue

It is broken (see below). Have you ever used dvbv5 tools with vdr format
output or did you know a "VDR user" who is using dvbv5-scan and not wscan?

>> to fixing it til it breaks.
> 
> Well, the libdvbv5 VDR output support was written aiming VDR version 2.1.6.
> I've no idea if it works with VDR 1.6.0. Don't remember if I tested support
> for such version when I wrote the code.
> 
> Also, as it seems that VDR 1.6.0 was released in 2008, it probably won't
> support DVB-T2 (with was added in 2011) and may not support DVB-S2
> (added in 2008, but support for DTV_STREAM_ID seems to be added only
> in 2012).

For me it is completely unclear, what was added when (see below).

> So, at least for DVB-T2/DVB-S2, people likely need some version newer
> than VDR 1.6.0 for full support. If so, the changes proposed by Markus
> and Chris won't be disruptive for 1.6, as they seem to be touching only
> on DVB-T2 and DVB-S2 support, right?

Not only DVB-T2 and DVB-S2, we also fix 

* the leading ":" 
* the symbol SRate of DVB-T DVB-T2,
* if given, the orbital position of DVB-S DVB-S2 is inserted and
* there is no field at position 4 / in between "Source" and "SRate" which
  might have a value. I suppose the '(null):' is the result of pointing
  to *nothing*.

E.g.: Chris fix DVB-T: 
old --> BBC TWO:498000:S0B8C23D12I999M64T8G32Y0:T:27500:201:202,206:0:0:4287:0:0:0:
new --> BBC TWO:498000:B8C23D12G32I999M64S0T8Y0:T:0:201:202,206:0:0:4287:0:0:0

E.g.: Markus fix DVB-S2:
old --> Das Erste HD:11494:S1HC23I0M5N1O35:S:(null):22000:5101:5102,5103,5106,5108:0:0:10301:0:0:0:
new --> Das Erste HD:11494:S1HC23I0M5N1O35:S:22000:5101:5102,5103,5106,5108:0:0:10301:0:0:0


Since these bugs are from the beginning and no one has rejected, 
I suppose, that these VDR 1.6.0 users are using wscan and not the
dvbv5 tools. IMHO the VDR format has never been worked,
so we can't break backwards compatible ;) and since there is wscan
widely used by old vdr hats, we do not need to care pre-DVB-[T|S]-2
formats.

As I said, it might be more helpful to place vdr in a public
repository and to document channel's format well. It is always a
hell for me to dig into the vdr sources without a version 
context and an ambiguous documentation ...

Different formats (compare):
* http://www.vdr-wiki.de/wiki/index.php/Channels.conf#Unterschiede
* https://www.linuxtv.org/vdrwiki/index.php/Syntax_of_channels.conf#Differences

Obsolete wscan
* http://www.vdr-wiki.de/wiki/index.php/Channels.conf_DVBS-S19.2E_Astra
e.g: 
Das Erste HD;ARD:11361:hC23M5O35S1:S19.2E:22000:6010:6020=ger,6021=ger;6022:6030:0:11100:1:1011:0

Dead channel editors:
* http://www.vdr-wiki.de/wiki/index.php/Channeleditoren

VDR wiki recommends wscan
* http://www.vdr-wiki.de/wiki/index.php/W_scan

I think, there is much room left to support developers and users
outside the vdr community ;) 

Would you like to test these patches from Chris and mine / Thanks
that will be very helpful.


-- M --




> 
> Please correct me if I'm wrong.
> 
> Thanks,
> Mauro
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] v4l-utils: fixed dvbv5 vdr format

[VDR User]

> It is broken (see below). Have you ever used dvbv5 tools with vdr format
> output or did you know a "VDR user" who is using dvbv5-scan and not wscan?

In my experience the v4l scanner, wscan, and VDR's internal scanner
has never worked well (for NA). I use nscan, which has easily been the
most successful of the scanners. An additional benefit to nscan is you
only supply a single transponder on the command line and it will
populate a channel list for the entire sat. You don't need to supply
an entire list of transponders to scan.

As far as other VDR users, of which I know many being a long time
user, they tend to use whatever works best for them.

>> Well, the libdvbv5 VDR output support was written aiming VDR version 2.1.6.
>> I've no idea if it works with VDR 1.6.0.

It's not uncommon to find VDR users who run versions as old as 1.6.0*.
Some are completely satisfied leaving their perfectly stable system be
with no concern about updating it.

> Since these bugs are from the beginning and no one has rejected,
> I suppose, that these VDR 1.6.0 users are using wscan and not the
> dvbv5 tools. IMHO the VDR format has never been worked,
> so we can't break backwards compatible ;) and since there is wscan
> widely used by old vdr hats, we do not need to care pre-DVB-[T|S]-2
> formats.

Instead of making that kind of assumption, why not ask VDR users
directly on the VDR mailing list?

> As I said, it might be more helpful to place vdr in a public
> repository and to document channel's format well. It is always a
> hell for me to dig into the vdr sources without a version
> context and an ambiguous documentation ...

There is already a publicly available VDR repository offering the
current stable & developer versions, along with all previous versions:
http://www.tvdr.de/download.htm

> Different formats (compare):
> * http://www.vdr-wiki.de/wiki/index.php/Channels.conf#Unterschiede
> * https://www.linuxtv.org/vdrwiki/index.php/Syntax_of_channels.conf#Differences

It's best to refer to VDRs packaged documention. You can get the
channels.conf format definition with `man 5 vdr`.

> VDR wiki recommends wscan
> * http://www.vdr-wiki.de/wiki/index.php/W_scan

That wiki shouldn't be viewed as a main reference point in general but
especially for scanning. As mentioned earlier, people tend to use what
works for them. In NA/SA nscan tends to be the top choice. Europe/Asia
tends to be other scanners.

> I think, there is much room left to support developers and users
> outside the vdr community ;)
>
> Would you like to test these patches from Chris and mine / Thanks
> that will be very helpful.

I'd recommend posting to the VDR mailing list where you'll find more
people who use and would be affected by these changes. Additionally,
you could inquire at vdr-portal.de, which is one of the most supported
VDR forums for both users and developers.

Re: [PATCH 2/2] v4l-utils: fixed dvbv5 vdr format

[Markus Heiser]

Am 07.09.2016 um 19:59 schrieb VDR User <user.vdr@gmail.com>:

>> It is broken (see below). Have you ever used dvbv5 tools with vdr format
>> output or did you know a "VDR user" who is using dvbv5-scan and not wscan?
> 
> In my experience the v4l scanner, wscan, and VDR's internal scanner
> has never worked well (for NA). I use nscan, which has easily been the
> most successful of the scanners. An additional benefit to nscan is you
> only supply a single transponder on the command line and it will
> populate a channel list for the entire sat. You don't need to supply
> an entire list of transponders to scan.
> 
> As far as other VDR users, of which I know many being a long time
> user, they tend to use whatever works best for them.
> 
>>> Well, the libdvbv5 VDR output support was written aiming VDR version 2.1.6.
>>> I've no idea if it works with VDR 1.6.0.
> 
> It's not uncommon to find VDR users who run versions as old as 1.6.0*.
> Some are completely satisfied leaving their perfectly stable system be
> with no concern about updating it.
> 
>> Since these bugs are from the beginning and no one has rejected,
>> I suppose, that these VDR 1.6.0 users are using wscan and not the
>> dvbv5 tools. IMHO the VDR format has never been worked,
>> so we can't break backwards compatible ;) and since there is wscan
>> widely used by old vdr hats, we do not need to care pre-DVB-[T|S]-2
>> formats.
> 
> Instead of making that kind of assumption, why not ask VDR users
> directly on the VDR mailing list?
> 
>> As I said, it might be more helpful to place vdr in a public
>> repository and to document channel's format well. It is always a
>> hell for me to dig into the vdr sources without a version
>> context and an ambiguous documentation ...
> 
> There is already a publicly available VDR repository offering the
> current stable & developer versions, along with all previous versions:
> http://www.tvdr.de/download.htm

?? these are tarballs, where is the version control system?

> 
>> Different formats (compare):
>> * http://www.vdr-wiki.de/wiki/index.php/Channels.conf#Unterschiede
>> * https://www.linuxtv.org/vdrwiki/index.php/Syntax_of_channels.conf#Differences
> 
> It's best to refer to VDRs packaged documention. You can get the
> channels.conf format definition with `man 5 vdr`.

Good point, but I have only 2.2 installed, so where get I the backward 
informations .. should I extract all theses tarballs and read through
them .. you see my point?


>> VDR wiki recommends wscan
>> * http://www.vdr-wiki.de/wiki/index.php/W_scan
> 
> That wiki shouldn't be viewed as a main reference point in general but
> especially for scanning.

And the main ref is https://www.linuxtv.org ... which is not updated?

> As mentioned earlier, people tend to use what
> works for them. In NA/SA nscan tends to be the top choice. Europe/Asia
> tends to be other scanners.

What I said, nobody use the vdr format of dvbv5-tools, since it 
is broken and now, Chris and I want to fix it.

> 
>> I think, there is much room left to support developers and users
>> outside the vdr community ;)
>> 
>> Would you like to test these patches from Chris and mine / Thanks
>> that will be very helpful.
> 
> I'd recommend posting to the VDR mailing list where you'll find more
> people who use and would be affected by these changes. Additionally,
> you could inquire at vdr-portal.de, which is one of the most supported
> VDR forums for both users and developers.

Chris and I want to patch something in v4l-utils which is broken 
and YOU make the assumption that our patches are not OK ... and now, #
I have to ask someone other on a different projects ML and their portal?

If you have a doubt about the patches from Chris and mine, make a test and
if you see any regression it would be great to post your experience here ...

thanks.

-- Markus --

Re: [PATCH 2/2] v4l-utils: fixed dvbv5 vdr format

[VDR User]

>> There is already a publicly available VDR repository offering the
>> current stable & developer versions, along with all previous versions:
>> http://www.tvdr.de/download.htm
>
> ?? these are tarballs, where is the version control system?

That would be a question for Klaus, the author of VDR. I will say that
whatever system he uses for `version control` has seemed to work fine
in the 12 years or so I've been using VDR. If it's that important to
you to download from git instead, you can use the following mirror:
https://projects.vdr-developer.org/git/vdr.git/

Don't expect that to be of any real advantage however. VDR is not
developed that way.

>> It's best to refer to VDRs packaged documention. You can get the
>> channels.conf format definition with `man 5 vdr`.
>
> Good point, but I have only 2.2 installed, so where get I the backward
> informations .. should I extract all theses tarballs and read through
> them .. you see my point?

That's not necessary. Klaus has designed VDR in such a way that things
don't break when they're updated. You only need to refer to the
documentation of the most recent version.

>> That wiki shouldn't be viewed as a main reference point in general but
>> especially for scanning.
>
> And the main ref is https://www.linuxtv.org ... which is not updated?

That page is certainly outdated and has never been considered a main
reference. People by far have always used vdrportal, another forum
which is now defunct (which focused on NA/SA), and the VDR mailing
list as their main reference points.

> What I said, nobody use the vdr format of dvbv5-tools, since it
> is broken and now, Chris and I want to fix it.

That, and there are other tools that are easier and/or simply work
better for some people (such as nscan).

>> I'd recommend posting to the VDR mailing list where you'll find more
>> people who use and would be affected by these changes. Additionally,
>> you could inquire at vdr-portal.de, which is one of the most supported
>> VDR forums for both users and developers.
>
> Chris and I want to patch something in v4l-utils which is broken
> and YOU make the assumption that our patches are not OK ... and now, #
> I have to ask someone other on a different projects ML and their portal?

I made no claim whether your patches are ok or not. I simply said you
should not intentionally or unnecessarily break backwards
compatibility, and I based that comment on what others have said.
Additionally, if you want to update tools to be more usable why
wouldn't you want input from the very people you hope will use them?!
Suggesting you should inquire on the VDR mailing list is clearly NOT
bad advice.

> If you have a doubt about the patches from Chris and mine, make a test and
> if you see any regression it would be great to post your experience here ...

Since everything I say is met with resistance, I think I'll pass. I
only replied in this thread to help but now I've lost interest. Good
luck with your patch however.

Re: [PATCH 2/2] v4l-utils: fixed dvbv5 vdr format

[Mauro Carvalho Chehab]

Em Wed, 7 Sep 2016 10:59:32 -0700
VDR User <user.vdr@gmail.com> escreveu:

> I use nscan, which has easily been the
> most successful of the scanners. An additional benefit to nscan is you
> only supply a single transponder on the command line and it will
> populate a channel list for the entire sat. You don't need to supply
> an entire list of transponders to scan.

Well, AFAIKT, nowadays, almost all scanners need just one frequency for
satellite and cable to get all channels (and even for some DVB-T/T2
broadcasters, but this is a way more commonly found on DVB-S/S2/C).

If the extra transponders are listed via other NIT tables (it depends on
the broadcaster), an extra parameter is needed (-N, in the case of
dvbv5-scan), as the scan time per channel increases a lot if it has to
wait to receive all NIT tables. So, most scanners default to use just
the main NIT table, providing an option to parse the other ones.


Thanks,
Mauro

[PATCH 0/2] v4l-utils: fixed dvbv5 vdr format

[Markus Heiser]

Hi Mauro, hi Chris

sorry (again) for my late reply [1]. I merged & tested the patches of Chris [2]
and mine [3] fixing the vdr channel format. Since the patches had a conflict,
I had to slightly modify the patch [2] from Chris. --> Chris, I hope this is OK
for you.

I tested DVB-S2 and DVB-T with vdr (2.2.0/2.2.0) / DVB-T(2) has also been tested
by Chris [2].

[1] https://www.mail-archive.com/linux-media@vger.kernel.org/msg102138.html
[2] https://patchwork.linuxtv.org/patch/35803/
[3] https://patchwork.linuxtv.org/patch/36293/

-- Markus --

Chris Mayo (1):
  libdvbv5: Improve vdr format output for DVB-T(2)

Markus Heiser (1):
  v4l-utils: fixed dvbv5 vdr format

 lib/libdvbv5/dvb-vdr-format.c | 56 +++++++++++++++++++++++++++++--------------
 1 file changed, 38 insertions(+), 18 deletions(-)

-- 
2.7.4

[PATCH 1/2] v4l-utils: fixed dvbv5 vdr format

[Markus Heiser]

From: Markus Heiser <markus.heiser@darmarIT.de>

From: Heiser, Markus <markus.heiser@darmarIT.de>

The vdr format was broken, I got '(null)' entries

HD:11494:S1HC23I0M5N1O35:S:(null):22000:5101:5102,5103,5106,5108:0:0:10301:0:0:0:
0-:1----:2--------------:3:4-----:

refering to the VDR Wikis ...

* LinuxTV: http://www.linuxtv.org/vdrwiki/index.php/Syntax_of_channels.conf
* german comunity Wiki: http://www.vdr-wiki.de/wiki/index.php/Channels.conf#Parameter_ab_VDR-1.7.4

There is no field at position 4 / in between "Source" and "SRate" which
might have a value. I suppose the '(null):' is the result of pointing
to *nothing*.

An other mistake is the ending colon (":") at the line. It is not
explicit specified but adding an collon to the end of an channel entry
will prevent players (like mpv or mplayer) from parsing the line (they
will ignore these lines).

At least: generating a channel list with

  dvbv5-scan --output-format=vdr ...

will result in the same defective channel entry, containing "(null):"
and the leading collon ":".

Signed-off-by: Markus Heiser <markus.heiser@darmarIT.de>
---
 lib/libdvbv5/dvb-vdr-format.c | 45 +++++++++++++++++++++++++++++--------------
 1 file changed, 31 insertions(+), 14 deletions(-)

diff --git a/lib/libdvbv5/dvb-vdr-format.c b/lib/libdvbv5/dvb-vdr-format.c
index a4bd26b..ab0e5cf 100644
--- a/lib/libdvbv5/dvb-vdr-format.c
+++ b/lib/libdvbv5/dvb-vdr-format.c
@@ -309,13 +309,14 @@ int dvb_write_format_vdr(const char *fname,
 		fprintf(fp, "%s", entry->channel);
 		if (entry->vchannel)
 			fprintf(fp, ",%s", entry->vchannel);
+		fprintf(fp, ":");
 
 		/*
 		 * Output frequency:
 		 *	in kHz for terrestrial/cable
 		 *	in MHz for satellite
 		 */
-		fprintf(fp, ":%i:", freq / 1000);
+		fprintf(fp, "%i:", freq / 1000);
 
 		/* Output modulation parameters */
 		fmt = &formats[i];
@@ -349,20 +350,30 @@ int dvb_write_format_vdr(const char *fname,
 
 			fprintf(fp, "%s", table->table[data]);
 		}
-
-		/* Output format type */
-		fprintf(fp, ":%s:", id);
+		fprintf(fp, ":");
 
 		/*
-		 * Output satellite location
-		 * FIXME: probably require some adjustments to match the
-		 *	  format expected by VDR.
+		 * Output sources configuration for VDR
+		 *
+		 *   S (satellite) xy.z (orbital position in degrees) E or W (east or west)
+		 *
+		 *   FIXME: in case of ATSC we use "A", this is what w_scan does
 		 */
-		switch(delsys) {
-		case SYS_DVBS:
-		case SYS_DVBS2:
-			fprintf(fp, "%s:", entry->location);
+
+		if (entry->location) {
+			switch(delsys) {
+			case SYS_DVBS:
+			case SYS_DVBS2:
+				fprintf(fp, "%s", entry->location);
+				break;
+			default:
+				fprintf(fp, "%s", id);
+				break;
+			}
+		} else {
+			fprintf(fp, "%s", id);
 		}
+		fprintf(fp, ":");
 
 		/* Output symbol rate */
 		srate = 27500000;
@@ -407,10 +418,16 @@ int dvb_write_format_vdr(const char *fname,
 		/* Output Service ID */
 		fprintf(fp, "%d:", entry->service_id);
 
-		/* Output SID, NID, TID and RID */
-		fprintf(fp, "0:0:0:");
+		/* Output Network ID */
+		fprintf(fp, "0:");
 
-		fprintf(fp, "\n");
+		/* Output Transport Stream ID */
+		fprintf(fp, "0:");
+
+		/* Output Radio ID
+		 * this is the last entry, tagged bei a new line (not a colon!)
+		 */
+		fprintf(fp, "0\n");
 		line++;
 	};
 	fclose (fp);
-- 
2.7.4

[PATCH 2/2] libdvbv5: Improve vdr format output for DVB-T(2)

[Markus Heiser]

From: Chris Mayo <aklhfex@gmail.com>

Before (1.10.1):
BBC TWO:498000:S0B8C23D12I999M64T8G32Y0:T:27500:201:202,206:0:0:4287:0:0:0
BBC TWO HD:474167:S1B8C23D999I999M256T32G128Y0:T:27500:101:102,106:0:0:17472:0:0:0
After:
BBC TWO:498000:B8C23D12G32I999M64S0T8Y0:T:0:201:202,206:0:0:4287:0:0:0
BBC TWO HD:474167:B8C23D999G128I999M256S1T32Y0:T:27500:101:102,106:0:0:17472:0:0:0

channels.conf (vdr 2.2.0):
BBC TWO:498000000:B8C23D12G32M64S0T8Y0:T:0:201=2:202=eng@3,206=eng@3:0;205=eng:0:4287:9018:4163:0
BBC TWO HD:474166670:C23G128M256P0Q16436S1T32X1Y0:T:27500:101=27:102=eng@17,106=eng@17:0;105=eng:0:17472:9018:16515:0

Signed-off-by: Chris Mayo <aklhfex@gmail.com>
---
 lib/libdvbv5/dvb-vdr-format.c | 11 +++++++----
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/lib/libdvbv5/dvb-vdr-format.c b/lib/libdvbv5/dvb-vdr-format.c
index ab0e5cf..3d09237 100644
--- a/lib/libdvbv5/dvb-vdr-format.c
+++ b/lib/libdvbv5/dvb-vdr-format.c
@@ -198,26 +198,26 @@ static const struct dvb_parse_table sys_dvbs2_table[] = {
 };
 
 static const struct dvb_parse_table sys_dvbt_table[] = {
-	{ DTV_DELIVERY_SYSTEM, PTABLE(vdr_parse_delivery_system) },
 	{ DTV_BANDWIDTH_HZ, PTABLE(vdr_parse_bandwidth) },
 	{ DTV_CODE_RATE_HP, PTABLE(vdr_parse_code_rate_hp) },
 	{ DTV_CODE_RATE_LP, PTABLE(vdr_parse_code_rate_lp) },
+	{ DTV_GUARD_INTERVAL, PTABLE(vdr_parse_guard_interval) },
 	{ DTV_INVERSION, PTABLE(vdr_parse_inversion) },
 	{ DTV_MODULATION, PTABLE(vdr_parse_modulation) },
+	{ DTV_DELIVERY_SYSTEM, PTABLE(vdr_parse_delivery_system) },
 	{ DTV_TRANSMISSION_MODE, PTABLE(vdr_parse_trans_mode) },
-	{ DTV_GUARD_INTERVAL, PTABLE(vdr_parse_guard_interval) },
 	{ DTV_HIERARCHY, PTABLE(vdr_parse_hierarchy) },
 };
 
 static const struct dvb_parse_table sys_dvbt2_table[] = {
-	{ DTV_DELIVERY_SYSTEM, PTABLE(vdr_parse_delivery_system) },
 	{ DTV_BANDWIDTH_HZ, PTABLE(vdr_parse_bandwidth) },
 	{ DTV_CODE_RATE_HP, PTABLE(vdr_parse_code_rate_hp) },
 	{ DTV_CODE_RATE_LP, PTABLE(vdr_parse_code_rate_lp) },
+	{ DTV_GUARD_INTERVAL, PTABLE(vdr_parse_guard_interval) },
 	{ DTV_INVERSION, PTABLE(vdr_parse_inversion) },
 	{ DTV_MODULATION, PTABLE(vdr_parse_modulation) },
+	{ DTV_DELIVERY_SYSTEM, PTABLE(vdr_parse_delivery_system) },
 	{ DTV_TRANSMISSION_MODE, PTABLE(vdr_parse_trans_mode) },
-	{ DTV_GUARD_INTERVAL, PTABLE(vdr_parse_guard_interval) },
 	{ DTV_HIERARCHY, PTABLE(vdr_parse_hierarchy) },
 	/* DVB-T2 specifics */
 	{ DTV_STREAM_ID, NULL, },
@@ -378,6 +378,9 @@ int dvb_write_format_vdr(const char *fname,
 		/* Output symbol rate */
 		srate = 27500000;
 		switch(delsys) {
+		case SYS_DVBT:
+			srate = 0;
+			break;
 		case SYS_DVBS:
 		case SYS_DVBS2:
 		case SYS_DVBC_ANNEX_A:
-- 
2.7.4