| Message ID | 1470822739-29519-3-git-send-email-markus.heiser@darmarit.de (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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 ---- 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
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 ---- 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
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 -- 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
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 -- 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
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 -- 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
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 -- 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
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 -- 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
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 -- 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
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. -- 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
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 -- 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
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 -- 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
> 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. -- 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
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 -- -- 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
>> 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. -- 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
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 -- 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
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(-)
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);