Re: [vdr] projects.vdr-developer.org - Domain down!
Am Dienstag, 2. November 2010 22:17:03 schrieb Tobias Grimm: The whole vdr-developer.org domain seems to be gone. Let's hope it hasn't expired and some stupid domain grabber gets his hands on it. Nothing to worry about - it was just a minor issue because of a domain transfer. http://projects.vdr-devloper.org should now be reachable again. There's an e missing: http://projects.vdr-developer.org However, http://www.vdr-developer.org is still not reachable. So is http://andreas.vdr-developer.org Do you know where i can find the source for vdradmin-am? regards, Tim ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] cSdtFIlter and LinkChannels
On 29.09.2010 15:22, Luca Olivetti wrote: Hello, I'm trying to understand cSdtFilter in order to write a channel scanner. I see that when it finds a SI::NVODReferenceDescriptorTag it will add it to the previously found channel with channel-SetLinkChannels, but it only does if it is in the current section (channel is a local variable) while the sdt could span several sections. From the specifications here http://neuron2.net/library/mpeg2/iso13818-1.pdf and here http://www.dvb.org/technology/standards/a005r5.tm1324r13.tr101211.v1.10.1.pdf I don't understand if this mechanism is correct, shouldn't the time_shifted_services link to the NVOD_reference? Besides, I don't see that the relation between a channels and its linkchannels is preserved in channels.conf (though I don't really care). You're right, the link channel information is not stored in channels.conf. I also see that cSdtFilter starts processing with the first section, and that shouldn't really be necessary as long as one processes all sections. Personally I'm not interested in that whole NVOD stuff, therefore I'm afraid I can't be of much help there. If you can suggest any improvements in that area, please post a patch. Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] RfC: add encryption and compression to VDR
Right now when the needs of a vdr extension goes beyond core SVDRP capabilities a different approach is being used by the each extensions. Prominent examples are: - vdradmin (using native SVDRP and suffering from its performance, optional use of direct file access to epg data) - live-plugin (integrating into vdr as plugin) - vdr iphone remote (using native SVDRP and due the bad performance and encryption capabilities an optional web-based interface) (and I'm sure there are more) While this is not bad per se there is obviously room for improvement. So my idea was to introduce a new standardized interface to VDR (either as plugin or native SVDRP commands) to plugins/extensions offering: - encryption (to be able to use it remotely in a more secure fashion) - compression (to overcome performance limitations especially when large amount of epg data have to be transferred) - and optionally authentication for obvious reasons Now I would like to start a few discussions related to this topic, the ones that come to my mind mind first are: - Should this be implemented as plugin or in core vdr as svdrp extension? - Would Klaus accept patches if this will be native SVDRP? - Are developers/maintainers of current or feature plugins/extensions interested in such a solution? - What technical implementation would make most sense? - Who would be willing to contribute to such a project? For the first step I was thinking about adding a STARTTLS command to core vdr (as patch) handling encryption and maybe also tranparent compression. This taks should be fairly easy as we could borrow ideas or even code from existing projects using STARTTLS (like mail servers). Authentication however would require a major redesign as far as I can tell. German version of this discussion can be found here: http://www.vdrportal.de/board/thread.php?threadid=101357 Thanks for your feedback, Christian ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] RfC: add encryption and compression to VDR
On 12.11.2010 17:04, Christian Tramnitz wrote: Right now when the needs of a vdr extension goes beyond core SVDRP capabilities a different approach is being used by the each extensions. Prominent examples are: - vdradmin (using native SVDRP and suffering from its performance, optional use of direct file access to epg data) - live-plugin (integrating into vdr as plugin) - vdr iphone remote (using native SVDRP and due the bad performance and encryption capabilities an optional web-based interface) (and I'm sure there are more) While this is not bad per se there is obviously room for improvement. So my idea was to introduce a new standardized interface to VDR (either as plugin or native SVDRP commands) to plugins/extensions offering: - encryption (to be able to use it remotely in a more secure fashion) - compression (to overcome performance limitations especially when large amount of epg data have to be transferred) - and optionally authentication for obvious reasons Now I would like to start a few discussions related to this topic, the ones that come to my mind mind first are: - Should this be implemented as plugin or in core vdr as svdrp extension? - Would Klaus accept patches if this will be native SVDRP? No. If at all, this has to go into a plugin. - Are developers/maintainers of current or feature plugins/extensions interested in such a solution? - What technical implementation would make most sense? - Who would be willing to contribute to such a project? For the first step I was thinking about adding a STARTTLS command to core vdr (as patch) handling encryption and maybe also tranparent compression. This taks should be fairly easy as we could borrow ideas or even code from existing projects using STARTTLS (like mail servers). Authentication however would require a major redesign as far as I can tell. Definitely no authentication or encryption stuff in core VDR. Klaus German version of this discussion can be found here: http://www.vdrportal.de/board/thread.php?threadid=101357 ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] cSdtFIlter and LinkChannels
Al 12/11/10 16:24, En/na Klaus Schmidinger ha escrit: I also see that cSdtFilter starts processing with the first section, and that shouldn't really be necessary as long as one processes all sections. Personally I'm not interested in that whole NVOD stuff, therefore Me neither, but that question was for normal sdt scanning, not related to NVOD. Meanwhile I took the faster approach: whichever section comes first it gets processed. Bye -- Luca ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] RfC: add encryption and compression to VDR
Hi Am Freitag, 12. November 2010 schrieb Christian Tramnitz: Right now when the needs of a vdr extension goes beyond core SVDRP capabilities a different approach is being used by the each extensions. Prominent examples are: - vdradmin (using native SVDRP and suffering from its performance, optional use of direct file access to epg data) - live-plugin (integrating into vdr as plugin) - vdr iphone remote (using native SVDRP and due the bad performance and encryption capabilities an optional web-based interface) (and I'm sure there are more) [...] Now I would like to start a few discussions related to this topic, the ones that come to my mind mind first are: - Should this be implemented as plugin or in core vdr as svdrp extension? - Would Klaus accept patches if this will be native SVDRP? - Are developers/maintainers of current or feature plugins/extensions interested in such a solution? - What technical implementation would make most sense? - Who would be willing to contribute to such a project? The live-plugin has support (contributed by third party developer) for SSL connections to its internal web-server. See the README file in LIVE for more details. The concept how LIVE works as plugin could be generalized to provide a 'generic' (SVDRP like) access via xml-http(s)-requests or via JSON etc. The general disadvantage of such an approach is, that it creates an 'officially unsupported' way to control VDR remotely. I mean it does not get 'standardized' by Klaus :) Regards Tadi -- Dieter Hametnerdh (plus) vdr (at) gekrumbel (dot) de live plugin developer http://live.vdr-developer.org signature.asc Description: This is a digitally signed message part. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
