Re: [vdr] Filesystem hierachy standard patch needs review.
Manuel Reimer wrote: So for me it seems to be useless to try to strictly separate VDR's configuration files between static and dynamic. They all should be dynamic and maybe at any time they could get dynamic, if Klaus improves the OSD setup possibilities. I'd still consider a file that is only modified if the user intentionally does so via the remote control static. There's no difference between that and using an editor except for the user interface. Lots of VDR-users use VDR as a standalone system and for those systems /var/spool might be more appropriate than /srv /var/spool is definitively wrong, as this applies to queue-like things. Well, that's your opinion. /srv is right, if the VDR-machine offers the recordings like a NAS or MediaServer, FHS says: | /srv : Data for services provided by this system So as VDR is the primary service of such a box, /srv seems to be OK for me. And many distributions share the recordings via FTP or Samba /srv in theory is taboo for distros (and it is in fact for Fedora) so distros will be forced to patch vdr to use something else. It's fine to use for a self compiled vdr but it's not for a distro package. For me the discussion about the default setting seems to be useless. The current default seems to match the FHS definitions pretty well and any distribution is able to easily add own settings via make parameters or via Make.config. So feel free to override the default and use your own settings. We are forced to do that already anyways. If vdr changes anything wrt fs layout I'd really like to see something acceptable for distros to end the ranting about the different locations of /video. Where are the vdr package maintainers of other distros hiding anyways? cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Filesystem hierachy standard patch needs review.
Klaus Schmidinger wrote: On 09.05.2012 16:36, Manuel Reimer wrote: what is the current status in this topic? Anyone working on this? Attached is a revised version of the patch, as I intend to adopt it in version 1.7.30. Looks like I missed the discussion when this patch was posted originally. Here are my 2¢'s: +VIDEODIR = /srv/vdr/video Using /srv is fishy and some distros like Fedora even disallow packages to put anything there. Recordings are automatically created and potentially also automatically deleted. Some of them you want to keep and some you delete after watching. So IMHO they are some kind of spool file where either the machine or a human decides about their fate. So nine years ago when I started packaging vdr for SUSE I decided to use /var/spool/video (could have been /var/spool/vdr too). The second best candidate would be /var/lib/vdr/something I think. +CONFDIR = /var/lib/vdr Even though vdr may update some of the files there itself I still think they belong to /etc to make sure they are included in backups by default. What's missing is a directory for include files to be able to build plugins separate from vdr. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Please share your systemd (Upstart) service file
Manuel Reimer wrote: Ludwig Nussel wrote: Yes. Not only for better systemd integration but in general it would be better if vdr could work without requiring any external scripting or configuration. You need some external script to call VDR as somewhere it is required to configure plugins and plugin parameters and many more stuff, VDR gets via command line options. That's the current state. I can't think of a good reason why it has to stay that way though. VDR itself could have a menu that allows to enable, disable and configure plugins. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Please share your systemd (Upstart) service file
Paul Menzel wrote: [...] and the one shipped by openSUSE [2]. [Unit] Descritpion=VDR After=lirc.service [Service] Type=once ExecStart=/usr/local/bin/runvdr TimeoutSec=0 The reference to /usr/local makes it pretty obvious that this isn't part of any distro. As the comments in the VDR-Portal thread [2] suggest, it would be great to do without any shell/Bash script and more or less execute plain VDR and let systemd do everything else. Yes. Not only for better systemd integration but in general it would be better if vdr could work without requiring any external scripting or configuration. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Recordings Numbering
Udo Richter wrote: Am 09.11.2010 16:35, schrieb Matthias Wächter: You just re-introduce the old problem. Don't ever re-number. If you don't renumber any SVDRP client can be safe in assuming for (nearly) any time span to mean the same recording as the server when it updates a recording's schedule. In other words, store the unique ID in the info file permanently, right? What happens if two VDR instances write to the same video directory? What if you download a recording from a friend? In that case you might have two recordings with the same ID. How should that be handled? Don't recordings actually already have a unique id? It's the name of the directory they are stored in. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Build failures with gcc 4.4
Klaus Schmidinger wrote: On 04.06.2009 09:12, Ludwig Nussel wrote: ... So gcc 4.4 finally hit openSUSE as well. I use the attached patch to make vdr compile. Seems to work fine too. The code that requires those const casts is really ugly though. How about the attached change? Should apply to VDR 1.6 just as well. Looks better indeed. I've added it to the vdr package in the build service now. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Build failures with gcc 4.4
Ville Skyttä wrote:
On Friday 27 February 2009, Ville Skyttä wrote:
I'm trying to build VDR 1.6.0-2 for the upcoming Fedora 11 release which
has gcc 4.4. There are a bunch of compilation errors as gcc has again
become less forgiving for C++ than it used to be.
One very common source of problems is explained here:
http://markmail.org/message/e5y6atneqztuvpw6#query:
+page:1+mid:hdkehz7bgl5b6vgc+state:results
There are quite a few of these problems in VDR 1.6.0-2 (error: invalid
conversion from 'const char*' to 'char*'). I started patching but quickly
realized that this is a job for someone who actually knows what he's doing.
[...]
...but until there's a real fix available, the attached ugly patch at least
makes the build succeed with gcc 4.4.
So gcc 4.4 finally hit openSUSE as well. I use the attached patch to
make vdr compile. Seems to work fine too. The code that requires
those const casts is really ugly though.
cu
Ludwig
--
(o_ Ludwig Nussel
//\
V_/_ http://www.suse.de/
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg)
Index: vdr-1.6.0/recording.c
===
--- vdr-1.6.0.orig/recording.c
+++ vdr-1.6.0/recording.c
@@ -509,8 +509,8 @@ cRecording::cRecording(cTimer *Timer, co
Utf8Strn0Cpy(SubtitleBuffer, Subtitle, MAX_SUBTITLE_LENGTH);
Subtitle = SubtitleBuffer;
}
- char *macroTITLE = strstr(Timer-File(), TIMERMACRO_TITLE);
- char *macroEPISODE = strstr(Timer-File(), TIMERMACRO_EPISODE);
+ const char *macroTITLE = strstr(Timer-File(), TIMERMACRO_TITLE);
+ const char *macroEPISODE = strstr(Timer-File(), TIMERMACRO_EPISODE);
if (macroTITLE || macroEPISODE) {
name = strdup(Timer-File());
name = strreplace(name, TIMERMACRO_TITLE, Title);
@@ -551,7 +551,7 @@ cRecording::cRecording(const char *FileN
sortBuffer = NULL;
fileName = strdup(FileName);
FileName += strlen(VideoDirectory) + 1;
- char *p = strrchr(FileName, '/');
+ const char *p = strrchr(FileName, '/');
name = NULL;
info = new cRecordingInfo;
@@ -1022,7 +1022,8 @@ void cRecordings::DelByName(const char *
if (recording) {
cThreadLock DeletedRecordingsLock(DeletedRecordings);
Del(recording, false);
- char *ext = strrchr(recording-FileName(), '.');
+ // wtf?
+ char *ext = strrchr(const_castchar*(recording-FileName()), '.');
if (ext) {
strncpy(ext, DELEXT, strlen(ext));
recording-fileSizeMB = DirSizeMB(recording-FileName());
Index: vdr-1.6.0/svdrp.c
===
--- vdr-1.6.0.orig/svdrp.c
+++ vdr-1.6.0/svdrp.c
@@ -736,7 +736,7 @@ void cSVDRP::CmdGRAB(const char *Option)
char *strtok_next;
FileName = strtok_r(p, delim, strtok_next);
// image type:
- char *Extension = strrchr(FileName, '.');
+ const char *Extension = strrchr(FileName, '.');
if (Extension) {
if (strcasecmp(Extension, .jpg) == 0 || strcasecmp(Extension, .jpeg) == 0)
Jpeg = true;
@@ -796,12 +796,12 @@ void cSVDRP::CmdGRAB(const char *Option)
if (FileName) {
if (grabImageDir) {
cString s;
- char *slash = strrchr(FileName, '/');
+ char *slash = strrchr(const_castchar*(FileName), '/');
if (!slash) {
s = AddDirectory(grabImageDir, FileName);
FileName = s;
}
- slash = strrchr(FileName, '/'); // there definitely is one
+ slash = strrchr(const_castchar*(FileName), '/'); // there definitely is one
*slash = 0;
char *r = realpath(FileName, RealFileName);
*slash = '/';
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] can't compile xine for vdr
Darren Salt wrote: I demand that Ludwig Nussel may or may not have written... Andreas Hölscher wrote: I installed a fresh SuSE 11.1 on my computer and tried to compile xine-lib for use with xine vdr plugin. [..doesn't work..] I'm not a programmer, so I don't know what to do now. Can anyone point me in the right direction please? libxine1 as shipped on 11.1 already contains the vdr plugin. Packman has the xine plugins for mpeg. That's binary-incompatible with other distributions. I hope that the soname has been adjusted appropriately... No, I actually haven't paid attention to that problem. AFAICS the ABI incompatible changes affect post_video_port_s in post.h and xine_video_port_s in video_out.h. Only post plugins or new video outputs would be affected by that I guess. So hopefully not that bad after all. cu Ludwig -- (o_ Ludwig Nussel //\ SUSE LINUX Products GmbH, Development V_/_ http://www.suse.de/ ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] can't compile xine for vdr
Andreas Hölscher wrote: I installed a fresh SuSE 11.1 on my computer and tried to compile xine-lib for use with xine vdr plugin. [..doesn't work..] I'm not a programmer, so I don't know what to do now. Can anyone point me in the right direction please? libxine1 as shipped on 11.1 already contains the vdr plugin. Packman has the xine plugins for mpeg. cu Ludwig -- (o_ Ludwig Nussel //\ SUSE LINUX Products GmbH, Development V_/_ http://www.suse.de/ ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Problems building xine-lib on openSUSE 11.0 w/ gcc 4.3.1
Harald Milz wrote: On Wed, Oct 15, 2008 at 06:50:40PM +0200, Harald Milz wrote: On Wed, Oct 15, 2008 at 05:08:10PM +0200, Ludwig Nussel wrote: Packman also offers xine packages built with the same options. But without netvdr as it seems ... Disregard - it's in. But --enable-vdr-keys is not ... That switch apparently doesn't exist anymore. Anyways, if you are still missing anything in the pre-built packages just file a bug report at bugzilla.novell.com. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Problems building xine-lib on openSUSE 11.0 w/ gcc 4.3.1
Harald Milz wrote: this seems to be a famous one, possibly a GCC bug according to some fora. I can't build vdr-xine-0.8.2 and the related xine-lib on openSUSE 11.0 with [...] gcc -O3 ... -O2 ... -Os Use -O2, that works for sure. See the xine backports (which include vdr-xine btw) in the build service: https://build.opensuse.org/project/show?project=multimedia%3Axine Packman also offers xine packages built with the same options. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] TV channel logo collection - logo requests and illustrator/freehand help
Hanno Zulla wrote: The strategy is to ask for vector graphics logos and for permission to use them in OSD and EPG non-commercial open-source applications. This will make the collection versatile enough to be used beyond vdr, e.g for mythtv etc. That 'non-commercial' restriction pretty much prevents plugins with such logos to be included in Linux distributions though. At least it makes the package non-free. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR developer version 1.5.15 - compilation warnings
Klaus Schmidinger wrote: On 02/19/08 21:26, Ludwig Nussel wrote: Klaus Schmidinger wrote: Apparently there are macros for this, like PRId64 and such. But i don't like having to write something like int64_t n = ...; printf(Some number % PRId64 \n, n); Don't know if the gettext mechanisms would be able to handle tr(Some number % PRId64 \n) I wonder why there ar no proper format specifiers for this. Or are there? [...] I really hope we can avoid this insanity in VDR... In this particular case you could change the API to use long long instead of int64_t since long long has eight bytes on the platforms vdr is made for anyways. Alternatively just ignore the warning. The %LX formats should be changed to %llX though as L is only defined for floating point types. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] vdr 1.5.15 rpm packages available
Hi, I've updated the vdr15 package in the build service[1] to version 1.5.15. It's unpatched so don't hesitate to report bugs. The vdr-plugins package now also includes the xine plugin for xine version 1.1.10.1. cu Ludwig [1] http://download.opensuse.org/repositories/vdr/ -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR developer version 1.5.15 - compilation warnings
Klaus Schmidinger wrote: Apparently there are macros for this, like PRId64 and such. But i don't like having to write something like int64_t n = ...; printf(Some number % PRId64 \n, n); Don't know if the gettext mechanisms would be able to handle tr(Some number % PRId64 \n) I wonder why there ar no proper format specifiers for this. Or are there? The gettext info page says: A similar case is compile time concatenation of strings. The ISO C 99 include file `inttypes.h' contains a macro `PRId64' that can be used as a formatting directive for outputting an `int64_t' integer through `printf'. It expands to a constant string, usually d or ld or lld or something like this, depending on the platform. Assume you have code like printf (The amount is %0 PRId64 \n, number); The `gettext' tools and library have special support for these `inttypes.h' macros. You can therefore simply write printf (gettext (The amount is %0 PRId64 \n), number); The PO file will contain the string The amount is %0PRId64\n. The translators will provide a translation containing %0PRId64 as well, and at runtime the `gettext' function's result will contain the appropriate constant string, d or ld or lld. So translations should still work. The ugliness of those macros remains. cu Ludwig -- (o_ Ludwig Nussel //\ SUSE LINUX Products GmbH, Development V_/_ http://www.suse.de/ ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] trouble with asprintf
Udo Richter wrote: Wolfgang Rohdewald wrote: char *s; asprintf(s,%ld-%.9s,random(),artist.original()); segfaults only if illegal utf8 chars appear in artist.original() asprintf returns -1, so s is nothing that could be freed, and this gives a nice backtrace: So its basically just free'ing an uninitialized pointer. Well, that leads to the question whether s is unchanged in case of a -1 error return, and whether this would work: char *s = NULL; asprintf(s,%ld-%.9s,random(),artist.original()); The manpage explicitly says that the content of s is undefined in case of error. So even if it works you can't really count on it. You can't get around checking the return value. cu Ludwig -- (o_ Ludwig Nussel //\ SUSE LINUX Products GmbH, Development V_/_ http://www.suse.de/ ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] trouble with asprintf
Darren Salt wrote:
I demand that Ludwig Nussel may or may not have written...
[snip]
asprintf needs to check for multibyte characters to not cut them in
the middle and produce invalid output.
No - it's encoding-neutral. What you want is your own version which does that
Try the following with 'LANG=C' and 'LANG=de_DE.UTF-8'. You will
notice that in the latter case it will not cut the umlaut.
#define _GNU_SOURCE
#include stdio.h
#include string.h
#include stdlib.h
#include locale.h
int main(void)
{
char* buffer;
char artist[] = Haegar;
int ret;
setlocale(LC_ALL, );
artist[1]=0xc3;
artist[2]=0xa4;
ret = asprintf(buffer,%.2s\n,artist);
printf(%d bytes\n, ret);
printf(buffer);
free(buffer);
return 0;
}
cu
Ludwig
--
(o_ Ludwig Nussel
//\
V_/_ http://www.suse.de/
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg)
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] trouble with asprintf
Wolfgang Rohdewald wrote:
My problem code:
mgDb::Build_cddbid(const mgSQLString artist) const
{
char *s;
asprintf(s,%ld-%.9s,random(),artist.original());
segfaults only if illegal utf8 chars appear in artist.original()
asprintf returns -1, so s is nothing that could be freed,
and this gives a nice backtrace:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1319449712 (LWP 22989)]
0xb7bf57ea in free () from /lib/tls/i686/cmov/libc.so.6
(gdb) bt
#0 0xb7bf57ea in free () from /lib/tls/i686/cmov/libc.so.6
#1 0xb7986908 in mgDb::Build_cddbid (this=0x86ed8e8, [EMAIL PROTECTED]) at
mg_db.c:1023
As you can see it doesn't segfault on asprintf but on free().
If I change %.9s to %s, everything is fine.
I cannot easily simplify that, if I try like this, it works:
char artist[50];
strcpy(artist,Celine Dion);
artist[1]=0xe9;
asprintf(buffer,%ld-%.9s,random(),artist);
printf(buffer);
free(buffer);
if(asprintf(...) = 0)
{
printf(...);
free(...);
}
Or just use normal snprintf as the amount of charactes to print is
fixed anyways so you don't need a variable sized buffer.
cu
Ludwig
--
(o_ Ludwig Nussel
//\
V_/_ http://www.suse.de/
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg)
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] trouble with asprintf
Wolfgang Rohdewald wrote:
since asprintf leads to segfaults if feeded with incorrect UTF-8 characters,
It's not asprintf that segfaults but the call to free uninitialized
memory afterwards.
I wanted to write a wrapper function which would then check the return value
of asprintf. However I have a problem with the variable argument list and
the va_* macros. Using gdb shows that, in the following example, in
res=asprintf (strp, fmt, ap);
ap is interpreted not as a list of arguments but as an integer.
use vasprintf
int
msprintf(char **strp, const char *fmt, ...)
{
va_list ap;
int res;
va_start (ap, fmt);
res=asprintf (strp, fmt, ap);
va_end (ap);
}
Even if you use vasprintf to make the function actually work you
still need to check the return value of vasprintf otherwise this
wrapper would be kind of useless.
cu
Ludwig
--
(o_ Ludwig Nussel
//\
V_/_ http://www.suse.de/
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg)
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] trouble with asprintf
Udo Richter wrote: Wolfgang Rohdewald wrote: since asprintf leads to segfaults if feeded with incorrect UTF-8 characters, I wanted to write a wrapper function which would then check the return value of asprintf. I never understood what the problem is with utf8 and asprintf, since utf8 is mostly ASCIIZ backwards compatible, and asprintf probably doesn't even know the difference between utf8 and ascii. What special handling does asprintf with utf8? Is there some example that causes the trouble? asprintf needs to check for multibyte characters to not cut them in the middle and produce invalid output. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Straw poll: stable version 1.6.0 now?
Klaus Schmidinger wrote: Should there be a stable version 1.6.0 now, based on what's in version 1.5.14, but without DVB-S2 or even H.264 support? Yes. It would be pity if that means that the stable version stays at 1.6.0 and doesn't receive any more bugfixes though. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Straw poll: stable version 1.6.0 now?
Ville-Pekka Vainio wrote: I've been using VDR for about a year and a half now and it's great. But with all due respect, I think you're doing this the wrong way around. At least here in Finland, decent DVB subtitles support is pretty much the only thing VDR needs to be usable out-of-the-box with the free channels we have. If ttxtsubs are that important and require patches to vdr, why don't we see them posted and discussed on the list? cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Straw poll: stable version 1.6.0 now?
Klaus Schmidinger wrote: On 02/04/08 09:46, Ludwig Nussel wrote: Ville-Pekka Vainio wrote: I've been using VDR for about a year and a half now and it's great. But with all due respect, I think you're doing this the wrong way around. At least here in Finland, decent DVB subtitles support is pretty much the only thing VDR needs to be usable out-of-the-box with the free channels we have. If ttxtsubs are that important and require patches to vdr, why don't we see them posted and discussed on the list? I believe there is a patch for that, but that's not the way I want to implement it. I want to convert the incoming teletext subtitles to DVB subtitles, so that on the recording/display side we only need to deal with one type of subtitles. (Besides, I guess some day teletext subtitles will become obsolete, anyway). Well, that's exactly the kind of feedback I'd expect if someone had actually posted the patch. Anyone out there who wants to step up now and implement it that way? :-) cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Howto vdr-xine installation
serge pecher wrote: I used to use the opensuse dvb-s2 wiki page to follow the instructions about the installation of xine-lib 1.2 and vdr-xine. If you don't need dvb-s2 and hdtv you may use the vdr/vdr15 and vdr-plugins packages from the build service: http://download.opensuse.org/repositories/vdr/openSUSE_10.3/repodata/ vdr-xine is now included in vdr-plugins. There is also xine-lib patched with the vdr-xine patch. You'll need to get the codecs required to decode mpeg2 elsewhere though. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [PATCH] Old DVB API patch for VDR-1.5.14
Udo Richter wrote: Asking myself if I want to build kernels and drivers for 4 different PCs or try my luck with an old DVB API patch for vdr-1.5.14, I've chosen the latter. The attached patch implements fallback for VDR in case no multiproto DVB driver headers are available. Nice, thanks! I wouldn't use the term emulate though. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.5.14
Klaus Schmidinger wrote: - Implemented handling of DVB-S2 (thanks to Marco Schlüßler and Reinhald Nissl for a patch that was used to implement this). VDR now requires the multiproto DVB driver, e.g. from http://jusst.de/hg/multiproto. Would it be possible to make that optional via compile time define? cu Ludwig -- (o_ Ludwig Nussel //\ SUSE LINUX Products GmbH, Development V_/_ http://www.suse.de/ ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.5.14
Klaus Schmidinger wrote: On 01/27/08 16:25, Ludwig Nussel wrote: Klaus Schmidinger wrote: - Implemented handling of DVB-S2 (thanks to Marco Schlüßler and Reinhald Nissl for a patch that was used to implement this). VDR now requires the multiproto DVB driver, e.g. from http://jusst.de/hg/multiproto. Would it be possible to make that optional via compile time define? I guess so, but I'm not going to ;-) This new driver appears to be stable enough now - at least I've been using it for a few days now without problems. *sigh* messing with kernel stuff sucks. Does a vdr built with the multiproto headers at least also work on vanilla kernels ie stable dvb drivers? That way one would only need to use different headers for building vdr but no extra kernel modules at run time. cu Ludwig -- (o_ Ludwig Nussel //\ SUSE LINUX Products GmbH, Development V_/_ http://www.suse.de/ ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.5.14
Klaus Schmidinger wrote: On 01/27/08 16:54, Ludwig Nussel wrote: Klaus Schmidinger wrote: On 01/27/08 16:25, Ludwig Nussel wrote: Klaus Schmidinger wrote: - Implemented handling of DVB-S2 (thanks to Marco Schlüßler and Reinhald Nissl for a patch that was used to implement this). VDR now requires the multiproto DVB driver, e.g. from http://jusst.de/hg/multiproto. Would it be possible to make that optional via compile time define? I guess so, but I'm not going to ;-) This new driver appears to be stable enough now - at least I've been using it for a few days now without problems. *sigh* messing with kernel stuff sucks. Does a vdr built with the multiproto headers at least also work on vanilla kernels ie stable dvb drivers? That way one would only need to use different headers for building vdr but no extra kernel modules at run time. I don't know. I just grab the latest driver from http://jusst.de/hg/multiproto and compile it on my SUSE 10.3 system, running the stock SUSE kernel. So just unload all DVB modules that come with the stock kernel and load the ones from the multiproto driver. Works fine for me. Works fine now, breaks tomorrow. We had the dvb kernel module package long enough and I was so glad when the dvb drivers finally went into the upstream kernel. I'm not going to maintain another kernel module package again. I just tried a vdr built with the multiproto headers with normal dvb drivers. Doesn't work. That means vdr 1.5.13 is the last version I can build useful packages for atm. cu Ludwig -- (o_ Ludwig Nussel //\ SUSE LINUX Products GmbH, Development V_/_ http://www.suse.de/ ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.5.14
Manu Abraham wrote: Ludwig Nussel wrote: Klaus Schmidinger wrote: On 01/27/08 16:25, Ludwig Nussel wrote: Klaus Schmidinger wrote: - Implemented handling of DVB-S2 (thanks to Marco Schlüßler and Reinhald Nissl for a patch that was used to implement this). VDR now requires the multiproto DVB driver, e.g. from http://jusst.de/hg/multiproto. Would it be possible to make that optional via compile time define? I guess so, but I'm not going to ;-) This new driver appears to be stable enough now - at least I've been using it for a few days now without problems. *sigh* messing with kernel stuff sucks. Does a vdr built with the multiproto headers at least also work on vanilla kernels ie stable dvb drivers? That way one would only need to use different headers for building vdr but no extra kernel modules at run time. AFAICT, the updated headers can be used along with the old drivers without any issues. If not there's an issue with regards to backward compatibility. Can you pleas point out the errors that which you see, when you are using the updated headers and the old drivers ? I just did a quick test and didn't debug it further. IIRC the only vdr error message was an error from the DVBFE_GET_DELSYS ioctl. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] improved LIRC remote for VDR-1.5.12
Nicolas Huillard wrote: Reinhard Nissl a écrit : Dominique Matz schrieb: sound very good, but vdr as root do not :-( do you think it is possible to use this or something else with an non root user? Well, only the LIRC_PRIORITYBOOST option requires root privileges to work. If you don't have root privileges, you'll just get an error logged and the LIRC thread runs without any change in priority -- that's all. See man setpriority for details. An option would be to lower priority of all threads except this one. I guess only relative priority within VDR is important. You can also raise priority in your init scripts (nice=-N), before running VDR. This way every thread will have nice=0 priority, except the LIRC one, which will stay at nice=-N Since the lirc thread doesn't do anything except waiting for input most of the time it should be scheduled quickly anyways. Maybe the useless select timeout destroys that advantage somewhat. Also if multiple lines in the buffer are a problem what about changing the code to consume only one line at a time instead of messing with thread priorities? cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] vdr 1.5.10 SUSE rpm packages available
Hi, I finally managed to update the vdr15 package to version 1.5.10. The RPMs can be downloaded from [1] once the build process is finished. I've also updated vdr-xine in vdr-plugins to 0.7.12, you'll need to manually rebuild the package against xine-lib from factory though since xine is currently missing from the build service. cu Ludwig [1] http://download.opensuse.org/repositories/vdr/ -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Not good behaviour from vdr
Klaus Schmidinger wrote: On 09/29/07 09:30, Timothy D. Lenz wrote: I don't know about it restarting. The crashing with loss of signal is suposed to be a safe guard against creating blank recordings. Seems like a bad idea to me to. Just delete the bad recordings, don't crash the system. Well, let me just comment on the nomenclature here ;-) When VDR does an emergency exit because there is no video data for a while, this is a *controlled* action that shall allow the driver to be reloaded. Full featured cards sometimes have the problem that they completely lock up, and reloading the driver fixes this. I wonder whether reloading modules is still an appropriate action. Nowadays it's possible for example to bind/unbind drivers to/from specific devices. Ie if you have multiple dvb-ttpci cards it should be possible to reset a specific one. Maybe it would even be possible to implement some kind of reset ioctl in the kernel drivers so vdr doesn't need to rely on external scripts at all. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.5.7
Klaus Schmidinger wrote:
On 08/19/07 12:43, Anssi Hannula wrote:
Anssi Hannula wrote:
It seems that it *does* work, i.e. LANGUAGE=de, LANGUAGE=fr, LANGUAGE=fi
will work even if there is no such locale at all.
I copied a .mo file into /usr/share/locale/testtest/LC_MESSAGES/, which
certainly is not a valid locale, and using LANGUAGE=testtest it was
correctly used! :)
Looks good. However, after some tests it would appear as if only the
very first setenv() call actually changes anything. Subsequent calls
have no further effect, and gettext() always returns the language
that was selected in the very first call to setenv().
The gettext info page says:
But there is one little hook. The code for gcc-2.7.0 and up
provides some optimization. This optimization normally prevents
the calling of the `dcgettext' function as long as no new catalog
is loaded. But if `dcgettext' is not called the program also
cannot find the `LANGUAGE' variable be changed (*note Optimized
gettext::). A solution for this is very easy. Include the
following code in the language switching function.
/* Change language. */
setenv (LANGUAGE, fr, 1);
/* Make change known. */
{
extern int _nl_msg_cat_cntr;
++_nl_msg_cat_cntr;
}
cu
Ludwig
--
(o_ Ludwig Nussel
//\ SUSE LINUX Products GmbH, Development
V_/_ http://www.suse.de/
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] change make install to be really useful
Matthias Schwarzott wrote: On Mittwoch, 15. August 2007, Klaus Schmidinger wrote: On 08/13/07 18:30, Matthias Schwarzott wrote: ... makefile-install-header.diff: It adds an install-header target which is also called by target install. This installs the header files and Make.config to $(HEADERDIR) (should that be changed to INCDIR ?) to be able to compile plugins against the installed vdr without the need to keep vdr sources. This doesn't make sense, because a plugin's Makefile does VDRDIR = ../../.. ... APIVERSION = $(shell sed -ne '/define APIVERSION/s/^.*\(.*\).*$$/\1/p' $(VDRDIR)/config.h) Sure one needs to point the plugin to the place where it can find the needed files. But I have not tried to find the minimal required changeset. Have a look at the SUSE vdr package. It installs headers and Make.config into /usr/include/vdr. When compiling plugins you have to use make VDRDIR=/usr/include/vdr LIBDIR=/usr/lib/vdr all. cu Ludwig -- (o_ Ludwig Nussel //\ SUSE LINUX Products GmbH, Development V_/_ http://www.suse.de/ ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] vdr 1.5.3 SUSE Linux rpm packages available
Hi, I've added vdr 1.5 to the buildservice now as well. Packages are available for 10.0, 10.1 and 10.2 at http://software.opensuse.org/download/vdr/ The package is called 'vdr15' and uses a different configuration directory so it can be installed in addition to the 1.4 version. The vdr-plugins package contains plugins both 1.4 as well as 1.5. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.5.3
Klaus Schmidinger wrote: I'm considering compiling one font file directly into the program, so that, in case no external fonts can be found, it can at least run properly. Can somebody suggest a freetype font that looks good, covers all necessary locales, and is really free, so that it can be redistributed with the VDR source? What about falling back to the bitmap font vdr currently uses? It would only be able to display ASCII but that would be sufficient to at least start up vdr in english. OTOH you can always puts(install true type fonts); exit(1) :-) cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.5.3
Klaus Schmidinger wrote: On 06/11/2007 10:08 AM, Oleg Roitburd wrote: Am Sonntag, 10. Juni 2007 15:45 schrieb Klaus Schmidinger: VDR developer version 1.5.3 is now available at ftp://ftp.cadsoft.de/vdr/Developer/vdr-1.5.3.tar.bz2 Now I'm running this version. And I would say: Converting of EPG to UTF-8 don't work My system has DVB-T card and I'm receiving only German ÖRP In schedule menuitem I can't see any umlaut or ß $LANG is setting to en_US.UTF-8 Please check whether the log says that the codeset is known (should be right after VDR's startup message). You may need to set LANG=en_US.utf8 (without the '-'). Maybe the strings in libsi/si.c should contain the extra '-'s, not sure what's best. $ LC_ALL=en_US.utf8 locale collate-codeset UTF-8 so the canonical spelling is UTF-8. As already suggested using nl_langinfo() instead of manually parsing enviroment variables is probably the better choice though. For my stable version 1.4.x I'm using UTF patch from Alexander Riedel. As I remember he has inserted extra field for channel codepage. And this works. Using such an extra field is not the way to go, because there is no standard way to fill it in (or is there?). ACK, considering that libsi can automatically determine the encoding for individual strings it seems to be awkward having to specify encodings per channel in channels.conf. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.5.3
Klaus Schmidinger wrote: The latest version of libsi does use the character encodings specified in the SI data for each string. Unfortunately, though, a certain German pay tv broadcaster doesn't adhere to the standard and sends the data in iso8859, but without marking the strings accordingly. So VDR assumes that they are ISO6937 (which is the default if no encoding is specified) and therefore converts the umlauts to garbage. But that's their fault, not VDR's... How do standalone dvb receivers deal with that? Do they have an extra workaround for that particular broadcaster? cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] A few observations on the vdr project
Klaus Schmidinger wrote: On 05/10/07 20:04, Udo Richter wrote: ... VDR development would speed up, if Klaus would delegate more work to other talented coders, and doing more review instead of coding most of it himself. Well, right now I'm dealing with the UTF-8 stuff, which is something I myself don't need at all. But unfortunately the patch(es) for this can't just be applied as it, because from what I've seen so far there it is assumed that the whole program is totally going UTF-8 - which it is *not*. I still want to be able to run it on a pure and clean iso8859-1 system. So I have to painstakingly go through the whole thing and take care that it only does UTF-8 if so requested - and that's a lot more work than just applying a patch... What's wrong with vdr using UTF-8 internally if it makes the code simpler? Offhand I could only imagine two places where using a different external encoding would be required and that's file names and tty i/o. Stuff like epg.data and svdrp should better use UTF-8 as you don't need to add extra meta data options to specify the encoding. cu Ludwig -- (o_ Ludwig Nussel //\ SUSE Labs V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] A few observations on the vdr project
Klaus Schmidinger wrote: On 05/11/2007 09:25 AM, Ludwig Nussel wrote: What's wrong with vdr using UTF-8 internally if it makes the code simpler? Offhand I could only imagine two places where using a different external encoding would be required and that's file names and tty i/o. Stuff like epg.data and svdrp should better use UTF-8 as you don't need to add extra meta data options to specify the encoding. It's very simple: I don't like it! The two languages I can handle can be perfectly well represented with iso8859-1, so I just don't want to have to go through all the hassle with UTF-8. To me, a character is a character is a byte is a byte. Period. Come on, take some Scheissegalpillen and stop beeing stubborn ;-) I aggree that UTF-8 isn't exactly delightful but from a user's point of view the hassle with UTF-8 is less than the hassle having to deal with multiple encodings. I mean even when ignoring languages other than German you have trouble with the stupid euro sign when using iso8859-*. Look at the bright side of UTF-8, at most places you don't really have to care about the actual characters so you don't need special treatment. After all it could be worse. If the new standard would be a fixed width multibyte encoding with embedded null bytes you'd have to really rewrite all your code. cu Ludwig -- (o_ Ludwig Nussel //\ SUSE Labs V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] plugin loading
e9hack wrote: Something is wrong in processplugins from runvdr (suse 10.1). 'VDR_PLUGINS' is set to 'dvd femon epgsearch lcdproc reelchannelscan wirbelscan atmo'. If my buggy image plugin does exist in the lib directory, 'missing_plugins' is set to 'dvd wirbelscan femon lcdproc epgsearch' and 'installed_plugins' is set to 'reelchannelscan atmo'. If the buggy plugin doesn't exist in the lib directory, 'missing_plugins' is empty and 'installed_plugins' is set with the content from 'VDR_PLUGINS'. Does vdr --version output anything unusal that could confuse the awk script inside runvdr? cu Ludwig -- (o_ Ludwig Nussel //\ SUSE LINUX Products GmbH, Development V_/_ http://www.suse.de/ ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] plugin loading
e9hack wrote: Udo Richter wrote: e9hack wrote: I've selected some plugins for loading. It exist ca. 100 plugins in the vdr lib directory. Does vdr load only the selected plugins or all plugins? There is no common way how the plugins get selected for loading. VDR itself does not load plugins unless instructed. (except for --version and --help) Plugins get loaded by the -P or --plugin command line option, by modifying the runvdr script that is part of the VDR sources, or by distribution dependent load mechanisms in case you're using pre-built packages. It seems, it is a problem of the runvdr script from suse. The script prepares a list of installed and missing plugins from a list of selected plugins. The script does some bogus things, if it exist an plugin with wrong import entries. What kind of bogus things do you mean? The script runs vdr --version to filter out obviously not working plugins, that's all. cu Ludwig -- (o_ Ludwig Nussel //\ SUSE Labs V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR version 1.4.5 released
Klaus Schmidinger wrote: VDR version 1.4.5 is now available at ftp://ftp.cadsoft.de/vdr/vdr-1.4.5.tar.bz2 I have updated the SUSE Linux RPM packages at http://software.opensuse.org/download/vdr/ to 1.4.5 as well. I have also added the vdr-plugins package. It contains some additional plugins. cu Ludwig -- (o_ Ludwig Nussel //\ SUSE LINUX Products GmbH, Development V_/_ http://www.suse.de/ ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR version 1.4.3 released
On Saturday 23 September 2006 16:16, Klaus Schmidinger wrote: VDR version 1.4.3 is now available at ftp://ftp.cadsoft.de/vdr/vdr-1.4.3.tar.bz2 1.4.3 RPM packages for SUSE Linux are now available via the build service: http://software.opensuse.org/download/repositories/vdr/ I've finally moved 1.4 into the 'vdr' package. The 'vdr13' package used for testing development versions therefore is obsolete and gets unistalled upon installation of the 1.4 package. cu Ludwig -- (o_ Ludwig Nussel //\ SUSE LINUX Products GmbH, Development V_/_ http://www.suse.de/ ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR version 1.4.2 released
On Sunday 27 August 2006 11:17, Klaus Schmidinger wrote: VDR version 1.4.2 is now available at ftp://ftp.cadsoft.de/vdr/vdr-1.4.2.tar.bz2 FWIW I've updated the SUSE Linux RPM packages to 1.4.2 as well http://software.opensuse.org/download/repositories/vdr/ cu Ludwig -- (o_ Ludwig Nussel //\ SUSE LINUX Products GmbH, Development V_/_ http://www.suse.de/ ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
