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 manuel.rei...@gmx.de 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
klaus.schmidin...@tvdr.de 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);
+ bool
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 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] 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] 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 joachim.wi...@gmail.com: 2013/1/25 Christopher Reimer c.reimer1...@gmail.com: 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
2013/1/23 Joachim Wilke joachim.wi...@gmail.com: 2013/1/22 Klaus Schmidinger klaus.schmidin...@tvdr.de 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] [ANNOUNCE] VDR developer version 1.7.36
Ever tried LCLBLD=1 or ONEDIR=1 ? Christopher 2013/1/25 Andreas Brachold m...@deltab.de: 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
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 joachim.wi...@gmail.com: 2013/1/25 Christopher Reimer c.reimer1...@gmail.com 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
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 c.reimer1...@gmail.com: 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 joachim.wi...@gmail.com: 2013/1/25 Christopher Reimer c.reimer1...@gmail.com 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] 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=AttachmentattachmentID=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 d...@lst.de: 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
2012/12/30 fnu v...@auktion.hostingkunde.de: 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
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 v...@dachsweb.de: 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
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 v...@helmutauer.de: 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/29 Udo Richter udo_rich...@gmx.de: 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
2012/12/25 Klaus Schmidinger klaus.schmidin...@tvdr.de: 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 user@gmail.com: 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 ludwig.nus...@suse.de: 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 geronimo...@gmx.de: 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/1 Klaus Schmidinger klaus.schmidin...@tvdr.de: 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] Filesystem hierachy standard patch needs review.
2012/9/3 Ludwig Nussel ludwig.nus...@suse.de: 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] [ANNOUNCE] epgfixer-plugin 0.0.4
2012/4/12 Matti Lehtimäki matti.lehtim...@gmail.com 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.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=^(?shorttext.{5,15})[\.][
](?description.*)$
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.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] [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] Filesystem hierachy standard patch needs review.
2012/4/9 Klaus Schmidinger klaus.schmidin...@tvdr.de 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 Manuel Reimer manuel.rei...@gmx.de 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/8 Udo Richter udo_rich...@gmx.de - 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 VDR User user@gmail.com 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/7 Udo Richter udo_rich...@gmx.de 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
[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] 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
Re: [vdr] TT Premium S2-6400
2011/6/5 Richard Scobie r.sco...@clear.net.nz 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] 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 linu...@nzbaxters.com 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
