"Frank Schmirler" wrote:
> > yes, intelligent timer migration between vdr instances is a not
> > trivial task. when a timer is to be fired, you have to ask all vdr
> > instances its timer list and move the timer to the most suitable
> > instance. taking into account recordings on the same transpo
Seppo Ingalsuo wrote:
> > vdr in a massive client server configuration is a giant hack with
> > many pieces each with its own little problems summing up.
>
> Not giant system, but some experiences: I have one server running
> three instances of vdr. Vdr #2 and #3 are connected by streamdev to
>
"Alex Betis" wrote:
> Strange... I sent that email to the list, but it doesn't appear there.
> Resending...
it has appeared. i guess you pull your mails from gmail via pop. gmail
does not send you your own mails. it's annoying - i know. :-)
___
vdr ma
Udo Richter wrote:
> I really don't get the point why it is necessary to totally rewrite
> VDR core to support multiple frontends (surely loosing compatibility
> to almost all plugins), when it will at the end just start one thread
> per frontend, while we can already start one VDR instance per
>
Tobi <[EMAIL PROTECTED]> wrote:
> Thanks for your patience!
very nice work, well done! useful and informative. kudos to you!
clemens
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Klaus Schmidinger <[EMAIL PROTECTED]> wrote:
> There should be only *one* DVB driver API - anything else is rubbish.
> But it should be one that is actually *useful*!
really strange POV. do you also think there should only be one audio API
or only one video driver interface, a.s.o ? how do you th
"VDR User" <[EMAIL PROTECTED]> wrote:
> The idea of adding the DVB support in form of plugins instead of
> including it in the core code? Before I left on vacation there was
> some talk about how this is a better solution these days but not sure
> if anything ever came out of that...?
i brought
Klaus Schmidinger <[EMAIL PROTECTED]> wrote:
> So as long as these cards are not
> supported, VDR will not go anywhere near S2API (and I certainly will
> not support two DVB APIs in parallel).
once again a strong reason to splitt off dvb support into plugins.
clemens
___
"Michael Stepanov" <[EMAIL PROTECTED]> wrote:
> > what does "VDR distribution" mean? the vdr source code? what are you
> > trying to achieve? i guess you have to download the "desired" vdr
> > version, copy your plugins into its PLUGINS/src directory and
> > compile them as usual.
> Yes, I mean
Klaus Schmidinger <[EMAIL PROTECTED]> wrote:
> > i always wondered why dvb support was directly compiled in while
> > other back and frontends were supposed to be plugins. this clearly
> > leaves a sign that dvb is the "preferd" plattform.
>
> Well, it was the first one - long before there even w
"Michael Stepanov" <[EMAIL PROTECTED]> wrote:
> I need to have a possibility to build VDR plugins using headers which
> are different then in VDR distribution.
what does "VDR distribution" mean? the vdr source code? what are you
trying to achieve? i guess you have to download the "desired" vdr
ve
Georg Acher <[EMAIL PROTECTED]> wrote:
> I also don't think that a vdr-repository would help in the development
> speed. Either the whole development procedure needs to be changed
> (more maintainer with KLS's approval) or it has no advantage compared
> to the .tgz-distribution.
maybe using git,
Oliver Endriss <[EMAIL PROTECTED]> wrote:
> Guys, I can't stand this blabla any longer.
why do you read the blabla then and even bother feeding the thread?
please be so tolerant and let people discuss VDR related topics on the
vdr mailing list. thank you.
> Klaus stated clearly how he wants to d
Lauri Tischler <[EMAIL PROTECTED]> wrote:
> Switching to MythTV is *not* a solution to anything. MythTV is slow
> huge, kitchen sink where nothing really works.
maybe s/MythTV/XBMC/g ?
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin
Laz <[EMAIL PROTECTED]> wrote:
> I have always been impressed with the quality of the source code for
> vdr. It's the first proper C++ application I've had course to look
> through in any detail (many, many years of pure C behind me, though!)
> and I've pretty much learned all of the C++ I know fr
"Simon Baxter" <[EMAIL PROTECTED]> wrote:
> Has anyone looked into or thought about a vdradmin style web front
> end, formatted for a mobile browser?
i long plan to hack up something like that for my ipaq and shiny new
openmoko. but i'd rather have a native application connecting via SVDRP
then
"Simon Baxter" <[EMAIL PROTECTED]> wrote:
> How do I do this? I've been looking at modifying xinitrc and
> xinitrc-common to remove the desktop manager, but this seems a bit
> brutal.
not at all. this is the way it is supposed to be.
i would edit /etc/initd.d/xdm (or whatever it is called on you
On Wed, Mar 12, 2008 at 8:13 AM, clemens kirchgatterer <[EMAIL PROTECTED]>
wrote:
> On Tue, Mar 11, 2008 at 3:46 PM, Joerg Pulz <[EMAIL PROTECTED]> wrote:
>
> > Out of this four cases (there are probably more, one for every Linux
> > distribution on this plan
On Tue, Mar 11, 2008 at 3:46 PM, Joerg Pulz <[EMAIL PROTECTED]> wrote:
> Out of this four cases (there are probably more, one for every Linux
> distribution on this planet), tell me which is the most reasonable
> default?
the most reasonable default is simply to put vdr.pc in
[$(DESTDIR)/]$(PR
On Tue, Mar 11, 2008 at 12:27 AM, Matthias Schwarzott <[EMAIL PROTECTED]> wrote:
> On Montag, 10. März 2008, Ville Skyttä wrote:
> So you can install .pc file anywhere you want if you add this location to
> PKG_CONFIG_PATH.
>
> So /usr/bin/pkg-config will always look into /usr/lib/pkgconfig.
>
On Mon, Mar 10, 2008 at 7:31 PM, Udo Richter <[EMAIL PROTECTED]> wrote:
> clemens kirchgatterer wrote:
> > structure bin, lib, include, share, ... if i want to compile software
> > using the libs (and headers) of opt1 i only have to do
> > "PKG_CONFIG_PATH=/opt1
On Sun, Mar 9, 2008 at 10:50 AM, Udo Richter <[EMAIL PROTECTED]> wrote:
> There is _one_ currently installed default version of the headers for
> this machine, and the question is why these headers are not at a default
> location, esp. since the binaries seem to be at a default location, or?
n
Klaus Schmidinger <[EMAIL PROTECTED]> wrote:
> On 03/08/08 19:12, Clemens Kirchgatterer wrote:
> > Klaus Schmidinger <[EMAIL PROTECTED]> wrote:
> >
> >> I still believe, though, that freetype2's include files are broken.
> >> A simple '#
Klaus Schmidinger <[EMAIL PROTECTED]> wrote:
> I still believe, though, that freetype2's include files are broken.
> A simple '#include ' should be enough. If their header
> file(s) would behave like the rest, we wouldn't have this discussion.
no. pkg-config and freetype-config have absolutly not
Klaus Schmidinger <[EMAIL PROTECTED]> wrote:
> On 03/08/08 15:01, Clemens Kirchgatterer wrote:
> > Udo Richter <[EMAIL PROTECTED]> wrote:
> >
> >> #>pkg-config --libs freetype2 fontconfig
> >> -bash: pkg-config: command not found
> >>
Udo Richter <[EMAIL PROTECTED]> wrote:
> Or even better: Is there a third way that works for both?
as i have written in my RFC there is:
freetype-config
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
before i start to suggest a patch for the current build system i would
like to discuss some issues that need addressing.
1. target version: i think it is best to wait for 1.7.0 before changing
the build process, because plugin Makefiles will most likly need
changes too.
2. which headers need expo
Udo Richter <[EMAIL PROTECTED]> wrote:
> #>pkg-config --libs freetype2 fontconfig
> -bash: pkg-config: command not found
>
> - no comment -
i could as easily argue with:
> make
bash: make: command not found
pkg-config is no exotic dependency that we have good reason to avoid.
clemens
___
Ville Skyttä <[EMAIL PROTECTED]> wrote:
> FWIW, I think providing a pkgconfig file is very much a "root"
> solution (ditto $foo-config scripts, but *.pc are much simpler to
> write and read and have a unified interface). Lots of library
> packages (and also some others) provide them nowadays whic
"Martin Prochnow" <[EMAIL PROTECTED]> wrote:
> > Is it possible to change font data directly in code or do I have to
> > create my own true type font containing the icons?
the best aproach IMHO would be an API in VDR that allows you to "nail"
custom glyphs into the glyph cache. though this could
"Theunis Potgieter" <[EMAIL PROTECTED]> wrote:
> udev rules
ha, that was even funny. :)
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Klaus Schmidinger <[EMAIL PROTECTED]> wrote:
> So, here's the straw poll:
>
>Should there be a stable version 1.6.0 now, based on what's in
>version 1.5.14, but without DVB-S2 or even H.264 support?
1.5 already introduced many new features as freetype, the new i18n,
subtitles, ... just t
Reinhard Nissl <[EMAIL PROTECTED]> wrote:
> oprofile also showed strreplace among the top 10 when profiling a 120
> second VDR session. Please find attached a "faster" solution.
i applied all your patches and indeed, vdr feels more responsive now on
the geode vdr client. no stabillity issues yet.
Reinhard Nissl <[EMAIL PROTECTED]> wrote:
> the attached patches speed up starting and stopping VDR on slow
> machines with huge channels.conf files, by avoiding some n / 2 * (n +
> 1) loops.
>
> Please test them and report bugs here.
i have your first patch (with the hashzise bug) running for a
JJussi <[EMAIL PROTECTED]> wrote:
> Have anybody notice that playback is little bit too fast.. Here easy
> way to determit that..
it is quite clear, that playing a recording has to be slower or faster
then live tv. i would even expect to see some difference between
broadcasters. when watching li
regarding to:
> But AFAICS unfortunately no gigabit Ethernet (which I'd like have
> in order to record to my server).
[..]
> I don't want to lose the ability to record 3 DVB-S transponders
> in parallel, and I also need the DVB-T card.
hmm, may i suggest to stick two of your DVB-S cards into th
when i list the recordigs i get no thumbnails and in the console the
following error message apears:
Invalid conversion in sprintf: "%"" at /opt/xxv/lib/xxv/Tools.pm line
154.
to create the thumbs i configured mplayer. xxv is from svn, checked out
aproximatly an hour ago.
bug or ebkac ?
best re
Klaus Schmidinger <[EMAIL PROTECTED]> wrote:
> > i suggest the introduction of a new command line option to switch
> > off writing any epg data (implicitly switching off epg scan). this
> > way only the server vdr maintains the epg and the clients only read
> > it.
> The clients would only read
Mario Ivankovits <[EMAIL PROTECTED]> wrote:
> Now, that I still got this exception I tried to track it down using
> gdb: I've come to cFont::GetFontFilename where FcFontSort returns
> "null".
i had the same, but on my system i simply had no fonts installed at all.
> I simple check (if fontset !=
Klaus Schmidinger <[EMAIL PROTECTED]> wrote:
> Each instance of VDR writes into epg.data without any locking or so.
> If you set up more than one VDR that write to the same epg.data,
> the last one writing it will "win", and if they write at the same
> time, results may be undefined.
i suggest th
is it save to share one epg.data file between multiple vdrs over nfs?
or should each client maintain its own copy?
thx ...
clemens
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Anssi Hannula <[EMAIL PROTECTED]> wrote:
> Dick Streefland wrote:
> > "VDR User" <[EMAIL PROTECTED]> wrote:
> > | I think a better idea is to just install a codec that plays
> > | whatever format your camera videos are in and use the mplayer
> > | plugin.
> >
> > But I have a rather underpowered
On Wed, 2007-08-15 at 18:55 +0200, Ludwig Nussel wrote:
> Have a look at the SUSE vdr package. It installs headers and
> Make.config into /usr/include/vdr. When compiling plugins you have
> to use "make VDRDIR=/usr/include/vdr LIBDIR=/usr/lib/vdr all".
it always strikes me, that vdrs build proces
Georg Acher <[EMAIL PROTECTED]> wrote:
> On Sun, Jul 01, 2007 at 06:47:18PM +0200, Clemens Kirchgatterer wrote:
>
> > or better or whatever. cool, no problem. what? you signed a NDA that
> > does not allow you distribute the os in the first place? your bad.
>
> O
Georg Acher <[EMAIL PROTECTED]> wrote:
> No, it's not. Free is free, you can't make differences between
> hardware vendors using Linux as a basis for their HW and SW vendors
> using Linux as an OS for their SW. And that's exactly the intention
> of your wording ("zero cost").
strange interpretat
Georg Acher <[EMAIL PROTECTED]> wrote:
> From a technical view this is right, but with just a component output
> you can't sell a HDTV decoder card nowadays. And HDMI is not only
> about encryption but also contains audio encapsulation. And that is
> an argument for HDMI vs. DVI...
true.
> HDCP
Georg Acher <[EMAIL PROTECTED]> wrote:
> 1) Don't use a HDMI transmitter and ignore the market demand.
the market never "demanded" an encrypted data stream on the HDMI cable,
and it is clearly the only reason they are picky about their secrets
within that driver. THEY want their chips be supporte
Anssi Hannula <[EMAIL PROTECTED]> wrote:
> If I understood correctly, you only need proprietary parts for the
> kernel that runs *in* the card. The kernel running on your actual
> system does not need proprietary parts, leaving you free to use a
> different kernel.
yes, but as there is linux als
Stefan Lucke <[EMAIL PROTECTED]> wrote:
> They decide on which kernel it runs. If I need for some other device
> a different kernel which they don't / won't support, I'm left alone.
that's exactly what the GPL tries to prevent.
> To my opinion that is a nogo way.
> I doubt if that's compatible w
Petri Hintukainen <[EMAIL PROTECTED]> wrote:
> If clock is turned 2 minutes back in middle of this, the code will
> wait 120100 ms instead of 100ms ... Might cause some quite weird
> problems. I belive there's no way to change pthread_..._timedwait
> functions, but cTimeMs can be changed to use mo
Chris <[EMAIL PROTECTED]> wrote:
> My assumption is that the problem occurs because of the missing wait
> call (if SystemExec is called 'detached'). I know, if VDR would wait
> in there, the script wouldn't run simultaneously. But if VDR never
> waits for the child's PID, the child's termination n
hi.
since i get many lines of
read incomplete section - len = 1127, r = 334
when my machine is recording and under heavy CPU load, i was curios what
this means. i had a look at the vdr source and saw that there is nearly
no code to recover from short reads from the corresponding
filedescriptor.
seams i have broken the audio chipset on my galaxy FF card. also
getting audio from the spdif connectors did not work out nicly because
there, the left channel is missing (no idea, how this is possible at
all). i tried even with 2 different soundcards. playing pcm both
channels work.
so my questio
Artur Skawina <[EMAIL PROTECTED]> wrote:
> I'd be great if somebody with a FF card could test the patch, the
> code has worked flawlessly on my vdr server, not a single overflow
> since v2.
i currently test your patch on vdr-1.5.2 with one FF card. i have some
timers pending this afternoon, so st
"Simon Baxter" <[EMAIL PROTECTED]> wrote:
> > Martin <[EMAIL PROTECTED]> wrote:
> >
> > > Hey Simon,my answer sounds maybe stupid, but I always have all
> > > output to 720x576.
> >
> > [..]
> >
> > please, for the love of god, fix your mua.
>
> Sorry - what's wrong with my mua?
this was of c
And since I am not convinced that this memory footprint issue is
significant,
at a first glance, IMHO dynamic buffers are a good thing. we can get
rid of small upper buffer size bounderies all together without wasting
amounts of memory. this should result in even less buffer overflows
when imple
Martin <[EMAIL PROTECTED]> wrote:
> Hey Simon,my answer sounds maybe stupid, but I always have all output
> to 720x576.
[..]
please, for the love of god, fix your mua.
thanx ...
clemens
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-
Torgeir Veimo <[EMAIL PROTECTED]> wrote:
> Does the UTF-8 support include the freetype font support?
> Antialiased fonts looks s much better.
UTF-8 makes no sense with a 7-bit ascii character set. so i guess, yes.
clemens
___
vdr mailing list
vdr@
This is the 'official' and updated vdr-mailing-list-etiquette-reminder.
Please take this as a serious advice. Take the time to read it,
especially if you are new to mailinglists in general.
E-mail formatting
=
Mailing list email should fit the following criteria:
DO
==
* Trim
Jouni Karvo <[EMAIL PROTECTED]> wrote:
> Reinhard Nissl writes:
> >
> > Are you using xine's video output driver xxmc?
>
> yes, I am.
but i don't. i have a full featured DVB card.
clemens
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org
Laz <[EMAIL PROTECTED]> wrote:
> On Saturday 03 February 2007 10:13, Clemens Kirchgatterer wrote:
> > Marko Myllymaa <[EMAIL PROTECTED]> wrote:
> > > Also this newer version does some weird busylooping or whatever
> > > from time to time. Vdr gets all remote
Marko Myllymaa <[EMAIL PROTECTED]> wrote:
> Also this newer version does some weird busylooping or whatever from
> time to time. Vdr gets all remote codes and buffers them, but just
> starts executing them after ~45s. One time it took so long, that I
> got ssh opened from other computer to restart
:). After an upgrade of hw (new mb and amd 3000+ sempron) the stuttering
lasts only a few seconds.
you have DMA enabled for your harddisk?
c.
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
"VDR User" <[EMAIL PROTECTED]> wrote:
> A PS3 running VDR is more of a novelty item considering the price.
> For the cost, you could easily build a computer that can handle HDTV,
> be a lot more robust, and have money left over.
how this? HPTC cases alone cost 100E upwards, HD-DVD drives go for
2
Matthias Schniedermeyer <[EMAIL PROTECTED]> wrote:
> I'd say the only downside of the Linux support kills it as a VDR
> platform. Graphic is NOT accelerated.
>
> That's the only downside i'm aware of, and i can understand Sony a
> little in this point. Otherwise all game developers could just ski
i can see many of us are seeking for the right hardware for vdr, so i
am. i want to start some discussion about the upcoming Sony PS3 as an
vdr client on steroids. as it will support linux out of the box, it
seams logical to, at least, think about it. i came to the following
pro/contra list:
pro:
"Rene Bartsch" <[EMAIL PROTECTED]> wrote:
> is there any plugin working like the control plugin but using HTTP
> instead of Telnet? This would allow to control VDR from a Browser.
> OSD options could be links and keypresses could be catched by
> JavaScript.
you have heard about vdradmin, havn't y
Hans-Werner Hilse <[EMAIL PROTECTED]> wrote:
> Changing the "free(aux);" to "if(aux) free(aux);" would probably care
> for that (resembling the earlier behaviour).
i know, the problem has been already fixed, but just for the record.
code like: if (bla) free(bla); will actually _never_ fix any bu
68 matches
Mail list logo
