Em Mon, 5 Sep 2016 15:13:04 +0200 Markus Heiser <markus.heiser@xxxxxxxxxxx> 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@xxxxxxxxxxxxxxxx>: > > > Em Wed, 24 Aug 2016 11:49:27 -0300 > > Mauro Carvalho Chehab <mchehab@xxxxxxxxxxxxxxxx> escreveu: > > > >> Hi Markus, > >> > >> Em Wed, 10 Aug 2016 11:52:19 +0200 > >> Markus Heiser <markus.heiser@xxxxxxxxxxx> escreveu: > >> > >>> From: Markus Heiser <markus.heiser@xxxxxxxxxxx> > >>> > >>> From: Heiser, Markus <markus.heiser@xxxxxxxxxxx> > >>> > >>> 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
