Re: [vdr] EPG for BBC TV channels?
I think you are looking for this patch http://www.rst38.org.uk/vdr/ Unfortunately it's quite old. Christopher Am 09.03.2014 15:19, schrieb Tony Houghton: On Sun, 09 Mar 2014 14:38:48 +0100 Manuel Reimer wrote: for most of the GB TV channels it is common to only have the current and the next event in the EPG list. I did a few tries to work around this problem using EPG parsed from internet services and imported to VDR via xmltv2vdr-Plugin. As this solution is a bit tricky and not very reliable, my question is, whether there is a better solution to get "real" EPG for those channels? Thank you very much in advance I guess you're using satellite because there was never a problem with the SD channels on DVB-T (Freeview). The eepg plugin supports Freesat and Sky's EPGs, but it has a memory leak and doesn't support Freeview HD, so instead I use a patch which various people have tweaked over time. I can't find a web download site for it or when it was last posted on this list, so if you're interested and others don't mind a 225K attachment I can post it here again. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Fix SIGNALSTRENGTH in vdr 2.0.3 TechniSat SkyStar 2 DVB-S rev 2.3P - dvbdevice.c
What's the problem? I wasn't difficult at all to generate a diff.
Christopher
Am 13.10.2013 10:42, schrieb Klaus Schmidinger:
> On 13.10.2013 01:45, VDR User wrote:
>
>> Shouldn't something like this be fixed in the driver?
>
> I don't know - haven't seen the 'diff' yet ;-)
>
> Klaus
> On Sat, Oct 12, 2013 at 2:08 PM, Klaus Schmidinger
> wrote: On 12.10.2013 21:21, knap.home wrote: With
> this change to the source I was able to run properly "SIGNAL STRENGTH." Using
> the device Netsystem TechniSat SkyStar 2 DVB-S rev 2.3P. Great as a solution
> ... Modified Source -> /usr/local/src/vdr-2.0.3/dvbdevice.c Please send just
> the differences (diff -u) between the original and the modified code. I'm
> afraid even though I tried I can't seem to generate a proper diff from what
> you've posted. And please send it as an attachment, not inline (lines get
> wrapped). Klaus
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr [1]
Links:
--
[1] http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
--- dvbdevice.c 2013-08-23 11:52:14.0 +0200
+++ dvbdevice.c.edit 2013-10-13 10:58:44.262951623 +0200
@@ -285,9 +285,10 @@
private:
static cMutex bondMutex;
enum eTunerStatus { tsIdle, tsSet, tsTuned, tsLocked };
+ bool SendDiseqc;
int frontendType;
const cDvbDevice *device;
- int fd_frontend;
+ mutable int fd_frontend;
int adapter, frontend;
uint32_t subsystemId;
int tuneTimeout;
@@ -298,9 +299,10 @@
const cScr *scr;
bool lnbPowerTurnedOn;
eTunerStatus tunerStatus;
- cMutex mutex;
+ mutable cMutex mutex;
cCondVar locked;
cCondVar newSet;
+ dvb_diseqc_master_cmd diseqc_cmd;
cDvbTuner *bondedTuner;
bool bondedMaster;
bool SetFrontendType(const cChannel *Channel);
@@ -313,6 +315,10 @@
void ResetToneAndVoltage(void);
bool SetFrontend(void);
virtual void Action(void);
+
+ mutable bool isIdle;
+ bool OpenFrontend(void) const;
+ bool CloseFrontend(void);
public:
cDvbTuner(const cDvbDevice *Device, int Fd_Frontend, int Adapter, int Frontend);
virtual ~cDvbTuner();
@@ -327,12 +333,18 @@
bool Locked(int TimeoutMs = 0);
int GetSignalStrength(void) const;
int GetSignalQuality(void) const;
+ bool SetIdle(bool Idle);
+ bool IsIdle(void) const { return isIdle; }
+ bool SendDiseqcCmd(dvb_diseqc_master_cmd cmd);
+private:
+ int GetCurrentDeliverySystem(void);
};
cMutex cDvbTuner::bondMutex;
cDvbTuner::cDvbTuner(const cDvbDevice *Device, int Fd_Frontend, int Adapter, int Frontend)
{
+ SendDiseqc = false;
frontendType = SYS_UNDEFINED;
device = Device;
fd_frontend = Fd_Frontend;
@@ -348,6 +360,7 @@
tunerStatus = tsIdle;
bondedTuner = NULL;
bondedMaster = false;
+ isIdle = false;
SetDescription("tuner on frontend %d/%d", adapter, frontend);
Start();
}
@@ -365,6 +378,8 @@
ExecuteDiseqc(lastDiseqc, &Frequency);
}
*/
+ if (device && device->IsSubDevice())
+ CloseFrontend();
}
bool cDvbTuner::Bond(cDvbTuner *Tuner)
@@ -509,6 +524,8 @@
void cDvbTuner::ClearEventQueue(void) const
{
+ if (!OpenFrontend())
+ return;
cPoller Poller(fd_frontend);
if (Poller.Poll(TUNER_POLL_TIMEOUT)) {
dvb_frontend_event Event;
@@ -531,32 +548,104 @@
//#define DEBUG_SIGNALSTRENGTH
//#define DEBUG_SIGNALQUALITY
-
+#define LOCK_THRESHOLD 5 // indicates that all 5 FE_HAS_* flags are set
+// Inizio Modifica
int cDvbTuner::GetSignalStrength(void) const
{
- ClearEventQueue();
- uint16_t Signal;
- while (1) {
-if (ioctl(fd_frontend, FE_READ_SIGNAL_STRENGTH, &Signal) != -1)
- break;
-if (errno != EINTR)
- return -1;
+ fe_status_t Status;
+ if (GetFrontendStatus(Status)) {
+ // Actually one would expect these checks to be done from FE_HAS_SIGNAL to FE_HAS_LOCK, but some drivers (like the stb0899) are broken, so FE_HAS_LOCK is the only one that (hopefully) is generally reliable...
+ if ((Status & FE_HAS_LOCK) == 0) {
+if ((Status & FE_HAS_SIGNAL) == 0)
+ return 0;
+if ((Status & FE_HAS_CARRIER) == 0)
+ return 1;
+if ((Status & FE_HAS_VITERBI) == 0)
+ return 2;
+if ((Status & FE_HAS_SYNC) == 0)
+ return 3;
+return 4;
}
- uint16_t MaxSignal = 0x; // Let's assume the default is using the entire range.
- // Use the subsystemId to identify individual devices in case they need
- // special treatment to map their Signal value into the range 0...0x.
- switch (subsystemId) {
-case 0x13C21019: // TT-budget S2-3200 (DVB-S/DVB-S2)
-case 0x1AE40001: // TechniSat SkyStar HD2 (DVB-S/DVB-S2)
- MaxSignal = 670; break;
-}
- int s = int(Signal) * 100 / MaxSignal;
- if (s > 100)
- s = 100;
#ifdef DEBUG_SIGNALSTRENGTH
- fprintf(stderr, "FE %d/%d: %08X S = %04X %04X %3d%%\n", adapter, frontend, subsystemId, MaxSignal, Signal, s);
+
Re: [vdr] Contribution to VDR - source codes, compiling latest 2.x on raspberry pi
Am 1.9.2013 19:58, schrieb Martin Stiborský: > Hi guys, > I'd like to ask you for a little help, small introduction into how it works > in VDR development. > > My goal: I'd like to have latest VDR on my RaspberyPi, I have there Archlinux > ARM installed, so it will be maybe a little bit more complicated, than just > upgrading already existing 1.x debian package, which you can use on Raspbian. > > You know, previously I had Raspbian on the RasPi and installing and > configuring VDR was really simple. > There was webinterface and streaming to my workstation with VLC as a client > was working out-of-box (I have right now only DVB-T USB dongle). > As far as I know there is only 1.x deb package now. > > I'd like to create similar package for Archlinux (PKGBUILD). > > I'll definitelly use already existing debian package as a starting point for > my work. That's definitely the wrong attempt. You can't use debian packages as starting point for Arch Linux packages. Maybe you want to contribute to vdr4arch --> https://github.com/CReimer/vdr4arch [8] > There are also already some projects existing on that matter: > http://sourceforge.net/projects/archvdr/ [1] > https://aur.archlinux.org/packages/vdr/ [2] > (I'm quite confused why there is already existing AUR PKGBUILD and also > another project for the same purpose, Wiki is saying that the other project > should be used instead of AUR package, really don't know why > https://wiki.archlinux.org/index.php/VDR#Installation [3]) ArchVDR is not up-to-date and it doesn't take care of the rules in Arch's DeveloperWiki. AUR is the most chaotic place you which exists in the Arch world. Most of the PKGBUILDs there are in very bad condition. > Now I need to get idea about the VDR project in general. > For example, I was not able to find some code repository with your code...are > you using git, hg or svn? Is the repository publicly accessible? > > Maybe this? http://projects.vdr-developer.org/git/ [4] > > I have found also this: http://linuxtv.org/repo/ [5] But VDR is not there, > although there is a lot of links and information about VDR. > > What is the main place for "dev" informations? Is it this wiki? > http://linuxtv.org/vdrwiki/index.php/Main_Page [6] > > Btw, what about to put such information on your homepage (http://www.tvdr.de/ > [7]) ? > Maybe even consider Github as a VDR development home, that would be awesome > :) But that's completely your things how to keep you project running. There's no publicly accessible GIT/HG repository for VDR, but you have the choice between stable versions (2.0.3) and developer versions (2.1.1) Christopher Reimer Links: -- [1] http://sourceforge.net/projects/archvdr/ [2] https://aur.archlinux.org/packages/vdr/ [3] https://wiki.archlinux.org/index.php/VDR#Installation [4] http://projects.vdr-developer.org/git/ [5] http://linuxtv.org/repo/ [6] http://linuxtv.org/vdrwiki/index.php/Main_Page [7] http://www.tvdr.de/ [8] https://github.com/CReimer/vdr4arch ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] New Makefile system
Am 24.03.2013 13:51, schrieb Lucian Muresan: Hi, On 24.03.2013 13:24, Helmut Auer wrote: [...] There's nothing to find anymore, I had to debug crashes of a plugin (not my own) which were caused by migrating to the new makefile, because cflags and c++flags were differnet. I can't imagine, that this is caused by a changed Makefile. There are lots of things that you can't imagine ;) Which plugin are you refering to? softhddevice and live Plugin. There was a mismatch between c an c++ flags and this was surely caused by the new makefile system :) I searched for the segfault in the code but the reason was the make, and that costs me some days. I could give you another example, Christopher, of which Makefile was migrated by yourself, with exactly the consequence pointed out by Helmut, I only don't think we're allowed to mention that plugin here, so just remember, 3 months ago, "Issue #18" of that Plugin on Github... Regards, Lucian Even before Issue 18 was fixed it worked flawlessly on Archlinux. live still uses the old makefile and softhddevice works great here. Christopher ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] New Makefile system
Am 24.03.2013 11:51, schrieb Helmut Auer: Helmut Auer wrote: Sorry to hack this thread , but my wound is still wide open :( There also was a makefile concept for ten years and apparently no one has a problem with it, but it was changed and that that has cost me many many hours and days and all the fun I had with VDR before ... Then please, finally, name your problems, so someone can help you to find solutions. There's nothing to find anymore, I had to debug crashes of a plugin (not my own) which were caused by migrating to the new makefile, because cflags and c++flags were differnet. I can't imagine, that this is caused by a changed Makefile. Which plugin are you refering to? I searched for the segfault in the code but the reason was the make, and that costs me some days. And also the migration of many plugins costs me a lot of time. You don't have to migrate them. You can stay with the old Makefiles. Take a look at the VDR4Arch Project https://github.com/CReimer/vdr4arch/blob/master/plugins/vdr-filebrowser/PKGBUILD The old Makefile system did not work well for packaging and made it unneccessarily difficult to build plugins from outside the VDR source. It also often required manual steps to be done after installing the plugin (copy resources or something like that) which can be done in the "install" target, now. So in my opinion the new system is a big benefit for 2.0. Just for my point of view, I do not have any benefit of the new makefile concept, only trouble. This makefile change has lead to the biggest cut in VDR times, imho such a change should be made after a major release not (in VDR times) short before a major release. If I'd be a a vdr user thats no problem, I can stay with vdr 1.7.32. Bu unfortunately I'm a distributor and I've promised my users a new version with VDR 2.0. Now I have the choice between breaking my word or setting up the new system which will cost me some more days with a system that I do not like. There's also a problem with your attitude. You want to provide all plugins regardless of how old or how broken they are. Christopher Reimer ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] RFC: Adding CPPFLAGS to Makefile
Am 23.02.2013 15:40, schrieb Ville Skyttä: On 2013-02-23 14:43, Tobi wrote: VDR's Makefile does not use CPPFLAGS (C-Pre-Processor flags) right now. Not a big deal and easy to work-around, but for the sake of providing a "standards-conform" Makefile I suggest adding CPPFLAGS as well. +1 to the general idea. To take it a bit further, I suppose at least DEFINES, CDEFINES, INCLUDES, CINCLUDES could be directly put to CPPFLAGS instead of being defined separately. +1 for Tobi's suggestion and +1 for yours. I didn't know that there's something else than CXXFLAGS, CFLAGS and LDFLAGS. The Archlinux build system only provides these three. Tobi's patch is minimally invasive (Ready for 2.0), but I'm afraid that your suggestion breaks something (better wait for 2.0+) ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.36
No, I tried it and it works with and without your patch. CINCLUDES has a lower priority, the order of the parameters matters. And the default INCLUDE stuff comes after CXXFLAGS (CINCLUDES is a part of CXXFLAGS in plugin makefiles) 2013/1/26 Joachim Wilke : > 2013/1/25 Christopher Reimer : >> Hmm, it is problematic. >> >> We can't make sure that "make plugins" uses the header files of the >> current source tree. >> >> plugins of 1.7.36 should be compiled against the 1.7.36 headers, even >> if there are older header files in /usr/include/vdr. > > This is an issue even without my suggested patch, right? > > -- > Best Regards, > Joachim. > > ___ > vdr mailing list > vdr@linuxtv.org > http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.36
Hmm, it is problematic. We can't make sure that "make plugins" uses the header files of the current source tree. plugins of 1.7.36 should be compiled against the 1.7.36 headers, even if there are older header files in /usr/include/vdr. 2013/1/25 Christopher Reimer : > OK, OK, OK... > > If it fixes your problem I don't see any problem with adding INCDIR to > CINCLUDES. I was a bit worried about the DESTDIR stuff, but this > change doesn't affect anything there. > > Christopher > > 2013/1/25 Joachim Wilke : >> >> >> 2013/1/25 Christopher Reimer >>> >>> > I think what Andreas means ist, that the INCDIR of the *installed* VDR >>> > headers is currently not included in the CXXFLAGS in vdr.pc. This causes >>> > plugins to not compile for themselves even if VDR has installed (using >>> > make >>> > install) before. >>> > >>> >>> But it works without any problems here. You don't need to add >>> /usr/include or /usr/local/include to the CXXFLAGS because they are >>> always included. >>> I can't imagine a reason why the includedir should not be a "standard >>> directory". >> >> >> So your imagination is limited. Nvertheless, it is no good practise to >> expect something to be included by default. >> As long as INCDIR or PREFIX can be changed in Make.config, this *has* to be >> considered when creating vdr.pc. I'm not requesting a feature, I'm just >> providing a bugfix. >> >> ___ >> vdr mailing list >> vdr@linuxtv.org >> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr >> ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.36
OK, OK, OK... If it fixes your problem I don't see any problem with adding INCDIR to CINCLUDES. I was a bit worried about the DESTDIR stuff, but this change doesn't affect anything there. Christopher 2013/1/25 Joachim Wilke : > > > 2013/1/25 Christopher Reimer >> >> > I think what Andreas means ist, that the INCDIR of the *installed* VDR >> > headers is currently not included in the CXXFLAGS in vdr.pc. This causes >> > plugins to not compile for themselves even if VDR has installed (using >> > make >> > install) before. >> > >> >> But it works without any problems here. You don't need to add >> /usr/include or /usr/local/include to the CXXFLAGS because they are >> always included. >> I can't imagine a reason why the includedir should not be a "standard >> directory". > > > So your imagination is limited. Nvertheless, it is no good practise to > expect something to be included by default. > As long as INCDIR or PREFIX can be changed in Make.config, this *has* to be > considered when creating vdr.pc. I'm not requesting a feature, I'm just > providing a bugfix. > > ___ > vdr mailing list > vdr@linuxtv.org > http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr > ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.36
Ever tried LCLBLD=1 or ONEDIR=1 ? Christopher 2013/1/25 Andreas Brachold : > Hi, > > Am Freitag, den 25.01.2013, 15:31 +0100 schrieb Christopher Reimer: >> I can't imagine a reason why the includedir should not be a "standard >> directory". > > I use this, to install multiple versions side by side. > Please remember you, the program vdr-1.7.x is a developer version ... > > Andreas > > > > > > ___ > vdr mailing list > vdr@linuxtv.org > http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.36
2013/1/23 Joachim Wilke : > 2013/1/22 Klaus Schmidinger >> >> On 20.01.2013 20:24, Andreas Brachold wrote: >>> >>> I think into vdr.pc is parameter includedir= missed, if $(INCDIR) not a >>> standard directory. >>> >> >> If you have an installed version of VDR on your system (i.e. there is >> a vdr.pc file in /usr/share/pkgconfig) and you 'make' a plugin from >> within the plugin's source directory, the information stored in that >> vdr.pc file will be used. >> > > I think what Andreas means ist, that the INCDIR of the *installed* VDR > headers is currently not included in the CXXFLAGS in vdr.pc. This causes > plugins to not compile for themselves even if VDR has installed (using make > install) before. > But it works without any problems here. You don't need to add /usr/include or /usr/local/include to the CXXFLAGS because they are always included. I can't imagine a reason why the includedir should not be a "standard directory". ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-1.7.35 Makefile woes
Hi Torsten, please try this patch against VDR 1.7.35. http://www.vdr-portal.de/index.php?page=Attachment&attachmentID=32523 At VDR-Portal we currently try to repair the whole Makefile stuff. It's time to post it on the Mailinglist. Christopher Reimer 2013/1/5 Torsten Duwe : > Hi all! > > This may or may not be related to the Make.config discussion. I'm > having difficulties to package vdr-1.7.35 compiled along with some > plugins; "make install" produces nonsense under $DESTDIR, no matter > whether I change $UP3 to use `pwd` or not. libdir and locdir always > contain $UP3, which is always incorrect. I haven't even tried yet to > compile other plugins against the installed vdr package. > > Please correct me if I'm wrong, IMHO there's a difference between the > place where vdr is compiled, and the final runtime on the target > system. Thus, if you stick to the package-config approach, 2 separate > vdr.pc files would be required: one for the plugins compiled along > with vdr, and one to be installed on the target system. I also fail > to see this differentiation in the Makefile: LOCDIR and PLUGINDIR (and > derived LIBDIR) appear only once in it, not to talk about INCDIR, see > above. All contain $CWD. > > What am I missing? > > Torsten > > > ___ > vdr mailing list > vdr@linuxtv.org > http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [DISCUSSION REQUEST] reintroduce a common make configuration file in VDR-1.7.35
I couldn't realize that there are so many non-German VDR users. I personally don't like to write English. Not because I hate the language, more because I'm worried to do something wrong (grammer, tenses etc.) Christopher ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [DISCUSSION REQUEST] reintroduce a common make configuration file in VDR-1.7.35
Nice 33%!! Then tell me why was there no answer on the mailinglist thread. No answer = everything is ok --> send patch to Klaus 2012/12/30 Gerald Dachs : > Am 30.12.2012 01:08, schrieb Christopher Reimer: > >> I don't consider the mailinglist as "central spot of developement". Here >> I'm forced to speak English. Almost all VDR Users are German. And in >> VDR-Portal I reach the critical mass. With the addition that I am allowed to >> speak my native language. > > What makes you believe that? Do you have any numbers? I don't have user > counts either. > > I know that visitors of yavdr.org are not the same as vdr users, but they > might be somehow related. Our statistics shows that the german group is with > %67 of course the biggest, but far away from "almost all". > > Gerald > > !DSPAM:50e02a13296741317615234! > > > > ___ > vdr mailing list > vdr@linuxtv.org > http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [DISCUSSION REQUEST] reintroduce a common make configuration file in VDR-1.7.35
2012/12/30 fnu : > And as far as I remember nobody did complain about the old Makefile > structur, and yes I mean nobody, because the two now known just changed it > w/o warning. Do what ever you need to do, I appriciate it, but remind always > some continuity for all others in the VDR universe. Ohh come on. There were warnings. VDR-Portal: http://www.vdr-portal.de/board17-developer/board25-patches/115856-redundanz-in-der-make-config-und-make-global/ Mailinglist: http://linuxtv.org/pipermail/vdr/2012-November/026813.html Everyone who complains now was just too proud or to ignorant to answer on one of these threads. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [DISCUSSION REQUEST] reintroduce a common make configuration file in VDR-1.7.35
2012/12/29 Udo Richter : Even if there was > an thread in vdr-portal, I did miss it, and there was no word of it in > the mailing list, which I always considered to be the central spot of > development. Really? http://linuxtv.org/pipermail/vdr/2012-November/026813.html There was NO answer at all. I don't consider the mailinglist as "central spot of developement". Here I'm forced to speak English. Almost all VDR Users are German. And in VDR-Portal I reach the critical mass. With the addition that I am allowed to speak my native language. > Right now it leaves the impression that the new system was > designed to make exactly two persons satisfied for their needs. Yes, I am happy with the new makefiles. I (and I think Klaus, too) knew that this change is not perfect, and that it would need further improvement. We are all willing to fix the remaining problems. Christopher ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [DISCUSSION REQUEST] reintroduce a common make configuration file in VDR-1.7.35
OK. 50 plugins doesn't sound impossible to deal with. But they have to be in one place, as Manuel mentioned. Name these 50 unmaintained plugins and then we can check when and how they'll be moved to vdr-developer.org. Christopher 2012/12/29 Helmut Auer : >> >> If there is really a need for that special unsupported plugin, then the >> best way >> to go would be that at least one of all those distributions, who currently >> maintains that plugin, "republishes" it somewhere (AFAIR >> projects.vdr-developer.org was invented for that?). >> >> First step could be to apply all those patches that are required to get >> the >> plugin to work with current VDR *developer* versions. >> >> If a plugin really is still needed by a bigger group of people, then it >> definitively needs to be maintained at some *central* place. It doesn't >> help if >> every distribution creates their own patches. It's much better to >> cooperate! >> > We are talking about > 100 Plugins. Maybe we can drop the half of these but >> 50 will be remaining ... > > -- > Helmut Auer, hel...@helmutauer.de > > > ___ > vdr mailing list > vdr@linuxtv.org > http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [DISCUSSION REQUEST] reintroduce a common make configuration file in VDR-1.7.35
2012/12/25 Klaus Schmidinger : > >> 3.) the file should be included into plugin Makefiles after having set >> PLUGIN and VERSION to be able to have some plugin-/version-dependent >> configuration. > > > Agreed. > No. Not agreed. Just use DEFINES+= in Make.config, and if that doesn't work, plugin makefiles have to be patched. There's also the possibility to add a Make.config to every plugin. Some plugin maintainer already started to include their own Make.config (e.g. http://projects.vdr-developer.org/git/vdr-plugin-ripit.git/tree/Make.config.template) Christopher ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] Redundancy in Make.config and Make.global
I just noticed that both Make.confg and Make.global contain this block: ifdef PLUGIN CFLAGS += -fPIC CXXFLAGS += -fPIC endif I tried to remove this block out of Make.config, which leads to plugin compilation problems, because -fPIC is not set. After a closer look into the Makefiles, I've started to think that there's a bigger problem. The main Makefile starts more or less the plugin Makefile Inside the plugin Makefile: At first it defines PLUGIN (e.g. PLUGIN = dvbsddevice) Then it sets the plugin compile parameters (-g -O3 -Wall -Werror=overloaded-virtual -Wno-parentheses) Afterwards it reads Make.global and it adds fPIC (-g -O3 -Wall -Werror=overloaded-virtual -Wno-parentheses -fPIC) And after that the Make.config gets included, which overwrites all parameters. We're back at the beginning without -fPIC (-g -O3 -Wall -Werror=overloaded-virtual -Wno-parentheses) I think Make.global and Make.config are included in the wrong order. Make.config should be included first, and Make.global afterwards. I know that all plugin Makefiles need to be edited again. But I think that is the only working solution. Christopher Reimer vdr-makefile-fix.diff Description: Binary data plugin-makeglobal-misplaced.diff Description: Binary data plugin-no-makeglobal.diff Description: Binary data ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] channels.conf overwritten when installing vdr 1.7.30
2012/10/8 VDR User : > Blindly overwriting files is terrible! The author of that FHS patch > should fix it so those files are only copied if they don't already > exist. Here's a patch which reverts this small misbehaviour. Christopher Reimer vdr-1.7.31-do-not-overwrite-confs.diff Description: Binary data ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Filesystem hierachy standard patch needs review.
Am 07.09.2012 12:33, schrieb Klaus Schmidinger:
On 06.09.2012 21:09, Manuel Reimer wrote:
Klaus Schmidinger wrote:
Attached is a revised version of the patch, as I intend to adopt
it in version 1.7.30.
Didn't try it, so far, but I had a look at it and maybe, I've found a
small problem:
+# By default VDR requires only one single directory to operate:
VIDEODIR = /video
-CONFDIR = $(VIDEODIR)
+# See Make.config.template if you want to build VDR according to the
FHS ("File system Hierarchy Standard")
[...]
+
+install-conf:
+@cp *.conf $(DESTDIR)$(CONFDIR)
For me this seems like "install-conf" does not longer work if FHS is
*not* used, as "CONFDIR" is not defined without the FHS mode enabled?
Mabe this would help:
--- Makefile2012/09/01 13:22:33 2.28
+++ Makefile2012/09/07 10:31:35
@@ -76,6 +76,10 @@
DEFINES += -DPLUGINDIR=\"$(PLUGINLIBDIR)\"
DEFINES += -DLOCDIR=\"$(LOCDIR)\"
+CONFDIR ?= $(VIDEODIR)
+CACHEDIR ?= $(VIDEODIR)
+RESDIR ?= $(CONFDIR)
+
# The version numbers of VDR and the plugin API (taken from VDR's
"config.h"):
VDRVERSION = $(shell sed -ne '/define
VDRVERSION/s/^.*"\(.*\)".*$$/\1/p' config.h)
Please let me know if this should be added.
Hmm, CONFDIR ist already defined in the Makefile.
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Filesystem hierachy standard patch needs review.
2012/9/6 Ludwig Nussel : > 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. > It's also my opinion. And the opinion of many others e.g. yaVDR Maintainers. OK timeshift recordings could be saved to /var/spool, but for most people the recording directory is more like an archive. >>> /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. I maintain build scripts for Archlinux (No, not ArchVDR) and there it's only "taboo" to install files there. A good example in Archlinux is httpd, nothing is installed to /srv but httpd is configured to search for website data there. > >> 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? > There is a thread about FHS in the German forum VDR-Portal (http://www.vdr-portal.de/board60-linux/board14-betriebssystem/65-vdr-verzeichnisse-nach-filesystem-hierarchy-standard-fhs-richtig-ablegen/) ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Filesystem hierachy standard patch needs review.
2012/9/4 Gero : >> I decided to use /var/spool/video (could have been /var/spool/vdr >> too). > > That's a good point! > > Lots of VDR-users use VDR as a standalone system and for those systems > /var/spool might be more appropriate than /srv > > /srv is right, if the VDR-machine offers the recordings like a NAS or > MediaServer, so in case the VDR is a backend machine, it might be better to > symlink /var/spool/video to /srv/video or the like. The FHS gives further examples for /var/spool "Printer spool directory" "Outgoing mail queue" I cannot see how a recording directory is comparable with a printer or outgoing mail queue. Christopher ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Filesystem hierachy standard patch needs review.
2012/9/3 Ludwig Nussel : > 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. > FHS 2.3 (http://www.pathname.com/fhs/pub/fhs-2.3.pdf) says: /var/spool contains data which is awaiting some kind of later processing. Data in /var/spool represents work to be done in the future (by a program, user, or administrator); often data is deleted after it has been processed. I don't think that this applies to recordings. > +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. > Some people mount their /etc read-only. This would break VDR's functionality. Nevertheless we already talked about this and most people agree with /var/lib/vdr > What's missing is a directory for include files to be able to build > plugins separate from vdr. Christopher ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Filesystem hierachy standard patch needs review.
2012/9/1 Klaus Schmidinger : > Please try it and let me know if it works as expected. I have patched my vdr and I cannot see any problems with this changes. I works with and without USE_FHS=1 as expected. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] epgfixer-plugin 0.0.5
Hey, I found another bug. VDR crashes as soon as VDR receives EPG data.
Please try the following regex-pattern.
S19.2E-1-1057-61205:description=^(?.{5,15})[\.][
](?.*)$
Thank you
Christopher Reimer
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] epgfixer-plugin 0.0.4
2012/4/12 Matti Lehtimäki > I think I'll also keep the option of using channel numbers since many > people have some desired order of channels and in that case unique IDs are > not necessary. > > I tried to use channel numbers, but it doesn't seem to work. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] epgfixer-plugin 0.0.4
OK, next feature request :-D Using channel numbers for channel matching only works for one specific channels.conf. Could you please use unique IDs for every channel (e.g. S19.2E-1-1089-12003-0)? ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] epgfixer-plugin 0.0.3
I tried your plugin with several german channels. There's one problem. Most german channels send broken EPG data. When I enable one regex it fixes one channel but breaks another. Could you please add the possibility to bind regexes to one or more channel? Christopher Reimer ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Filesystem hierachy standard patch needs review.
2012/4/9 Klaus Schmidinger > > However, there is one thing in the current behavior that I would even > consider a bug: if one starts VDR with > > vdr -v /mydir > > it uses /mydir as the video directory, but still uses /video for the > configuration files. I believe that as long as there is no explicit > -c option given, the config directory should follow what's given in > the -v option. So I wouldn't mind if this was fixed along with implementing > the FHS stuff ;-) (or in a separate step). > > Ok, maybe Udo can add this to the patch. Udo, please also mind the additional Makefile change I mentioned before. I can't find a special place where to add this to the documentation. In addition I think it's self explanatory ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Filesystem hierachy standard patch needs review.
2012/4/8 VDR User > I know several people who set their directories on the command line > and ignore maintaining Make.config completely so it's not true > everyone uses Make.config. > OK, that could be possible, although I don't understand why. Let's wait what Klaus says. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Filesystem hierachy standard patch needs review.
2012/4/8 Udo Richter > - If CACHEDIR or RESDIR is not set (empty string), fall back to whatever > --video and --config is set to. > No, CACHEDIR and RESDIR should work in the same behaviour as CONFDIR or VIDEODIR. This sounds a bit like you set all your directories by command line. Sorry, but why don't you just use Make.config like everyone else does. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Filesystem hierachy standard patch needs review.
2012/4/8 Manuel Reimer > > ACK from me, but without the last additions by Christopher (more complex > handling of directory paths based on whether the new parameters to VDR are > given). > > Yes, I also think it's better to not use these additions. It's complex and I don't see any reason for them. Usually everything which is set in Make.config is right. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Filesystem hierachy standard patch needs review.
2012/4/7 Udo Richter > Am 06.04.2012 15:01, schrieb Christopher Reimer: > > could someone please review the attached patch? It's originally posted > > by Maniac in this thread --> > > On the original topic, I see room for one improvement: > > I tried to fix this on my own. So be careful In case CACHEDIR and VIDEODIR are equal and Cachdir isn't set via command line while Videodir is set. It should now use the Videodir as Cachedir. It is a bit confusing that there's no DEFAULTVIDEODIR in vdr.c RESDIR and CONFDIR should work similar. Nevertheless isn't ConfigDir also staying default, in case the VideoDir is changed via --video. Christopher vdr_fhs_1.3.diff Description: Binary data ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Filesystem hierachy standard patch needs review.
I think there's one problem left. Doesn't VDR try to create the "plugins" subdir? VDR runs usually as user. Most distribution maintainer will give VDR write permission for the cache dir and the config dir. But not for the resource dir. To prevent these permission problems I think it's neccessary to change the Makefile from install-dirs: @mkdir -p $(DESTDIR)$(VIDEODIR) @mkdir -p $(DESTDIR)$(CONFDIR) @mkdir -p $(DESTDIR)$(RESDIR) @mkdir -p $(DESTDIR)$(CACHEDIR) to install-dirs: @mkdir -p $(DESTDIR)$(VIDEODIR) @mkdir -p $(DESTDIR)$(CONFDIR)/plugins @mkdir -p $(DESTDIR)$(RESDIR)/plugins @mkdir -p $(DESTDIR)$(CACHEDIR)/plugins or at least install-dirs: @mkdir -p $(DESTDIR)$(VIDEODIR) @mkdir -p $(DESTDIR)$(CONFDIR) @mkdir -p $(DESTDIR)$(RESDIR)/plugins @mkdir -p $(DESTDIR)$(CACHEDIR) ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] Filesystem hierachy standard patch needs review.
Hi Mailinglist, could someone please review the attached patch? It's originally posted by Maniac in this thread --> http://www.vdr-portal.de/board60-linux/board14-betriebssystem/p1054966-vdr-verzeichnisse-nach-filesystem-hierarchy-standard-fhs-richtig-ablegen/#post1054966 The documentation and some Makefile changes are my work. The main code changes are Maniac's work. I hope the code as well as the documentation is ok, so that the patch can be added in the next VDR Version. Thanks, Christopher Reimer vdr_fhs_1.2.diff Description: Binary data ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] TT Premium S2-6400
2011/6/5 Richard Scobie > Can anyone tell me if this includes YUV/RGB out, or just composite? > There's both. Red, green, blue --> YUV and yellow, red, white --> Composite. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] skip +/- 60 sec suggestion.
2011/2/6 Steffen Barszus > On Sun, 6 Feb 2011 12:47:33 -0800 > VDR User wrote: > > > On Sun, Feb 6, 2011 at 12:16 PM, Theunis Potgieter > > wrote: > > >> IIRC, mythtv had a feature built-in that skips ads automagically. > > >> Maybe a plugin could be written for VDR which provides the same > > >> function. Would be very cool and resolve the problem with seeking > > >> h264 recordings where the still frame will remain unchanged for > > >> several seconds and by the time it does change, its seeked several > > >> minutes. So with h264 ffw/rew you either seek no where or too far. > > >> It's pretty bad unfortunately. > > > > > > There is a package called noad for vdr which makes the marks on > > > where the adverts start/stop. you just need to press skip to jump > > > to the next mark while playing or you can enable it in vdr to > > > automatically jump. This is of course a patch that enables this > > > feature. > > > > I'll gladly give it a try but the only url I found for noad just goes > > to some apache page. Do you have a current url or even hg/git > > address? > > there is an actively maintained plugin called markad - which might be > worth consideration before ... Yes, markad is the better choice!!! ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Framerates
That's a Bug in VDR. Klaus already posted a quick'n'dirty bugfix here -> http://vdr-portal.de/board/thread.php?postid=951626#post951626 2010/12/27 Tobias Grimm > Hi! > > I have tiny question: > > When recording from a HD channel (720p50), the *.rec/info -file tells me > the recording has a framerate of 25 fps. mediainfo or ffmpeg detect > 50 fps. Why such a difference? And what's the framerate the frame number > in the *.rec/marks -file is based on? > > Tobias > > > > > ___ > vdr mailing list > vdr@linuxtv.org > http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr > ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] dvbsddevice-Plugin: Problems with A/V Sync
OK, I think I know the reason of my A/V-Problems The Harddrive is too slow. (Activy 300 => UDMA 66) ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [PATCH] Improved pause handling
Thanks for this nice small patch. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] dvbsddevice-Plugin: Problems with A/V Sync
Anyone else? ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] dvbsddevice-Plugin: Problems with A/V Sync
2010/11/25 Simon Baxter > I had some problems with vdr-1.7.x and vdr-xine front end with audio > sync, but fixed them in xine. > > > Frontend??? I'm using a Technotrend Full-Featured Card. So the backend is the Full-Featured Card and the frontend, too ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] dvbsddevice-Plugin: Problems with A/V Sync
Hi everyone, I am using vdr version 1.7.16 and I have discovered some A/V Sync problems after jumping to another mark or jumping with the yellow/green button. Is that an already-known-problem? ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr 1.7.15 & eHD & French HD DTV
Am 13.06.2010 11:17, schrieb ECLiPSE: Hi, i have an eHD card that is running fine with vdr 1.7.15 except i don't have sound on the HD french channels (TF1HD, France2HD & M6HD) which use the e-AC3 format. Is your VDR patched, then? Or how does the reelbox-Plugin work in your system? ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] ERROR: driver buffer overflow on device 1
Perhaps it's the same problem as I have with my unmodded FF-Card ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-1.7.12 + reelbox plugin
Am 09.02.2010 17:34, schrieb Antti Hartikainen: I don't know if there is later patch available, but this applies fine and works fine with current SVN version of eHD software. Yes, there is an newer patch... --> http://vdr-portal.de/board/thread.php?postid=884015#post884015 ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] S2API wrapper + hard link cutter for VDR-1.7.11
Hard Link Cutter patch, for fast editing of recordings: New version for VDR-1.7.11 http://www.udo-richter.de/vdr/patches.en.html#hlcutter Why isn't this great patch integrated into VDR? ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] VDR crashes while recording a high bandwith channel
Hello, my VDR has exactly *one* Full Featured DVB card as tuner card. The card has *no* hardware mods. If I record a channel with "higher bandwith" (like the german ARD) and watch this channel at the same time, then, after some time, VDR, the driver or "something else" seems to get problems with some kind of "buffer". The following log is from a try with VDR 1.7.10, but I'm able to reproduce the same bug with 1.7.11, too. The DVB drivers are the latest drivers from the v4l hg repository. While this recording, the OSD also gets *pretty* slow. Seems like the FF-card gets pretty busy. Yours Christopher Reimer Log follows: Jan 2 13:13:00 vdr vdr: [3691] switching device 1 to channel 5 Jan 2 13:13:01 vdr vdr: [3702] TS buffer on device 1 thread ended (pid=3691, tid=3702) Jan 2 13:13:01 vdr vdr: [3691] timer 1 (5 1313-1535 'Catch me if you can - Mein Leben auf der Flucht') start Jan 2 13:13:01 vdr vdr: [3691] Title: 'Catch me if you can - Mein Leben auf der Flucht' Subtitle: 'Spielfilm USA 2002 (Catch me if you can)' Jan 2 13:13:01 vdr vdr: [3691] record /var/vdr/video0/Catch_me_if_you_can_-_Mein_Leben_auf_der_Flucht/2010-01-02.13.13.5-0.rec Jan 2 13:13:01 vdr vdr: [3691] creating directory /var/vdr/video0/Catch_me_if_you_can_-_Mein_Leben_auf_der_Flucht Jan 2 13:13:01 vdr vdr: [3691] creating directory /var/vdr/video0/Catch_me_if_you_can_-_Mein_Leben_auf_der_Flucht/2010-01-02.13.13.5-0.rec Jan 2 13:13:01 vdr vdr: [3701] buffer stats: 4136 (0%) used Jan 2 13:13:01 vdr vdr: [3701] receiver on device 1 thread ended (pid=3691, tid=3701) Jan 2 13:13:01 vdr vdr: [3691] recording to '/var/vdr/video0/Catch_me_if_you_can_-_Mein_Leben_auf_der_Flucht/2010-01-02.13.13.5-0.rec/1.ts' Jan 2 13:13:01 vdr vdr: [3708] recording thread started (pid=3691, tid=3708) Jan 2 13:13:01 vdr vdr: [3709] receiver on device 1 thread started (pid=3691, tid=3709) Jan 2 13:13:01 vdr vdr: [3710] TS buffer on device 1 thread started (pid=3691, tid=3710) Jan 2 13:13:02 vdr vdr: [3691] switching to channel 3 Jan 2 13:13:02 vdr vdr: [3691] info: Kanal nicht verfügbar! Jan 2 13:13:03 vdr vdr: [3697] channel 5 (Das Erste) event Sam 02.01.2010 13:10-13:15 (VPS: 02.01 13:10) 'Tagesschau' status 4 Jan 2 13:13:04 vdr vdr: [3691] switching to channel 5 Jan 2 13:13:04 vdr vdr: [3691] buffer stats: 0 (0%) used Jan 2 13:13:04 vdr vdr: [3691] creating directory /var/cache/vdr/vtx/S19.2E-1-1101-28106 Jan 2 13:13:04 vdr vdr: [3711] osdteletext-receiver thread started (pid=3691, tid=3711) Jan 2 13:13:05 vdr vdr: [3691] OSD size changed to 720x576 @ 1,4 Jan 2 13:14:31 vdr vdr: [3710] buffer usage: 70% (tid=3709) Jan 2 13:14:31 vdr vdr: [3710] buffer usage: 60% (tid=3709) Jan 2 13:14:31 vdr vdr: [3710] buffer usage: 70% (tid=3709) Jan 2 13:14:31 vdr vdr: [3710] buffer usage: 60% (tid=3709) Jan 2 13:14:31 vdr vdr: [3710] buffer usage: 70% (tid=3709) Jan 2 13:14:31 vdr vdr: [3710] buffer usage: 60% (tid=3709) Jan 2 13:14:31 vdr vdr: [3710] buffer usage: 70% (tid=3709) Jan 2 13:14:31 vdr vdr: [3710] buffer usage: 60% (tid=3709) Jan 2 13:14:31 vdr vdr: [3710] buffer usage: 70% (tid=3709) Jan 2 13:14:31 vdr vdr: [3710] buffer usage: 60% (tid=3709) Jan 2 13:14:31 vdr vdr: [3710] buffer usage: 70% (tid=3709) Jan 2 13:14:31 vdr vdr: [3710] buffer usage: 60% (tid=3709) Jan 2 13:14:31 vdr vdr: [3710] buffer usage: 70% (tid=3709) Jan 2 13:14:31 vdr vdr: [3710] buffer usage: 60% (tid=3709) Jan 2 13:14:31 vdr vdr: [3710] buffer usage: 70% (tid=3709) Jan 2 13:14:31 vdr vdr: [3710] buffer usage: 60% (tid=3709) Jan 2 13:14:31 vdr vdr: [3710] buffer usage: 70% (tid=3709) Jan 2 13:14:31 vdr vdr: [3710] buffer usage: 60% (tid=3709) Jan 2 13:14:31 vdr vdr: [3710] buffer usage: 70% (tid=3709) Jan 2 13:14:31 vdr vdr: [3710] buffer usage: 60% (tid=3709) Jan 2 13:14:31 vdr vdr: [3710] buffer usage: 70% (tid=3709) Jan 2 13:14:31 vdr vdr: [3710] buffer usage: 60% (tid=3709) Jan 2 13:14:31 vdr vdr: [3710] buffer usage: 70% (tid=3709) Jan 2 13:14:31 vdr vdr: [3710] buffer usage: 60% (tid=3709) Jan 2 13:14:31 vdr vdr: [3710] buffer usage: 70% (tid=3709) Jan 2 13:14:31 vdr vdr: [3710] buffer usage: 60% (tid=3709) Jan 2 13:14:31 vdr vdr: [3710] buffer usage: 70% (tid=3709) Jan 2 13:14:31 vdr vdr: [3710] buffer usage: 60% (tid=3709) Jan 2 13:14:31 vdr vdr: [3710] buffer usage: 70% (tid=3709) Jan 2 13:14:31 vdr vdr: [3710] buffer usage: 60% (tid=3709) Jan 2 13:14:31 vdr vdr: [3710] buffer usage: 70% (tid=3709) Jan 2 13:14:31 vdr vdr: [3710] buffer usage: 60% (tid=3709) Jan 2 13:14:31 vdr vdr: [3710] buffer usage: 70% (tid=3709) Jan 2 13:14:31 vdr vdr: [3710] buffer usage: 60% (tid=3709) Jan 2 13:14:31 vdr vdr: [3710] buffer usage: 70% (tid=3709) Jan 2 13:14:31 vdr vdr: [3710] buffer usage: 60% (tid=3709) Jan 2 13:14:31 vdr vdr: [3710] buffer usage: 70% (tid=3709) Jan 2 13:14:31 vdr vdr: [3710] buffer usage:
