Re: [vdr] [PATCH] MaxThemeName and MaxSkinName limit
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 of 16 to theme and skin names, letting them >> be NAME_MAX as almost any files, since these names can also be involved >> in file names. >> Was there a good reason to limit them at 16 only, perhaps the fear that >> the name won't fit on the OSD? I don't really think someone would really >> make use of as many as 255 characters for this. On the other hand, users >> just encountered crashes with plugins which (unfortunately, yet) have >> themes of their own, when just adding a new theme with a name longer >> than 16 and at the same time the original plugin author relied on >> MaxThemeName when allocating the string length. > > Those are bugs in the plugins and should be fixed there. > Or is this something that can also happen in the core VDR? So be it, it's quite easy for plugins to ignore MaxThemeName or allocate such a string length, say 4*MaxThemeName as long as they mange their own themes... I did not test how VDR reacts when it is fed with a theme or a skin with a name longer than 16 (seems those are the only 2 places in VDR where you use those, on statically allocating the strings holding the theme and the skin, which you store to and load from setup... >> So, what do you think, easy to adopt? > > Well, for one, now is definitely not the right time for a change like this! > And furthermore, skin and theme names should be short. What sense does it > make to call a theme something like "This is the theme that implements a > range > of colors from 400 nanometers to 700 nanometers", when you could just plain > simple call it "rainbow"? ;-) Not necessary to exaggerate with such an hilarious example, you're getting near to sarcastic and missing the point, let's just take your short example in a more realistic scenario: rainbow_1920x1080.theme rainbow_1280x768.theme just because there still are plugins having to use skins which are resolution-dependent, so those names aren't at all that uncommonly long like your example, yet they try to carry some little useful information. And still, one of them is already violating the limit (if we do not consider the file extension). Of course, you might say, take out the '_', or the 'x', I could answer I'd rather take out some letter out of "rainbow", and so on, you see what I'm trying to point out, it's hitting a limit difficult to argue... > So I'd say the limit is there for a reason, and should stay there. Could you at least please, name it? Regards, Lucian ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [PATCH] MaxThemeName and MaxSkinName limit
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 of 16 to theme and skin names, letting them be NAME_MAX as almost any files, since these names can also be involved in file names. Was there a good reason to limit them at 16 only, perhaps the fear that the name won't fit on the OSD? I don't really think someone would really make use of as many as 255 characters for this. On the other hand, users just encountered crashes with plugins which (unfortunately, yet) have themes of their own, when just adding a new theme with a name longer than 16 and at the same time the original plugin author relied on MaxThemeName when allocating the string length. Those are bugs in the plugins and should be fixed there. Or is this something that can also happen in the core VDR? So be it, it's quite easy for plugins to ignore MaxThemeName or allocate such a string length, say 4*MaxThemeName as long as they mange their own themes... I did not test how VDR reacts when it is fed with a theme or a skin with a name longer than 16 (seems those are the only 2 places in VDR where you use those, on statically allocating the strings holding the theme and the skin, which you store to and load from setup... So, what do you think, easy to adopt? Well, for one, now is definitely not the right time for a change like this! And furthermore, skin and theme names should be short. What sense does it make to call a theme something like "This is the theme that implements a range of colors from 400 nanometers to 700 nanometers", when you could just plain simple call it "rainbow"? ;-) Not necessary to exaggerate with such an hilarious example, you're getting near to sarcastic and missing the point, let's just take your short example in a more realistic scenario: 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. just because there still are plugins having to use skins which are resolution-dependent, so those names aren't at all that uncommonly long like your example, yet they try to carry some little useful information. And still, one of them is already violating the limit (if we do not consider the file extension). Of course, you might say, take out the '_', or the 'x', I could answer I'd rather take out some letter out of "rainbow", and so on, you see what I'm trying to point out, it's hitting a limit difficult to argue... So I'd say the limit is there for a reason, and should stay there. Could you at least please, name it? Keeping the names *short* ;-) This limit has been in there for almost ten years and has apparently never been a problem (at least not to my knowledge). I can't change that so close before the release of a major new version - even if it might look like it won't break anything. You can get back to me with this after version 2.0.0 is out. Version 2.1.x can pick up such changes again... Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [PATCH] MaxThemeName and MaxSkinName 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 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 ... -- Helmut Auer, hel...@helmutauer.de ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] New Makefile system (was: [PATCH] MaxThemeName and MaxSkinName limit)
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 please, finally, name your problems, so someone can help you to find solutions. The old Makefile system did not work well for packaging and made it unneccessarily difficult to build plugins from outside the VDR source. It also often required manual steps to be done after installing the plugin (copy resources or something like that) which can be done in the "install" target, now. So in my opinion the new system is a big benefit for 2.0. Yours Manuel ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [PATCH] MaxThemeName and MaxSkinName limit
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, that's the way some of the themes unfortunately work, but that's due to the technology they use (they are displaying background images and the like, which are pre-generated for that exact resolution, possibly a dynamic scaling won't look right in those cases). On the other hand, I'm completely with you, they should behave better, but they are not my skins, nor do I particularly use them, I was only trying to help the users a bit, which add such skins without touching any code... >> just because there still are plugins having to use skins which are >> resolution-dependent, so those names aren't at all that uncommonly long >> like your example, yet they try to carry some little useful information. >> And still, one of them is already violating the limit (if we do not >> consider the file extension). Of course, you might say, take out the >> '_', or the 'x', I could answer I'd rather take out some letter out of >> "rainbow", and so on, you see what I'm trying to point out, it's hitting >> a limit difficult to argue... >> >>> So I'd say the limit is there for a reason, and should stay there. >> >> Could you at least please, name it? > > Keeping the names *short* ;-) Seriously ;) ? > This limit has been in there for almost ten years and has apparently > never been a problem (at least not to my knowledge). I can't change that > so close before the release of a major new version - even if it might > look like it won't break anything. You can get back to me with this after > version 2.0.0 is out. Version 2.1.x can pick up such changes again... That's fair enough and also ok with me, thanks. Regards, Lucian ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] New Makefile system
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 please, finally, name your problems, so someone can help you to find solutions. 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 searched for the segfault in the code but the reason was the make, and that costs me some days. And also the migration of many plugins costs me a lot of time. The old Makefile system did not work well for packaging and made it unneccessarily difficult to build plugins from outside the VDR source. It also often required manual steps to be done after installing the plugin (copy resources or something like that) which can be done in the "install" target, now. So in my opinion the new system is a big benefit for 2.0. Just for my point of view, I do not have any benefit of the new makefile concept, only trouble. This makefile change has lead to the biggest cut in VDR times, imho such a change should be made after a major release not (in VDR times) short before a major release. If I'd be a a vdr user thats no problem, I can stay with vdr 1.7.32. Bu unfortunately I'm a distributor and I've promised my users a new version with VDR 2.0. Now I have the choice between breaking my word or setting up the new system which will cost me some more days with a system that I do not like. -- Helmut Auer, hel...@helmutauer.de ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] skin nOpacity 0.1.0
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 problem: no osd :-( I tried to install softhddevice, but i could not get it to compile due to missing libraries etc. If you know which packages is needed in Ubuntu, then it would be great to get help with this :-) Hi Louis, Now i got all compoled. I recompiled everything (vdr etc) and i managed (i think) to get all libraries installed too. I can now change to the theme, but i don't get the video resized even if that setting is set.. Any idea what i might have missed? René ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] New Makefile system
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 the fun I had with VDR before ... Then please, finally, name your problems, so someone can help you to find solutions. 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. Which plugin are you refering to? I searched for the segfault in the code but the reason was the make, and that costs me some days. And also the migration of many plugins costs me a lot of time. You don't have to migrate them. You can stay with the old Makefiles. Take a look at the VDR4Arch Project https://github.com/CReimer/vdr4arch/blob/master/plugins/vdr-filebrowser/PKGBUILD The old Makefile system did not work well for packaging and made it unneccessarily difficult to build plugins from outside the VDR source. It also often required manual steps to be done after installing the plugin (copy resources or something like that) which can be done in the "install" target, now. So in my opinion the new system is a big benefit for 2.0. Just for my point of view, I do not have any benefit of the new makefile concept, only trouble. This makefile change has lead to the biggest cut in VDR times, imho such a change should be made after a major release not (in VDR times) short before a major release. If I'd be a a vdr user thats no problem, I can stay with vdr 1.7.32. Bu unfortunately I'm a distributor and I've promised my users a new version with VDR 2.0. Now I have the choice between breaking my word or setting up the new system which will cost me some more days with a system that I do not like. There's also a problem with your attitude. You want to provide all plugins regardless of how old or how broken they are. Christopher Reimer ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] New Makefile system
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 ;) 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 :) I searched for the segfault in the code but the reason was the make, and that costs me some days. And also the migration of many plugins costs me a lot of time. You don't have to migrate them. You can stay with the old Makefiles. Take a look at the VDR4Arch Project https://github.com/CReimer/vdr4arch/blob/master/plugins/vdr-filebrowser/PKGBUILD I already know this, but there were times without the compatibility flag. If I'd be a a vdr user thats no problem, I can stay with vdr 1.7.32. Bu unfortunately I'm a distributor and I've promised my users a new version with VDR 2.0. Now I have the choice between breaking my word or setting up the new system which will cost me some more days with a system that I do not like. There's also a problem with your attitude. You want to provide all plugins regardless of how old or how broken they are. Thats your point of view I just want to build these plugins which are used by Gen2VDR users ... -- Helmut Auer, hel...@helmutauer.de ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] New Makefile system
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. >> > There are lots of things that you can't imagine ;) > >> 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 :) > > >>> I searched for the segfault in the code but the reason was the make, >>> and that costs me some days. I could give you another example, Christopher, of which Makefile was migrated by yourself, with exactly the consequence pointed out by Helmut, I only don't think we're allowed to mention that plugin here, so just remember, 3 months ago, "Issue #18" of that Plugin on Github... Regards, Lucian ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] New Makefile system
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, that this is caused by a changed Makefile. There are lots of things that you can't imagine ;) 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 :) I searched for the segfault in the code but the reason was the make, and that costs me some days. I could give you another example, Christopher, of which Makefile was migrated by yourself, with exactly the consequence pointed out by Helmut, I only don't think we're allowed to mention that plugin here, so just remember, 3 months ago, "Issue #18" of that Plugin on Github... Regards, Lucian Even before Issue 18 was fixed it worked flawlessly on Archlinux. live still uses the old makefile and softhddevice works great here. Christopher ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] New Makefile system
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 incompatibilities. I can understand your frustration - changing a myriad of packages is an annoying task (been there - done that! :-) But after all I think the new Makefile is much better and for the first time works out of the box with the standard Debian packaging tools (which require *FLAGS, DESTDIR, PREFIX and so on). Packaging is much easier right now as you basically only have to do: make all PREFIX=/ ... make install DESTDIR=... And for plugins that haven't migrated to the new Makefile the only change I had to do was: export CXXFLAGS += $(shell pkg-config vdr --variable=cxxflags) The only thing I'm missing is a CPPFLAG in the Makefiles, which I hope gets added in 2.0+X. But I'm talking from the Debian/Ubuntu perspective only - things might be slighty more complicated in Gentoo. Tobias ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] New Makefile system
On Sun, Mar 24, 2013 at 5:24 AM, Helmut Auer 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 softhddevice git, I was getting crashed. Johns acknowledged the plugin had issues with the new Makefile and recommended to continue using the provided old-style Makefile. So are you saying that you've actually fixed softhddevice so it works correctly and no longer crashes when using the new-style Makefile? If so, would you mind submitting that patch to Johns so he can merge it? ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] New Makefile system
Am 24.03.2013 15:48, schrieb VDR User: On Sun, Mar 24, 2013 at 5:24 AM, Helmut Auer 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 softhddevice git, I was getting crashed. Johns acknowledged the plugin had issues with the new Makefile and recommended to continue using the provided old-style Makefile. So are you saying that you've actually fixed softhddevice so it works correctly and no longer crashes when using the new-style Makefile? If so, would you mind submitting that patch to Johns so he can merge it? I don't know whether Tobi started his plugin from scratch, or used our yavdr package as template, but we don't have crashes either. With vdr 1.7.41 and 1.7.42 and softhddevice 0.6.0 there are no Problems at least with vdpau on 64 bit systems. The only used patch (attached) has nothing to do with the new makefiles. Gerald !DSPAM:514f1e83250661305017642! Index: vdr-plugin-softhddevice-0.5.2.git.20130303.1729/Makefile === --- vdr-plugin-softhddevice-0.5.2.git.20130303.1729.orig/Makefile 2013-03-11 16:32:00.0 +0100 +++ vdr-plugin-softhddevice-0.5.2.git.20130303.1729/Makefile2013-03-12 11:40:16.893647421 +0100 @@ -32,8 +32,8 @@ #CONFIG += -DHAVE_PTHREAD_NAME # supports new pthread_setname_np #CONFIG += -DNO_TS_AUDIO # disable ts audio parser #CONFIG += -DUSE_TS_VIDEO # build new ts video parser -#CONFIG += -DUSE_MPEG_COMPLETE # support only complete mpeg packets -#CONFIG += -DUSE_VDR_SPU # use VDR SPU decoder. +CONFIG += -DUSE_MPEG_COMPLETE # support only complete mpeg packets +CONFIG += -DUSE_VDR_SPU# use VDR SPU decoder. ifeq ($(ALSA),1) CONFIG += -DUSE_ALSA ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] New Makefile system
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 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 ;) >>> 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 :) >>> >>> > I searched for the segfault in the code but the reason was the > make, > and that costs me some days. >> >> I could give you another example, Christopher, of which Makefile was >> migrated by yourself, with exactly the consequence pointed out by >> Helmut, I only don't think we're allowed to mention that plugin here, >> so >> just remember, 3 months ago, "Issue #18" of that Plugin on Github... >> >> Regards, Lucian >> > > 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 patched VDR on Archlinux? Gentoo uses the extended patch, it's just the way it is, users are just glad that this is possible for them, and when doing so it is absolutely necessary that all of the plugins are built with the exact same DEFINES introduced by the patches, and that happens to well, happen or not, in the plugin Makefile. Ignoring them, just because of thinking "plugin A does not use any of the patches X, Y or Z, so I don't need the DEFINES" is likely to give you a working plugin only if you are _very_ lucky, otherwise unexpected crashes will bite you. To take this out of the fortune domain one would have to either analyze with some true coverage techniques that absolutely no patched code is called in a specific plugin (and by that I mean, VDR internal code is also calling itself, so that's why an analysis is not trivial), or to just make sure, give the DEFINES to all of the plugins. So it turns out that the new Makefiles are just adopted in a different way by people, and also there was no clear directive where to store the DEFINES in case of patches, in /usr/include/vdr/Make.conf (or how it should be called lately), or right into the cxxflags and cxflags in vdr.pc... So you see, the whole process caused also a lot of confusion, also because each Makefile contains the whole logic, I would have placed the logic in a central, pseudo-Makefile shipped with the vdr sources, and generated some kind of Makefile stubs for the plugins, including the central one for the logic, and providing plugin-specifics (even custom, additional targets) through a well defined interface. That way, once the interface would have been established, the central logic could have been adapted fromtime to time without having to ever touch plugin Makefiles again. Unfortunatley, for me it just wasn't the right time to interfere in the makefile discussions when they were elaborated. I might come back with a drop-in proposal by the the time of the next developent series, quite possible that having only a few lines makefiles would be interesting for someone... Regards, Lucian ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] New Makefile system
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 there should be no ABI > incompatibilities. > > I can understand your frustration - changing a myriad of packages is an > annoying task (been there - done that! :-) > > But after all I think the new Makefile is much better and for the first > time works out of the box with the standard Debian packaging tools > (which require *FLAGS, DESTDIR, PREFIX and so on). > > Packaging is much easier right now as you basically only have to do: > > make all PREFIX=/ ... > make install DESTDIR=... > > And for plugins that haven't migrated to the new Makefile the only > change I had to do was: > > export CXXFLAGS += $(shell pkg-config vdr --variable=cxxflags) > > The only thing I'm missing is a CPPFLAG in the Makefiles, which I hope > gets added in 2.0+X. > > But I'm talking from the Debian/Ubuntu perspective only - things might > be slighty more complicated in Gentoo. Well, see my other answer to Christopher, where I explained what can go wrong (which of course, doesn't have to happen if using plain vanilla VDR). Regards, Lucian ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] New Makefile system
On 24 March 2013 16:36, Lucian Muresan 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 this 'template' system for which plugins can base their Makefiles upon. Consider that most other apps that provide extension points for plugins to implements only provide pkg-config flags, and nothing else :) Klaus is already doing people a massive favour by maintaining this Make system and continuing to support it. The changes in 2.0 were well agreed, refined and implemented. Any plugins that don't trivially build within the new way should be left up to their maintainer to fix, or interested parties to submit patches. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] New Makefile system
> 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 VDR, despite which Makefile system. This was IMHO a great job, to keep 99% of the old system with the view into the future. With post 2.0 Klaus can now uncompromising cut everything old and unnecessary, which will probably sort out 80% of all plugins and make distributors live even easier ... ^^ Thanks for this great work up to now Klaus! === Kind regards fnu ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] New Makefile system
On Sun, Mar 24, 2013 at 9:36 AM, Lucian Muresan 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 patched VDR on Archlinux? Gentoo > uses the extended patch, it's just the way it is, users are just glad > that this is possible for them, and when doing so it is absolutely > necessary that all of the plugins are built with the exact same DEFINES > introduced by the patches, and that happens to well, happen or not, in > the plugin Makefile. > Ignoring them, just because of thinking "plugin A does not use any of > the patches X, Y or Z, so I don't need the DEFINES" is likely to give > you a working plugin only if you are _very_ lucky, otherwise unexpected > crashes will bite you. I've seen enough coder complaints to know it's an unwritten rule of thumb that when you patch things and it changes/breaks vanilla behavior, it's your responsibility to maintain and fix anything that gets lamed. Rather than expecting Klaus to cater to such cases, you should appreciate he's willing to consider them. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] Livebuffer for VDR 2.0
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é ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.42
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 for asking a stupid question. I noticed that the vdr.pc that get's generated has a wrong apiversion for the 1.7.42 version. I wonder if this is right, because i noticed that the plugins endling up under PLUGINS/lib have the 1.7.41 version instead of 1.7.42.. Best Regards, René ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.42
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 ftp://ftp.tvdr.de/vdr/Developer/vdr-1.7.41-1.7.42.diff Hi Klaus, I'm sorry for asking a stupid question. I noticed that the vdr.pc that get's generated has a wrong apiversion for the 1.7.42 version. I wonder if this is right, because i noticed that the plugins endling up under PLUGINS/lib have the 1.7.41 version instead of 1.7.42.. 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 have been no changes to // VDR header files since the last APIVERSION. This allows compiled // plugins to work with newer versions of the core VDR as long as no // VDR header files have changed. Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.42
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 have been no changes to // VDR header files since the last APIVERSION. This allows compiled // plugins to work with newer versions of the core VDR as long as no // VDR header files have changed. Oh, ok. This makes sense :-) René ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] New Makefile system
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 recommended to continue using the provided old-style Makefile. So are you saying that you've actually fixed softhddevice so it works correctly and no longer crashes when using the new-style Makefile? If so, would you mind submitting that patch to Johns so he can merge it? Sorry to say - I haven't fixed that, after I recognized that this * makefile stuff was the reason I switched back to vdr.1.7.32 and stopped every development for newer versions. -- Helmut Auer, hel...@helmutauer.de ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] [ANNOUNCE] skin nOpacity 0.1.0
Hi Rene, fine that you got the skin running finally ;) > I can now change to the theme, but i don't get the video resized even if > that setting is set.. > Any idea what i might have missed? Yes...the output device has to implement the VDR scaling API introduced by Klaus in VDR1.7.33. xineliboutput has not been updted for this afaik, so scaling is not working with this output device currently. I don't know if the developer will implement it. btw: softhddevice has implemented the scaling API and scaling works fine with this output plugin ;) Cheers Louis Gesendet: Sonntag, 24. März 2013 um 13:01 Uhr Von: "René" An: "VDR Mailing List" Betreff: Re: [vdr] [ANNOUNCE] skin nOpacity 0.1.0 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 > problem: no osd :-( > > I tried to install softhddevice, but i could not get it to compile due > to missing libraries etc. If you know which packages is needed in > Ubuntu, then it would be great to get help with this :-) Hi Louis, Now i got all compoled. I recompiled everything (vdr etc) and i managed (i think) to get all libraries installed too. I can now change to the theme, but i don't get the video resized even if that setting is set.. Any idea what i might have missed? René ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
