Re: [vdr] [DISCUSSION REQUEST] reintroduce a common make configuration file in VDR-1.7.35
Hi, Am 26.12.2012 15:54, schrieb Manuel Reimer: I think that we should keep the possibility to configure highlevel plugin options from a central place like plugins.conf just as Make.config did up to VDR-1.7.33. What is your plan? Do you want to build plugins the old way inside the VDR source dir? If so, then just add your options to your Make.config as you did in the past, but prefix them with an export . Something like: export PLUGIN_OPTION = any_value This way the options reach the plugin Makefiles if you do your make plugins as the global VDR Makefile exports the value. Thanks for this hint. This is what I was looking for. If it works as you write, then at least I have no need for plugins.conf at the moment. Bye. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:rni...@gmx.de ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.34
On 26.12.2012 22:28, Udo Richter wrote: ...(or returning to 1.7.31 where editing recordings doesn't take forever.) If you want to use your hardlink cutter with recent versions of VDR, you could simply patch out the calls to DanglingPacketStripper.Process(), GetPendingPackets() and ptsFixer.Fix() in cCuttingThread::ProcessSequence(). There will be no fixing of timestamps and continuity counters then, but I guess you don't need that, anyway... Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] Positioner and multi-tuner setup?
Hi. I would want to somehow configure VDR to use positioner (H-H motor) and dual tuner setup, to receive two transponders from same source at one time. My current hardware setup is: TechnoTrend S2-6400 dual tuner DVB-S2 with H/W decoder, H-H motor and a quad LNB. I'm using diseqc commands in diseqc.conf to control the motor, as GOTOXX patch and rotorng plugin are both too buggy to be used. Rotorng I used to store the positions. Currently I only have one tuner in use, and it is connected to the motor. I was wondering if it would be somehow possible to get second tuner in use also. It would be connected directly to LNB, and that tuner would be limited to the same satellite source as the other tuner is tuned to, and have independent frequency/polarization. Thanks. PS. What is the current recomended way for using positioner with VDR? Preferred would be a USALS capable setup. ___ 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
On 26.12.2012 20:19, Udo Richter wrote: ... Oh, and by the way, with introducing $(CWD) some previously relative paths got hard coded, so moving these builds around or accessing them from different mount points might now be broken. For example, my default lib dir changed from ./PLUGINS/lib to /usr/src/pc/vdr/vdr-1.7.34/PLUGINS/lib, which only makes sense within a single virtual machine that cannot even run VDR at all. I'll have to add some overrides for that. The attached patch changes the VDR Makefile back to using relative paths if the plugins are built locally. The patch also contains - Making sure that plugins include the VDR header files from the actual VDR source directory when doing make plugins (suggested by Christoper Reimer). - Increased the version numbers of all plugins to reflect the recent Makefile changes. - If set, DVBDIR is now conveyed to plugins via the CFLAGS. - Removed some redundancy from Make.config.template. - Changed == to = in the Makefile to make it POSIX style. - Now using targets install-lib and install-i18n when building plugins locally. - Added MANDIR to the vdr.pc file, so that plugins that need it can retrieve it via MANDIR = $(DESTDIR)$(call PKGCFG,mandir). - Using relative paths again when building plugins locally (by request of Udo Richter). ...still considering what to do with the plugin configuration stuff. Currently I tend to put a plgcfg entry into vdr.pc, since apparently everybody wants this to be somewhere else. I'm just glad Linux distribution managers don't build cars - otherwise we would most likely be long dead before we find the brake pedal... ;-) Klaus --- Makefile 2012/12/23 11:28:13 2.36 +++ Makefile 2012/12/27 16:02:53 @@ -4,7 +4,7 @@ # See the main source file 'vdr.c' for copyright information and # how to reach the author. # -# $Id: Makefile 2.36 2012/12/23 11:28:13 kls Exp $ +# $Id: Makefile 2.41 2012/12/27 14:00:51 kls Exp kls $ .DELETE_ON_ERROR: @@ -17,14 +17,13 @@ CXXFLAGS ?= $(CFLAGS) -Werror=overloaded-virtual -Wno-parentheses CFLAGS += -fPIC -CXXFLAGS += -fPIC CDEFINES = -D_GNU_SOURCE CDEFINES += -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE # Directories: -CWD := $(shell pwd) +CWD = . LSIDIR = ./libsi DESTDIR ?= PREFIX ?= /usr/local @@ -49,6 +48,12 @@ -include Make.config +ifdef DVBDIR +CFLAGS += -I$(DVBDIR)/include +endif + +UP3 = $(if $(findstring $(LIBDIR)-$(LOCDIR),$(CWD)/PLUGINS/lib-$(CWD)/locale),../../../,) + SILIB= $(LSIDIR)/libsi.a OBJS = audio.o channels.o ci.o config.o cutter.o device.o diseqc.o dvbdevice.o dvbci.o\ @@ -127,15 +132,16 @@ .PHONY: vdr.pc vdr.pc: @echo bindir=$(BINDIR) $@ + @echo mandir=$(MANDIR) $@ @echo configdir=$(CONFDIRDEF) $@ @echo videodir=$(VIDEODIR) $@ @echo cachedir=$(CACHEDIRDEF) $@ @echo resdir=$(RESDIRDEF) $@ - @echo libdir=$(LIBDIR) $@ - @echo locdir=$(LOCDIR) $@ + @echo libdir=$(UP3)$(LIBDIR) $@ + @echo locdir=$(UP3)$(LOCDIR) $@ @echo apiversion=$(APIVERSION) $@ - @echo cflags=$(CFLAGS) $(CDEFINES) -I$(INCDIR) $@ - @echo cxxflags=$(CXXFLAGS) $(CDEFINES) -I$(INCDIR) $@ + @echo cflags=$(CFLAGS) $(CDEFINES) -I$(UP3)$(INCDIR) $@ + @echo cxxflags=$(CXXFLAGS) $(CDEFINES) -I$(UP3)$(INCDIR) $@ @echo $@ @echo Name: VDR $@ @echo Description: Video Disk Recorder $@ @@ -193,10 +199,14 @@ continue;\ fi;\ target=all;\ - if [ $(LIBDIR) == $(CWD)/PLUGINS/lib ] [ $(LOCDIR) == $(CWD)/locale ]; then\ - target=install;\ + if [ $(LIBDIR) = $(CWD)/PLUGINS/lib ] [ $(LOCDIR) = $(CWD)/locale ]; then\ + target=install-lib install-i18n;\ + fi;\ + includes=;\ + if [ $(INCDIR) != $(CWD)/include ]; then\ + includes=INCLUDES=-I$(UP3)/include;\ fi;\ - $(MAKE) --no-print-directory -C $(PLUGINDIR)/src/$$i VDRDIR=$(CWD) $$target || failed=$$failed $$i;\ + $(MAKE) --no-print-directory -C $(PLUGINDIR)/src/$$i VDRDIR=$(UP3)$(CWD) $$includes $$target || failed=$$failed $$i;\ done;\ if [ -n $$noapiv ] ; then echo; echo *** plugins without APIVERSION:$$noapiv; echo; fi;\ if [ -n $$failed ] ; then echo; echo *** failed plugins:$$failed; echo; exit 1; fi @@ -239,7 +249,7 @@ install-plugins: plugins @for i in `ls $(PLUGINDIR)/src | grep -v '[^a-z0-9]'`; do\ - $(MAKE) --no-print-directory -C $(PLUGINDIR)/src/$$i VDRDIR=$(CWD) DESTDIR=$(DESTDIR) install;\ + $(MAKE) --no-print-directory -C $(PLUGINDIR)/src/$$i VDRDIR=$(UP3)$(CWD) DESTDIR=$(DESTDIR) install;\ done # Includes: ___ 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
Klaus Schmidinger wrote: ...still considering what to do with the plugin configuration stuff. Currently I tend to put a plgcfg entry into vdr.pc, since apparently everybody wants this to be somewhere else. I'm just glad Linux distribution managers don't build cars - otherwise we would most likely be long dead before we find the brake pedal... ;-) Distributors don't need global plugin configuration. At least not for any distribution, I know. The usual way is to have all stuff, that belongs to one package, in one place. Noone edits the build relevant stuff for the base VDR package if a new plugin has to be packaged. So: No need for global plugin configuration in this case. To anyone who wants that global configuration: Why do you need it and don't you think an alternative way will do just as well? Yours Manuel ___ 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
On 27.12.2012 17:22, Manuel Reimer wrote: Klaus Schmidinger wrote: ...still considering what to do with the plugin configuration stuff. Currently I tend to put a plgcfg entry into vdr.pc, since apparently everybody wants this to be somewhere else. I'm just glad Linux distribution managers don't build cars - otherwise we would most likely be long dead before we find the brake pedal... ;-) Distributors don't need global plugin configuration... This was more like a general rant about Linux distributions all wanting there files in different locations. Klaus ___ 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
Klaus Schmidinger wrote: This was more like a general rant about Linux distributions all wanting there files in different locations. This is common on most Unix systems. There are common paths where specific types of files should be placed to. If you are used to the common paths, then you'll find the files, you are looking for, without the need to have to look into the programs documentation. The alternative would be that everyone places stuff to wherever they want which would result in noone knowing about where to search for a specific library on the system. So maybe most software would be linked statically or would bring their own version of $LIBRARY. It would be a total mess to update this if a security hole in a popular library has to be patched... Yours Manuel ___ 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
On 27.12.2012 17:43, Manuel Reimer wrote: Klaus Schmidinger wrote: This was more like a general rant about Linux distributions all wanting there files in different locations. This is common on most Unix systems. There are common paths where specific types of files should be placed to. If you are used to the common paths, then you'll find the files, you are looking for, without the need to have to look into the programs documentation. But these common paths tend to be different on the various systems, and that's what bothers me. But we're getting OT here... Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.34
Am 27.12.2012 14:43, schrieb Klaus Schmidinger: If you want to use your hardlink cutter with recent versions of VDR, you could simply patch out the calls to DanglingPacketStripper.Process(), GetPendingPackets() and ptsFixer.Fix() in cCuttingThread::ProcessSequence(). There will be no fixing of timestamps and continuity counters then, but I guess you don't need that, anyway... Its probably a bit more tricky than that, as the exact definition of editing marks has changed. (eg. two marks at same place, including the ending GOP, etc.) It needs a proper rewrite from scratch to get at least the old style back, and my time is way to limited. A pragmatic quick-hack I've thought of was to set up a recording command that launches an old VDR version's command line editing call. It also handles editing marks the old style though. Cheers, Udo ___ 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'm just glad Linux distribution managers don't build cars - otherwise we would most likely be long dead before we find the brake pedal... ;-) As a distribution manger I have to disagree ;) All I'm doing now, is to wait til you find a solution which won't be changed within the next five days and then I put my distribution around it ;) But I think I have to wait til V2, there are way too much changes at the moment :) -- Helmut Auer, hel...@helmutauer.de ___ 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
Am 27.12.2012 19:11, schrieb Helmut Auer: I'm just glad Linux distribution managers don't build cars - otherwise we would most likely be long dead before we find the brake pedal... ;-) As a distribution manger I have to disagree ;) All I'm doing now, is to wait til you find a solution which won't be changed within the next five days and then I put my distribution around it ;) Something similar I wrote in the portal. So Full ACK. Gerald !DSPAM:50dc90eb87784772790529! ___ 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
... there are way too much changes at the moment :) FullAck, but the number of changes are not the issue, it's more the sustainability and the time frame within the changes. Looking to the last 5 versions, each of them do look allmost like a complete new version. There is allmost no time for other developers (plugins, addons and distros) to react to them and the worse, they don't now if their work is valid for the next vdr developer version. If you want to stop any development around VDR, go ahead like this ... But don't forget, you don't make a solution liek VDR a success or BBS like vdr-portal only with a few make; make install users. Over 95% of VDR users are using a distribution. === Kind regards fnu ___ 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
Am 27.12.2012 19:11, schrieb Helmut Auer: I'm just glad Linux distribution managers don't build cars - otherwise we would most likely be long dead before we find the brake pedal... ;-) As a distribution manger I have to disagree ;) All I'm doing now, is to wait til you find a solution which won't be changed within the next five days and then I put my distribution around it ;) But I think I have to wait til V2, there are way too much changes at the moment :) P.S: That doesn't mean you should hurry up to find a solution, I can live very well with former VDR versions, these are all great for getting a stable PVR at home - Thanks Klaus ! -- Helmut Auer, hel...@helmutauer.de ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.34
On 27.12.2012 18:48, Udo Richter wrote: Am 27.12.2012 14:43, schrieb Klaus Schmidinger: If you want to use your hardlink cutter with recent versions of VDR, you could simply patch out the calls to DanglingPacketStripper.Process(), GetPendingPackets() and ptsFixer.Fix() in cCuttingThread::ProcessSequence(). There will be no fixing of timestamps and continuity counters then, but I guess you don't need that, anyway... Its probably a bit more tricky than that, as the exact definition of editing marks has changed. (eg. two marks at same place, including the ending GOP, etc.) It needs a proper rewrite from scratch to get at least the old style back, and my time is way to limited. I don't see why you would have to even care about this modified handling of marks. This is all taken care for in cCuttingThread::Action(), and cCuttingThread::ProcessSequence() only has to make sure the data from BeginIndex to EndIndex-1 goes into the edited version. Just take a short look at the new code. I'm sure you'll see how the fromMarks handling is now completely separated from the actual data handling. A pragmatic quick-hack I've thought of was to set up a recording command that launches an old VDR version's command line editing call. It also handles editing marks the old style though. Whatever suits you best. I was just trying to give some pointers. Klaus ___ 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
On 27.12.2012 13:21, VDR User wrote: On Thu, Dec 27, 2012 at 10:20 AM, fnu v...@auktion.hostingkunde.de wrote: ... there are way too much changes at the moment :) FullAck, but the number of changes are not the issue, it's more the sustainability and the time frame within the changes. Looking to the last 5 versions, each of them do look allmost like a complete new version. There is allmost no time for other developers (plugins, addons and distros) to react to them and the worse, they don't now if their work is valid for the next vdr developer version. If you want to stop any development around VDR, go ahead like this ... Keep in mind, all these changes are occurring in the _developer_ version of VDR, not stable. If package maintainers choose to use developer rather than stable versions, they should expect things like this. Maybe the problem isn't the changes, it's that they've picked the wrong version to work with. Just a thought. When software advances at glacial speeds(*) reality tends compensate for that over time. See the permanent Beta-marking that many Google-Services tended to have in the past. *: The timestamp of the 1.6.0 release (a.k.a. vdr-current.tar.bz2) on ftp.tvdr.de is: 23.03.2008, -- Matthias ___ 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
Am 27.12.2012 22:21, schrieb VDR User: On Thu, Dec 27, 2012 at 10:20 AM, fnu v...@auktion.hostingkunde.de wrote: But don't forget, you don't make a solution liek VDR a success or BBS like vdr-portal only with a few make; make install users. Over 95% of VDR users are using a distribution. I completely disagree with you claiming over 95% of VDR users are using a distribution. Most of the users I talk to regularly, or observe in various forums do not use pre-made distributions, they compile VDR themselves so they have full control over what patches (if any) are being applied, how it's set up, etc. I would never come to the idea to say that over 95% of the VDR users use a distribution and I even would not say the opposite, because I really have no idea. But what makes you so sure that it is wrong? Do you think you know more than 5% of all VDR users? Gerald !DSPAM:50dccbaa99813830873357! ___ 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
Keep in mind, all these changes are occurring in the _developer_ version of VDR, not stable. Oh damn, I did not even realize this ... ^^ Nobody really want to use VDR 1.6.0 anymore these days, in Europe we would not be able to watch HDTV. Facing this fact VDR 1.7.3+ is more than just a developer playground. All plugins for VDR 1.6.0 are already saddled, for 1.7.x they need keep up with VDR's development, so that is not a question of choosing the wrong version. It can't be the right way that there is a VDR developer version, which is just usable from vanilla source w/o any addon and hardly in any other environment. How should anybody test it for real life, assuming that the next version does again deny all work again ... ? I don't deny changes, quite the contrary, Klaus does now it, I appreciate them. But the way of the last changes, in best manner of Louis XIV, ignoring all other needs around can't be the right way. Derek tell me, do you compile your Linux also from scratch/source? I would assume you don't do this and rather using something like Fedora, RedHat, SuSE, Debian, Gentoo etc. using comfortably the offered packages ot their repositories, even the ones from unstable sources. If I talk about distro, I do talk rather about these package offerings. I did compile my VDR from source for many years since the year 2000/2001, but I appreciate to have it as Debian package or similar later days. I would also not compile my libreoffice from source, why, it's already there. And I like to offer up to date Ubuntu packages for interessted users. VDR is indeed a success and my alltime HTPC favorite, thanks for it Klaus. But that is not from the users compiling from source. I do not talk about some dozens of US users compiling VDR themselfs from source. VDR start to get a huge distribution in Germany and later Europe from pre-packaged ISOs, like vdr4you, linvdr and especially c't-vdr (thanks Tobi and team). These days easyvdr, gen2vdr, MLD and yaVDR do provide OOTB VDRs for thousands of installations in Germany, Europe, maybe worldwide. Does anybody think these users would be interssted in VDR 1.6.0 nowadays? No, they are more than happy with these VDR 1.7.x based installations, modern and capable for HDTV and they do tell this their neighbours using any crappy satellite receiver with a lot of problems ... ;-) Linux wouldn't have been that succesfull, if Linus Torvalds would not had an ear to the needs of others, even business needs ... === Kind regards fnu ___ 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
On 27.12.2012 23:40, fnu wrote: ... But the way of the last changes, in best manner of Louis XIV, ignoring all other needs around can't be the right way. All I did was to accept a patch from Christopher Reimer that removed some redundancy in the Makefiles and would better isolate the plugins Makefiles from the core VDR. Sure, it's an incompatible change, but sometimes you have to make some deeper cuts, and a developer version is the place to do that. I even provided a sample patch that shows all the necessary changes to plugin Makefiles, and I am now working on integrating the input that was triggered by this change (see the patch I posted earlier today). If I don't accept patches, I'm blamed for slowing down development. If I do accept a patch that causes a little work to adapt to (but looks promising in the long run), I'm being offended by being compared to Louis XIV. I guess you just can't win 'em all... Klaus ___ 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
If I don't accept patches, I'm blamed for slowing down development. If I do accept a patch that causes a little work to adapt to (but looks promising in the long run), I'm being offended by being compared to Louis XIV. I guess you just can't win 'em all... You're absolutely right here. The problem behind is that there are about 250 working plugins for VDR and about 200 of these are only maintained by the distributors. So its a lot of work for all distributors to patch these plugins to get those running again. (And I would prefer for my distri to patch VDR instead of fixing these plugin Makefiles) But you don't have to care about this, the distributors are using many patches :) -- Helmut Auer, hel...@helmutauer.de ___ 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
On 27 Dec 2012, at 23:41, fnu v...@auktion.hostingkunde.de wrote: Linux wouldn't have been that succesfull, if Linus Torvalds would not had an ear to the needs of others, even business needs ... A Christmas message from Linus – “IF YOU BREAK USERSPACE I HATE YOU AND YOU ARE A TERRIBLE PERSON” http://article.gmane.org/gmane.linux.kernel/1414106 ___ 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
Dominic, good one! I know, a coin has always two sides, but hack, look where Linux nowadays is . ^^ Cheers Frank Im Auftrag von Dominic Evans Gesendet: Freitag, 28. Dezember 2012 00:47 An: VDR Mailing List Betreff: Re: [vdr] [DISCUSSION REQUEST] reintroduce a common make configuration file in VDR-1.7.35 On 27 Dec 2012, at 23:41, fnu wrote: Linux wouldn't have been that succesfull, if Linus Torvalds would not had an ear to the needs of others, even business needs ... A Christmas message from Linus - IF YOU BREAK USERSPACE I HATE YOU AND YOU ARE A TERRIBLE PERSON http://article.gmane.org/gmane.linux.kernel/1414106 http://article.gmane.org/gmane.linux.kernel/1414106 ___ 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
Matthias Schniedermeyer: Pointing out that the last stable release of VDR having an old timestamp has nothing to do with people _choosing_ to use the developer version, which is warned and well-known to possibly contain changes that will cause problems for those expecting stable behavior. The advice has always been, and will always be, if you expect stable then use stable. Gerald Dachs: I think fnu is wrong in his assumption that over 95% of VDR users use pre-made VDR distributions because I see no evidence of it anywhere. Not in forums, mailing lists, irc, ... Ultimately nobody knows the true answer but that doesn't mean you should look at things with blinders on that only allow you to see what you want to see. @fnu: Nobody really want to use VDR 1.6.0 anymore these days, in Europe we would not be able to watch HDTV. Facing this fact VDR 1.7.3+ is more than just a developer playground. VDR 1.7.3+ _are_ developer versions no matter how many users use it, or why they do. It can't be the right way that there is a VDR developer version, which is just usable from vanilla source w/o any addon and hardly in any other environment. Plugin authors have two choices.. They can 1) follow the VDR developer versions knowing that there may be many changes and require a lot of work to make their plugins work with each version, or 2) update their plugin only at stable version intervals.. Thankfully it seems #1 is the popular choice because it keeps them active and makes it highly likely their plugins will work with the next stable release at the moment it's released. But, again, choosing developer VDR means you may face the possibility that everything will break with the next version. History says this rarely happens but it could and whether or not it does shouldn't be the deciding factor in if VDR adopts a change or not. Klaus I'm sure has had many VDR growing pains over the years -- it's not exactly unreasonable to say plugin authors might have them as well. Derek tell me, do you compile your Linux also from scratch/source? I would assume you don't do this and rather using something like Fedora, RedHat, SuSE, Debian, Gentoo etc. using comfortably the offered packages ot their repositories, even the ones from unstable sources. I use Debian testing and compile the following; VDR, VDR plugins I use, mplayer2, ffmpeg, the kernel, external (media_build) dvb lirc drivers. I do not use a desktop and therefore don't waste my time with anything beyond installing xserver so my VDR boxes have a way to output video. But compiling an entire distro from scratch? No, I don't do that. I hope you're not comparing compiling VDR to compiling an entire distro because that would be dumb. VDR is indeed a success and my alltime HTPC favorite, thanks for it Klaus. But that is not from the users compiling from source. I do not talk about some dozens of US users compiling VDR themselfs from source. You're not only vastly underestimating the size of the NA user base (not just the US), but you're also ignoring all the european VDR users who do not user pre-made VDR and the history VDR had before pre-made was around. Many users install pre-made packages or use something like yavdr. And very obviously many users do not. Pulling magical numbers out of thin air won't change that fact and neither will pretending other types of VDR users don't exist. You think VDR is successful because of pre-made stuff. I think it was successful before that. Let's just agree to disagree. You can keep installing yavdr, I will keep compiling VDR myself, and everyone else will do whatever they do. Linux wouldn't have been that succesfull, if Linus Torvalds would not had an ear to the needs of others, even business needs ... I'm not sure why you're mentioning this. Are you implying that VDR-1.7.34 goes against the _needs_ of plugin authors? Klaus certainly takes what other people want into consideration and has implemented things that wouldn't have happened if they were based solely on his own opinion/preference/needs/wants. Lack of consideration for others isn't even an issue here so I'm not sure why you're bringing it up. Everyone: Sorry for using this reply format but it seemed more appropriate than posting several replies in a row. ___ 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
On 27.12.2012 16:55, VDR User wrote: Matthias Schniedermeyer: Pointing out that the last stable release of VDR having an old timestamp has nothing to do with people _choosing_ to use the developer version, which is warned and well-known to possibly contain changes that will cause problems for those expecting stable behavior. The advice has always been, and will always be, if you expect stable then use stable. It is, or can be, a dependency problem. If your main use-case is for e.g. provided by a plugin that only works with the lastest development-release you are more or less forced to use a development release. Or some other example i use a self compiled VDR, but i'm also a Debian user. Debian is currently in a freeze-phase for the next stable release. So i looked which version of VDR i could install: apt-cache show vdr | grep Version Version: 1.7.28-1 There isn't even a 1.6 version to install only a single 1.7 Version. (Technically i'm on unstable, but there shouldn't be that much difference as long as Wheezy isn't released ) And this is Debian, famous for being ultraconservative when it is about stability. I'm smelling a problem of reality. When the caravan moves on Linus realized that when he changed the development-model of the kernel last time some years ago: Yearlong gaps are a problem in reality. -- Matthias ___ 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 think fnu is wrong in his assumption that over 95% of VDR users I'm not wrong, the users compiling VDR from scratch are far in minority. Again I'm not just talking about ready to run ISO images. There are plenty of silent users working the packages out of Linux' distros repositories, Debian, Ubuntu, Gentoo, Fedrora etc. Many of them run VDR underneath any other HTPC solution. These users don't argue on mailing lists nor on the different forum, so nobody can hear them. On top of these amount, there are a lot of silent users running ISO based VDRs. I assume there is still a good hundred linvdr installations out there, running their good old FF cards. But that is not the topic here, it's more that the few maintainers of these repositories, what ever kind, are ignored in their needs to provide usable packages to these quite huge number of users. A few DIY users are more equal then even fewer distro and packaging maintainers ... === Kind regards fnu ___ 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
On Thu, Dec 27, 2012 at 5:29 PM, fnu v...@auktion.hostingkunde.de wrote: I'm not wrong, the users compiling VDR from scratch are far in minority. Again I'm not just talking about ready to run ISO images. You make this claim but the opposite is observed on mailing lists, forums, and irc. Since you're so convinced, maybe you can share some actual evidence that backs it up since taking your word for it isn't proof of anything. Or maybe your sentence was incomplete.. Did you mean to say, I'm not wrong, the users compiling VDR from scratch are far in minority... on the yavdr forum? There are plenty of silent users working the packages out of Linux' distros repositories, Debian, Ubuntu, Gentoo, Fedrora etc. Many of them run VDR underneath any other HTPC solution. These users don't argue on mailing lists nor on the different forum, so nobody can hear them. I agree that there is a huge number of silent users. I know many myself, most of which compile VDR -- the opposite of what you're claiming. Does that mean anything? Not really... Only that there are obviously many VDR users with differing VDR preferences. The difference between my view and yours is that you seem to think barely anyone outside of your own viewpoint exists.. On top of these amount, there are a lot of silent users running ISO based VDRs. I assume there is still a good hundred linvdr installations out there, running their good old FF cards. I wouldn't assume that. I can't even name a single person who uses linvdr but at least I don't deny that they might exist. But that is not the topic here, it's more that the few maintainers of these repositories, what ever kind, are ignored in their needs to provide usable packages to these quite huge number of users. A few DIY users are more equal then even fewer distro and packaging maintainers ... I'm not sure why you keep pretending there's hardly even a small handful of DIY users when there's plenty of evidence that says otherwise. I guess you think if you say it enough, people will be hypnotized into believing it. It may be hard for you to accept but reality is that VDR has a successful life way past yavdr and `apt-get install 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
On Thu, Dec 27, 2012 at 7:38 PM, fnu v...@auktion.hostingkunde.de wrote: users when there's plenty of evidence that says otherwise. You did not provide any ... you also just pray your truth ... This mailing list, the freebsd multimedia mailing list, forums such as vdr-portal, dvbn, and numerous others, irc channels, etc. all have many users who compile VDR themselves. It's so absurd to deny it that I'm forced to think you're just trolling with the outlandish claims you keep making. It may be hard for you to accept but reality is that VDR has a successful life way past yavdr and `apt-get install vdr`. Yes, I know, I have been part of it. I still keep the same historic case of the first VDR ever, bought in 2000 after my first contact to Klaus, see pic on tvdr.de ... So, fortunately the majority of Linux world has left the make; make install cave. You must know how incredibly stupid that comment is. Anyone who thinks otherwise should google linux make install and be careful not to drown in the ocean of posts messages they find. Please stop the ridiculousness -- it's not like you've provided a single shred of evidence, or a single person has taken your magical numbers assumptions as truth. Let's not waste more mailing list space with this nonsense. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
