Re: [vdr] Technotrend DVB-C 1501
Hi, after searching a while i found it. With vdr-version 1.7.8 the cvs version of xineliboutput has to be used. Now everything works fine. 2010/10/15 Rainer Blickle : > Hi, > > i have a Technotrend DVB-C 1501 device (I guess the chip is the > saa7146). With this card i cannot view a recording or live tv with the > xineliboutput. live tv or a recording done by a pvrinput device works > fine. > > Does anyone has a clue why the dvb-c device doesn't work with xineliboutput ? > > I have an ubuntu system with vdr 1.7.16. > > Regards, Rainer > ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] Technotrend DVB-C 1501
Hi, i have a Technotrend DVB-C 1501 device (I guess the chip is the saa7146). With this card i cannot view a recording or live tv with the xineliboutput. live tv or a recording done by a pvrinput device works fine. Does anyone has a clue why the dvb-c device doesn't work with xineliboutput ? I have an ubuntu system with vdr 1.7.16. Regards, Rainer ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Request - support for ATSC type channel numbers
On Fri, Oct 15, 2010 at 6:38 AM, Rob Davis wrote: > Not sure if in Euroland, you're aware of how US digital is working and > whether it's possible to support the US/ATSC channel number system. > > Essentially what's happening is a channel will appear on a frequency, then > each sub channel is appending to the frequency number with either a . or a > -. So, my ABC local channel is on 17. The main channel has a sid of 1, so > the channel number is 17.1 or 17-1. They also have a network called > MyNetwork, which has a sid of 2, so comes in as 17-2. I had requested support for this some time ago but unfortunately that basically ended with `don't hold my breath`. It would be great if someone managed to implement this at least as a patch, even if it never made it into stock VDR. It's a huge disadvantage that there isn't really any (well, hardly any) North American coders contributing to VDR. Sorry my reply doesn't bring better news. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Alternative-Channel patch
The patch won't be applied to the main stream. You're right that the patch spreads about many multiple files. I was afraid (and i'm still) that i am the only person needing an applying the patch. Perhaps its also possible to provide such functionality with a plugin. I will examine the source code and analyze ... If not, i will provide a smaller patch without some of the features. Because i changed some interface, the skincurses plugin is also affected by the patch. But you don't need to use it for using the "alternative" functionality. Do you intend to apply the patch ? 2010/10/14 Rob Davis : > On 14/10/10 02:27, Rainer Blickle wrote: >> >> Has anybody but me applied this patch ? >> >> Rainer > > The patch seems spread across vdr and skincurses, which I don't use, so it > didn't apply. > > Am looking at breaking it up into manageable parts and trying. > > > -- > > Rob Davis > > ___ > 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] Replay Problems with Extension HD
> From: Hannu Tirkkonen > Sent: Friday, 15 October, 2010 11:18 > To: VDR Mailing List > Subject: Re: [vdr] Replay Problems with Extension HD > > Is it still required to modify also the dvbsubtitle.c? No. > btw; Your previous patch reelbox-svn15208-vdr.bin for reelbox svn 15208 > didn't apply clean to VideoPlayerHd.c. The line 313 in svn 15208 > (VideoPlayerHd.c) start with: > const UInt repeat = 6; > and your patch expect it to start with > const UInt repeat = 4; > > It's easy to fix, but I thought I let you know... > Correct patch in the attachment, original was broken (wrong version) as you found. This do not include yet that STC fix. -- Vesa reelbox-svn15208b-vdr.diff Description: Binary data ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] Request - support for ATSC type channel numbers
Not sure if in Euroland, you're aware of how US digital is working and whether it's possible to support the US/ATSC channel number system. Essentially what's happening is a channel will appear on a frequency, then each sub channel is appending to the frequency number with either a . or a -. So, my ABC local channel is on 17. The main channel has a sid of 1, so the channel number is 17.1 or 17-1. They also have a network called MyNetwork, which has a sid of 2, so comes in as 17-2. Just to confuse matters, the 17 is actually the frequency of their old over the air frequency, they actually come in on a different frequency but have a virtual channel number of 17. The SD channels come in essentially as the same, but with a 2 stuck at the beginning, so 217.1 is ABC in SD. My normal TV when channel scanning mixes analog cable channels with digital ones. So old channels are on 2, 3, 4 up to 66, then ATSC channels appear starting on 13.1, 13.2, with 14 being an NTSC analog channel. (This is for Clear-QAM, although ATSC ota has the same type of numbering.). Anyway, is there anyway of getting VDR to support a sub channel number with a dash or period? -- Rob Davis ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Replay Problems with Extension HD
On 15.10.2010 10.28, Vesa wrote: Unfortunately it is not working.. The Working Fix is this: - return (stc == 0) ? -1LL : stc; + if (Transferring()){ + stc -= 9L; + } + else { + stc -= 52L; + } + return (stc == 0) ? -1LL : (stc& 0x); Replaying returns always true, Transferring returns true only for live. eHD seems to need small delay also for live. With this patch eHD looks usable device. I have to do long time testing for stability, but so far it is more stable than xine/vdpau based solutions. I'm using reelbox testing tree version 15208 for reelbox-3 and eHD device driver. Is it still required to modify also the dvbsubtitle.c? btw; Your previous patch reelbox-svn15208-vdr.bin for reelbox svn 15208 didn't apply clean to VideoPlayerHd.c. The line 313 in svn 15208 (VideoPlayerHd.c) start with: const UInt repeat = 6; and your patch expect it to start with const UInt repeat = 4; It's easy to fix, but I thought I let you know... ...hanu -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Replay Problems with Extension HD
> From: Hannu Tirkkonen > Subject: Re: [vdr] Replay Problems with Extension HD > > On 14.10.2010 19.17, Vesa wrote: > >> From: Rolf Ahrenberg > >> > >> Would it help to modify the plugin's GetSTC() method only when > >> replaying? > >> > >> + if (Replaying()) > >> +STC -= 50L; // or configurable: 900L * > ReelSetup.STCDelayMs; > >> > > > > Yes, that works. Complete fix for ReelBoxDevice.c around line 996: > > > > - return (stc == 0) ? -1LL : stc; > > + if (Replaying()) > > + stc -= 52L; > > + return (stc == 0) ? -1LL : (stc& 0x); > > > > > > With this change Reelbox delivers stc in correct format and timing is > > correct for live show. For recordings 52 is suitable mid range > offset on > > Yle SD feed. I assume that eHD buffer is for mpeg/h264 and delay is > based on > > bit/s. > > > OMG :) It's really working. Unfortunately it is not working.. The Working Fix is this: - return (stc == 0) ? -1LL : stc; + if (Transferring()){ + stc -= 9L; + } + else { + stc -= 52L; + } + return (stc == 0) ? -1LL : (stc & 0x); Replaying returns always true, Transferring returns true only for live. eHD seems to need small delay also for live. With this patch eHD looks usable device. I have to do long time testing for stability, but so far it is more stable than xine/vdpau based solutions. I'm using reelbox testing tree version 15208 for reelbox-3 and eHD device driver. -- Vesa ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr