Re: [vdr] VDR with S2API (update)
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 transponder to not waste dvb devices. the same gues for finding a free dvb device for life-view. You're no longer talking about client-server here. What you have in mind is peer-to-peer. Streamdev et al. haven't been designed for this. I never looked at videgor, but AFAIK it was a peer-to-peer aproach. exactly what i was talking about. at the moment a multi vdr setup is a peer to peer setup and thus makes timer migration complex. or you do it by hand with the help of remote timers plugin and the like. but this lacks the DVB sharing across vdr instances. clemens ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Duplicate channels list
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. :-) ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR with S2API (update)
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 streamdev to vdr #1 that owns dvb hardware. Timersync plugin syncronizes timers to vdr #1. 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 transponder to not waste dvb devices. the same gues for finding a free dvb device for life-view. best regards ... clemens ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR with S2API (update)
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 instance per frontend right now. at least the /video directory that is shared across multiple vdr instances that know nothing about each other is a single race-condition on its own. vdr in a massive client server configuration is a giant hack with many pieces each with its own little problems summing up. clemens ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR - S2API: 2 questions
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 progress can ever be made when you don't allow diversity. what you call *working* and *useful* may be a dead end and obsolete in a few month/years. only time will tell. if dvb was not built into vdr core, then you wouldn't even have to bother. best regards ... clemens ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] What ever happened to...
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 topic several times, but klaus never made any commitment to the whole idea. i think he does not like it. so long ... clemens ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [PATCH] S2API for vdr-1.7.1 vanilla and extensions patch 64 ( 071020008 )
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 mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR Development
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 Klaus's well-laid out source code! i, by no means, want to question klaus' competence as a coder, but to call VDR proper C++ sounds really strange to me. i can accept the source formatting as being a thing of personal taste, maybe even hungarian notation, something i personally find unbearable and wrong from the ground up, but the refusal to use the STL in a C++ project leaves me dumbfounded. i CAN absolutly understand why klaus codes VDR as he does. writing a string class or a linked list is fun sometimes and as long as VDR stays a one man show it is only up to him to decide. keeping the closed development process makes things much easier for him and avoids long arguments about personal preferences. if i had an GPL project that size, i would probably do the same. do i like the way VDR is developed? hell, no! nevertheless it is, what it is. a very usable and stable program for watching, recording and replaying TV shows with a dvb card. If a new feature is needed, a lot can be achieved with plugins, or create a patch and forward on to Klaus and the list. maintaining patches over multiple revisions in a coding style that is orthogonal to your own, waiting for it to get eventually merged upstream some day, is not something many peaople like. just my 2 cents ... clemens ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR Development
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/mailman/listinfo/vdr
Re: [vdr] VDR Development
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 VDR development, and he has the right to do it his way! No matter whether you like it or not! so what? My suggestion for those who are unhappy with the current situation: 0. Stop this discussion. 1. Read the GPL. 2. Understand the GPL. 2. Clone the existing VDR code. 3. Give it a new name to make clear, that it is not VDR. 4. Make it better (if you can). 5. Last but not least: Maintain it for 8 years or longer. thank you for aducating us in forking a GPL project. SCNR ... clemens ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR Development
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 you can pull into your own repository for privat vdr hacking and let other people check it out may be worth a thought. But I think the repository stuff is only marginal. The design itself matters. When looking at the experiences at Reel, there are some things to be considered in the (far) future of vdr 2.0: full ack. - vdr has grown/evolved since 2000, but is still based in its design on the FF card and its capabilities. There are now different signal source setups (LNBs, rotor, multiproto, mixed tuners or shared tuners/CAMs like in the NetCeiver, and not forgetting the IPTV variants), various output types and devices (FF, DXR3, HDE, X11, ...) and especially more expectations what a PC-based STB should be able to do (playback of other media, home automatisation, etc.). 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. - It allows no real server/client distinction. It is quite common to have a real file server somewhere in the house, but it's hard to get a vdr running on it and viewing on other clients. Even the recordings sharing of two vdrs is not that easy (touch update here and there...). One of the main advantages of Unix was resource sharing and distribution in heterogenous networks (like X over network), but vdr is currently focused only on its platform. for me the biggest obstacle so far in many years of vdr usage. i have already layed down CAT5 into the living room, why do i still have to connect directly to the satelite dish to get flawless live viewing? - Based on the long evolution history, vdr IMO also has some design problems. Every object interacts with each other, I'm personally lost in the inheritance-graph of dozens of identically named Get/Put/Add/Del/Action/Process-calls. Also the main loop (almost 1500LOC) is a bit fat ;-) This makes it hard for newcomers and potential contributors. I guess that there are only very few people that actually know what is going on in the device/devbdevice/remux/libsi-core. not only that, but also are many standard containers reimplemented in the core source that increase LOC count for no good, at least i can't see it. I still favour vdr over mythTV or MCE, because their neglect the TV side. But we have to face it: Radio is dying already. Old fashioned TV over antenna is also getting more and more unimportant and is merged with other data sources (IPTV, internet radio, podcasts, ...). Full convergence is no if, it's a when. yes, there is currently no better software for watching, recording and replaying TV if one uses vdr with a FF card. best regards ... clemens ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Build plugin with different headers then in VDR distribution
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, copy your plugins into its PLUGINS/src directory and compile them as usual. clemens ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Build plugin with different headers then in VDR distribution
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 understand how to build plugins using headers from the VDR's sources. But in my case I have patched headers only (source is not available yet - headers only). i don't see the point. if the header files are different in respect to ABI compatibillity (for example class member order, number of members or object size) then your plugins will not work anyway. if the headers are compatible, it does not matter which one you used to compile them. anyway, vdr and plugins must be compiled with compatible header files. this is what the APIVERSION is for. you could try to copy your patched headers over a fresh vdr source tree and compile it including your plugins. hope this helps ... clemens ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdradmin for mobile client?
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 webinterface. i think it should have two modes. first: a ordinary remote controll (like the one in vdradmin) and second: OSD navigation to do complicated tasks like setting a timer or selecting mp3s even if the tv-set (or in my case the beamer) is off. best regards ... clemens ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR as a set top box
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 system) to execute startx instead of the display mangager. a more clean solution is to remove /etc/initd.d/xdm and write a new script to start X though, you get the idea. then edit /etc/X11/xinitrc to contain exec /usr/local/bin/runvdr. YMMV. best regards ... clemens ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [PATCH] Install headers, add pkgconfig file
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)/]$(PREFIX)/lib/pkgconfig. for cases that this is not appropriate, there is $PKG_CONFIG_PATH. best regards ... clemens ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [PATCH] Use pkg-config to find freetype/fontconfig flags
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 LD_LIBRARY_PATH=/opt1 prog. given the Makefile of prog uses pkg-config properly. And thats so much better than make INCLUDES=/opt1/usr/include? yes it is, because 1. pkg-config will handle the linker flags as well (otherwise you will have to give gcc the correct -L/opt1/usr/lib path), an 2. dealing with pkg-config is the standard way of doing this kind of things. My point is: There's one version of the libs that is in the default library search path. Shouldn't there also be one header in the default header search path then? why should the libraries (and their headers) be installed in the default search path in the first place? Btw. do I need to call /opt1/usr/bin/freetype-config? or will any freetype-config be ok? /opt1/usr/bin/freetype-config thats one of the reasons why pkg-config is prefered. it has a distinctiv $PKG_CONFIG_PATH and does not depend on $PATH. geetings ... clemens ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [PATCH] Use pkg-config to find freetype/fontconfig flags
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 great, and has made the things you express dissatisfaction with in the above as well as other similar ones pretty much moot. i can't agree more. In fact, I think VDR should also provide a *.pc file. I ship one in Fedora's VDR packages, and a good deal of it would be applicable to upstream VDR too. Just let me know if you're interested and I'll have a look at making a upstreamable version of it. i would even say VDR is broken in the way it handles plaugins. VDR's Makefile should install all exported vdr headers in $(PREFIX)/include/vdr and provide a vdr.pc file (as you suggest). then plugins could be buildable outside of VDR's source directory and install themself in $(PREFIX)/lib/vdr. as any other plugin capable program out there i know. just my 2 cents ... clemens ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [PATCH] Use pkg-config to find freetype/fontconfig flags
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 ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [PATCH] Use pkg-config to find freetype/fontconfig flags
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 absolutly nothing to do with that. i think nearly every obtional library has one of these to provide a way to find them at compile and link time. please see the output of: ls /usr/bin/*-config clemens ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [PATCH] Use pkg-config to find freetype/fontconfig flags
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 behave like the rest, we wouldn't have this discussion. no. pkg-config and freetype-config have absolutly nothing to do with that. i think nearly every obtional library has one of these to provide a way to find them at compile and link time. please see the output of: ls /usr/bin/*-config But would it kill anybody to simply have all header files at a standard place (/usr/include and /usr/local/include)? yes it would. how would you install different versions of the same libraries (with their headers) if it wasn't in different paths? and what about cross compilers? the possibillity of having libs and headers in different places is a very important feature, not an anoying bug. Why should every application go on a scavenger hunt to find all the header files it needs? see above. anyway, thats the way it was since many many years for good reasons. it's the standard way of finding compiler and linker flags for libraries and you like obeying standards, don't you? SCNR... clemens ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] DVB-T card on the move
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
Re: [vdr] Straw poll: stable version 1.6.0 now?
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 name some. h264 has not seen that broad of an adoption to be a must have for the next stable release either. and the switch to the new kernel API will make things even more troublesome for packagers who want to ship the latest stable vdr release. IMHO Yes or No? yes. c.k. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR-1.5.12: some micro speed improvements
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. well done! best regards ... clemens ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Playback too fast..
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 tv you have no influence about the frames per second you get from the air, so the dvb card takes the frames as they come in. but watching a recording the dvb card requests the frames on its own with its internal clock, which of course is not synced to the broadcasting anymore. best regards ... clemens ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] nfs sharing epg.data
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 at program start. I don't think this would be a good idea... ic. so vdr only writes to the file (and reads it once at startup) and gets the EPG from internal data structures in ram on demand. so sharing epg.data is not so good of an idea. nevertheless, running vdr in a client-server environment is becoming increasingly popular so this would be a nice feature. most notably if you inject epg from different sources (internet). clemens ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] xxv-1.0 recording thumbnails
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 regards ... clemens ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] nfs sharing epg.data
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
Re: [vdr] Convert video clip to .vdr format
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 full-featured DVB-S card, so I really need to use the hardware MPEG decoder. Mplayer can play MPEG files using the hardware MPEG decoder without re-encoding. but it's NOT an mpeg file he wants to play! so we're back to where we started from. ;-) c. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] OT: issues about binary only code in GPLed programs [WAS] future VDR and Net??eiver OEM from Reelmultimedia
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 open Linux system is useless anyway. hdcp is useless on any system. it is the same with every single DRM scheme out there, it only limits the legal ownders in what they can do with what they bought. but this is even more off topic. because that means they get an stable and well performing OS at zero cost for their embedded designes what makes these chips sell better. So what? Wasn't it idea of free Software to get it without paying for it? no. and i'm a little bit shocked to read this from you. i hope this is just an unlucky wording. Or is there a newly inserted paragraph about hardware vendors to pay something if they use free SW? sarcasm does not help here either. free software does not care about how practical or profitable it is for you to fulfill your distribution-license requirements. Overall, all this (IMO useless) discussion is only about the HDMI driver part which is currently (accidently) implemented in the kernel. I can't see that it's getting any better from an OSS standpoint when it's a closed-source user space program. Get real... that's your opinion. The usual practical anti-binary arguments for a PC platform (new mainboard requires new kernel) don't count here, it's an embedded system. You can't simply switch the kernel anyway, as it has many additions for the V4L-stuff. what if i wan't to put additional faetures into the card? what if i want to fix a bug in the firmware? benefit from performance improvments in later kernel releases? it is not you who has to decide what i do with my hardware. THAT is the whole point of free software. get real. [..] many people don't care about their freedom as users. either because they don't have the knowledege to fiddle with the software themselfs or they rather have binary drivers for their expensive / high performance video card than free drivers for a cheep one. fine. but at least vendors MUST respect the will of the countless developers who release their work under the license of their choice for a reason. best regards ... clemens ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] OT: issues about binary only code in GPLed programs [WAS] future VDR and Net??eiver OEM from Reelmultimedia
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 my words. where did i say, that there is any difference from SW to HW vedors? zero cost implied, that some vendors just try to get a free ride. otherwise there was no need for http://gpl-violations.org/ Oh, it helps a lot to tolerate opinions from people who don't know what's behind selling hardware with chips from others. There are things you can't change, eg. NDAs. you can't change the GPL either. free software does not care about how practical or profitable it is for you to fulfill your distribution-license requirements. Until now, there's AFAIK no legal decision that you are not allowed to include binary only modules in the kernel. If it gets that far, we will put in user space. No real gain, but if it helps... you are nitpicking. if you have read the kernel license and you understood its intention you can not think binary modules would not violate it. the GPL was never really challenged in court (at least to my knownledge), does that mean it's invalid? the FSF itself clearly stated, that binray only modules violate the GPL, who would know better? [..] it is not you who has to decide what i do with my hardware. THAT is the whole point of free software. get real. Don't buy it and wait for a card with better Linux support. I'm beginning to understand why big consumer hardware vendors won't do Linux support at all, if they get always this friendly reception... the usual ranting. what does linux support have to do with wether you obey a certain license or not? we are talking about the os on a pci card here. you decided to use free software for your benefit, to make the card cheaper 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. if it is so easy for you to change the offending software part, why not from the beginning? your product specs sound really good and the fact that there is linux running on top of the hardware seems to make it a nice toy, at least at a first glance. the firmware of the ttpci cards are a good example of why i would love to have a more open firmware on it. how long did it take until it was stable? too long. 4MB ram support could only be added by someone with access to the source code. did it help anybody to keep the source locked up? did it prevent sc? no. so i'm all for a DVB/video card that does not have these limitations. people like to tinker with their harware. even if it's not me personally who does something unusual with that thing, someone will. the pure possiblillity of beeing hackable adds value to it. the linux kernel, being monolithic, can be a showstopper if it can not be changed/upgraded. many people don't care about their freedom as users. either because they don't have the knowledege to fiddle with the software themselfs or they rather have binary drivers for their expensive / high performance video card than free drivers for a cheep one. fine. but at least vendors MUST respect the will of the countless developers who release their work under the license of their choice for a reason. Apropos developers: How much do YOU already have developed for the Linux kernel, DVB-API or vdr? I've made the experience that the loudest people in this GPL issue have the least contributions... regardless of wether this has something to do with the validity of my arguments or not: i never contributet patches to the linux kernel directly only some bugreports and patch-tests. i released one small plugin and once or twice sent patches for vdr, but they got rejected AFAICR, nevermind. besides from some small libraries and rather useless tools from my early days i hope that i can convince my employer to release my main project of the last 3 years under GPL3 [would be hopefully rather useful for STB vendors or even xbmc]. nevertheless i doubt i'm one of the loudest who endorses free software either. but i truly believe that the one and only reason, why GNU/Linux is what it is because of the GPL. otherwise it would be at best as untot as the BSDs. But it's getting tedious. Take it or leave it, that's all I can say. a decision i will make when time has come depending on the circumstances. best regards ... clemens ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] future VDR and Net??eiver OEM from Reelmultimedia
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 GPL. i agree, binary only kernel modules do violate the GPL. unfortunatly many vendors get away with it. best regards ... clemens ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] future VDR and Net??eiver OEM from Reelmultimedia
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 running on the card the GPL applies there as well. what if i want to change that? clemens ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] future VDR and Net??eiver OEM from Reelmultimedia
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 linux because that means they get an stable and well performing OS at zero cost for their embedded designes what makes these chips sell better. hardware venders should start to obey to the rules of the game, when they want our money. 2) Use a HDMI transmitter, care about the NDA and deliver binary modules for controlling it. why not use [Free|Net|Open]BSD on the card? that whould not mean the consumer has any advantage but at least no license violation happens. best regards ... clemens ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] broken audio on FF card
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 question is, do i have to dump the card or is there a plugin, that can play video via the FF card and send audio to a soundcard? i thought about something like bitstream but for stereo (bitstream will not work, will it?). any tips, what i can do to rescue the FF card? :-) thx best regards ... clemens ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [PATCH] dynamically sized ringbuffers v2
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 implemented correctly. it seems doable to me. clemens ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Re: BROKEN MAILS [was] 4:3 stretched to 16:9?
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 you, but to martin noname, who apearently denys considering switching his mail service for no valid reason. i'm not going to argue endlessly with him and fixed the problem on my side. at least for me. best regards ... clemens ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] Mailing List Etiquette
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 quoted material to the minimum needed to clarify what you're talking about. * Add a blank line _before_ and _after_ each quote for better readability. * Make sure you are attributing material to the correct person (i.e. make sure the On 19/07/2002, Joe Bloggs said: is correct) * Write your responses _after_ the quoted text, not before. If your mail client makes it difficult to do this, get a new one. * Make sure lines are wrapped at maximum 76 characters (to fit an 80 character wide screen), even if the text had been quotet several times. * Use the correct number of characters at the start of each quoted line. * Set your mail client to english headers to avoid subjects like: AW: Antwort: Re: AW: AW: AW: Re: Some Topic allready trunkated If you see one, don't just add another Re: but remove all AW: and other chained Re:. * Use a descriptive subject! A message titled A small wish doesn't tell what it is about. Better use something like should do xyz or crashes when doing xyz. * If the topic of the thread changed/degrades meanwhile, change the subject too. That means: Before you start to answer, have a look into the subject your are going to reply to. For example use: New topic [WAS] old topic * Always write one separate message per topic. some people (especially those who matter) might not read mixed-up and lengthy threads. * Start a new thread when posting a new subject. * Make emails as short as possible whilst keeping them comprehensible. Don't = * Don't post in either HTML-only or in Text and HTML. If your mail client doesn't support this, change it. * Don't top post. * Don't give a one line answer having quoted the whole post. * Don't use a too long signature. Approx. 4 lines should always be enought. * Don't reply where you should have started a new thread. This means, make sure that you're not responding to an existing posting. Just changing the subject header and deleting any quoted text is NOT enough, because the message's header will still contain references to other messages. * Don't break threads by sending a new mail, where you should have replied. * Don't test post. Send your test posts to [EMAIL PROTECTED] or similar reply machines. * Don't use lengthly disclaimers. If not possible, use a freemail account. * Don't quote disclaimers and other footers. General Etiquette = This can really be summed up in one phrase - 'be polite'. Allways use your 'Real Name' when posting to mailinglists or newsgroups. If you think something is off-topic, don't reply to the list although you may want to send a short and *polite* note to the person privately telling them which list would be more appropriate; don't just say - that is OT here. Before asking a question, please Have a look at the mailing list archives at http://www.linuxtv.org/pipermail/vdr/ If someone flames or trolls the list, don't reply - it wastes everyones bandwidth and time. Don't reply to spam which gets through to the list - just ignore it when it does. Resources = * The ultimate guide to most matters to do with email etiquette is RFC-2822 which can be found at: ftp://ftp.isi.edu/in-notes/rfc2822.txt * A german site set up by some usenet-people, who take it even more serious with netiquette. http://learn.to/quote ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Vdr or driver performance dropout
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, but vdr had recovered. i can confirm this. i get the same delays in key processing very frequently. i use also a low end machine - PII 233 MHz. And third problem which have gone worse is weird black output I get. Vdr is up and running, osd is shown, but no live video. Changing channels are very slow (ie. vdr shows the info screen very long). Restarting vdr corrects this (propably reloading the drivers is the actual fix). This has happened with 1.3.19 about once a week. Now with 1.4.4 I had to restart vdr everyday. That's not so nice. me 2 also on this point. exactly the same behalfier. clemens ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Vdr or driver performance dropout
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 executing them after ~45s. One time it took so long, that I got ssh opened from other computer to restart vdr, but vdr had recovered. i can confirm this. i get the same delays in key processing very frequently. i use also a low end machine - PII 233 MHz. What type of remote receiver are you using? I've had delays with some remotes but not others: home brewed ir receiver on serial port using lirc. the same as you say worked best for you. i'm sure the problem is not on the IR side but on vdr, as that setup was not changed between vdr upgrades. best regards ... clemens ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] vdr on PS3
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: it supports HD (and Blue-Ray), is small and living room ready, comes with linux, has powerful CPU, you get a gameconsole for free ;-) contra: gets hot, likly DRM locked in some regards, it's a sony the last point may be even not so bad, as sony loses money on each selled device. so what do others think about this idea? anything i have not thought about that makes it even impossible to run vdr (or some other softdevice client) on the PS3? best regards ... clemens ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr on PS3
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, then you only have 300E left for HDMI GFX card, MoBo, CPU and Ram. at least, these are the prices i get from google and ebay. so it might be possible to get it cheaper, but this is not obvious to me. and why should a PC be more robust? besides that, i don't want to argue about a few euros here and there. i find the practical and technical implications of [EMAIL PROTECTED] more interresting. I say this jokingly but not every idea is a good one mate! :) i must agree. clemens ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] HTTP-Version of Control-Plugin?
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? clemens ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] *** glibc detected *** double free or corruption 1.4.2-1 Patch
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. either bla is a valid pointer and can be free'ed or bla is NULL and the free does not hurt anyway, because one is explicitely allowed to free NULL pointers by the standard. clemens ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
