[vdr] Compiling dxr3 plugin against vdr-1.5.11
Hi, Did anybody try to compile dxr3 plugin from source from e-tobi repositories against 1.5.11 tree? Any luck? Regards, Y. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] dxr3 compiling and 1.5.11
Hi, Did anybody try to compile dxr3 plugin from source from e-tobi repositories against 1.5.11 tree? Any luck? Regards, Yarema ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] dxr3 and 1.5.11 antialiasing
Luca Olivetti wrote: Jan Willies [EMAIL PROTECTED] escribió: Luca Olivetti wrote: FWIW I have 2.3.1 (the version that came with mandriva 2007.1). Seems that debian only has Version: 2.3.5-1+b1 and Version: 2.2.1-5+etch1. Unfortunately, 2.2.1 seems pretty old when trying to downgrade: Hey, I just told you my version for information, I doubt that the version of freetype is the problem (or maybe it is, I cannot say). I'm trying to sort out where the problem is and because I have no idea about freetype/fonts playing with different freetype versions is my first bet :P - Jan ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] dxr3 compiling and 1.5.11
YUP wrote: Did anybody try to compile dxr3 plugin from source from e-tobi repositories against 1.5.11 tree? Any luck? It compiles fine for me from cvs. No idea what e-tobi uses, but probably not current trunk. - Jan ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] dxr3 compiling and 1.5.11
Well, I will try. Thanks for a tip. Yarema Jan Willies wrote: YUP wrote: Did anybody try to compile dxr3 plugin from source from e-tobi repositories against 1.5.11 tree? Any luck? It compiles fine for me from cvs. No idea what e-tobi uses, but probably not current trunk. - Jan ___ 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] next features?
Hi, Reinhard Nissl wrote: And I don't think that we will see a FF card which can handle H.264. Gfx cards take over that business and once the VA API is released and supported, those functionality will even be available on Linux. Let´s hope that the VA API will soon be released and get working drivers because the current situation is not satisfying. I am a satisfied FF-SD user for years, but it´s biggest pro, the 1:1 interlace output, becomes unimportant in times of progressive LCD screens. And the gfx cards are already good enough in decoding H.264 (at least on Windows) that I currently don´t see any sense in waiting for a FF-HD card - apart from the mentioned missing H.264 acceleration on linux. In fact, I fear more limitations in the ongoing VDR development if people again have to take care e.g. for OSD sizes of certain hardware boards and have to fight with (closed source) firmware bugs. A hardware independent approach would allow e.g. more flexibility in UI control. You might say: The UI is sufficient, but if I think of using VDR as media center I think of all the complicated things that need to be done e.g. to simply get an image displayed on FF cards (see the discussion on interlaced display of images some days ago). Also features like a web browser plug-in (e.g. for easier access to web-tv) will never be possible as people still have to take care of certain hardware limitations. Another approach would be calling external web browsers, media players etc. from VDR, but then I doubt that I can still use the remote control for also controlling the external applications. Just my thoughts about the future of VDR in a future flat-screen-enhanced living room (still enjoying superb tube tv quality...). With kind regards Joerg Knitter ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] next features?
VDR User wrote: Many users are moving away from FF cards and into the realm of h264 and HDTV, which is why VDR has lost a lot of users to that other software I won't mention. ;( ... I've been using VDR for many years now and am very loyal to it and I must say I don't like seeing users leaving because VDR is being left in the dust when it comes to support for current future things like h264 and HDTV. But VDR does support h.264 broadcasts already, although with patching, but still. So there is no need for anyone to stop using VDR because of a lack of h.264 support. -Petri ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] next features?
VDR User [EMAIL PROTECTED] writes: Some of us aren't ready to switch just yet but there's no ignoring the shift in peoples interests. All I can say is when it comes time that I can't ignore those requirements anymore, I can only hope that VDR has envolved with the times and I won't be forced to use something else. Agreed, but in the end I'm pretty sure I will be forced to use something else. (I've been thinking that for a long time and I'm still using it :)) I'm not even sure vdr is modular enough to allow my requirements without changing everything, is it ? (When Reinhard says it would be a big patch I guess BIG is meant.) Anyway, there's no public TODO, no public cvs/svn, etc... I'm surprised there's no fork yet. note: this message is not meant to be nasty, disrespectful or provocative in any way. -- ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] dxr3 compiling and 1.5.11
Hi, Did anybody try to compile dxr3 plugin from source from e-tobi repositories against 1.5.11 tree? Any luck? About dxr3 plugin I still have bloody green screen... ;( No luck at all to make this card working... ;( /Xavier -- Xavier Beaudouin - http://oav.net/ ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] dxr3 compiling and 1.5.11
I successfully compiled dxr3 plugin from cvs (stable at it was described here http://www.linuxtv.org/vdrwiki/index.php/Dxr3-plugin), but still no luck - vdr crashes with segmentation fault. Compiling official dxr3 1.2.7 plugin marked as stable gives me the following errors: ../../../include/vdr/osd.h:410: warning: ‘virtual cOsd* cOsdProvider::CreateOsd(int, int, uint)’ was hidden dxr3osd.h:13: warning: by ‘virtual cOsd* cDxr3OsdProvider::CreateOsd(int, int)’ g++ -fPIC -O2 -Wall -Woverloaded-virtual -c -DPLUGIN_NAME_I18N='dxr3' -D_GNU_SOURCE -DMICROCODE=\/lib/firmware/em8300.bin\ -DUSE_XINE_SCALER -I../../../include `ffmpeg-config --cflags` -I/usr/include dxr3device.c /usr/include/ffmpeg/avcodec.h:2432: warning: attribute ignored in declaration of ‘struct ImgReSampleContext’ /usr/include/ffmpeg/avcodec.h:2432: warning: attribute for ‘struct ImgReSampleContext’ must follow the ‘struct’ keyword /usr/include/ffmpeg/avcodec.h:2437: warning: ‘ImgReSampleContext’ is deprecated (declared at /usr/include/ffmpeg/avcodec.h:2434) /usr/include/ffmpeg/avcodec.h:2444: warning: ‘ImgReSampleContext’ is deprecated (declared at /usr/include/ffmpeg/avcodec.h:2434) /usr/include/ffmpeg/avcodec.h:2448: warning: ‘ImgReSampleContext’ is deprecated (declared at /usr/include/ffmpeg/avcodec.h:2434) /usr/include/ffmpeg/avcodec.h:2450: warning: ‘ImgReSampleContext’ is deprecated (declared at /usr/include/ffmpeg/avcodec.h:2434) ../../../include/vdr/osd.h:410: warning: ‘virtual cOsd* cOsdProvider::CreateOsd(int, int, uint)’ was hidden dxr3osd.h:13: warning: by ‘virtual cOsd* cDxr3OsdProvider::CreateOsd(int, int)’ dxr3device.c: In member function ‘virtual void cDxr3Device::MakePrimaryDevice(bool)’: dxr3device.c:53: error: cannot allocate an object of abstract type ‘cDxr3OsdProvider’ dxr3osd.h:10: note: because the following virtual functions are pure within ‘cDxr3OsdProvider’: ../../../include/vdr/osd.h:410: note: virtual cOsd* cOsdProvider::CreateOsd(int, int, uint) make: *** [dxr3device.o] Error 1 Yarema Xavier Beaudouin wrote: Hi, Did anybody try to compile dxr3 plugin from source from e-tobi repositories against 1.5.11 tree? Any luck? About dxr3 plugin I still have bloody green screen... ;( No luck at all to make this card working... ;( /Xavier -- Xavier Beaudouin - http://oav.net/ ___ 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] next features?
On 11/15/07 17:33, VDR User wrote: ... Klaus has made it very clear that he only cares how VDR works in his environment and if you want that support then you should use different software. I'm sure a large number of users don't like hearing that but it is what it is. Klaus has the right to include or neglect anything he wishes in VDR, and users do have the option to use something else instead. Some comments in this thread (and others) sound as if there is an imminent need to switch to HDTV/H.264, because otherwise we won't be able to watch tv any more within a few months. I don't see any real incentive in taking all the extra efforts to do HDTV. The programmes I usually watch are all broadcast in normal MPEG2, SDTV. Even if I had the ability to receive HDTV, I would have to pay extra to actually see anyting - so what's the point? For my taste currently manufacturers, broadcasters and studios are way too busy trying to *prevent* people from enjoying HDTV than to *enable* them to do it. Just take the infamous HDCP, for instance. You can have a tv set that does HDCP, and also a receiver that does it, but that doesn't necessarily mean that these two can actually work together. And unless both receiver and tv set are from the same manufacturer, chances are both manufacturers will point fingers at each other and say it's their fault... I'm not saying that VDR will never, ever do HDTV/H.264 (after all there are already patches to support that). It's just that I don't feel like spending time on this right now. And if this means that some VDR users who absolutely need this, and maybe also prefer shiny bells-and-whistles user interfaces, will switch to a different program, that's perfectly ok with me. Everybody should use the software that best suits their needs ;-) Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] next features?
I don't think anyone has implied that it's imminent VDR adopt h264/HDTV support or tv viewing will cease to exist. That would be a ridiculous claim to make! However, the truth is more and more HDTV broadcasts are being offered by providers on a consistent and constant basis due to market demand. H264 is becoming more widely used to help accommodate. SDTV will not vanish overnight but there is certainly a shift that can't be ignored. Klaus asks the question that even if he was able to view HDTV, he would have to pay more so whats the point? Well, the point is that it's clearly something people want and are willing to pay more to get considering the investment providers, and others, are making to offer more appealing services products to the customer base. Look at all the HDTV televisions available at inexpensive prices now, and it doesn't stop there... As media pc's become more 'the norm' and the center of home entertainment systems, it's no coincidence that video card vendors are offering up devices capable of this stuff as well. To have a blind eye to all this would be crazy to say the least. Also, I talk with many dvb users on pretty much a daily basis and I've never once heard someone say they've left VDR for that other software because of eye-candy/UI. Most people seem to be concerned with capability functionality, not pretty graphics. My personal opinion is that, because I'm biased in favor of VDR, it's disappointing to see so many users abandon it simply because of the lack of support for things that are becoming more common in-demand every day. I would love that VDR is able to be on the curve, or actually ahead of it, rather then trailing far behind. That being said, I fully respect appreciate the work Klaus and others have done with VDR over the years, and by no means am I trying to sound negative towards it. Lastly with regard to Petri's comment that, But VDR does support h.264 broadcasts already, although with patching, but still. So there is no need for anyone to stop using VDR because of a lack of h.264 support. I don't think anyone would argue that stock support for things such as h264 is far more desirable over the requirement of patches and modifying an app. Generally speaking, the less a user has to alter the source code, the better. In a related note, one of the most common questions I see being asked is how to patch this or that. The number of linux dvb users is growing in large part due to the lack of good solid dvb software for Windows. A lot of these guys aren't coders, aren't used to compiling things, and aren't even used to using a console for that matter. At any rate, the growing demand for things such as h264 and HDTV is clear, as is the fact that Klaus has no intention of supporting these things any time soon. Like mentioned many times before, we all have to figure out what we need and decide what software to use based on that. The more the interest shifts, the more people will leave VDR in its current state behind for something more suitable. Klaus very honestly said he's perfectly ok with that and sees no incentive to support this stuff so the story pretty much ends there. Well, one can always dream I guess! ;) ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] dxr3 compiling and 1.5.11
El Thu, 15 Nov 2007 19:58:43 +0100 YUP [EMAIL PROTECTED] escribió: I successfully compiled dxr3 plugin from cvs (stable at it was described here http://www.linuxtv.org/vdrwiki/index.php/Dxr3-plugin), but still no luck - vdr crashes with segmentation fault. This happened to me with the first version of vdr using truetype fonts: since my vdr machine is headless, has no X and consequently no kde/gnome desktop, I had no truetype font installed. Installing TT fonts and configuring vdr to use the installed fonts solved my problem. Bye -- Luca ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-1.5.11 subtitling problems
Hi,
Timo J. Rinne schrieb:
Anyways, it's been on for 25 minutes so far and has worked perfectly.
If I notice something in contrary to this, I'll report further.
Nope, it still doesn't quite work. In live mode it seems to skip
subtitles every now and then. It even seems to depend on the program.
Today I watched something and saw maybe one subtitle of ten. Sometimes
it seems to work more or less perfectly.
When I recorded the program that in live mode didn't work too well, the
subtitles were fine in playback.
I have ff card and I think the problems are present mainly (if not only)
in direct live mode. When I forced it to transport mode by
simultaneously recording an encrypted channel and watching fta channel
live (transport mode), subtitles showed OK.
Please try the attached patch on a vanilla VDR-1.5.11. It should write
the subtitle TS and PES packets to separate files at /video. The
additionally recorded timestamps of your system time and the primary
device's STC should allow us to determine whether the packets arrive in
time and get properly remuxed.
Once you've seen enough anomalies, please provide us (a link to) the files.
BTW: the patch is almost untested as there are currently no subtitles
running.
Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:[EMAIL PROTECTED]
diff -Nurp ../vdr-1.5.11-orig/device.c ./device.c
--- ../vdr-1.5.11-orig/device.c 2007-11-03 14:30:09.0 +0100
+++ ./device.c 2007-11-12 21:57:36.0 +0100
@@ -210,7 +210,7 @@ int cPesAssembler::PacketSize(const ucha
#define DEFAULTPRIORITY -1
// The minimum number of unknown PS1 packets to consider this a pre 1.3.19 private stream:
-#define MIN_PRE_1_3_19_PRIVATESTREAM 10
+#define MIN_PRE_1_3_19_PRIVATESTREAM 0 /*10*/
int cDevice::numDevices = 0;
int cDevice::useDevice = 0;
diff -Nurp ../vdr-1.5.11-orig/remux.c ./remux.c
--- ../vdr-1.5.11-orig/remux.c 2007-11-03 15:18:07.0 +0100
+++ ./remux.c 2007-11-15 23:02:54.0 +0100
@@ -1387,6 +1387,51 @@ int cDolbyRepacker::BreakAt(const uchar
return -1;
}
+class cLogger {
+ static int instance;
+ FILE *logFileTS;
+ FILE *logFilePES;
+ static void Store(FILE *LogFile, const uchar *Data, int Count);
+public:
+ cLogger(void);
+ ~cLogger();
+ void PutTS(const uchar *Data) { Store(logFileTS, Data, 188); }
+ void PutPES(const uchar *Data, int Count) { Store(logFilePES, Data, Count); }
+ };
+
+int cLogger::instance = 0;
+
+cLogger::cLogger(void)
+{
+ int Instance = instance++;
+ char FileNameTS[200];
+ sprintf(FileNameTS, /video/subtitle_log_%d_%02d.ts, getpid(), Instance);
+ logFileTS = fopen(FileNameTS, wb);
+ char FileNamePES[200];
+ sprintf(FileNamePES, /video/subtitle_log_%d_%02d.pes, getpid(), Instance);
+ logFilePES = fopen(FileNamePES, wb);
+}
+
+cLogger::~cLogger()
+{
+ fclose(logFileTS);
+ fclose(logFilePES);
+}
+
+#include sys/time.h
+#include device.h
+
+void cLogger::Store(FILE *LogFile, const uchar *Data, int Count)
+{
+ timeval tv;
+ gettimeofday(tv, 0);
+ int64_t stc = cDevice::PrimaryDevice()-GetSTC();
+ fwrite(tv, sizeof (tv), 1, LogFile);
+ fwrite(stc, sizeof (stc), 1, LogFile);
+ fwrite(Data, Count, 1, LogFile);
+ fflush(LogFile);
+}
+
// --- cTS2PES ---
#include netinet/in.h
@@ -1474,12 +1519,14 @@ public:
int Pid(void) { return pid; }
void ts_to_pes(const uint8_t *Buf); // don't need count (=188)
void Clear(void);
+cLogger *logger;
};
uint8_t cTS2PES::headr[] = { 0x00, 0x00, 0x01 };
cTS2PES::cTS2PES(int Pid, cRingBufferLinear *ResultBuffer, int Size, uint8_t RewriteCid, uint8_t SubStreamId, cRepacker *Repacker)
{
+logger = (Repacker ? 0 : new cLogger);
pid = Pid;
resultBuffer = ResultBuffer;
size = Size;
@@ -1504,6 +1551,7 @@ cTS2PES::cTS2PES(int Pid, cRingBufferLin
cTS2PES::~cTS2PES()
{
+delete logger;
if (tsErrors || ccErrors)
dsyslog(cTS2PES got %d TS errors, %d TS continuity errors, tsErrors, ccErrors);
free(buf);
@@ -1519,6 +1567,7 @@ void cTS2PES::Clear(void)
void cTS2PES::store(uint8_t *Data, int Count)
{
+if (logger) logger-PutPES(Data, Count);
if (repacker)
repacker-Repack(resultBuffer, Data, Count);
else
@@ -1749,14 +1798,15 @@ void cTS2PES::instant_repack(const uint8
case AUDIO_STREAM_S ... AUDIO_STREAM_E:
case VIDEO_STREAM_S ... VIDEO_STREAM_E:
case PRIVATE_STREAM1:
-
-if (mpeg == 2 found == 9) {
+/* make sure to not write the data twice by looking at count */
+if (mpeg == 2 found == 9 count found) {
write_ipack(flag1, 1);
write_ipack(flag2, 1);
write_ipack(hlength, 1);
}
-if (mpeg == 1 found == mpeg1_required) {
+/* make sure to not write the data twice by looking at count */
+if (mpeg == 1 found == mpeg1_required count found) {
write_ipack(flag1, 1);
if
[vdr] [Patch] vdr-dvd: drive speed limiter v2
Hi!
Here's a new version:
- set cmd_len correctly (libata checks for correct cmd_len before
passing commands through)
- indent cleanup
- earlier entry point to slow down drive before playback starts
Todo:
- proper error handling
- try old SET CD/DVD SPEED command in case SET STREAMING isn't supported
Regards
Sebastian
diff -Nur dvd/i18n.c dvd.new/i18n.c
--- dvd/i18n.c 2007-11-13 15:59:36.0 +0100
+++ dvd.new/i18n.c 2007-11-13 15:51:06.0 +0100
@@ -280,6 +280,32 @@
#endif
},
{
+ Setup.DVD$DVD-ROM Speed, // English
+DVD-ROM-Geschwindigkeit, // Deutsch
+DVD-ROM Speed,// Slovenski
+DVD-ROM Speed,// Italiano
+DVD-ROM Speed,// Nederlands
+DVD-ROM Speed,// Português
+DVD-ROM Speed,// Français
+DVD-ROM Speed,// Norsk
+DVD-ROM Speed,// suomi
+DVD-ROM Speed,// Polski
+DVD-ROM Speed,// Español
+DVD-ROM Speed,// ÅëëçíéêÜ (Greek)
+DVD-ROM Speed,// Svenska
+DVD-ROM Speed,// Romaneste
+DVD-ROM Speed,// Magyar
+DVD-ROM Speed,// Català
+DVD-ROM Speed,// ÀãááÚØÙ
(Russian)
+DVD-ROM Speed,// Hrvatski
(Croatian)
+DVD-ROM Speed,// Eesti
+DVD-ROM Speed,// Dansk
+DVD-ROM Speed,// Czech
+#if VDRVERSNUM = 10502
+DVD-ROM Speed // Türkçe
+#endif
+},
+{
Setup.DVD$Gain (analog),
Verstärkung (analog), // Deutsch
Ojaèanje (analogno), // Slovenski
diff -Nur dvd/player-dvd.c dvd.new/player-dvd.c
--- dvd/player-dvd.c2007-09-17 21:04:43.0 +0200
+++ dvd.new/player-dvd.c2007-11-13 15:58:50.0 +0100
@@ -35,6 +35,11 @@
#include control-dvd.h
#include dvd.h
+/* Needed for DvdSetSpeed() */
+#include linux/cdrom.h
+#include scsi/sg.h
+#include sys/ioctl.h
+
/**
* this was weak's solution of a forced
* SPU only stream choice,
@@ -252,6 +257,7 @@
bool cDvdPlayer::HasBitStreamOut = false;
bool cDvdPlayer::HasSoftDeviceOut = false;
bool cDvdPlayer::SoftDeviceOutActive = false;
+bool cDvdPlayer::DvdSetSpeedActive = false;
const int cDvdPlayer::MaxAudioTracks= 0x20;
const int cDvdPlayer::AudioTrackMask= 0x1F;
@@ -565,6 +571,93 @@
#endif
}
+/* This function was ripped off of mplayer */
+void cDvdPlayer::DvdSetSpeed(const char *device, int speed)
+{
+#if defined(SG_IO) defined(GPCMD_SET_STREAMING)
+int fd;
+unsigned char buffer[28];
+unsigned char cmd[12];
+unsigned char sense[16];
+struct sg_io_hdr sghdr;
+struct stat st;
+
+memset(sghdr, 0, sizeof(sghdr));
+memset(buffer, 0, sizeof(buffer));
+memset(sense, 0, sizeof(sense));
+memset(cmd, 0, sizeof(cmd));
+memset(st, 0, sizeof(st));
+
+if (stat(device, st) == -1) {
+esyslog(ERROR: dvd-plugin: DVD device %s doesn't exist, device);
+return;
+}
+
+if (!S_ISBLK(st.st_mode)) {
+esyslog(ERROR: dvd-plugin: DVD device %s is not a block device,
device);
+return;
+}
+
+if ((fd = open(device, O_RDWR | O_NONBLOCK)) == -1) {
+esyslog(ERROR: dvd-plugin: Failed to open DVD device %s O_RDWR |
O_NONBLOCK, device);
+return;
+}
+
+if (speed 100 speed 0) { /* speed times 1350KB/s (DVD single speed)
*/
+speed *= 1350;
+}
+
+switch (speed) {
+case 0: /* don't touch speed setting */
+close(fd);
+return;
+case -1: /* restore default value */
+speed = 0;
+buffer[0] = 4; /* restore default */
+isyslog(dvd-plugin: Restoring initial DVD drive speed);
+break;
+default: /* limit to speed KB/s */
+isyslog(dvd-plugin: Limiting speed to %d KB/s, speed);
+break;
+}
+
+sghdr.interface_id = 'S';
+sghdr.timeout = 5000;
+sghdr.dxfer_direction = SG_DXFER_TO_DEV;
+sghdr.mx_sb_len = sizeof(sense);
+sghdr.dxfer_len = sizeof(buffer);
+sghdr.cmd_len = sizeof(cmd);
+sghdr.sbp = sense;
+sghdr.dxferp = buffer;
+sghdr.cmdp = cmd;
+
+cmd[0] = GPCMD_SET_STREAMING;
+cmd[10] = sizeof(buffer);
+
+buffer[8] = 0xff; /* first sector 0, last
Re: [vdr] vdr-1.5.11 subtitling problems
En/na Reinhard Nissl ha escrit: BTW: the patch is almost untested as there are currently no subtitles running. FYI, if you can see astra 2d I just found that at least CBeebies and BBC4 broadcast dvb subtitles. Bye -- Luca ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
