Re: [vdr] [ANNOUNCE] VDR successfully ported to Windows
Hi, I stopped to use Windows many years ago -- no interest from me for bloatware with all it's problems and horrible support. There are many programs in Windows to watch TV and some is completely free. But as you know a huge number of people use pirated software -- I have doubt that these people will be interested in your port. VDR was designed to run on older equipment with limited resources -- Windows goes against this policy by definition. VDR was designed for smaller system and there is a trend to use it in embedded systems. From my past experience (I work as Systems Analyst at one of biggest universities of Canada) 85% of Windows users are mouse monkeys -- they even do not know how to set variable. Do you expect that they will be able to configure and dig inside of VDR with it's plugins -- I have big doubts in this regard. Andy On 18/05/12 2:30 PM, WinVDR wrote: I have successfully ported VDR to Windows :) The port is a *native* Windows port using MinGW-w64 (does NOT use cygwin). (I will post the patch when every thing is ready). The only unsolved problem is that section filtering functions in cDevice cannot be implemented on Windows since hardware drivers do not use file descriptors to deliver data, another problem is that some drivers like the SkyStar2 driver do not provide section filtering at all, so if you want that data you have to extract it from TS packets directly. To solve that problem we need to modify these functions and avoid using file descriptors: int cDevice::OpenFilter(u_short Pid, u_char Tid, u_char Mask); void cDevice::CloseFilter(int Handle); Does any body have suggestions about the best way to implement this. We might also consider implementing builtin section filtering in VDR so we can extract section filtering data from TS packets directly if the driver does not provide them. The libdvbpsi library might be handy for that purpose. I have implemented a plugin to support the SkyStar2 budget card and it works fine, but since cDevice::OpenFilter() is not implemented, all the recordings produced by VDR do not include section packets(PAT,PMT..) so they are not playable. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Request: E parameter in channels.conf for epg scan
Dear Pasi, it is a great idea to fork a new line and rewrite code to satisfy all requests which been put forward. Please let me know when you will set a repository and write stable code so that I could give it a try. Please make changes quick so that people who was waiting for this changes had a chance to have better software. You will be our hero. NOTE: many demand but few commit time and do it. Thank you, Andy On 17/12/10 1:58 PM, Pasi Juppo wrote: On 12/15/2010 10:49 PM, Ville Skyttä wrote: On Wednesday 15 December 2010, Jouni Karvo wrote: I think adding dependencies to outside packages is a burden that should be avoided. There are already many things I need to install separately in order the vdr box to work; kernel, graphics drivers, and xine-lib. Luckily, lirc is now already part of the kernel, and DVB drivers, too; much less hassle than before. This is the right direction to go - not adding more moving parts that need to be installed (with compatible versions). I'm not saying anything about the epg data as plain text vs sqlite thing, but would like to note that things are not always that black and white as the above seems to say. In my opinion it does not make sense to reimplement everything that's required just in order to avoid dependencies (but other valid reasons for not using something that's already there might of course exist). And it's not only to avoid unnecessary wheel inventing but also going towards more generic solution of the software itself. If I'm not mistaking sqlite would actually help also in multi-instance (server solution) vdr implementation when each instance would be reading/writing from/to same DB but also external tools to read/write epg data way more faster than via vdr. But this depate can go on forever back and forth - probably leading to no changes what so ever. Klaus have already decided few posts ago to keep the text file based solution. Same goes for standalone-server wishes (vdr will not change to server-client system). And same for few other features. That said and with no disrespect to the author of vdr in my opinion it starts to be a time to fork vdr and redefine its base + few other elements. There are many very talented coders reading this mailing-list (+ many others over different vdr related sites) who are developing plugins and patches - some being very big. Put sources to accessible version control system (almost already existing at place where previously unmaintained plugins where brought alive), set up issue handling system with roadmaps etc. (like Mantis) and of course set up a core team of developers who make decisions what go in and what not. I believe this would also speed up the development of the vdr itself tremendeously due to much greater man power. Of course things can remain the same but will we ever see natively implemented in vdr: -_proper_ implementation of server-client solution (centralized records, epg etc. without hacks) -good looking high res OSD -good integration to XBMC or similar -fully redefinable menu system -channel specific configurability (epg...) -native ATSC support -several of the big patches integrated (long list) and configurable -etc.etc. If I've not read incorrectly what have been written in this mailing-list then the answer is *no*. Hope to get some active discussion around this and actions as well. Br, Pasi ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] Q::LinuxTV::USB-DVB-S -- what is supported?
Hi, My friend is looking for USB DVB-S device with support HDTV. A quick search on seach engines didn't give much information. Could you share your expirience with USB DVB-S devices and give some recommendations what to buy? At this time he interested to buy it and make it work in Windows and little latter when he will get more confortable with Linux -- make it work in Linux. So far we found next devices: http://cgi.ebay.com/Twinhan-DTV-VisionPlus-Starbox-NIB-Sealed_W0QQitemZ200175470168QQihZ010QQcategoryZ3761QQssPageNameZWDVWQQrdZ1QQcmdZViewItem http://cgi.ebay.com/USB-2-0-DVB-S-Satellite-HDTV-TV-receiver-w-Remote-SAT_W0QQitemZ180180995870QQihZ008QQcategoryZ3761QQssPageNameZWDVWQQrdZ1QQcmdZViewItem http://cgi.ebay.com/GeniaTech-Satellite-DVB-S-FTA-USB-Receiver-HDTV_W0QQitemZ330159401404QQihZ014QQcategoryZ32848QQrdZ1QQssPageNameZWD1VQQcmdZViewItem Could somebody who has any experience with this devices share what advantages and disadvantages this devices have? NOTE: LinuxTVWiki does not have any information for USB devices http://www.linuxtv.org/wiki/index.php/DVB_USB http://www.mjmwired.net/kernel/Documentation/dvb/README.dvb-usb Could you refer us to documentation with a list of supported USB DVB-S devices? What would be best place to buy USB DVB-S device? Thank you, Andy ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] VDR with two DVBS cards
Hi, could somebody point me in right direction? I am looking into configuring a second DVBS card to use with vdr. Configuration: Athlon 1.2GHz MB: ABIT Memory: 512MB OS: Mandriva 2006 vdr: 1.4.5 DVBS1: Nexus-S DVBS2: Twinhan 1025a At this time I use Nexus-S and it works fine. What modification/patches will require to make both cards work with vdr? Is there any documentation for this case? Greatly appreciated your help in advance, Andrey ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
