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 bug.
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 you?
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:
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
200E,
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 vdr,
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 codes and buffers them,
but just starts
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
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
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 course not directed to
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
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 with
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 also
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 supported in
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 on a
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 interpretation of
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 VDR machine with a
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
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 this once
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
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 live
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.
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 to
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
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 which is
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
Klaus Schmidinger [EMAIL PROTECTED] wrote:
I still believe, though, that freetype2's include files are broken.
A simple '#include freetype2.h' 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
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 '#include freetype2.h' should be enough. If their header
file(s) would
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 make and to start that program
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
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 your
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 a
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 from
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
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 do
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, where
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
version,
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 VDR sources. I
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
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 up this
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 think
Udo Richter udo_rich...@gmx.de 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
Alex Betis alex.be...@gmail.com 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. :-)
Seppo Ingalsuo seppo.ingal...@iki.fi 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
Frank Schmirler v...@schmirler.de 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
44 matches
Mail list logo
