Hi.
For certain situations, it'd be great to exclude some channels from the automatic channel update. For example, when one has entered a channel manually which broadcasts wrong channel informations. With the next channel update, all is overwritten. So one has to either completely disable the automatic updates or live without the channel for the time being.
I had just a quick look over the vdr source and figured it wouldn't be too hard to come up with a patch to support something like this I guess. So I wanted to ask if this new feature would be considered ok for inclusion into vdr-1.7.x or if there are reasons against it? Otherwise I would put it on my todo list and get to it when I get some time... if no one else does it in the meantime that is. :-)
Best regards, matthias.
Hi.
On Tuesday 27 January 2009 10:37:24 Klaus Schmidinger wrote:
Have you tried contacting the broadcaster about this? Such problems should be fixed at the root ;-)
I agree. There is just one exception: it's done intentionally by the broadcaster to limit reception to certain boxes. :-} For those cases it would be nice to exclude those channels from the automatic update process.
Best regards, matthias.
Hi.
On Tuesday 27 January 2009 11:28:12 Klaus Schmidinger wrote:
Do you have a complete channels.conf entry for this one?
This should work, according to different posts on this list. I haven't yet tested it myself because ITV HD broadcasts only selected ITV shows/movies and is thus not 24/7 on the air and I just haven't gotten around to it yet:
ITV HD;BSkyB:11426:hC23M2O0S0:S28.2E:27500:3401:0;3402=eng:0:0:10510:0:0:0
Best regards, matthias.
On 27.01.2009 11:54, Matthias Dahl wrote:
When I tune to that transponder, I only get
Brit Shorts;Arqiva:11426:hC23M2O0S0:S28.2E:27500:1451=2:1452=eng:1455:0:3846:59:2315:0 HINRG LOWNRG;Arqiva:11426:hC23M2O0S0:S28.2E:27500:0:641:0:0:55213:59:2315:0 WELL CLASS;Arqiva:11426:hC23M2O0S0:S28.2E:27500:0:643:0:0:55214:59:2315:0 GROOVE;Arqiva:11426:hC23M2O0S0:S28.2E:27500:0:645:0:0:55215:59:2315:0 -;Arqiva:11426:hC23M2O0S0:S28.2E:27500:0:646:0:0:55216:59:2315:0 RADIO SHEPHERD;Arqiva:11426:hC23M2O0S0:S28.2E:27500:0:4101:0:0:10551:59:2315:0
There is no channel with an unknown stream type announced here.
Maybe all it would take is to add 0x0B to the switch in cPatFilter::Process(), as in:
for (SI::Loop::Iterator it; pmt.streamLoop.getNext(stream, it); ) { switch (stream.getStreamType()) { case 1: // STREAMTYPE_11172_VIDEO case 2: // STREAMTYPE_13818_VIDEO case 0x0B: // MPEG4 XXX case 0x1B: // MPEG4 Vpid = stream.getPid();
Can you try that?
Klaus
Hi.
On Wednesday 28 January 2009 17:45:49 Klaus Schmidinger wrote:
When I tune to that transponder, I only get
Please try...
ITV HD;BSkyB:11427:hC23M2O0S0:S28.2E:27500:3401=2:3402:0:0:10510:0:0:0
Works fine here. You will get a test picture.
Maybe all it would take is to add 0x0B to the switch in cPatFilter::Process(), as in:
Nope vdr changes the correct channel data to:
ITVHD;BSkyB:11427:hC23M2O0S0:S28.2E:27500:3404+3401=11:0;3402=eng:0:0:10510:0:0:0
Without adding 0x0B it's being changed to:
ITV HD;BSkyB:11427:hC23M2O0S0:S28.2E:27500:0:0;3402=eng:0:0:10510:0:0:0
Hope that helps. Thanks for taking the time by the way. :-)
Best regards, matthias.
On 28.01.2009 21:51, Matthias Dahl wrote:
I doubt that '2' is the "correct" video stream type, because even if I disable the automatic channel update and use the above channel data, VDR can't find any frame borders in that stream.
The video stream is announced as 0x0B, which, as far as I have seen in some Google searches, means H.222. So instead of "clamping" the video type to 2 (i.e. MPEG2) it would be better to find out what exactly H.222 is and how to handle it in cPatFilter::Process(), cFrameDetector::Analyze() and cPatPmtParser::ParsePmt(). Otherwise, while you may even get a picture in live mode, VDR won't be able to record anything.
I'll have to leave this to somebody with more knowledge about H.222, though...
Klaus
Hi Klaus.
On Friday 30 January 2009 16:33:48 Klaus Schmidinger wrote:
The video stream is announced as 0x0B, which, as far as I have seen in some Google searches, means H.222.
That's right. But that's just to confuse non-official boxes. The stream is just a plain and simple H.264 one. There is no H.222 being transmitted. And like I said that's done on purpose. :-) So you won't need any H.222 knowledge, it's just about stopping vdr from being mislead. ;)
Best regards, matthias.
On Tue, 2009-01-27 at 10:34 +0100, Matthias Dahl wrote:
I deal with this type of problem by having two copies of the channel, with one with rid=1. The one with rid=0 will be automatically updated to incorrect values, while the one with rid=1 will not be updated, so it can be tuned as needed.
On Wed, 2009-01-28 at 08:39 +0200, Alex Betis wrote:
Duplicates would be removed, but if one channel has rid=1 and one has rid=0 they are not exact duplicates.
From man 5 vdr:
RID The Radio ID of this channel (typically 0, may be used to dis- tinguish channels where NID, TID and SID are all equal).
The fields are separated by : and the last one is the rid.
-
Alex Betis -
Klaus Schmidinger -
Malcolm Caldwell -
Matthias Dahl