On 24.03.2013 10:49, Lucian Muresan wrote:
On 23.03.2013 22:50, Klaus Schmidinger wrote:
On 23.03.2013 17:14, Lucian Muresan wrote:
Hi,
thank you Klaus for holding up your release plan for 2.0!
However, I hope this minor patch won't be too much trouble for you, as
it only increases the limit
Am 24.03.2013 11:00, schrieb Klaus Schmidinger:
This limit has been in there for almost ten years and has apparently
never been a problem (at least not to my knowledge).
Sorry to hack this thread , but my wound is still wide open :(
There also was a makefile concept for ten years and
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
Hi,
On 24.03.2013 11:00, Klaus Schmidinger wrote:
[...]
rainbow_1920x1080.theme
rainbow_1280x768.theme
Themes are all about colors - why do they even need to mention resolutions?
Besides, skins should react dynamically on the current OSD size.
as mentioned right after giving the example,
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
On 22.03.2013 1:12 , René wrote:
Hi Louis,
I start xineliboutput with the following line
xineliboutput --local=none --remote=37890 --primary --fullscreen
I tried to add --hud but it did not work. To had to remove first
--fullscreen because vdr did not start, but to the end i had the same
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
Hi
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 ;)
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.
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,
On 24.03.2013 13:51, Lucian Muresan wrote:
I searched for the segfault in the code but the reason was the make,
and that costs me some days.
There's not very much which go wrong. As long as the plugins are compiled
with -fPIC and -D_FILE_OFFSET_BITS=64 there should be no ABI
On Sun, Mar 24, 2013 at 5:24 AM, Helmut Auer v...@helmutauer.de wrote:
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 :)
When using the new style Makefile supplied with
Am 24.03.2013 15:48, schrieb VDR User:
On Sun, Mar 24, 2013 at 5:24 AM, Helmut Auer v...@helmutauer.de wrote:
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 :)
When using the
On 24.03.2013 14:10, Christopher Reimer wrote:
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
On 24.03.2013 14:15, Tobi wrote:
On 24.03.2013 13:51, Lucian Muresan wrote:
I searched for the segfault in the code but the reason was the make,
and that costs me some days.
There's not very much which go wrong. As long as the plugins are
compiled with -fPIC and -D_FILE_OFFSET_BITS=64
On 24 March 2013 16:36, Lucian Muresan luci...@users.sourceforge.net wrote:
Even before Issue 18 was fixed it worked flawlessly on Archlinux.
Well, and therefore you concluded it ought to work on any system, but
that's not necessarily true.
*SNIP*
tbh VDR is quite unusual that it provides
Klaus is already doing people a massive favour by maintaining this Make
system and continuing to support it.
FullAck, I guess most people appreciate this way, it makes live not that
bad, some minor changes needed to keep any plugin. There's more work for
many plugins regarding other changes in
On Sun, Mar 24, 2013 at 9:36 AM, Lucian Muresan
luci...@users.sourceforge.net wrote:
Even before Issue 18 was fixed it worked flawlessly on Archlinux.
Well, and therefore you concluded it ought to work on any system, but
that's not necessarily true.
I wonder, do you use vanilla VDR or a
Hi all!
Now that VDR 2.0 is just around the corner i would like to check if
there is any progress to the great livebuffer that was back in the 1.6
days? I tested a 1.7.x version some long time ago, but that did not
work as well as the original version..
René
On 23.03.2013 13:16 , Klaus Schmidinger wrote:
VDR developer version 1.7.42 is now available at
ftp://ftp.tvdr.de/vdr/Developer/vdr-1.7.42.tar.bz2
A 'diff' against the previous version is available at
ftp://ftp.tvdr.de/vdr/Developer/vdr-1.7.41-1.7.42.diff
Hi Klaus,
I'm sorry
On 24.03.2013 23:17, René wrote:
On 23.03.2013 13:16 , Klaus Schmidinger wrote:
VDR developer version 1.7.42 is now available at
ftp://ftp.tvdr.de/vdr/Developer/vdr-1.7.42.tar.bz2
A 'diff' against the previous version is available at
On 25.03.2013 24:22 , Klaus Schmidinger wrote:
The apiversion is not wrong. Since there has been no change to the API,
the version number has not been incremented.
See config.h:
// When loading plugins, VDR searches them by their APIVERSION, which
// may be smaller than VDRVERSION in case there
softhddevice and live Plugin.
There was a mismatch between c an c++ flags and this was surely caused by
the new makefile system :)
When using the new style Makefile supplied with softhddevice git, I
was getting crashed. Johns acknowledged the plugin had issues with the
new Makefile and
23 matches
Mail list logo
