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.
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 was designed to run on older equipment with limited resources
This is nonsense, like Windows (MCE) VDR can run same hardware with limited resources, but with all the same pro's and con's. Actual distros with their actual kernels do have the same requirements to hardware. And looking to the common DVB stream rates here in Europe, users need appropriate CPU power even if they use a hardware decoder. Nobody want to wait 30min until a HD recording is cutted ...
@WinVDR
Wow, sounds interessting, keep us updated about progress :-)
Cheers fnu
-----Original Message----- From: vdr-bounces@linuxtv.org [mailto:vdr-bounces@linuxtv.org] On Behalf Of Andrey Vlassov Sent: Friday, May 18, 2012 11:43 PM To: VDR Mailing List Subject: 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 5/19/12, Andrey Vlassov andreyv@ece.ubc.ca wrote:
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 is better than most of those programs and that is why many people might be interested in this port.
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.
I have already solved this problem and developed a Qt GUI app that runs VDR as background process, and all VDR configuration is done using nice GUI dialog, so to enable or disable a plugin all you have to do is to click a checkbox in the settings dialog. (I am already using this GUI app to run and configure VDR on Linux, I no longer use a script to run VDR)
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
Am 18.05.2012 23:30, schrieb WinVDR:
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.
nice work. sounds great :)
will it be possible to have a windows vdr as a slave to a linux vdr via streamdev for example?
if there is one thing missing since years it is a reliable frontend including osd on the windows platform.
i for myself would really appreciate to have the opportunity to cut recordings or even to do some debug work on my plugins regardless on what os i am on. of course there may be lot more opportunities to make use of the port.
greets
Michael
That's great news. The more VDR users, the better. I don't really care what os they're using, as long as they're using VDR. :)
Andrey Vlassov, will you please find some other mailing list to post your Windows-bashing and Windows user-bashing in? We like to keep this mailing list as garbage-free as possible. Thanks.
On 5/19/12, Midas vdrportal_midas@gmx.de wrote:
Am 18.05.2012 23:30, schrieb WinVDR: will it be possible to have a windows vdr as a slave to a linux vdr via streamdev for example?
Any plugin that does not use APIs from outside VDR can be ported without any modification (except for minor modifications in the Makefile).
After a quick look at streamdev source I think it can be easily ported since most of the code uses VDR API and the part that uses Linux sockets API can be easily ported to Winsock.
if there is one thing missing since years it is a reliable frontend including osd on the windows platform.
i for myself would really appreciate to have the opportunity to cut recordings or even to do some debug work on my plugins regardless on what os i am on. of course there may be lot more opportunities to make use of the port.
greets
Michael
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
I'm too interested in running windows vdr port as a slave on windows. Please try to compile stremdev and give us a note if it's working Marx
On Sat, May 19, 2012 at 12:30:43AM +0300, WinVDR wrote:
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 had the same problem with NetCeiver-plugin (full DVB-device emulation over network). Everything is vdr is nicely abtracted and then there are suddenly file handles instead of get-functions :-(
We've solved this issue by using pipes (Unix-sockets). This probably works also on Windows...
You can have a look in filter.c of https://svn.baycom.de/repos/vdr-mcli-plugin/
-
Andrey Vlassov -
Frank Neumann -
Georg Acher -
Marx -
Midas -
VDR User -
WinVDR