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
[vdr] [ANNOUNCE] VDR maintenance patch 1.6.0-2
VDR maintenance patch 1.6.0-2 is now available at ftp://ftp.cadsoft.de/vdr/Developer/vdr-1.6.0-2.diff This is a 'diff' against version 1.6.0-1 (which is the official version 1.6.0, patched with ftp://ftp.cadsoft.de/vdr/Developer/vdr-1.6.0-1.diff). Small fixes to the officially released VDR versions will be first made available as maintenance patches in the Developer directory, so that they can be reviewed and tested before a new official release is published. So please apply the above patch(es) and report whether it works (or if it causes any new problems). This version is binary compatible to the previous one, so plugins don't need to be recompiled. The changes since version 1.6.0-1: - Updated the Italian OSD texts (thanks to Diego Pierotto). - The SVDRP signon message now indicates the character encoding in use, as in 220 video SVDRP VideoDiskRecorder 1.7.1; Fri May 2 16:17:10 2008; ISO-8859-1. This may be useful for instance for external tools that provide EPG data, so that they can correctly encode the strings. - No longer calling FcFini() to avoid problems with older (broken) versions of fontconfig (suggested by Edgar Toernig). - Updated the sources.conf file (thanks to Oleg Roitburd). - Fixed a possible integer overflow in GetAbsTime() (thanks to Alexander Rieger). - Fixed a problem with calling isyslog() from within the SignalHandler() (thanks to Udo Richter). - Replaced the Finnish language code smi with suo (thanks to Rolf Ahrenberg). - Fixed wrong value for TableIdBAT in libsi/si.h (thanks to Winfried Köhler). - Removed unneeded include files linux/dvb/dmx.h und time.h from remux.h (reported by Tobias Grimm). Have fun! Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] [ANNOUNCE] VDR developer version 1.7.1
VDR developer version 1.7.1 is now available at ftp://ftp.cadsoft.de/vdr/Developer/vdr-1.7.1.tar.bz2 A 'diff' against the previous version is available at ftp://ftp.cadsoft.de/vdr/Developer/vdr-1.7.0-1.7.1.diff WARNING: This is a *developer* version. Even though *I* use it in my productive environment, I strongly recommend that you only use it under controlled conditions and for testing and debugging. This version marks the first step towards using TS (Transport Stream) as recording format. It does this by switching the Transfer Mode to TS and introducing all the necessary cDevice and cPlayer functions to handle TS. Actual recording is still done in PES, though. This should provide a reasonable developing and testing environment for HDTV device plugins to prepare for replaying TS. There appears to be a problem with replaying the payload from TS packets on Full-Featured DVB cards. On some channels this works rather fine (with only very small glitches from time to time), while on other channels there are heavy glitches and sometimes even the audio goes mute. My initial approach to replaying TS on FF cards was to simply strip the TS header and send the payload to the usual PlayVideo() and PlayAudio() functions, since the driver itself examines the data and assembles the 2KB PES packets it sends to the hardware. Since the FF cards can replay the TS data as it comes in from the transponder, my assumption was that the same should be possible in Transfer Mode. But maybe there is something wrong with this assumption? Could this be a driver problem? I don't think that simply throwing memory at the problem is the solution. Any thoughts? The changes since version 1.7.0: - Adapted the tuning code to the new DVBFE_SET_DELSYS API (thanks to Reinhard Nissl). VDR now uses the driver from http://jusst.de/hg/multiproto_plus. - Updated the Italian OSD texts (thanks to Diego Pierotto). - Removed obsolete $(NCURSESLIB) from the Makefile. - Implemented handling the standard component descriptor for AC3 (stream=4), as it will soon be used by the German ARD channels (thanks to Michael Pennewiß for advance information about this change). The previously used Premiere pseudo standard (stream=2, type=5) still works, but has apparently been wrongfully used by broadcasters from the beginning. - Added missing description of the 'S' channel parameter to vdr.5 (reported by Reinhard Nissl). - The SVDRP signon message now indicates the character encoding in use, as in 220 video SVDRP VideoDiskRecorder 1.7.1; Fri May 2 16:17:10 2008; ISO-8859-1. This may be useful for instance for external tools that provide EPG data, so that they can correctly encode the strings. - No longer calling FcFini() to avoid problems with older (broken) versions of fontconfig (suggested by Edgar Toernig). - Removed the compile time option VFAT to allow users of precompiled binary distributions to have full control over whether or not to use the --vfat option at runtime (suggested by Michael Nork). - First step towards switching to TS (Transport Stream) as recording format: + The new function cDevice::PlayTs() is used to play TS packets. + The new functions cDevice::PlayTsVideo() and cDevice::PlayTsAudio() are used to play video and audio TS packets, respectively. + The new function cAudio::PlayTs() is used to play audio TS packets. + The new class cPatPmtGenerator is used to generate a PAT/PMT pair that precedes the TS data in Transfer Mode. + The new class cPatPmtParser is used by cDevice to parse the PAT/PMT data in a TS in order to find out which streams it contains. + The new class cTsToPes is used to convert TS packets to a PES packet. + cTransfer no longer uses cRemux, and doesn't run a separate thread any more. It just generates a PAT/PMT and sends all received TS packets to the primary device's PlayTs(). + Live subtitle display no longer uses a ring buffer and separate thread. + cPesAssembler has been removed. Old VDR recordings only contain complete PES packets. + Since a TS needs to have a PAT/PMT, which requires the video stream type to be explicitly given, the format of the VPID field in the channels.conf file and the SVDRP commands NEWC/MODC/LSTC has been extended. The video stream type now follows the VPID and optional PPID, separated by an '=' sign. - Updated the sources.conf file (thanks to Oleg Roitburd). - Fixed a possible integer overflow in GetAbsTime() (thanks to Alexander Rieger). - Fixed a problem with calling isyslog() from within the SignalHandler() (thanks to Udo Richter). - Replaced the Finnish language code smi with suo (thanks to Rolf Ahrenberg). - Fixed wrong value for TableIdBAT in libsi/si.h (thanks to Winfried Köhler). - Errors in config files no longer keep VDR from starting. - Removed unneeded include files linux/dvb/dmx.h und time.h from remux.h (reported by Tobias
Re: [vdr] [ANNOUNCE] VDR maintenance patch 1.6.0-2
Klaus Schmidinger schrieb: VDR maintenance patch 1.6.0-2 is now available at Thanks :-) Have a nice day! Thomas ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.1
On Sun, Sep 07, 2008 at 12:11:35PM +0200, Klaus Schmidinger wrote: This version marks the first step towards using TS (Transport Stream) as recording format. It does this by switching the Transfer Mode to TS and introducing all the necessary cDevice and cPlayer functions to handle TS. Actual recording is still done in PES, though. This should provide a reasonable developing and testing environment for HDTV device plugins to prepare for replaying TS. :-) Thank you very much !!! I'll be trying some other ~VDR clone~ because of the lack of TS in vdr, but for me they are all *censored*... It's great to have this one, thank you very much for all your great work !!! -- Grégoire FAVRE http://gregoire.favre.googlepages.com http://www.gnupg.org http://picasaweb.google.com/Gregoire.Favre ___ 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 (Number of users)
Hi On 09/05/08 18:38, VDR User wrote: ... Seeing how many people have already left VDR, it's already happening! :( I have no idea how many people actually use VDR, but you apparently have some solid numbers on how many people dropped VDR. Do you mind sharing these numbers? I do not have exact numbers but a rough guess would tell me that about 5-10 K people are using Gen2VDR. And thats surely not the main VDR Distribution ;) -- Helmut Auer, [EMAIL PROTECTED] ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.1
The sky plugin does not compile any more, because it uses PID_MASK_HI
which got renamed to TS_PID_MASK_HI. Patch is attached. A similar
problem strikes for streamdev.
Cheers,
Udo
--- vdr-1.7.1-old/PLUGINS/src/sky/sky.c 2008-09-07 13:34:53.0 +0200
+++ vdr-1.7.1/PLUGINS/src/sky/sky.c 2008-09-07 13:38:23.0 +0200
@@ -160,12 +160,12 @@
Data = tsBuffer-Get();
if (Data) {
// insert the actual PIDs:
-int Pid = (((uint16_t)Data[1] PID_MASK_HI) 8) | Data[2];
+int Pid = (((uint16_t)Data[1] TS_PID_MASK_HI) 8) | Data[2];
if (Pid == DUMMYAPID)
Pid = apid;
else if (Pid == DUMMYVPID)
Pid = vpid;
-Data[1] = ((Pid 8) 0xFF) | (Data[1] ~PID_MASK_HI);
+Data[1] = ((Pid 8) 0xFF) | (Data[1] ~TS_PID_MASK_HI);
Data[2] = Pid 0xFF;
}
return true;
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.1
On 09/07/08 13:48, Udo Richter wrote: The sky plugin does not compile any more, because it uses PID_MASK_HI which got renamed to TS_PID_MASK_HI. Patch is attached. Thanks. At some point I guess I should just drop the sky plugin, since it's of no real use any more... Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.1
On 09/07/08 13:55, Jelle De Loecker wrote: Multiproto_plus is quite outdated, Manu (the maintainer) has done a bunch of updates on the original multiproto tree (http://jusst.de/hg/multiproto) He even added support for the old API (yay) and merged the latest V4L tree with it. Basically, it compiles and it just works with everything :) Thanks. I forgot to update and verify that - I'm still using the one from http://jusst.de/hg/multiproto_plus, dated 2008-04-13 (was just too lazy to recompile a newer one). Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] DVB API Wrapper for VDR-1.7.1
Hi list, A minimal update to the DVB API wrapper for VDR 1.7.1 is available on my web site. http://www.udo-richter.de/vdr/patches.en.html#dvb-api-wrapper http://www.udo-richter.de/vdr/patches.html#dvb-api-wrapper Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.1
Multiproto_plus is quite outdated, Manu (the maintainer) has done a bunch of updates on the original multiproto tree (http://jusst.de/hg/multiproto) He even added support for the old API (yay) and merged the latest V4L tree with it. Basically, it compiles and it just works with everything :) /Met vriendelijke groeten,/ *Jelle De Loecker* Kipdola Studios - Tomberg Klaus Schmidinger schreef: VDR developer version 1.7.1 is now available at ftp://ftp.cadsoft.de/vdr/Developer/vdr-1.7.1.tar.bz2 A 'diff' against the previous version is available at ftp://ftp.cadsoft.de/vdr/Developer/vdr-1.7.0-1.7.1.diff WARNING: This is a *developer* version. Even though *I* use it in my productive environment, I strongly recommend that you only use it under controlled conditions and for testing and debugging. This version marks the first step towards using TS (Transport Stream) as recording format. It does this by switching the Transfer Mode to TS and introducing all the necessary cDevice and cPlayer functions to handle TS. Actual recording is still done in PES, though. This should provide a reasonable developing and testing environment for HDTV device plugins to prepare for replaying TS. There appears to be a problem with replaying the payload from TS packets on Full-Featured DVB cards. On some channels this works rather fine (with only very small glitches from time to time), while on other channels there are heavy glitches and sometimes even the audio goes mute. My initial approach to replaying TS on FF cards was to simply strip the TS header and send the payload to the usual PlayVideo() and PlayAudio() functions, since the driver itself examines the data and assembles the 2KB PES packets it sends to the hardware. Since the FF cards can replay the TS data as it comes in from the transponder, my assumption was that the same should be possible in Transfer Mode. But maybe there is something wrong with this assumption? Could this be a driver problem? I don't think that simply throwing memory at the problem is the solution. Any thoughts? The changes since version 1.7.0: - Adapted the tuning code to the new DVBFE_SET_DELSYS API (thanks to Reinhard Nissl). VDR now uses the driver from http://jusst.de/hg/multiproto_plus. - Updated the Italian OSD texts (thanks to Diego Pierotto). - Removed obsolete $(NCURSESLIB) from the Makefile. - Implemented handling the standard component descriptor for AC3 (stream=4), as it will soon be used by the German ARD channels (thanks to Michael Pennewiß for advance information about this change). The previously used Premiere pseudo standard (stream=2, type=5) still works, but has apparently been wrongfully used by broadcasters from the beginning. - Added missing description of the 'S' channel parameter to vdr.5 (reported by Reinhard Nissl). - The SVDRP signon message now indicates the character encoding in use, as in 220 video SVDRP VideoDiskRecorder 1.7.1; Fri May 2 16:17:10 2008; ISO-8859-1. This may be useful for instance for external tools that provide EPG data, so that they can correctly encode the strings. - No longer calling FcFini() to avoid problems with older (broken) versions of fontconfig (suggested by Edgar Toernig). - Removed the compile time option VFAT to allow users of precompiled binary distributions to have full control over whether or not to use the --vfat option at runtime (suggested by Michael Nork). - First step towards switching to TS (Transport Stream) as recording format: + The new function cDevice::PlayTs() is used to play TS packets. + The new functions cDevice::PlayTsVideo() and cDevice::PlayTsAudio() are used to play video and audio TS packets, respectively. + The new function cAudio::PlayTs() is used to play audio TS packets. + The new class cPatPmtGenerator is used to generate a PAT/PMT pair that precedes the TS data in Transfer Mode. + The new class cPatPmtParser is used by cDevice to parse the PAT/PMT data in a TS in order to find out which streams it contains. + The new class cTsToPes is used to convert TS packets to a PES packet. + cTransfer no longer uses cRemux, and doesn't run a separate thread any more. It just generates a PAT/PMT and sends all received TS packets to the primary device's PlayTs(). + Live subtitle display no longer uses a ring buffer and separate thread. + cPesAssembler has been removed. Old VDR recordings only contain complete PES packets. + Since a TS needs to have a PAT/PMT, which requires the video stream type to be explicitly given, the format of the VPID field in the channels.conf file and the SVDRP commands NEWC/MODC/LSTC has been extended. The video stream type now follows the VPID and optional PPID, separated by an '=' sign. - Updated the sources.conf file (thanks to Oleg Roitburd). - Fixed a possible integer overflow in GetAbsTime() (thanks to Alexander Rieger). - Fixed a
Re: [vdr] VDR Development (Number of users)
Original-Nachricht Datum: Sun, 07 Sep 2008 13:31:22 +0200 Von: Helmut Auer [EMAIL PROTECTED] An: VDR Mailing List vdr@linuxtv.org Betreff: Re: [vdr] VDR Development (Number of users) Hi On 09/05/08 18:38, VDR User wrote: ... Seeing how many people have already left VDR, it's already happening! :( I have no idea how many people actually use VDR, but you apparently have some solid numbers on how many people dropped VDR. Do you mind sharing these numbers? I do not have exact numbers but a rough guess would tell me that about 5-10 K people are using Gen2VDR. And thats surely not the main VDR Distribution ;) How did you calculate that number? -- Release early, release often. Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten Browser-Versionen downloaden: http://www.gmx.net/de/go/browser ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR Development (Number of users)
Hi Hans How did you calculate that number? By counting the downloads of fixes (which are only made once with the internal update script). And I guess that some users will never update a running system ... -- Helmut Auer, [EMAIL PROTECTED] ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR Development
Glad to see some discussion taking place here.. It's quite funny some people think hdtv, h264, and other standard or quickly-becoming-standard things are bleeding edge. You've got to be kidding! Also, to put it simply, it's ignorant to think there's nothing wrong. When many VDR users are abandoning the software for other more capable options, why do you think that is? Because it lacks support for -current needs-, and for that matter lacks support for even some of the most basic stuff! You can bash MythTV all you want but it doesn't change the fact that people are leaving VDR in favor of it. I agree that MythTV is big, poorly designed in some respects, and generally a pain to get running...but that obviously isn't stopping people. Stability is a great thing to have, but so is support for basic needs. And where is the rule that says you can't have both? Just like code is improved, so can the processes which generate the code and bring it together. It seems like some are taking this discussion as an attack on Klaus and that is NOT the case. It's absurd this has to be pointed out -again- but the intentions are only to improve VDR's development, features (even some of the most basic), and ensure that VDR will not become obsolete because it isn't keeping pace with the rest of the world. Ignoring basic needs simply because they don't apply to you isn't exactly the picture of great design or development now is it? The 'as long as it works here, everyone else can stay in the cold' attitude has never resulted in anything positive. Nobody should ever say sorry for the idea of taking a good product and making it better! ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.1
On 09/07/08 16:48, Luca Olivetti wrote: El Sun, 07 Sep 2008 12:11:35 +0200 Klaus Schmidinger [EMAIL PROTECTED] escribió: t. + cTransfer no longer uses cRemux, and doesn't run a separate thread any more. It just generates a PAT/PMT and sends all received TS packets to the primary device's PlayTs(). Just asking before I try to recompile everything, but does it mean that output plugins (xine, dxr3, etc.) have to be rewritten? They can implement cDevice::PlayTs() if they need to handle the TS packets by themselves. Otherwise the TS payload will be extracted from the TS, assembled to complete PES packets and delivered via the existing PlayVideo() and PlayAudio() functions. I assume HDTV output plugins will want to handle the TS by themselves - that's the whole point in switching to TS. Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR Development
FULLACK Oliver, You have forgotten the point: * help to add dvb-s2 support into main kernel!! Danke Gruß Halim On So, Sep 07, 2008 at 05:08:37 +0200, Oliver Endriss wrote: Guys, I can't stand this blabla any longer. 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! 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. Oliver -- VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/ ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr -- Halim Sahin E-Mail: halim.sahin (at) t-online.de ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR Development
Just a couple of observations on this discussion.. I see that some advocates of VDR repository are calling Myth project 'bloated','kitchen sink', 'not alternative to VDR'…, but, at the same time, they are pushing VDR project the same way, which will virtually transform VDR into sort of Myth-2, because the most important advantages of VDR can persist only as long as Klaus has fun, hence motivation to continue development of his great project. And he clearly stated that collective development way is not appropriate to his own development style and his view on how VDR project should be managed. Well ok, we all expect open source development to be driven by personal need, but it is the combination of code created by many people who each had their own needs which is where the magic lies. Again, why do we need Myth-2 if we already have Myth-1 incorporating all the mentioned magic.. A well maintained bazaar-style project is generally thought to produce much higher quality code. Look at the Linux kernel and compare it to any other operating system. Linux kernel development is a good example of the fact that greatness of a project is dependant in the first place on the person who leads the project. Importance of the chosen tool (community tree, or something else) is in the second place. Collective development via repository, or single coder ruling - this is just a tool that the project leaders have fun and convenience to use for their projects. A lot of projects use community tree as their tool of development, but it doesn’t necessarily guarantee to them so high level of appreciation that Linux kernel has, for example.. _ Invite your mail contacts to join your friends list with Windows Live Spaces. It's easy! http://spaces.live.com/spacesapi.aspx?wx_action=createwx_url=/friends.aspxmkt=en-us___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] Subtitles not shown after language change
Hi, I noticed a problem with multi-language broadcast with subtitles or actually playback of recording of that (I didn't watch it in live). The clip is mainly having swedish audio, but during the interviews audio is finnish. However audio track seems to marked as swedish only. During the swedish audio the clip has finnish subtitles and vice versa. But during the playback when finnish subtitles should be shown again after swedish, they will not appear. Only way to fix that is to stop the playback and press play again and then the finnish subtitles are shown again. I noticed that subtitle menu shows that actually finnish subtitles might be in swedish track for a while. But still, if I stop and then continue the playback, VDR shows the subtitles, so I'm not sure where the problem is. I uploaded the 100MB sample clip to here: http://rapidshare.com/files/143391850/Sportmagasinet.tgz.html My system consists from VDR 1.6.0-1 on FC4, TechnoTrend DVB-C FF 2.1+Satelco DVB-C budget. Default languages are set as Finnish, Swedish and English in that order for subtitles and Finnish, English, Swedish for audio. -- Tero ___ 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
On Sun, Sep 07, 2008 at 05:46:01PM +0200, Halim Sahin wrote: FULLACK Oliver, You have forgotten the point: * help to add dvb-s2 support into main kernel!! Which one? SCNR :-) 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. 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: - 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.). - 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. - The current plugin concept allows only a very limited access or modfications in the core behaviour. At least without core patches... - 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. 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. So, the main discussion topic should be: What is needed for a future-proof design? It is not about XML or SQL or other hype buzzwords, it's about the overall design and how individual modules/plugins interact with each other. Just my EUR0.01... -- Georg Acher, [EMAIL PROTECTED] http://www.lrr.in.tum.de/~acher Oh no, not again ! The bowl of petunias ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR Development
On Sun, Sep 7, 2008 at 8:08 AM, Oliver Endriss [EMAIL PROTECTED] wrote: Guys, I can't stand this blabla any longer. Then don't read this thread. 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! What's your point? At one point he also said he didn't intend to support HDTV because he doesn't use it, as well as said he had no intention to move away from mpeg-pes. Thanks to the discussions input on this mailing list by the users, he has changed his mind. My suggestion for those who are unhappy with the current situation: 0. Stop this discussion. I will NEVER suggest to prohibit or censor discussion, especially at a place where open discussion should be promoted. We all have the right to our opinions and I see no crime in voicing them. Judging by the number of responses, many people have strong opinions on the subject regardless of which side of the fence they stand on, and I'm glad to read them all. Your idea that we should just shut up and if we don't like it, then make a fork, maintain it for 8 years bla bla bla, is a bit childish at best. Sorry, but nobody here needs your permission or approval to discuss VDR related topics on the VDR mailing list. Again, my suggestion is to do what I do Don't read threads that don't interest me. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] new rolloff paramemter in channels.conf for vdr 1.7.0
As Manu explained me it's not possible to set manually rolloff/FEC for stb0899. that's why I'm wondering - what for need the new roll off (parameter O) parameter in channels.conf ? Only for reading the current state of roll off in demod ? (0,35% is default for dvb-s/s2 BPSK, QPSK, 8PSK) Is work really ? It's a transponder parameter that is broadcast in the NIT and can be set in the DVB-API. VDR simply hands it over and doesn't care if a particular device uses it or not. thanks for your answer. It's clear for me now Or did I misunderstand your question? you understood me correctly :) Goga ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR Development
Hi, On So, Sep 07, 2008 at 06:44:46 +0200, Georg Acher wrote: On Sun, Sep 07, 2008 at 05:46:01PM +0200, Halim Sahin wrote: FULLACK Oliver, You have forgotten the point: * help to add dvb-s2 support into main kernel!! Which one? I don't know. But I have forgotten another important point: Help to develope an fullfeatured, h264 capable card, or hw accelerated video driver for radeon/nvidia/intel cards. (greener VDR?) Nice stuff h264, HDTV. We need hdtv capable hardware!!! regards Halim ___ 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
[vdr] Build plugin with different headers then in VDR distribution
Hi, I need to have a possibility to build VDR plugins using headers which are different then in VDR distribution. Does somebody knows how to do it? Thanks in advance. -- Cheers, Michael ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR Development
VDR does need some of its core functionality upgraded - for example something like the Reel channel scan is badly missing, you should be able to easily scan for transponders from within VDR, just like most satellite receivers. +1 Hmmm. My VDR automatically updates its channel list by itself, and adds all channels and transponders I ever needed. (which is far from what other receivers I know do.) The only thing I miss is a built-in way to get rid of channels that are gone. (I do have my own solution though.) ah, you are watching the Astra 19.2 E , yes ? Astra has corrected service tables (nit, sdt,...) due to this vdr can update and add new channels. Please, try to delete your channels.conf and start to scan Astra with reelchannelscan, Will you find dvb-s2 channels ?? Goga ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR Development
With regards to dvb cards that include mpeg4 hardware decoders... There aren't many even in development and the ones that do actually (if they do) make it to production will be very expensive. At the cost of the card you can build a pc capable of the same and a lot more for your money. In conversations I've had with dvb devs, the demand for such a card just isn't big enough to bring the price down to something the average user will pay. For this reason I don't think it's wise to continue treating VDR in a way that assumes most users dusted off the old piece of crap pc in their closet and put a full-featured card in it. There is no way to ignore the fact that home entertainment is moving to htpc-based setups, especially now that hardware is cheap enough that you can build a powerful pc for little expense. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] h264 patch for vdr 171 (was -[ANNOUNCE] VDR developer version 1.7.1)
Hi, Klaus thanks for your work. what about h264 patch ? will it update ? Goga ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR Development
On Sun, Sep 07, 2008 at 07:21:04PM +0200, Halim Sahin wrote: * help to add dvb-s2 support into main kernel!! Which one? I don't know. :-) I guess nobody does... But I have forgotten another important point: Help to develope an fullfeatured, h264 capable card, or hw accelerated Been there, done that already :-) The HDE from Reel decodes h264, I wrote a lot of the driver stuff for it. So there is (at least one) h264-decoder card, and btw, vdr is the main platform for the HDE. video driver for radeon/nvidia/intel cards. There are rumours that Ati is planning such drivers... In the long term special decoder cards will vanish, but I think it will still take some time. -- Georg Acher, [EMAIL PROTECTED] http://www.lrr.in.tum.de/~acher Oh no, not again ! The bowl of petunias ___ 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] VDR Development
Georg Acher 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. 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: - 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.). - 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. - The current plugin concept allows only a very limited access or modfications in the core behaviour. At least without core patches... - 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. 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. So, the main discussion topic should be: What is needed for a future-proof design? It is not about XML or SQL or other hype buzzwords, it's about the overall design and how individual modules/plugins interact with each other. Just my EUR0.01... Indeed this would be a very interesting discussion. CU Oliver -- VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/ ___ 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
On Sun, Sep 7, 2008 at 9:26 PM, Clemens Kirchgatterer [EMAIL PROTECTED]wrote: 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. 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). clemens ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr -- Cheers, Michael ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] vdr channels.conf compatibility
Hello, my question is? Does dvb-apps 1.1.1 and their utility scan support vdr 1.6 format? dvb-apps 1.1.1 is official tarball on dvb-apps website. Thanks! David ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR Development
Hello, On So, Sep 07, 2008 at 08:25:56 +0200, Georg Acher wrote: Been there, done that already :-) The HDE from Reel decodes h264, I wrote a lot of the driver stuff for it. So there is (at least one) h264-decoder card, and btw, vdr is the main platform for the HDE. Yes right that might be an option for short time. Micronas stopped the support of the used chips I think. How many boards can be equipped with the available chips How many boards are available for vdr users? I like to have a more general solution! Regards Halim ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] Fw: about eHD from Reelmultimedia (was - VDR Development)
I have resent with more correct subject :) Дата: Sun, 7 Sep 2008 21:51:54 +0200 От: Halim Sahin [EMAIL PROTECTED] Кому: vdr@linuxtv.org Тема: Re: [vdr] VDR Development Hello, On So, Sep 07, 2008 at 08:25:56 +0200, Georg Acher wrote: Been there, done that already :-) The HDE from Reel decodes h264, I wrote a lot of the driver stuff for it. So there is (at least one) h264-decoder card, and btw, vdr is the main platform for the HDE. Yes right that might be an option for short time. Micronas stopped the support of the used chips I think. How many boards can be equipped with the available chips How many boards are available for vdr users? I like to have a more general solution! Regards Halim ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Fw: about eHD from Reelmultimedia (was - VDR Development)
On Mon, Sep 08, 2008 at 12:09:11AM +0400, Goga777 wrote: Yes right that might be an option for short time. Micronas stopped the support of the used chips I think. Support!=availability How many boards can be equipped with the available chips AFAIK we have received no last order date yet. I don't know of any sourcing problems. How many boards are available for vdr users? Enough... ;) -- Georg Acher, [EMAIL PROTECTED] http://www.lrr.in.tum.de/~acher Oh no, not again ! The bowl of petunias ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Recommended xine settings for Arte HD ?
Hi, Gregoire Favre schrieb: On Mon, Sep 01, 2008 at 01:14:51PM +0200, Gregoire Favre wrote: On Thu, Aug 21, 2008 at 01:14:23PM +0200, Gregoire Favre wrote: On Thu, Aug 21, 2008 at 12:18:02PM +0400, Goga777 wrote: yes, but for me it's not errors, it's only information messages, nothing special. May be I wrong... I guess so. how ? Edit the source, recompil, install. I changed this : grep BUFSIZE *|grep MEGABYTE dvbplayer.c:#define PLAYERBUFSIZE MEGABYTE(4) recorder.c:#define RECORDERBUFSIZE MEGABYTE(20) transfer.c:#define TRANSFERBUFSIZE MEGABYTE(8) My computer has 4Gb of ram so I can be large... I rarely used VDR for quiete a long time, and I wanted to try some other way : I compiled ffmpeg with icc using -O3 -xT -gcc -mtune=core2 and that make a difference : now my CPU is almost enough for ARTE HD which wasn't the case with gcc ;-) If the weather stay so bad, I shall use VDR again a lots (not for recording as for that I'll wait vdr-1.7.1 but anyway) :-) What CPU do you have (MHz)? Have you tried compiling it with gcc -O3 ? I would like to know, if there is a performance increase, when compiling ffmpeg with gcc -O3 instead of -O2. Maybe some other applications, like the X-Server should also be compiled with -O3 to get a better performance with h264 decoding... Regards, Artem ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR Development
On 09/07/08 19:42, Clemens Kirchgatterer wrote: ... i always wondered why dvb support was directly compiled in while other back and frontends were supposed to be plugins. this clearly leaves a sign that dvb is the preferd plattform. Well, it was the first one - long before there even was a plugin interface. Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Recommended xine settings for Arte HD ?
On Sun, Sep 07, 2008 at 11:03:46PM +0200, Artem Makhutov wrote: What CPU do you have (MHz)? Intel Core 2 Duo @ 2.4GHz. Have you tried compiling it with gcc -O3 ? Yes. I would like to know, if there is a performance increase, when compiling ffmpeg with gcc -O3 instead of -O2. Not for everything, AFAIK it's sometimes slower ??? Maybe some other applications, like the X-Server should also be compiled with -O3 to get a better performance with h264 decoding... My xorg-server-1.5 is also compiled with icc :-) -- Grégoire FAVRE http://gregoire.favre.googlepages.com http://www.gnupg.org http://picasaweb.google.com/Gregoire.Favre ___ 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
