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
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
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
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
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
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
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
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
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
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
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
... 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
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
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
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.
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
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
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
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
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”
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
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
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
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,
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
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
26 matches
Mail list logo
