Re: [vdr] [ANNOUNCE] vdr-xine-0.9.0 plugin
Hi, Reinhard Nissl schrieb: > Lauri Tischler schrieb: >> Darren Salt wrote: >>> I demand that Lauri Tischler may or may not have written... >>> Reinhard Nissl wrote: > after being away 7 month from VDR development I'm pleased to announce > release 0.9.0. You can find it on my homepage as usual: Wonder where can I find keybindings of vdr-xine. It seems that keypadkeys in general work (keypad arrows, keypad enter) but where the hell are colorkeys (red, green, yellow, green) ? Started VDR with -P 'xine -r' >>> They're wherever the rest of the key bindings are for whichever xine-lib >>> front end you happen to be using. >> Sort of assumed that they would be defined in VDR's remote.conf file, >> where the Lord intended them to be :) > > The problem was that xine-ui didn't provide enough keys to cover > all VDR functionality. That's why we introduced further VDR > specific events. But they are not bound to any key by default. So it made no sense to go through the remote learning mode if these additional keys had to be bound in xine-ui anyway. > See MANUAL for additional information about the keys. Bye. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:rni...@gmx.de ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] vdr-xine-0.9.0 plugin
Hi, Lauri Tischler schrieb: > Darren Salt wrote: >> I demand that Lauri Tischler may or may not have written... >> >>> Reinhard Nissl wrote: after being away 7 month from VDR development I'm pleased to announce release 0.9.0. You can find it on my homepage as usual: >>> Wonder where can I find keybindings of vdr-xine. >>> It seems that keypadkeys in general work (keypad arrows, keypad enter) but >>> where the hell are colorkeys (red, green, yellow, green) ? >>> Started VDR with -P 'xine -r' >> They're wherever the rest of the key bindings are for whichever xine-lib >> front end you happen to be using. > > Sort of assumed that they would be defined in VDR's remote.conf file, > where the Lord intended them to be :) The problem was that xine-ui didn't provide enough keys to cover all VDR functionality. That's why we introduced further VDR specific events. But they are not bound to any key by default. See MANUAL for additional information about the keys. Bye. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:rni...@gmx.de ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Small VDR-streamdev patch for Popcorn Hour NMT
Hi, I want to ask you about actual state of streamdev-server for NMT Popcornhour (A-110). I have vdr-1.7.0 and streamdev-0.3.4 with patch patpmt_first_v5.diff. Streamimg to Popcornhour is practically O.K. (without image failure), but sometimes popcornhour freezes and hard restart is needed. And sometimes it takes a long time at buffering (between select channel and start playing). VLC clients works fine. I want to ask you about some additional patches for streamdev or some advices for solve this issues. Thank you Regards Tomas S. 2008/11/20 : >> Can you post a quick review of how using popcorn clients with VDR >> works, with screenshots etc? > > Better screenshots - What you get with PCH > > http://myhdworld.multiply.com/photos/album/2/POPCORN_HOUR_Screenshots > > ___ > vdr mailing list > vdr@linuxtv.org > http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr > > -- Tomáš Skočdopole Manager IT Mobil: +420 606 554 676 ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Disabling EPG update from air or shift it in time
On Sun, Feb 1, 2009 at 9:03 PM, user.vdr wrote: > > The use is simple, show more information for programs. Many sities of the > > channels provide that information already, including pictures and movie > > trailers. There is also IMDB that can be used. As an example, MythTv has > a > > nice use of IMDB for stored movies. > > Same can be implemented for live movies as well. > > I always thought it would be cool if VDR was able to pull a > poster/cover and IMDB summary of movies but I doubt we'd see that in > vdr core. A plugin maybe. I'd think a cache somewhere would be far > more effecient then using epg.data for that though. That's also an option. I had a thought of saving description in HTML format, so it will be easy to design the output. > > > ___ > vdr mailing list > vdr@linuxtv.org > http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr > ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Disabling EPG update from air or shift it in time
> The use is simple, show more information for programs. Many sities of the > channels provide that information already, including pictures and movie > trailers. There is also IMDB that can be used. As an example, MythTv has a > nice use of IMDB for stored movies. > Same can be implemented for live movies as well. I always thought it would be cool if VDR was able to pull a poster/cover and IMDB summary of movies but I doubt we'd see that in vdr core. A plugin maybe. I'd think a cache somewhere would be far more effecient then using epg.data for that though. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Disabling EPG update from air or shift it in time
On Sun, Feb 1, 2009 at 7:11 PM, user.vdr wrote: > On Sun, Feb 1, 2009 at 6:10 AM, Alex Betis wrote: > > By the way, if we already discussing EPG... > > I think the epg.data is very limited. I would like to see an option to > > integrate pictures or even movies in that file. > > Ofcause I could place tags in description and have a plugin that could > parse > > those tags and show the pictures stored somewhere else, but I think it > > should all be located in the same place. > > I can't imagine why you would want to mix movies and epg data > together. The size of that file would grow tremendously which I > assume would have nothing but adverse affects. I don't really see the > point of pictures either. Can you elaborate on what purpose this > would serve? Well, I agree that storing meida files separately would be wiser, but being able to point to those files from within the EPG.data file without abusing description or other fields with tags-reinvention will be helpful. The use is simple, show more information for programs. Many sities of the channels provide that information already, including pictures and movie trailers. There is also IMDB that can be used. As an example, MythTv has a nice use of IMDB for stored movies. Same can be implemented for live movies as well. > > > ___ > vdr mailing list > vdr@linuxtv.org > http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr > ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] no channel update for certain channels
On Sun, Feb 01, 2009 at 05:06:11PM +0100, Klaus Schmidinger wrote: > On 31.01.2009 07:47, Patrick Rother wrote: > > On Fri, Jan 30, 2009 at 05:09:24PM +0100, Klaus Schmidinger wrote: > >> On 28.01.2009 19:33, Patrick Rother wrote: > >>> I am currently suffering from events like this: > >>> > >>> Jan 28 05:50:53 vdr vdr: [15232] changing pids of channel 84 from > >>> 2815+2815:2816=deu:0:32 to 2815+2815:2816=deu:0:0 > >>> Jan 28 05:50:54 vdr vdr: [15232] changing pids of channel 83 from > >>> 1535+1535:1536=deu:0:32 to 1535+1535:1536=deu:0:0 > >>> Jan 28 05:50:54 vdr vdr: [15232] changing pids of channel 82 from > >>> 1023+1023:1024=deu:0:32 to 1023+1023:1024=deu:0:0 > >>> Jan 28 05:50:54 vdr vdr: [15232] changing pids of channel 85 from > >>> 3071+3071:3072=deu:0:32 to 3071+3071:3072=deu:0:0 > >>> Jan 28 05:50:55 vdr vdr: [15232] changing pids of channel 81 from > >>> 1791+1791:1792=deu:0:32 to 1791+1791:1792=deu:0:0 > >>> Jan 28 05:50:55 vdr vdr: [15224] stopping recording due to modification > >>> of channel 83 > >>> > >>> Jan 28 05:52:45 vdr vdr: [15232] changing pids of channel 84 from > >>> 2815+2815:2816=deu:0:0 to 2815+2815:2816=deu:0:32 > >>> Jan 28 05:52:45 vdr vdr: [15232] changing pids of channel 83 from > >>> 1535+1535:1536=deu:0:0 to 1535+1535:1536=deu:0:32 > >>> Jan 28 05:52:45 vdr vdr: [15232] changing pids of channel 82 from > >>> 1023+1023:1024=deu:0:0 to 1023+1023:1024=deu:0:32 > >>> Jan 28 05:52:45 vdr vdr: [15232] changing pids of channel 85 from > >>> 3071+3071:3072=deu:0:0 to 3071+3071:3072=deu:0:32 > >>> Jan 28 05:52:45 vdr vdr: [15232] changing pids of channel 81 from > >>> 1791+1791:1792=deu:0:0 to 1791+1791:1792=deu:0:32 > >>> Jan 28 05:52:45 vdr vdr: [15232] changing pids of channel 75 from > >>> 2559+2559:2560=deu:0:0 to 2559+2559:2560=deu:0:32 > >>> Jan 28 05:52:45 vdr vdr: [15224] stopping recording due to modification > >>> of channel 83 > >>> > >>> Recording gets heavily fragmented and unviewable. > >> Can you post the channels.conf entry of a channel where this happens? > > > > These are 81 .. 85: > > > > BEATE-UHSE.TV,B-UHSE;PREMIERE:11758:hC34:S19.2E:27500:1791:1792=deu:32:1702,1722,1837,1833,1834,9C4,B00,D05:21:133:17:0 > > DISCOVERY > > CHANNEL,DISCOVERY;PREMIERE:11758:hC34:S19.2E:27500:1023:1024=deu:32:1702,1722,1837,1833,1834,9C4,B00,D05:14:133:17:0 > > DISCOVERY > > GESCHICHTE,GESCHICHTE;PREMIERE:11758:hC34:S19.2E:27500:1535:1536=deu:32:1702,1722,1837,1833,1834,9C4,B00,D05:13:133:17:0 > > ANIMAL > > PLANET,ANIMAL;PREMIERE:11758:hC34:S19.2E:27500:2815:2816=deu:32:1702,1722,1837,1833,1834,9C4,B00,D05:12:133:17:0 > > FOCUS GESUNDHEIT,FOCUS > > G;PREMIERE:11758:hC34:S19.2E:27500:3071:3072=deu:32:1702,1722,1837,1833,1834,9C4,B00,D05:15:133:17:0 > > I can't see any permanently changing pids on that transponder. > When you say "Recording gets heavily fragmented and unviewable" > I would assume that the pids change every few minutes - but I haven't > seen that yet. > Does this happen only at certain times of day? > Or was it maybe a glitch on the provider side? It doesn't look like a glitch. If nobody else is seeing this, I have to assume that my CAM stuff is more unstable than I am aware of. Anyway I'd like to repeat my suggestion that recordings shall only be interupted when relevant changes have been made to the PIDs. Please include this to your todo list, maybe at the lower half. ;) Thank you. Jan 22 05:02:21 vdr vdr: [23430] changing pids of channel 53 from 225+225:226=deu:0:231 to 225+225:226=deu:0:0 Jan 22 05:02:34 vdr vdr: [23430] changing pids of channel 53 from 225+225:226=deu:0:0 to 225+225:226=deu:0:231 Jan 24 20:05:14 vdr vdr: [23823] changing pids of channel 83 from 1535+1535:1536=deu:0:32 to 1535+1535:1536=deu:0:0 Jan 24 20:05:14 vdr vdr: [23823] changing pids of channel 82 from 1023+1023:1024=deu:0:32 to 1023+1023:1024=deu:0:0 Jan 24 20:05:14 vdr vdr: [23823] changing pids of channel 85 from 3071+3071:3072=deu:0:32 to 3071+3071:3072=deu:0:0 Jan 24 20:05:15 vdr vdr: [23823] changing pids of channel 81 from 1791+1791:1792=deu:0:32 to 1791+1791:1792=deu:0:0 Jan 24 20:05:15 vdr vdr: [23823] changing pids of channel 75 from 2559+2559:2560=deu:0:32 to 2559+2559:2560=deu:0:0 Jan 24 20:05:16 vdr vdr: [23823] changing pids of channel 84 from 2815+2815:2816=deu:0:32 to 2815+2815:2816=deu:0:0 Jan 24 20:27:48 vdr vdr: [23820] changing pids of channel 83 from 1535+1535:1536=deu:0:0 to 1535+1535:1536=deu:0:32 Jan 24 20:27:49 vdr vdr: [23820] changing pids of channel 82 from 1023+1023:1024=deu:0:0 to 1023+1023:1024=deu:0:32 Jan 24 20:27:49 vdr vdr: [23820] changing pids of channel 85 from 3071+3071:3072=deu:0:0 to 3071+3071:3072=deu:0:32 Jan 24 20:27:49 vdr vdr: [23820] changing pids of channel 81 from 1791+1791:1792=deu:0:0 to 1791+1791:1792=deu:0:32 Jan 24 20:27:50 vdr vdr: [23820] changing pids of channel 75 from 2559+2559:2560=deu:0:0 to 2559+2559:2560=deu:0:32 Jan 24 20:27:51 vdr vdr: [23820] changing pids of channel 84 from 2815+
Re: [vdr] Disabling EPG update from air or shift it in time
On Sun, Feb 1, 2009 at 6:10 AM, Alex Betis wrote: > By the way, if we already discussing EPG... > I think the epg.data is very limited. I would like to see an option to > integrate pictures or even movies in that file. > Ofcause I could place tags in description and have a plugin that could parse > those tags and show the pictures stored somewhere else, but I think it > should all be located in the same place. I can't imagine why you would want to mix movies and epg data together. The size of that file would grow tremendously which I assume would have nothing but adverse affects. I don't really see the point of pictures either. Can you elaborate on what purpose this would serve? ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] no channel update for certain channels
On 31.01.2009 07:47, Patrick Rother wrote: > On Fri, Jan 30, 2009 at 05:09:24PM +0100, Klaus Schmidinger wrote: >> On 28.01.2009 19:33, Patrick Rother wrote: >>> I am currently suffering from events like this: >>> >>> Jan 28 05:50:53 vdr vdr: [15232] changing pids of channel 84 from >>> 2815+2815:2816=deu:0:32 to 2815+2815:2816=deu:0:0 >>> Jan 28 05:50:54 vdr vdr: [15232] changing pids of channel 83 from >>> 1535+1535:1536=deu:0:32 to 1535+1535:1536=deu:0:0 >>> Jan 28 05:50:54 vdr vdr: [15232] changing pids of channel 82 from >>> 1023+1023:1024=deu:0:32 to 1023+1023:1024=deu:0:0 >>> Jan 28 05:50:54 vdr vdr: [15232] changing pids of channel 85 from >>> 3071+3071:3072=deu:0:32 to 3071+3071:3072=deu:0:0 >>> Jan 28 05:50:55 vdr vdr: [15232] changing pids of channel 81 from >>> 1791+1791:1792=deu:0:32 to 1791+1791:1792=deu:0:0 >>> Jan 28 05:50:55 vdr vdr: [15224] stopping recording due to modification of >>> channel 83 >>> >>> Jan 28 05:52:45 vdr vdr: [15232] changing pids of channel 84 from >>> 2815+2815:2816=deu:0:0 to 2815+2815:2816=deu:0:32 >>> Jan 28 05:52:45 vdr vdr: [15232] changing pids of channel 83 from >>> 1535+1535:1536=deu:0:0 to 1535+1535:1536=deu:0:32 >>> Jan 28 05:52:45 vdr vdr: [15232] changing pids of channel 82 from >>> 1023+1023:1024=deu:0:0 to 1023+1023:1024=deu:0:32 >>> Jan 28 05:52:45 vdr vdr: [15232] changing pids of channel 85 from >>> 3071+3071:3072=deu:0:0 to 3071+3071:3072=deu:0:32 >>> Jan 28 05:52:45 vdr vdr: [15232] changing pids of channel 81 from >>> 1791+1791:1792=deu:0:0 to 1791+1791:1792=deu:0:32 >>> Jan 28 05:52:45 vdr vdr: [15232] changing pids of channel 75 from >>> 2559+2559:2560=deu:0:0 to 2559+2559:2560=deu:0:32 >>> Jan 28 05:52:45 vdr vdr: [15224] stopping recording due to modification of >>> channel 83 >>> >>> Recording gets heavily fragmented and unviewable. >> Can you post the channels.conf entry of a channel where this happens? > > These are 81 .. 85: > > BEATE-UHSE.TV,B-UHSE;PREMIERE:11758:hC34:S19.2E:27500:1791:1792=deu:32:1702,1722,1837,1833,1834,9C4,B00,D05:21:133:17:0 > DISCOVERY > CHANNEL,DISCOVERY;PREMIERE:11758:hC34:S19.2E:27500:1023:1024=deu:32:1702,1722,1837,1833,1834,9C4,B00,D05:14:133:17:0 > DISCOVERY > GESCHICHTE,GESCHICHTE;PREMIERE:11758:hC34:S19.2E:27500:1535:1536=deu:32:1702,1722,1837,1833,1834,9C4,B00,D05:13:133:17:0 > ANIMAL > PLANET,ANIMAL;PREMIERE:11758:hC34:S19.2E:27500:2815:2816=deu:32:1702,1722,1837,1833,1834,9C4,B00,D05:12:133:17:0 > FOCUS GESUNDHEIT,FOCUS > G;PREMIERE:11758:hC34:S19.2E:27500:3071:3072=deu:32:1702,1722,1837,1833,1834,9C4,B00,D05:15:133:17:0 I can't see any permanently changing pids on that transponder. When you say "Recording gets heavily fragmented and unviewable" I would assume that the pids change every few minutes - but I haven't seen that yet. Does this happen only at certain times of day? Or was it maybe a glitch on the provider side? Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] eHD and how subtitle timing start work
On Sun, Feb 01, 2009 at 10:41:32AM +0100, Klaus Schmidinger wrote: > Efforts should go into making the devices provide the actual PTS of > the most recently presented frame - anything else is just trying to cure > symptoms and not a real solution. The DeCypher delivers an STC over shared memory, there's also the GetSTC-method implemented. Currently I just don't know why it works only when the mainboard sound is enabled... -- Georg Acher, ac...@in.tum.de http://www.lrr.in.tum.de/~acher "Oh no, not again !" The bowl of petunias ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Disabling EPG update from air or shift it in time
On Sun, Feb 1, 2009 at 11:58 AM, Klaus Schmidinger < klaus.schmidin...@cadsoft.de> wrote: > On 31.01.2009 11:51, Alex Betis wrote: > > ... [ EPG for time shifted channels ] ... > > > > As an example, 75.0E has NTV and NTV-2, or DTV and DTV-2 > > > > Please post the complete channels.conf entries of these channels. > > > > Here it is: > > > > This couple looks like sending the EPG shifted correctly: > > HTB;GTSS:12640:vM2O0S0:S75.0E:22000:503:504,505:0:0:100:58:103:0 > > HTB-3;GTSS:12640:vM2O0S0:S75.0E:22000:501:502:0:0:500:58:103:0 > > > > This couple looks like not shifting the EPG at all: > > DTV-0;GTSS:12640:vM2O0S0:S75.0E:22000:201:202:0:0:200:58:103:0 > > DTV-2;GTSS:12518:vC78M2O0S0:S75.0E:22000:701:702=eng:0:0:504:86:100:0 > > > > This one looks like shifting the EPG in wrong direction (its scrambled, > > but I've compared the content of EPG.data with official site): > > CTC+7;CTC Media:12640:vM2O0S0:S75.0E:22000:401:402:0:2600:400:58:103:0 > > Looks like you got all sorts of variations: some do it right, some do > it wrong, and some don't do it at all ;-) > > Since every channel has its own SID, it also has its own EPG data, which > logically needs to correspond to the times the programmes are actually > broadcast. So far I don't se any proper solution than having the providers > fix this. As I wrote, those channels started transmitting EPG not long ago, so I hope the issue will be fixed one day. I agree that its probably a provider fault. Anyway, I think a configuration that will allow disabling EPG from DVB might be useful for those who retrieve all EPG data from the net, that in most cases contains more data than transmitted by the provider. By the way, if we already discussing EPG... I think the epg.data is very limited. I would like to see an option to integrate pictures or even movies in that file. Ofcause I could place tags in description and have a plugin that could parse those tags and show the pictures stored somewhere else, but I think it should all be located in the same place. > > > > > > I use s script that updates those channels from internet, so > > I don't > > > > mind to disable EPG update received on the channel. > > > > > > You can set the "table id" of these events to 0 (see man 5 > vdr). > > > > > > The problem is not with overwriting the data, but appending the > wrong > > > data for that channel. > > > I see both script inserted and DVB transmitted data that are > differ. > > > > > > Is there such "table id" setting per channel and not per EPG entry? > > > > No, this is per EPG event, not per channel. > > > > I'll probably patch the code for now to disable the received EPG > processing. > > > > But as I see it, there is an issue even when the EPG is correctly > > transmitted by a provider, for example: > > What VDR will do when there is a change in the program and there is a > > delay in transmission of some program? > > Will it have 2 entries for the same program or update the previous entry? > > VDR will update/replace all EPG entries according to the new tables. > There shouldn't be double entries. > > > If EPG time is in UTC, than that's a mystery how should those coupled > > channels be handled. > > As I said, each channel has its own SID, and therefore its very own > EPG data, which needs to be adjusted to the actual broadcast times > of that channel. > > As an example: if you have two channels, say ABC and ABC+1, where ABC+1 > broadcasts everything one hour later that ABC, then if the air time of > event XY is 8:00 for channel ABC, it needs to be 9:00 for channel ABC+1. > All times given in UTC, of course. > > Klaus > > ___ > vdr mailing list > vdr@linuxtv.org > http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr > ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Disabling EPG update from air or shift it in time
On 31.01.2009 11:51, Alex Betis wrote: > ... [ EPG for time shifted channels ] ... > > As an example, 75.0E has NTV and NTV-2, or DTV and DTV-2 > > Please post the complete channels.conf entries of these channels. > > Here it is: > > This couple looks like sending the EPG shifted correctly: > HTB;GTSS:12640:vM2O0S0:S75.0E:22000:503:504,505:0:0:100:58:103:0 > HTB-3;GTSS:12640:vM2O0S0:S75.0E:22000:501:502:0:0:500:58:103:0 > > This couple looks like not shifting the EPG at all: > DTV-0;GTSS:12640:vM2O0S0:S75.0E:22000:201:202:0:0:200:58:103:0 > DTV-2;GTSS:12518:vC78M2O0S0:S75.0E:22000:701:702=eng:0:0:504:86:100:0 > > This one looks like shifting the EPG in wrong direction (its scrambled, > but I've compared the content of EPG.data with official site): > CTC+7;CTC Media:12640:vM2O0S0:S75.0E:22000:401:402:0:2600:400:58:103:0 Looks like you got all sorts of variations: some do it right, some do it wrong, and some don't do it at all ;-) Since every channel has its own SID, it also has its own EPG data, which logically needs to correspond to the times the programmes are actually broadcast. So far I don't se any proper solution than having the providers fix this. > > > I use s script that updates those channels from internet, so > I don't > > > mind to disable EPG update received on the channel. > > > > You can set the "table id" of these events to 0 (see man 5 vdr). > > > > The problem is not with overwriting the data, but appending the wrong > > data for that channel. > > I see both script inserted and DVB transmitted data that are differ. > > > > Is there such "table id" setting per channel and not per EPG entry? > > No, this is per EPG event, not per channel. > > I'll probably patch the code for now to disable the received EPG processing. > > But as I see it, there is an issue even when the EPG is correctly > transmitted by a provider, for example: > What VDR will do when there is a change in the program and there is a > delay in transmission of some program? > Will it have 2 entries for the same program or update the previous entry? VDR will update/replace all EPG entries according to the new tables. There shouldn't be double entries. > If EPG time is in UTC, than that's a mystery how should those coupled > channels be handled. As I said, each channel has its own SID, and therefore its very own EPG data, which needs to be adjusted to the actual broadcast times of that channel. As an example: if you have two channels, say ABC and ABC+1, where ABC+1 broadcasts everything one hour later that ABC, then if the air time of event XY is 8:00 for channel ABC, it needs to be 9:00 for channel ABC+1. All times given in UTC, of course. Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] eHD and how subtitle timing start work
On 01.02.2009 09:52, Vesa wrote: > Klaus Schmidinger wrote: >> Why can't the eHD plugin just deliver a correct STC? >> It doesn't even have to be a "real" STC - the PTS of the most >> recently presented frame would do just fine. >> > I do not know. My comment has based on only observation and > reelbox-plugin use. I can assume that some part of issue is buffering > start, system needs some time to fill buffer with data and before that > you can not get real delay value. > > One item for these "long buffer" output devices is fast forward and > rewind. It is quit difficult to skip commersials or find start of the > program with 6s delay on video path. When user see video and press play, > VDR is delay*speed over that spot. Vdr should compensate this and jump > where user thinks to be on video. Efforts should go into making the devices provide the actual PTS of the most recently presented frame - anything else is just trying to cure symptoms and not a real solution. Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] eHD and how subtitle timing start work
Klaus Schmidinger wrote: > Why can't the eHD plugin just deliver a correct STC? > It doesn't even have to be a "real" STC - the PTS of the most > recently presented frame would do just fine. > I do not know. My comment has based on only observation and reelbox-plugin use. I can assume that some part of issue is buffering start, system needs some time to fill buffer with data and before that you can not get real delay value. One item for these "long buffer" output devices is fast forward and rewind. It is quit difficult to skip commersials or find start of the program with 6s delay on video path. When user see video and press play, VDR is delay*speed over that spot. Vdr should compensate this and jump where user thinks to be on video. -- Vesa ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdpau ouput to pal tv
On 1 Feb 2009, at 18:12, Torgeir Veimo wrote: > I am having some issues trying out vdpau with an nvidia card on the > svideo output; I'm getting testing. Hmm hangover day... Was going to say I'm getting tearing. -- Torgeir Veimo torg...@pobox.com ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] vdpau ouput to pal tv
I am having some issues trying out vdpau with an nvidia card on the svideo output; I'm getting testing. Does anyone have any tips on how to fix this? It seems to be a persistent problem for a number of users, yet some people claim to have fixed it. -- Torgeir Veimo torg...@pobox.com ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
