Re: [vdr] Minor *.po patch
On 04.12.2010 13:09, Tobias Grimm wrote: The gettext version I use automatically adds a Language field to the headers of the po-Files. It would be nice to have this field there in the first place, so here's a small patch that adds it. According to a patch I recevied from Ville Skyttä a while ago the Language... entries currently look like this in my source (which will become VDR version 1.7.17): po/ar.po:Language-Team: Arabic a...@li.org\n po/ar.po:Language: ar\n po/ca_ES.po:Language-Team: Catalan vdr@linuxtv.org\n po/ca_ES.po:Language: ca\n po/cs_CZ.po:Language-Team: Czech vdr@linuxtv.org\n po/cs_CZ.po:Language: cs\n po/da_DK.po:Language-Team: Danish vdr@linuxtv.org\n po/da_DK.po:Language: da\n po/de_DE.po:Language-Team: German vdr@linuxtv.org\n po/de_DE.po:Language: de\n po/el_GR.po:Language-Team: Greek vdr@linuxtv.org\n po/el_GR.po:Language: el\n po/es_ES.po:Language-Team: Spanish vdr@linuxtv.org\n po/es_ES.po:Language: es\n po/et_EE.po:Language-Team: Estonian vdr@linuxtv.org\n po/et_EE.po:Language: et\n po/fi_FI.po:Language-Team: Finnish vdr@linuxtv.org\n po/fi_FI.po:Language: fi\n po/fr_FR.po:Language-Team: French vdr@linuxtv.org\n po/fr_FR.po:Language: fr\n po/hr_HR.po:Language-Team: Croatian vdr@linuxtv.org\n po/hr_HR.po:Language: hr\n po/hu_HU.po:Language-Team: Hungarian vdr@linuxtv.org\n po/hu_HU.po:Language: hu\n po/it_IT.po:Language-Team: Italian vdr@linuxtv.org\n po/it_IT.po:Language: it\n po/lt_LT.po:Language-Team: Lithuanian vdr@linuxtv.org\n po/lt_LT.po:Language: lt\n po/mk_MK.po:Language-Team: Macedonian e...@li.org\n po/mk_MK.po:Language: mk\n po/nl_NL.po:Language-Team: Dutch vdr@linuxtv.org\n po/nl_NL.po:Language: nl\n po/nn_NO.po:Language-Team: Norwegian Nynorsk vdr@linuxtv.org\n po/nn_NO.po:Language: nn\n po/pl_PL.po:Language-Team: Polish vdr@linuxtv.org\n po/pl_PL.po:Language: pl\n po/pt_PT.po:Language-Team: Portuguese vdr@linuxtv.org\n po/pt_PT.po:Language: pt\n po/ro_RO.po:Language-Team: Romanian vdr@linuxtv.org\n po/ro_RO.po:Language: ro\n po/ru_RU.po:Language-Team: Russian vdr@linuxtv.org\n po/ru_RU.po:Language: ru\n po/sk_SK.po:Language-Team: Slovak vdr@linuxtv.org\n po/sk_SK.po:Language: sk\n po/sl_SI.po:Language-Team: Slovenian vdr@linuxtv.org\n po/sl_SI.po:Language: sl\n po/sv_SE.po:Language-Team: Swedish vdr@linuxtv.org\n po/sv_SE.po:Language: sv\n po/tr_TR.po:Language-Team: Turkish vdr@linuxtv.org\n po/tr_TR.po:Language: tr\n po/uk_UA.po:Language-Team: Ukrainian vdr@linuxtv.org\n po/uk_UA.po:Language: uk\n po/zh_CN.po:Language-Team: Chinese (simplified) vdr@linuxtv.org\n po/zh_CN.po:Language: zh_CN\n Please advise whether this is correct. Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Minor *.po patch
On Sunday 12 December 2010, Klaus Schmidinger wrote: On 04.12.2010 13:09, Tobias Grimm wrote: The gettext version I use automatically adds a Language field to the headers of the po-Files. It would be nice to have this field there in the first place, so here's a small patch that adds it. According to a patch I recevied from Ville Skyttä a while ago the Language... entries currently look like this in my source (which will become VDR version 1.7.17): [...] Please advise whether this is correct. I believe it is, see rest of the messages in this thread. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Request: E parameter in channels.conf for epg scan
On 09.12.2010 07:59, Steffen Barszus wrote: On Wed, 08 Dec 2010 23:22:05 +0100 Klaus Schmidinger klaus.schmidin...@tvdr.de wrote: On 08.12.2010 20:25, Jochen Dolze wrote: To be able using other epg sources with other event ids as from the broadcaster. Today i cannot add 14 days of external epg without patching. Why would you have to patch VDR for that? External event's by default have a table id if 0, which means they will never be overwritten by data from the transponder. You will get duplicate EPG entries if the time doesn't match Hmm, I see. So how about changing cEIT in such a way that it never overwrites any events in a schedule if the first existing event in that schedule has a table id of 0? Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Include Path in Makefile (VDR =1.7.15)
On 20.11.2010 11:39, Joachim Wilke wrote: 2010/11/19 Hans-Peter Jansen h...@urpla.net: The HISTORY file states: Include paths are now added instead of overwriting INCLUDES in the Makefile However, in the Makefile changes: -INCLUDES = -I/usr/include/freetype2 +INCLUDES ?= -I/usr/include/freetype2 Shouldn't that be += instead of ?=. No, the conditional variable assignment operator ?= allows one to replace this variable via command line/environment. Thats not what the HISTORY reads. Either the Makefile or the HISTORY should be changed. This change was posted here on the list by Paul Menzel on 2010-04-05. I guess the phrase Include paths are now added instead of overwriting... in the HISTORY was my fault. @Paul: would it be ok with you to make this INCLUDES += -I/usr/include/freetype2 instead of INCLUDES ?= -I/usr/include/freetype2 Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] CAM auto resetting - feature request??
On 01.12.2010 16:28, Halim Sahin wrote:
Hi,
On Sun, Dec 06, 2009 at 04:42:02PM +0100, Klaus Schmidinger wrote:
On 01.09.2009 23:38, Simon Baxter wrote:
I was afraid that might be the suggestion!
It seems pretty random when the CAM will crash. It is possible it's
only on certain channels, and only one of the CAMs - it only happens
very rarely
So you have 2 identical CAMs (Alphacrypt) (with the same firmware?),
and exactly one of them sometimes fails, right?
Have you tried swapping the two CAMs?
This should tell us whether the problem is with the CAM or with
the CI adapter.
Klaus
I've discovered this happens to both CAMs, so it's either not a hardware
issue, or both CAMs are affected.
Managed to capture the following logs prior to the CAM dropping from
AlphaCrypt to CAM Ready (with no decrypting)
Sep 2 08:17:21 freddy vdr: [27702] switching to channel 11
Sep 2 08:17:21 freddy vdr: [1150] transfer thread ended (pid=27702,
tid=1150)
Sep 2 08:17:21 freddy vdr: [27702] buffer stats: 110356 (5%) used
Sep 2 08:17:21 freddy vdr: [6564] transfer thread started (pid=27702,
tid=6564)
Sep 2 08:17:21 freddy vdr: [1152] TS buffer on device 1 thread ended
(pid=27702, tid=1152)
Sep 2 08:17:21 freddy vdr: [1151] buffer stats: 75388 (3%) used
Sep 2 08:17:21 freddy vdr: [1151] receiver on device 1 thread ended
(pid=27702, tid=1151)
Sep 2 08:17:21 freddy vdr: [6565] receiver on device 1 thread started
(pid=27702, tid=6565)
Sep 2 08:17:21 freddy vdr: [6566] TS buffer on device 1 thread started
(pid=27702, tid=6566)
Sep 2 08:17:23 freddy vdr: [6564] setting audio track to 1 (0)
Sep 2 08:17:34 freddy vdr: [27702] switching to channel 1
Sep 2 08:17:34 freddy vdr: [6564] transfer thread ended (pid=27702,
tid=6564)
Sep 2 08:17:34 freddy vdr: [27702] cTS2PES got 0 TS errors, 2 TS
continuity errors
Sep 2 08:17:34 freddy vdr: [27702] cTS2PES got 0 TS errors, 2 TS
continuity errors
Sep 2 08:17:34 freddy vdr: [27702] buffer stats: 63544 (3%) used
Sep 2 08:17:34 freddy vdr: [6567] transfer thread started (pid=27702,
tid=6567)
Sep 2 08:17:34 freddy vdr: [6566] TS buffer on device 1 thread ended
(pid=27702, tid=6566)
Sep 2 08:17:34 freddy vdr: [6565] buffer stats: 62980 (3%) used
Sep 2 08:17:34 freddy vdr: [6565] receiver on device 1 thread ended
(pid=27702, tid=6565)
Sep 2 08:17:34 freddy vdr: [6568] receiver on device 1 thread started
(pid=27702, tid=6568)
Sep 2 08:17:34 freddy vdr: [6569] TS buffer on device 1 thread started
(pid=27702, tid=6569)
Sep 2 08:17:38 freddy vdr: [6567] transfer thread ended (pid=27702,
tid=6567)
Sep 2 08:17:38 freddy vdr: [6569] TS buffer on device 1 thread
ended
(pid=27702, tid=6569)
Sep 2 08:17:38 freddy vdr: [6568] buffer stats: 193828 (9%) used
Sep 2 08:17:38 freddy vdr: [6568] receiver on device 1 thread ended
(pid=27702, tid=6568)
Sep 2 08:17:39 freddy vdr: [27702] switching to channel 1
Sep 2 08:17:39 freddy vdr: [27702] buffer stats: 116748 (5%) used
Sep 2 08:17:39 freddy vdr: [27702] info: Channel not available!
Sep 2 08:17:41 freddy vdr: [27702] switching to channel 9
Sep 2 08:17:41 freddy vdr: [6570] transfer thread started (pid=27702,
tid=6570)
Sep 2 08:17:41 freddy vdr: [6570] setting audio track to 1 (0)
Sep 2 08:17:54 freddy vdr: [27707] ERROR: can't write to CI adapter on
device 0: Input/output error
Sep 2 08:17:54 freddy vdr: [27707] ERROR: can't write to CI adapter on
device 0: Input/output error
Sep 2 08:17:55 freddy vdr: [27707] ERROR: can't write to CI adapter on
device 0: Input/output error
Sep 2 08:17:55 freddy kernel: dvb_ca adapter 0: DVB CAM detected and
initialised successfully
This looks more like a driver bug to me.
Well maybe but unfortunately responds to my mails in linux-dvb /
linux-media mailinglist for that problem.
@Klaus:
If that problem happens, a manual reset of the cam under vdr's
menu-settings-ci brings the cam back.
What about trying to reset a cam automatically when it's Status is !=
msReady?
Like this:
diff --git a/device.c b/device.c
index 681049b..7904de2 100644
--- a/device.c
+++ b/device.c
@@ -239,6 +239,8 @@ cDevice *cDevice::GetDevice(const cChannel *Channel, int
Priority, bool LiveView
if (Channel-Ca() = CA_ENCRYPTED_MIN) {
for (cCamSlot *CamSlot = CamSlots.First(); CamSlot; CamSlot =
CamSlots.Next(CamSlot)) {
SlotPriority[CamSlot-Index()] = MAXPRIORITY + 1; // assumes it
can't be used
+ if (CamSlot-ModuleStatus() == msPresent)
+CamSlot-Reset();
if (CamSlot-ModuleStatus() == msReady) {
if (CamSlot-ProvidesCa(Channel-Caids())) {
if (!ChannelCamRelations.CamChecked(Channel-GetChannelID(),
CamSlot-SlotNumber())) {
Have you tested this?
Did it actually work?
Klaus
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Include Path in Makefile (VDR =1.7.15)
Am Sonntag, den 12.12.2010, 16:29 +0100 schrieb Klaus Schmidinger: On 20.11.2010 11:39, Joachim Wilke wrote: 2010/11/19 Hans-Peter Jansen h...@urpla.net: The HISTORY file states: Include paths are now added instead of overwriting INCLUDES in the Makefile However, in the Makefile changes: -INCLUDES = -I/usr/include/freetype2 +INCLUDES ?= -I/usr/include/freetype2 Shouldn't that be += instead of ?=. No, the conditional variable assignment operator ?= allows one to replace this variable via command line/environment. Thats not what the HISTORY reads. Either the Makefile or the HISTORY should be changed. This change was posted here on the list by Paul Menzel on 2010-04-05. The link to the message in the archive is [1]. I guess the phrase Include paths are now added instead of overwriting... in the HISTORY was my fault. @Paul: would it be ok with you to make this INCLUDES += -I/usr/include/freetype2 instead of INCLUDES ?= -I/usr/include/freetype2 Reading my commit message, In some environments, i. e. when cross building, include files are not located in the standard path like `/usr/includes/freetype2`. Make it possible to provide the correct path without needing to patch `Makefile`. I would say that it would not work when cross compiling. I am no expert though. I would recommend to change the entry in HISTORY and I will ask on openembedded-devel what they suggest. Thanks, Paul [1] http://www.linuxtv.org/pipermail/vdr/2010-April/022831.html signature.asc Description: This is a digitally signed message part ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Include Path in Makefile (VDR =1.7.15)
Am Sonntag, den 12.12.2010, 16:46 +0100 schrieb Paul Menzel: Am Sonntag, den 12.12.2010, 16:29 +0100 schrieb Klaus Schmidinger: On 20.11.2010 11:39, Joachim Wilke wrote: 2010/11/19 Hans-Peter Jansen h...@urpla.net: The HISTORY file states: Include paths are now added instead of overwriting INCLUDES in the Makefile However, in the Makefile changes: -INCLUDES = -I/usr/include/freetype2 +INCLUDES ?= -I/usr/include/freetype2 Shouldn't that be += instead of ?=. No, the conditional variable assignment operator ?= allows one to replace this variable via command line/environment. Thats not what the HISTORY reads. Either the Makefile or the HISTORY should be changed. This change was posted here on the list by Paul Menzel on 2010-04-05. The link to the message in the archive is [1]. I guess the phrase Include paths are now added instead of overwriting... in the HISTORY was my fault. @Paul: would it be ok with you to make this INCLUDES += -I/usr/include/freetype2 instead of INCLUDES ?= -I/usr/include/freetype2 Reading my commit message, In some environments, i. e. when cross building, include files are not located in the standard path like `/usr/includes/freetype2`. Make it possible to provide the correct path without needing to patch `Makefile`. I would say that it would not work when cross compiling. I am no expert though. I would recommend to change the entry in HISTORY and I will ask on openembedded-devel what they suggest. My message already got an answer [2] which advises to use `pkg-config`. IMO you should use pkg-config or freetype-config instead, e.g.: INCLUDES ?= `pkg-config --cflags freetype2` or better, instead of using INCLUDES at all: FREETYPE_CFLAGS ?= `pkg-config --cflags freetype2` CFLAGS += $(FREETYPE_CFLAGS) This will work in most environments. Thanks, Paul [1] http://www.linuxtv.org/pipermail/vdr/2010-April/022831.html [2] http://lists.linuxtogo.org/pipermail/openembedded-devel/2010-December/027801.html signature.asc Description: This is a digitally signed message part ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Request: E parameter in channels.conf for epg scan
On Sun, 12 Dec 2010 16:19:00 +0100 Klaus Schmidinger klaus.schmidin...@tvdr.de wrote: On 09.12.2010 07:59, Steffen Barszus wrote: On Wed, 08 Dec 2010 23:22:05 +0100 Klaus Schmidinger klaus.schmidin...@tvdr.de wrote: On 08.12.2010 20:25, Jochen Dolze wrote: To be able using other epg sources with other event ids as from the broadcaster. Today i cannot add 14 days of external epg without patching. Why would you have to patch VDR for that? External event's by default have a table id if 0, which means they will never be overwritten by data from the transponder. You will get duplicate EPG entries if the time doesn't match Hmm, I see. So how about changing cEIT in such a way that it never overwrites any events in a schedule if the first existing event in that schedule has a table id of 0? If we can be sure that between clre and adding the external epg no event comes into vdr by cEIT, means it can be ensured that this holds true for any stations external epg is used. On a side note to this, slightly OT: Thinking: What if a plugin could provide the EPG functionality for vdr ? In the long run it might be more useful if a more advanced merge from the different epgs source could happen at submission of the epg. The processing should happen in a seperate thread ( Having external epg for 18 days sums up to approx. 70MB, where vdr runs into emergency exit at the moment, if processed at once.) Current starting time from DVB might still be interesting, even if external epg is a lot better. Having epg in a DB (sqlite,mysql) might also be nice. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] [PATCH] Makefile: pass `LDFLAGS` to compiler
Dear Jörg, Am Samstag, den 25.09.2010, 13:15 +0200 schrieb Joerg Bornkessel: […] we have an open bug [1] to all versions of VDR on gentoo we changed any weeks befor our default profiles to use LDFLAGS on compile prozesses. snipp news-info about this from 2010-08-01 -Wl,--as-needed has been added to the default profile's LDFLAGS. This option optimizes the linking process, only linking binaries to libraries that are trully needed. This way, fewer libraries are loaded at runtime and fewer packages need to be rebuilt after library updates. /snap For more information on --as-needed, read [2]. Plz. let us check is it possible to add a fix generally to the Makefile to respect the LDFLAGS or should i fixed always localy on gentoo Disti. fixed should it be in this part of Makefile -# The main program: - -vdr: $(OBJS) $(SILIB) -$(CXX) $(CXXFLAGS) -rdynamic $(OBJS) $(LIBS) $(LIBDIRS) $(SILIB) -o vdr +# The main program: + +vdr: $(OBJS) $(SILIB) +$(CXX) $(CXXFLAGS) -rdynamic $(LDFLAGS) $(OBJS) $(LIBS) $(LIBDIRS) $(SILIB) -o vdr [1] http://bugs.gentoo.org/show_bug.cgi?id=333493 [2] http://www.gentoo.org/proj/en/qa/asneeded.xml Should `LDFLAGS` also be passed to the compiler when building the plugins? I made a patch from your message which does not include any changes to the plugins. Thanks, Paul 88 Date: Sun, 12 Dec 2010 18:19:42 +0100 Some distributions pass special flags to the linker [1][2]. Respect those by using `LDFLAGS`. [1] http://cgit.openembedded.org/cgit.cgi/openembedded/tree/recipes/vdr/vdr-1.7.10/linkerflags.patch [2] http://www.linuxtv.org/pipermail/vdr/2010-September/023623.html Signed-off-by: Paul Menzel paulepan...@users.sourceforge.net --- Makefile |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/Makefile b/Makefile index cca4d55..e12e2b2 100644 --- a/Makefile +++ b/Makefile @@ -95,7 +95,7 @@ $(DEPFILE): Makefile # The main program: vdr: $(OBJS) $(SILIB) - $(CXX) $(CXXFLAGS) -rdynamic $(OBJS) $(LIBS) $(LIBDIRS) $(SILIB) -o vdr + $(CXX) $(CXXFLAGS) -rdynamic $(LDFLAGS) $(OBJS) $(LIBS) $(LIBDIRS) $(SILIB) -o vdr # The libsi library: -- 1.7.2.3 signature.asc Description: This is a digitally signed message part ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Request: E parameter in channels.conf for epg scan
On Sun, Dec 12, 2010 at 9:21 AM, Steffen Barszus steffenbpu...@googlemail.com wrote: Having epg in a DB (sqlite,mysql) might also be nice. You are going to find a lot of opposition to this. Thinking of sql, I don't recall ever hearing anyone suggest VDR using it would be a good idea but I have heard people will look into other options if it ever did go that route (as mythtv uses currrently). ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Request: E parameter in channels.conf for epg scan
Am Sonntag, den 12.12.2010, 09:33 -0800 schrieb VDR User: On Sun, Dec 12, 2010 at 9:21 AM, Steffen Barszus steffenbpu...@googlemail.com wrote: Having epg in a DB (sqlite,mysql) might also be nice. You are going to find a lot of opposition to this. Thinking of sql, I don't recall ever hearing anyone suggest VDR using it would be a good idea but I have heard people will look into other options if it ever did go that route (as mythtv uses currrently). That is why Steffen wrote to make it a plugin. Thanks, Paul signature.asc Description: This is a digitally signed message part ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Request: E parameter in channels.conf for epg scan
On Sun, Dec 12, 2010 at 9:46 AM, Paul Menzel paulepan...@users.sourceforge.net wrote: Having epg in a DB (sqlite,mysql) might also be nice. You are going to find a lot of opposition to this. Thinking of sql, I don't recall ever hearing anyone suggest VDR using it would be a good idea but I have heard people will look into other options if it ever did go that route (as mythtv uses currrently). That is why Steffen wrote to make it a plugin. EPG support falls into the category of the most basic functionality. I'm not convinced things like this belong as optional plugins to be honest. Some things, such as VDR's attachment to FF cards, make sense as plugins. But it seems the automatic answer to everything is 'make it a plugin' now. So is VDR to become merely a plugin manager with no actual core functionality anymore? Is it wise to have VDR rely on plugins to be usable at all? These types of questions deserve consideration when you want to walk on slippery slopes. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Request: E parameter in channels.conf for epg scan
On 12/12/2010 19:24, VDR User wrote: On Sun, Dec 12, 2010 at 9:46 AM, Paul Menzel paulepan...@users.sourceforge.net wrote: Having epg in a DB (sqlite,mysql) might also be nice. You are going to find a lot of opposition to this. Thinking of sql, I don't recall ever hearing anyone suggest VDR using it would be a good idea but I have heard people will look into other options if it ever did go that route (as mythtv uses currrently). That is why Steffen wrote to make it a plugin. EPG support falls into the category of the most basic functionality. I'm not convinced things like this belong as optional plugins to be honest. Some things, such as VDR's attachment to FF cards, make sense as plugins. But it seems the automatic answer to everything is 'make it a plugin' now. So is VDR to become merely a plugin manager with no actual core functionality anymore? Is it wise to have VDR rely on plugins to be usable at all? These types of questions deserve consideration when you want to walk on slippery slopes. Remember that for example in france the DVB-T stream EPG contains only the actual program and the next program. So it is hardly useable at all. You now have most other video recorder code that use xmltv one way or other (tvheadend, myth, ...). I like VDR because it is simple but OSD is so poor that it need to be integrated in something else (xine, xbmc) to provide a decent GUI and then you need a bunch of plugins (streamdev, epgsearch, ...). Plus there is almost no up-to-date documentation for plugins, or only in german, no centrailised source repositories because of the plugins are developped elsewhere... So I second this post and think that decent epg is a basic feature for searching program and programmed recording based on epg and that dvb-t based stream is not the right way to go because it will contain very few infos in most countries. For those on linux, look at what qmagneto does and imagine it can talk to vdr to program recordings... I use it in cunjunction with mpalyer --dumpfile -dumstream to record IPTV streams. -- eric ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] EPG DB discussion (was Re: Request: E parameter in channels.conf for epg scan)
On Sun, 12 Dec 2010 10:24:31 -0800 VDR User user@gmail.com wrote: On Sun, Dec 12, 2010 at 9:46 AM, Paul Menzel paulepan...@users.sourceforge.net wrote: Having epg in a DB (sqlite,mysql) might also be nice. You are going to find a lot of opposition to this. Thinking of sql, I don't recall ever hearing anyone suggest VDR using it would be a good idea but I have heard people will look into other options if it ever did go that route (as mythtv uses currrently). That is why Steffen wrote to make it a plugin. EPG support falls into the category of the most basic functionality. I'm not convinced things like this belong as optional plugins to be honest. Some things, such as VDR's attachment to FF cards, make sense as plugins. But it seems the automatic answer to everything is 'make it a plugin' now. So is VDR to become merely a plugin manager with no actual core functionality anymore? Is it wise to have VDR rely on plugins to be usable at all? These types of questions deserve consideration when you want to walk on slippery slopes. I strongly believe that there is a way to make it possible to replace/extend core functionality by a plugin - i can see that not everybody might want what i would imagine to be perfect. Still i did not wrote mysql alone, my thought was sqlite for normal use, and a real db (rather postgre ?) for networked/client-server use. sqlite i could imagine even in core - making the connection sql - mysql - mythtv - bad , doesn't have any substance at all. And talking about people who would leave vdr for the reason of what i'm talking about doesn't add anything either. I daily load a full set of epg from an external source, for the statistics: 70MB EPG data, containing 102.006 records, loaded daily. Extended by VDR-Seriestimer.pl called by epgsearch at the time of creating a timer. Wanting to say it can be easy or can have any complexity you want, for the latter, vdr current epg handling doesnt scale so well ;) ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Request: E parameter in channels.conf for epg scan
On Sun, 12 Dec 2010 19:46:32 +0100 Eric Valette eric.vale...@free.fr wrote: On 12/12/2010 19:24, VDR User wrote: On Sun, Dec 12, 2010 at 9:46 AM, Paul Menzel paulepan...@users.sourceforge.net wrote: Having epg in a DB (sqlite,mysql) might also be nice. You are going to find a lot of opposition to this. Thinking of sql, I don't recall ever hearing anyone suggest VDR using it would be a good idea but I have heard people will look into other options if it ever did go that route (as mythtv uses currrently). That is why Steffen wrote to make it a plugin. EPG support falls into the category of the most basic functionality. I'm not convinced things like this belong as optional plugins to be honest. Some things, such as VDR's attachment to FF cards, make sense as plugins. But it seems the automatic answer to everything is 'make it a plugin' now. So is VDR to become merely a plugin manager with no actual core functionality anymore? Is it wise to have VDR rely on plugins to be usable at all? These types of questions deserve consideration when you want to walk on slippery slopes. Remember that for example in france the DVB-T stream EPG contains only the actual program and the next program. So it is hardly useable at all. external epg source is possible allready - i just think the merge and general handling could be improved :) You now have most other video recorder code that use xmltv one way or other (tvheadend, myth, ...). I like VDR because it is simple but OSD is so poor that it need to be integrated in something else (xine, xbmc) to provide a decent GUI and then you need a bunch of plugins (streamdev, epgsearch, ...). Plus there is almost no up-to-date documentation for plugins, or only in german, no centrailised source repositories because of the plugins are developped elsewhere... vdr-developer.org is a beginning :) and most new development is announced here too. So I second this post and think that decent epg is a basic feature for searching program and programmed recording based on epg and that dvb-t based stream is not the right way to go because it will contain very few infos in most countries. xmltv epg can be translated and imported into VDR now allready, there are a couple of other epg providing plugins and scripts as well, the main problem is available epg data possible to be fetched and translated. For those on linux, look at what qmagneto does and imagine it can talk to vdr to program recordings... I use it in cunjunction with mpalyer --dumpfile -dumstream to record IPTV streams. What about live plugin if the epg is imported into vdr ? It can handle epgsearch searchtimer, normal timer etc - so that allready exist to some extend :) ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] EPG DB discussion (was Re: Request: E parameter in channels.conf for epg scan)
On Sun, Dec 12, 2010 at 11:14 AM, Steffen Barszus steffenbpu...@googlemail.com wrote: sqlite i could imagine even in core - making the connection sql - mysql - mythtv - bad , doesn't have any substance at all. And talking about people who would leave vdr for the reason of what i'm talking about doesn't add anything either. I wouldn't be so quick to disregard user opinion. I think it's important to consider what people think who are using sql in a similar way. Do you honestly believe their first-hand experience in this area is meaningless, and that all the complaints about it with virtually nobody suggesting its a great idea is mere worthless chatter? There's a reason sql is unpopular. It's unfortunate you think that has no value and should be disregarded. It seems you think anything or any opinion that doesn't support the idea simply 'doesn't add anything'. I know a whole lot of users who will disagree with you on that. There are also other options that could be explored as well - and should be if there's to be any changes made. (Btw, Klaus has made it clear VDR was never intended to be a server/client system. Maybe at some point it will address that need in a well-thought out way but as it stands now I'm not so sure it's a good basis for argument.) ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] EPG DB discussion (was Re: Request: E parameter in channels.conf for epg scan)
On 12/12/2010 22:02, VDR User wrote: (Btw, Klaus has made it clear VDR was never intended to be a server/client system. Maybe at some point it will address that need in a well-thought out way but as it stands now I'm not so sure it's a good basis for argument.) On the other hand, with streamdev server, vnsi server, we are approaching the client server mode. I think the real question for selecting a database are: 1) do I need a SQL interface, 2) do I need a client server model, sqlite is in use in 200MHZ mips router/ Tokyo/Kyoto cabinet can do less but consume even less. --eric ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Request: E parameter in channels.conf for epg scan
On 12/12/2010 20:29, Steffen Barszus wrote: external epg source is possible allready - i just think the merge and general handling could be improved :) If you try to prove everything is possible via plugin yes. Vdr could even be simply a plugin loader as someone else suggested. The problem for the end user is how many packages do he have to install and configure to get a decent functionality and how easy is it. for most users compiling from sources is simply too complicated. I tried packages from yavdr and they do not work for me. I have been forced to use the debian pacakging and remove patches to correctly have HD TV via XBMC. vdr-developer.org is a beginning :) and most new development is announced here too. I rarely found anything useful at vdr-developer.org except maybe a small description of some plugins but almost nothing about their status if they are actively maintained, the git location and so on. Even the description of channel.conf is quite innacurate. In fact this list is the almost unique source for information. xmltv epg can be translated and imported into VDR now allready, there are a couple of other epg providing plugins and scripts as well, the main problem is available epg data possible to be fetched and translated. Did you try to use it recently. The xmltv to vdr perl script is unmaintained and obsolete... What about live plugin if the epg is imported into vdr ? It can handle epgsearch searchtimer, normal timer etc - so that allready exist to some extend :) live plugin needs streamdev and epgsearch to function right. So again it is not basic VDR. Plus, in France in never managed to find anything useful via the various search feature. --eric ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] [PATCH] tools.h: include `stdarg.h` to fix `error: 'va_list' has not been declared` with uClibc
: *** Waiting for unfinished jobs | make: *** [config.o] Error 1 | make: *** [channels.o] Error 1 | make: *** [ci.o] Error 1 | FATAL: oe_runmake failed | ERROR: Function do_compile failed NOTE: package vdr-1.7.16-r0: task do_compile: Failed ERROR: TaskFailed event exception, aborting ERROR: Build of /oe/openembedded/recipes/vdr/vdr_1.7.16.bb do_compile failed ERROR: Task 11 (/oe/openembedded/recipes/vdr/vdr_1.7.16.bb, do_compile) failed with 256 ERROR: '/oe/openembedded/recipes/vdr/vdr_1.7.16.bb' failed ERROR: '/oe/openembedded/recipes/vdr/vdr_1.7.16.bb' failed ERROR: '/oe/openembedded/recipes/vdr/vdr_1.7.16.bb' failed I used OpenEmbedded as a framework and tested this patch with the following configurations. Build Configuration: BB_VERSION= 1.10.0 METADATA_BRANCH = org.openembedded.dev METADATA_REVISION = ff41526 TARGET_ARCH = arm TARGET_OS = linux-uclibceabi MACHINE = beagleboard DISTRO= minimal-uclibc DISTRO_VERSION= dev-snapshot-20101212 TARGET_FPU= hard Build Configuration: BB_VERSION= 1.10.0 METADATA_BRANCH = org.openembedded.dev METADATA_REVISION = ff41526 TARGET_ARCH = arm TARGET_OS = linux-gnueabi MACHINE = beagleboard DISTRO= minimal DISTRO_VERSION= dev-snapshot-20101212 TARGET_FPU= hard This change was made by Henning Heinhold when packaging VDR 1.7.10 for OpenEmbedded [1]. [1] http://cgit.openembedded.org/cgit.cgi/openembedded/tree/recipes/vdr/files/cplusplus.patch Signed-off-by: Paul Menzel paulepan...@users.sourceforge.net CC: Henning Heinold hein...@inf.fu-berlin.de --- tools.h |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/tools.h b/tools.h index 95c35ff..1fbe005 100644 --- a/tools.h +++ b/tools.h @@ -17,6 +17,7 @@ #include iconv.h #include math.h #include poll.h +#include stdarg.h #include stddef.h #include stdint.h #include stdio.h -- 1.7.2.3 signature.asc Description: This is a digitally signed message part ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] [RFC] [PATCH] tools.c: use C++ headers instead of deprecated C headers
Looking at Henning Heinhold’s patch [1] he changed the includes to the C++
headers instead of the C headers. At least Wikipedia says [2], that the C
headers are deprecated.
C++ provides this functionality in the header cstdarg; the C header, though
permitted, is deprecated in C++.
Is it desirable to change the includes in all files? If yes, is there a tool
which would accomplish this, since after the substitution a reordering is
needed?
[1]
http://cgit.openembedded.org/cgit.cgi/openembedded/tree/recipes/vdr/files/cplusplus.patch?id=97e1b707d6504343f02e683f49eb2cb6db2cc091
[2] https://secure.wikimedia.org/wikipedia/en/wiki/Stdarg.h
Signed-off-by: Paul Menzel paulepan...@users.sourceforge.net
---
tools.c | 10 +-
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/tools.c b/tools.c
index 3ce12ec..9a400a8 100644
--- a/tools.c
+++ b/tools.c
@@ -8,9 +8,12 @@
*/
#include tools.h
-#include ctype.h
+#include cctype
+#include cerrno
+#include cstdarg
+#include cstdlib
+#include ctime
#include dirent.h
-#include errno.h
extern C {
#ifdef boolean
#define HAVE_BOOLEAN
@@ -18,11 +21,8 @@ extern C {
#include jpeglib.h
#undef boolean
}
-#include stdarg.h
-#include stdlib.h
#include sys/time.h
#include sys/vfs.h
-#include time.h
#include unistd.h
#include utime.h
#include i18n.h
--
1.7.2.3
signature.asc
Description: This is a digitally signed message part
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [RFC] [PATCH] tools.c: use C++ headers instead of deprecated C headers
On 12.12.2010 23:13, Paul Menzel wrote: Looking at Henning Heinhold’s patch [1] he changed the includes to the C++ headers instead of the C headers. At least Wikipedia says [2], that the C headers are deprecated. C++ provides this functionality in the header cstdarg; the C header, though permitted, is deprecated in C++. Is it desirable to change the includes in all files? If yes, is there a tool which would accomplish this, since after the substitution a reordering is needed? I like the classic headers more, so unless they are completely eradicated (which I doubt will ever happen, because it would simply break too many sources) I'm not going to switch to C++ headers. Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Request: E parameter in channels.conf for epg scan
On 12.12.2010 18:21, Steffen Barszus wrote: On Sun, 12 Dec 2010 16:19:00 +0100 Klaus Schmidinger klaus.schmidin...@tvdr.de wrote: On 09.12.2010 07:59, Steffen Barszus wrote: On Wed, 08 Dec 2010 23:22:05 +0100 Klaus Schmidinger klaus.schmidin...@tvdr.de wrote: On 08.12.2010 20:25, Jochen Dolze wrote: To be able using other epg sources with other event ids as from the broadcaster. Today i cannot add 14 days of external epg without patching. Why would you have to patch VDR for that? External event's by default have a table id if 0, which means they will never be overwritten by data from the transponder. You will get duplicate EPG entries if the time doesn't match Hmm, I see. So how about changing cEIT in such a way that it never overwrites any events in a schedule if the first existing event in that schedule has a table id of 0? If we can be sure that between clre and adding the external epg no event comes into vdr by cEIT, means it can be ensured that this holds true for any stations external epg is used. I guess that should be pretty easy to establish. Simply blocking any EPG data coming from the transponders for a certain time (10 seconds, one minute? you name it) after a CLRE command has been received should do it. Once there is an EPG event in the schedule that has a table id of 0, that schedule would no longer receive any data from the DVB stream (until all its events have timed out and no further external events have been supplied, at which time it would fall back to the DVB EPG data). On a side note to this, slightly OT: Thinking: What if a plugin could provide the EPG functionality for vdr ? EPG is a core feature of VDR (and DVB at large) and as such shall stay in the core VDR code. Besides, only the EPG data provided from the DVB data stream can support actual running status and thus VPS functionality In the long run it might be more useful if a more advanced merge from the different epgs source could happen at submission of the epg. The processing should happen in a seperate thread ( Having external epg for 18 days sums up to approx. 70MB, where vdr runs into emergency exit at the moment, if processed at once.) Current starting time from DVB might still be interesting, even if external epg is a lot better. You don't have to feed the whole 70MB into VDR at once. Do it channel by channel, and maybe with one channel day by day. That should allow enough time for VDR to keep its main loop alive. Having epg in a DB (sqlite,mysql) might also be nice. Definiteley *no* database in VDR! I've said it on many occasions, and I'll repeat it as many times as necessary! If you want to handle EPG data in a database, do it externally and feed the resulting EPG data into VDR via SVDRP. Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Request: E parameter in channels.conf for epg scan
On 12.12.2010 19:46, Eric Valette wrote: On 12/12/2010 19:24, VDR User wrote: On Sun, Dec 12, 2010 at 9:46 AM, Paul Menzel paulepan...@users.sourceforge.net wrote: Having epg in a DB (sqlite,mysql) might also be nice. You are going to find a lot of opposition to this. Thinking of sql, I don't recall ever hearing anyone suggest VDR using it would be a good idea but I have heard people will look into other options if it ever did go that route (as mythtv uses currrently). That is why Steffen wrote to make it a plugin. EPG support falls into the category of the most basic functionality. I'm not convinced things like this belong as optional plugins to be honest. Some things, such as VDR's attachment to FF cards, make sense as plugins. But it seems the automatic answer to everything is 'make it a plugin' now. So is VDR to become merely a plugin manager with no actual core functionality anymore? Is it wise to have VDR rely on plugins to be usable at all? These types of questions deserve consideration when you want to walk on slippery slopes. Remember that for example in france the DVB-T stream EPG contains only the actual program and the next program. So it is hardly useable at all. Have you ever considered complaining to your broadcasters about this? Here in Germany even DVB-T has an extensive EPG. You now have most other video recorder code that use xmltv one way or other (tvheadend, myth, ...). I like VDR because it is simple but OSD is so poor that it need to be integrated in something else (xine, xbmc) to provide a decent GUI and then you need a bunch of plugins (streamdev, epgsearch, ...). I always find it amusing how people consider the GUI so important. Come on! It's a *video recorder* for cryin' out loud! It's main purpose is to record and replay tv broadcasts. The menus are tools that allow the user to program timers, select channels and replay recordings. If the GUI is more important to you than the actual functionality, go ahead and install some of the nice skins floating around, or use something completely different as the user interface. To me, the menu system is nothing more than a means of making VDR do what I want it to do - and that's recording and replaying actual broadcasts, rather than showing me some pretty eye candy. Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [PATCH] tools.h: include `stdarg.h` to fix `error: 'va_list' has not been declared` with uClibc
On 12.12.2010 23:03, Paul Menzel wrote: From a94d15b582df5d1464cec8bc7dd68be46e1bf937 Mon Sep 17 00:00:00 2001 From: Paul Menzel paulepan...@users.sourceforge.net Date: Sun, 12 Dec 2010 19:21:25 +0100 Subject: [PATCH] tools.h: include `stdarg.h` For some reason using uClibc `tools.h` needs to have `stdarg.h` included explicitly. Otherwise it fails with the following error. Using Libc or EGLIBC this error does not surface. Since tools.h uses va_list you're apparently right. I wonder which one of the other header files tools.h includes pulls in that declaration (apparently unnecessarily). ... This change was made by Henning Heinhold when packaging VDR 1.7.10 for OpenEmbedded [1]. [1] http://cgit.openembedded.org/cgit.cgi/openembedded/tree/recipes/vdr/files/cplusplus.patch So I'll mention Henning in the CONTRIBUTORS file then, if that's ok with you. Signed-off-by: Paul Menzel paulepan...@users.sourceforge.net CC: Henning Heinold hein...@inf.fu-berlin.de --- tools.h |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/tools.h b/tools.h index 95c35ff..1fbe005 100644 --- a/tools.h +++ b/tools.h @@ -17,6 +17,7 @@ #include iconv.h #include math.h #include poll.h +#include stdarg.h #include stddef.h #include stdint.h #include stdio.h The '#include stdarg.h' can then also be removed from tools.c, and apparently it's included unnecessarily in osd.c and receiver.c. Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [PATCH] Makefile: pass `LDFLAGS` to compiler
Dear Jörg, Am Samstag, den 25.09.2010, 13:15 +0200 schrieb Joerg Bornkessel: […] [2] http://www.gentoo.org/proj/en/qa/asneeded.xml Should `LDFLAGS` also be passed to the compiler when building the plugins? We have this fixed global on Gentoo for all plugins. All plugin Makefile's are sed'ed/patched to use the LDFLAGS. I made a patch from your message which does not include any changes to the plugins. I dont know, what distri you use, one way would be to fix this in the make.global ( used up from vdr-1.7.(not shure yet)) and inherit this in the plugin Makefile. Should be standard in the vdr-1.7.x adapted plugin Makefiles -- Regards Gentoo Developer Joerg Bornkessel hd_bru...@gentoo.org ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Request: E parameter in channels.conf for epg scan
On 12/12/10 22:33, Klaus Schmidinger wrote: On 12.12.2010 18:21, Steffen Barszus wrote: Having epg in a DB (sqlite,mysql) might also be nice. Definiteley *no* database in VDR! I've said it on many occasions, and I'll repeat it as many times as necessary! If you want to handle EPG data in a database, do it externally and feed the resulting EPG data into VDR via SVDRP. VDR stores data about the EPG, presumably indexes it somehow, and looks up information in it. That *is* a database. What's wrong with using an existing database engine? Less code for you to maintain, easier to access it with 3rd party tools, and if something like sqlite3 isn't quite as efficient as your code tailored for EPGs, does anyone still use a PC old enough that it would make any noticeable difference? ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Request: E parameter in channels.conf for epg scan
On Sun, Dec 12, 2010 at 2:44 PM, Klaus Schmidinger klaus.schmidin...@tvdr.de wrote: I always find it amusing how people consider the GUI so important. Come on! It's a *video recorder* for cryin' out loud! It's main purpose is to record and replay tv broadcasts. The menus are tools that allow the user to program timers, select channels and replay recordings. If the GUI is more important to you than the actual functionality, go ahead and install some of the nice skins floating around, or use something completely different as the user interface. To me, the menu system is nothing more than a means of making VDR do what I want it to do - and that's recording and replaying actual broadcasts, rather than showing me some pretty eye candy. I think you underestimate the amount of time people spend in the menus, whether its searching through tv listings, summaries, recordings, lists of photos/music, etc. There are 4 VDR users in my household and I can say that each of us spend considerable time in the osd doing various things. I don't believe eye candy should be the most important thing but I don't disregard nice osd's as pointless either since they _do_ enhance the user experience. With high resolution HDTV's being common place these days, it's a pretty small leap that users would love to be able to scroll through their channel listings with say high resolution logos for each next to their respective channel numbers. It's true there are skin replacements for the current VDR osd. But, these are merely skins. They aren't full osd overhauls that add any real new possibilities. As an analogy, some people are perfectly fine with a car that doesn't have things such as power windows/seats, air conditioning, nice woodgrain trim, leather seats, etc. It serves no other purpose then to get that person from point A to point B. However, plenty of other people prefer something more luxurious while they spend time in their car -- and there's nothing wrong with that. VDR's experience from a user perspective isn't simply watching live tv or recordings with nothing in between. The fact that people have expressed their interest on this subject in the past proves the point. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] CAM auto resetting - feature request??
Sep 2 08:17:55 freddy vdr: [27707] ERROR: can't write to CI adapter on
device 0: Input/output error
Sep 2 08:17:55 freddy kernel: dvb_ca adapter 0: DVB CAM detected and
initialised successfully
This looks more like a driver bug to me.
Well maybe but unfortunately responds to my mails in linux-dvb /
linux-media mailinglist for that problem.
@Klaus:
If that problem happens, a manual reset of the cam under vdr's
menu-settings-ci brings the cam back.
What about trying to reset a cam automatically when it's Status is !=
msReady?
Like this:
diff --git a/device.c b/device.c
index 681049b..7904de2 100644
--- a/device.c
+++ b/device.c
@@ -239,6 +239,8 @@ cDevice *cDevice::GetDevice(const cChannel *Channel,
int Priority, bool LiveView
if (Channel-Ca() = CA_ENCRYPTED_MIN) {
for (cCamSlot *CamSlot = CamSlots.First(); CamSlot; CamSlot =
CamSlots.Next(CamSlot)) {
SlotPriority[CamSlot-Index()] = MAXPRIORITY + 1; // assumes it
can't be used
+ if (CamSlot-ModuleStatus() == msPresent)
+CamSlot-Reset();
if (CamSlot-ModuleStatus() == msReady) {
if (CamSlot-ProvidesCa(Channel-Caids())) {
if
(!ChannelCamRelations.CamChecked(Channel-GetChannelID(),
CamSlot-SlotNumber())) {
Have you tested this?
Did it actually work?
Klaus
Will give it a try and report back
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Request: E parameter in channels.conf for epg scan
On 12/12/2010 23:44, Klaus Schmidinger wrote: I always find it amusing how people consider the GUI so important. Come on! It's a *video recorder* for cryin' out loud! It's main purpose is to record and replay tv broadcasts. I know its the main purpose but do not forget that in order to record, you need to correctly tune the adapter. So its also a DVB tuner. Once tuned, you can direct the stream on disk but also elsewhere. That's the primary purpose of the streamdev extension. I rarly see VDR used standalone... --eric ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
