Re: [vdr] Problem with VDR 1.5.14 and FF card version 2.1 card and channels with high bitrate
Klaus Schmidinger wrote: > On 02/01/08 19:17, Magnus Andersson wrote: > >> Hello! >> >> I have problems with channels that uses high bitrate on Thor 1W. A few >> channels uses between 10-11 Mbit/s mpeg2 and if I use tv-out from FF >> card vdr 1.5.14 the picture glitches and the remote response becomes >> really slow. It can take 10 seconds or more to change channel. There are >> no problems if I use xineliboutput and vdr 1.5.14 or channels with low >> bitrate. VDR 1.4.7 is ok with both xinliboutput plugin and tv-out from >> FF card so my question is how to log this? I start vdr with option -l 3 >> but there is nothing in the log. >> > > Please post the channel definitions of some of these channels. > > Klaus > > ___ > vdr mailing list > vdr@linuxtv.org > http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr > 24;Telenor:12303:vC34M0O0S0:S1.0W:27799:523:684=sve:576:B00:3012:70:16:0 SVT2 ¬stNytt;Telenor:12303:vC34M0O0S0:S1.0W:27799:512:640=sve;641=sve:576:B00:3009:70:16:0 24 ¬stNytt;Telenor:12303:vC34M0O0S0:S1.0W:27799:523:684=sve:576:B00:3020:70:16:0 The problem is not always permanent but here a good way to reproduce the problem. Restart vdr on BBC World (FTA) channel on Thor 1W and configure vdr to start at last channel. BBC World;Telenor:11325:hC78M0O0S0:S1.0W:24500:513:644=eng:577:1:1001:70:25:0 When BBC world has started tune one of the high bitrate channels and you will see the problem. /Magnus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] Freeview Replay aka TV-Anytime patch
There was a discussion here last year about implementing support for Freeview Replay, the cut-down version of TV-Anytime (ETSI TS 102 323) broadcast in the UK. I've now produced a patch which implements the low-level support needed for Freeview Replay. It captures the series and item CRIDs and stores the information in epg.data and channels.conf. If anyone is interested in taking this forward and building high-level functions to make use of the data, the patch is at http://www.pickles.me.uk/vdrtva-0.0.1.tar.gz The patch was prepared against vdr-1.5.13. -- Dave ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Problem with VDR 1.5.14 and FF card version 2.1 card and channels with high bitrate
> On 02/01/08 19:17, Magnus Andersson wrote: >> Hello! >> >> I have problems with channels that uses high bitrate on Thor 1W. A few >> channels uses between 10-11 Mbit/s mpeg2 and if I use tv-out from FF >> card vdr 1.5.14 the picture glitches and the remote response becomes >> really slow. It can take 10 seconds or more to change channel. There are >> no problems if I use xineliboutput and vdr 1.5.14 or channels with low >> bitrate. VDR 1.4.7 is ok with both xinliboutput plugin and tv-out from >> FF card so my question is how to log this? I start vdr with option -l 3 >> but there is nothing in the log. > > Please post the channel definitions of some of these channels. > > Klaus > > ___ > vdr mailing list > vdr@linuxtv.org > http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr > 24;Telenor:12303:vC34M0O0S0:S1.0W:27799:523:684=sve:576:B00:3012:70:16:0 SVT2 ¬stNytt;Telenor:12303:vC34M0O0S0:S1.0W:27799:512:640=sve;641=sve:576:B00:3009:70:16:0 24 ¬stNytt;Telenor:12303:vC34M0O0S0:S1.0W:27799:523:684=sve:576:B00:3020:70:16:0 The problem is not always permanent but here a good way to reproduce the problem. Restart vdr on BBC World (FTA) channel on Thor 1W and configure vdr to start at last channel. BBC World;Telenor:11325:hC78M0O0S0:S1.0W:24500:513:644=eng:577:1:1001:70:25:0 When BBC world has started tune one of the high bitrate channels and you will see the problem. /Magnus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Problem with VDR 1.5.14 and FF card version 2.1 card and channels with high bitrate
Klaus Schmidinger wrote: > On 02/01/08 19:17, Magnus Andersson wrote: > >> Hello! >> >> I have problems with channels that uses high bitrate on Thor 1W. A few >> channels uses between 10-11 Mbit/s mpeg2 and if I use tv-out from FF >> card vdr 1.5.14 the picture glitches and the remote response becomes >> really slow. It can take 10 seconds or more to change channel. There are >> no problems if I use xineliboutput and vdr 1.5.14 or channels with low >> bitrate. VDR 1.4.7 is ok with both xinliboutput plugin and tv-out from >> FF card so my question is how to log this? I start vdr with option -l 3 >> but there is nothing in the log. >> > > Please post the channel definitions of some of these channels. > > Klaus > > ___ > vdr mailing list > vdr@linuxtv.org > http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr > 24;Telenor:12303:vC34M0O0S0:S1.0W:27799:523:684=sve:576:B00:3012:70:16:0 SVT2 ¬stNytt;Telenor:12303:vC34M0O0S0:S1.0W:27799:512:640=sve;641=sve:576:B00:3009:70:16:0 24 ¬stNytt;Telenor:12303:vC34M0O0S0:S1.0W:27799:523:684=sve:576:B00:3020:70:16:0 The problem is not always permanent but here a good way to reproduce the problem. Restart vdr on BBC World (FTA) channel on Thor 1W and configure vdr to start at last channel. BBC World;Telenor:11325:hC78M0O0S0:S1.0W:24500:513:644=eng:577:1:1001:70:25:0 When BBC world has started tune one of the high bitrate channels and you will see the problem. /Magnus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] new drivers
Tony, I got rid of the xine blue screen/hang by downgrading libX11 and libX11-devel to the ones from fedora 7 :) Hope it works for you too. Regards, Hans ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] What is H264 Spatial Direct Mode?
Here's an update on this for those interested in H264 and VDR. I brought up the problems with Spatial Direct Mode and FFMPEG on their mailing list and Loren has implemented it within the code. When tuning to one of the affected channels I no longer get messages saying that spatial direct is not implemented, but I still get extreme artifacting, dropped frames and problems with xine: - video_out: throwing away image with pts 1124374 because it's too old (diff : 31864). buffer usage: 1689, 0, 0, 0, 0x9639a0 buffer usage: 1689, 0, 1, 0, 0x9639a0 ffmpeg_video_dec: error decompressing frame ffmpeg_video_dec: error decompressing frame buffer usage: 1669, 0, 1, 0, 0x9639a0 ffmpeg_video_dec: error decompressing frame buffer usage: 1662, 0, 1, 0, 0x9639a0 ffmpeg_video_dec: error decompressing frame buffer usage: 1647, 0, 1, 0, 0x9639a0 video_out: throwing away image with pts 1126698 because it's too old (diff : 33319). buffer usage: 1714, 0, 0, 0, 0x9639a0 buffer usage: 1675, 0, 0, 0, 0x9639a0 buffer usage: 1675, 0, 1, 0, 0x9639a0 video_out: throwing away image with pts 1138960 because it's too old (diff : 25556). Hopefully, we can continue the interest and get these issues fixed. Reinhard, do you have any idea why this might be occuring? I can upload some samples somewhere if required. Thanks ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Problem with VDR 1.5.14 and FF card version 2.1 card and channels with high bitrate
Hi, On Fri, Feb 01, Magnus Andersson wrote: > I have problems with channels that uses high bitrate on Thor 1W. A few > channels uses between 10-11 Mbit/s mpeg2 and if I use tv-out from FF > card vdr 1.5.14 the picture glitches and the remote response becomes > really slow. It can take 10 seconds or more to change channel. There are > no problems if I use xineliboutput and vdr 1.5.14 or channels with low > bitrate. VDR 1.4.7 is ok with both xinliboutput plugin and tv-out from > FF card so my question is how to log this? I start vdr with option -l 3 > but there is nothing in the log. > > vdr 1.5.14 > patches: > vdr-1.5.14-liemikuutio-1.17.diff > vdr-1.5.14-ttxtsubs-0.0.5.diff > vdr-1.5.14-dvb-api-emulate-0.1.diff > > I have seen this in earlier versions of 1.5 so it is not related to > 1.5.14 only. I've the same problem with ARD, when I switch audio to dolby digital. When I set audio to stereo, there are no problems. Can you try to disable dolby digital ? PS.: cpu is "Mobile Genuine Intel(R) processor 900MHz" and ff card is a 01:0f.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 01) -- Gruß Dieter -- I do not get viruses because I do not use MS software. If you use Outlook then please do not put my email address in your address-book so that WHEN you get a virus it won't use my address in the From field. pgpAZbkZX4CwY.pgp Description: PGP signature ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] What is H264 Spatial Direct Mode?
Hi, Morfsta schrieb: > Hopefully, we can continue the interest and get these issues fixed. > Reinhard, do you have any idea why this might be occuring? I can > upload some samples somewhere if required. I've planned a big pull of all that stuff (ffmpeg, xine-lib, xine-ui) this weekend, but I'm not sure whether I'll find time for it. Bye. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:[EMAIL PROTECTED] ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] 2 motorized dishes
I recently added to my single-FF-card VDR-box a second card, it's a TT-S2-3200. It's working fine with the multiproto dirvers and vdr-1.5.14, i can watch SDTV on the nexus-s' tv out or HDTV (quite well) via vdr-xine. I have one issue with my dishes. I know that few of the vdr users have motorized dish, well I have two of them :) The first one, a 1.8m prime focus is controlled fine with Diseqc 1.2 commands in diseqc.conf. But I have a second one connected to my S2-3200. Is there any way to control this motor via diseqc.conf? Thanks, Istvan PS. In my old vdr I had a nice patch, which allowed me to easily enter the recordings paths with the arrow keys, without typing the folder's name. I applied the liemikuutio patch to vdr-1.5.14 but i cannot find this feature. Where can I find this patch? -- 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
[vdr] Looking for DVB-T card (TVHD compatible) for vdr
@igor and @nico, Thanks for your responses. In France, MPEG4 HDTV DVB-T will begin shortly (several weeks). I don't know yet if we will swap to DVB-T2 around 2009-2010 :-( Since I need two DVB-T tuners by vdrbox, I won't buy WinTV-HVR-4000, it will be too much expensive (env 190 € each in France !). It's better for me to choose a double tuner PCI DVB-T card. As any budget can receive DVB-T, even in HDTV mode, I plan to buy one of theses items : Choice 1 : http://www.fusionhdtv.co.kr/ENG/products/DVBTdual4.aspx => unfortunately, I didn't find this hardware in Europe. "Where to buy" gives "glowlounge techno" in UK, "FNAC" and "Surcouf" in France, but none of theses has the card. Could you please confirm that there is no compatibility problem, with this model in France ? If someone know a reseller in Europe, please give as the link ! Choice 2 : http://www.hauppauge.fr/pages/products/data_nova-t-500.html => No problem to find this card in France, but I am not 100% shure that the hardware will be TVHD compliant. Hauppauge doesn't communicate about that, contrary to fusionhdtv. @all, As usually, any comment will be appreciate. Thanks. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] Transfer-Mode without remux
In a crude attempt to run VDR's Transfer-Mode without using a cRemux
(and thus avoiding all the extra buffering and processing) I am
trying to send the payload of the TS packets directly to the device.
The attached patch implements cDevice::PlayTS() and handles video
and audio packets with fixed PIDs (just for testing).
I do get audio and video (using a FF-DVB card as output device),
but there are some distortions. From all the debug output I've
made there doesn't seem to be anything wrong - even the TS continuity
counters check out (except for the initial one, which is to be expected).
Am I missing something obvious here?
Maybe somebody on the list can find out what's wrong here - or can
argue why this attempt can't work in the first place.
If you try the patch, just change the hardcoded PIDs in cDevice::PlayTS()
to whatever video and audio PID the channel has you're going to
test with.
Klaus
--- ./device.c 2008/01/27 10:40:46 1.149
+++ ./device.c 2008/02/02 14:58:05
@@ -1387,6 +1387,64 @@
return Length;
}
+//XXX make generally available?
+#define TS_LENGTH 188//XXX
+#define ADAPT_FIELD0x20
+#define CONT_CNT_MASK 0x0F
+#define PAY_LOAD 0x10
+#define TS_ERROR 0x80
+inline int TsPid(const uchar *Data)
+{
+ return (((uint16_t)Data[1] & PID_MASK_HI) << 8) | Data[2];
+}
+inline int TsPayloadOffset(const uchar *Data)
+{
+ return (Data[3] & ADAPT_FIELD) ? Data[4] + 4 : 4;
+}
+inline int TsContinuityCounter(const uchar *Data)
+{
+ return Data[3] & CONT_CNT_MASK;
+}
+//XXX
+
+int cDevice::PlayTS(const uchar *Data, int Length, bool VideoOnly)
+{
+ static int ccV = 0, ccA = 0;//XXX
+ if (Length == TS_LENGTH) {
+ int PayloadOffset = TsPayloadOffset(Data);
+ if (PayloadOffset < Length) {
+if (Data[1] & TS_ERROR)
+ fprintf(stderr, "E");
+if (!(Data[3] & (ADAPT_FIELD | PAY_LOAD)))
+ fprintf(stderr, "D");
+if (!(Data[3] & PAY_LOAD)) {
+ fprintf(stderr, "0");
+ return 0;
+ }
+//XXX more checks?
+int Pid = TsPid(Data);
+if (Pid == 3210) {
+ if ((Data[3] ^ (ccV + 1)) & CONT_CNT_MASK)
+ fprintf(stderr, "V %d %d\n", ccV, TsContinuityCounter(Data));
+ ccV = TsContinuityCounter(Data);
+ return PlayVideo(Data + PayloadOffset, Length - PayloadOffset);
+ }
+if (Pid == 3211) {
+ if ((Data[3] ^ (ccA + 1)) & CONT_CNT_MASK)
+ fprintf(stderr, "A %d %d\n", ccA, TsContinuityCounter(Data));
+ ccA = TsContinuityCounter(Data);
+ return PlayAudio(Data + PayloadOffset, Length - PayloadOffset, 0);
+ }
+//fprintf(stderr, " P");//XXX
+return 0;//XXX
+}
+ else fprintf(stderr, " O");//XXX
+ }
+ else fprintf(stderr, " L");//XXX
+ return -1;
+}
+//XXX change description of PlayVideo()/PlayAudio()? "no longer an entire PES packet"?
+
int cDevice::Priority(void) const
{
int priority = IsPrimaryDevice() ? Setup.PrimaryLimit - 1 : DEFAULTPRIORITY;
--- ./device.h 2008/01/27 10:35:18 1.87
+++ ./device.h 2008/02/02 13:10:05
@@ -554,6 +554,8 @@
///< to a complete packet with data from the next call to PlayPes().
///< That way any functions called from within PlayPes() will be
///< guaranteed to always receive complete PES packets.
+ virtual int PlayTS(const uchar *Data, int Length, bool VideoOnly = false);
+ ///< XXX
bool Replaying(void) const;
///< Returns true if we are currently replaying.
bool Transferring(void) const;
--- ./player.h 2007/10/13 12:18:10 1.20
+++ ./player.h 2008/02/02 13:48:41
@@ -41,6 +41,7 @@
// Sends the given PES Data to the device and returns the number of
// bytes that have actually been accepted by the device (or a
// negative value in case of an error).
+ int PlayTS(const uchar *Data, int Length, bool VideoOnly = false) { return device ? device->PlayTS(Data, Length, VideoOnly) : -1; }
public:
cPlayer(ePlayMode PlayMode = pmAudioVideo);
virtual ~cPlayer();
--- ./transfer.c 2007/01/05 10:45:28 1.34
+++ ./transfer.c 2008/02/02 14:16:29
@@ -32,6 +32,7 @@
void cTransfer::Activate(bool On)
{
+ return;//XXX
if (On)
Start();
else {
@@ -42,6 +43,9 @@
void cTransfer::Receive(uchar *Data, int Length)
{
+ int r = PlayTS(Data, Length);//XXX
+ //fprintf(stderr, " %d", r);//XXX
+ return;
if (cPlayer::IsAttached() && Running()) {
int p = ringBuffer->Put(Data, Length);
if (p != Length && Running())
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Transfer-Mode without remux
On 02/02/08 16:27, Klaus Schmidinger wrote:
> In a crude attempt to run VDR's Transfer-Mode without using a cRemux
> (and thus avoiding all the extra buffering and processing) I am
> trying to send the payload of the TS packets directly to the device.
>
> The attached patch implements cDevice::PlayTS() and handles video
> and audio packets with fixed PIDs (just for testing).
>
> I do get audio and video (using a FF-DVB card as output device),
> but there are some distortions. From all the debug output I've
> made there doesn't seem to be anything wrong - even the TS continuity
> counters check out (except for the initial one, which is to be expected).
>
> Am I missing something obvious here?
>
> Maybe somebody on the list can find out what's wrong here - or can
> argue why this attempt can't work in the first place.
>
> If you try the patch, just change the hardcoded PIDs in cDevice::PlayTS()
> to whatever video and audio PID the channel has you're going to
> test with.
Nevermind, I just found it myself: it must be +5 instead of +4 in
inline int TsPayloadOffset(const uchar *Data)
{
return (Data[3] & ADAPT_FIELD) ? Data[4] + 5 : 4;
}
Now it works - and Transfer-Mode never switched as fast as this :-)
Klaus
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Transfer-Mode without remux
Hi, Klaus Schmidinger schrieb: > Now it works - and Transfer-Mode never switched as fast as this :-) Have you never tried my syncearly patch? Bye. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:[EMAIL PROTECTED] ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Transfer-Mode without remux
On 02/02/08 16:59, Reinhard Nissl wrote: > Hi, > > Klaus Schmidinger schrieb: > >> Now it works - and Transfer-Mode never switched as fast as this :-) > > Have you never tried my syncearly patch? Sorry, but I never found the time to try it. By sending the TS payload data directly to the device, audio appears almost instantaneously - which I believe is what the syncearly patch does, too, right? Plus it saves two ringbuffers (one in cTransfer and one in cRemux) and one extra thread - sounds like some simplification to me ;-) Of course I'll need to see how this behaves in every day live, and all the audio track handling needs to be adjusted accordingly. But for the moment it looks good to me. Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Transfer-Mode without remux
On Feb 2, 2008 8:14 AM, Klaus Schmidinger <[EMAIL PROTECTED]> wrote: > On 02/02/08 16:59, Reinhard Nissl wrote: > > Have you never tried my syncearly patch? > > Sorry, but I never found the time to try it. > > By sending the TS payload data directly to the device, audio appears almost > instantaneously - which I believe is what the syncearly patch does, too, > right? Maybe you should make some time to try his patches so you won't have to spend time creating code that already exists. ;) ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Transfer-Mode without remux
On 02/02/08 18:01, VDR User wrote: > On Feb 2, 2008 8:14 AM, Klaus Schmidinger <[EMAIL PROTECTED]> wrote: >> On 02/02/08 16:59, Reinhard Nissl wrote: >>> Have you never tried my syncearly patch? >> Sorry, but I never found the time to try it. >> >> By sending the TS payload data directly to the device, audio appears almost >> instantaneously - which I believe is what the syncearly patch does, too, >> right? > > Maybe you should make some time to try his patches so you won't have > to spend time creating code that already exists. ;) Well, I didn't write code that already existed - I eliminated unnecessary code ;-) Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] [Announce] vdr-fritzbox-0.0.11
Dear Fritz!Box- and VDR-Users, a new version of the Fritz!Box Plugin is available at http://joachim-wilke.de/index.htm?alias=vdr-fritz - - - The Fritz!Box Plugin connects to your Fritz!Box to inform you about incoming calls. The plugin can automatically mute or pause VDR when a call comes in. Via VDR's main menu you can browse your Fritz!Box phone book, the call lists and initiate calls out of all lists. - - - The last changes are: 2008-02-02: Version 0.0.11 - fixed the "#96*5*"-code in README.de (reported by Hans Jürgen [22]) - fixed request-URL of das-oertliche.de (patch provided by Reinhard [11]) - now always unlocking FritzBoxMutex even when an exception is thrown - fixed wrong logging messages in fritzfonbuch.c claiming to be from calllist.c - an error message is now shown, if the phonebook is not read yet - replaced gethostbyname with threadsafe function getaddrinfo in cTcpClient - improved timing cHttpClient::Read() - simplified socket read in cOertlichesFonbuch::ResolveToName() - now reading country- and regioncode from Fritz!Box; this removes the setup option "Country Code" Set up your location in the Fritz!Box (navigate to "Einstellungen -> Telefonie -> Internettelefonie -> Erweiterte Einstellungen") (thanks to Reinhard [11] for the hint to this option) - now normalizing number when doing a lookup to dasoertliche.de (reported by Reinhard [11]) - - - Regards, Joachim. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Problem with VDR 1.5.14 and FF card version 2.1 card and channels with high bitrate
Dieter Bloms wrote: > Hi, > > On Fri, Feb 01, Magnus Andersson wrote: > > >> I have problems with channels that uses high bitrate on Thor 1W. A few >> channels uses between 10-11 Mbit/s mpeg2 and if I use tv-out from FF >> card vdr 1.5.14 the picture glitches and the remote response becomes >> really slow. It can take 10 seconds or more to change channel. There are >> no problems if I use xineliboutput and vdr 1.5.14 or channels with low >> bitrate. VDR 1.4.7 is ok with both xinliboutput plugin and tv-out from >> FF card so my question is how to log this? I start vdr with option -l 3 >> but there is nothing in the log. >> >> vdr 1.5.14 >> patches: >> vdr-1.5.14-liemikuutio-1.17.diff >> vdr-1.5.14-ttxtsubs-0.0.5.diff >> vdr-1.5.14-dvb-api-emulate-0.1.diff >> >> I have seen this in earlier versions of 1.5 so it is not related to >> 1.5.14 only. >> > > I've the same problem with ARD, when I switch audio to dolby digital. > When I set audio to stereo, there are no problems. > > Can you try to disable dolby digital ? > > PS.: cpu is "Mobile Genuine Intel(R) processor 900MHz" and ff card is a > 01:0f.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 01) > > Thank you for your inputs. I never use dolby digital because I use stereo speakers on the TV. Even if I disable dolby digital in the DVB configuration I still get the problems. Somtimes high bitrate channels works after switching to the DVB-T card and then back again and with your information I can force the problem to come back even if channel works without problem. By changing to dolby digital audio instead of stereo the channel becomes bad again and remote is barely responsive. My configuration is: Gentoo linux with Athlon64 3500+ CPU compiled for 64 bit with Hauppauge version 2.1 DVB-S and one Airstar2 DVB-T. I have the same here 04:07.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 01) /Magnus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
