VDR developer version 1.5.14 is now available at
ftp://ftp.cadsoft.de/vdr/Developer/vdr-1.5.14.tar.bz2
A 'diff' against the previous developer version is available at
ftp://ftp.cadsoft.de/vdr/Developer/vdr-1.5.13-1.5.14.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.
The changes since version 1.5.13:
- Fixed the Play function in the pictures plugin. - Updated the Finnish OSD texts (thanks to Rolf Ahrenberg). - Updated the Makefile of the skincurses plugin (thanks to Rolf Ahrenberg). - The new option --localedir can be used to set the locale directory at runtime (based on a patch from Stefan Huelswitt). - Fixed finding new transponders (thanks to Winfried Köhler). - Implemented handling of DVB-S2 (thanks to Marco Schlüßler and Reinhald Nissl for a patch that was used to implement this). VDR now requires the "multiproto" DVB driver, e.g. from http://jusst.de/hg/multiproto. - Removed switching to the next higher or lower channel if the current channel is not available, in order to allow staying on an encrypted channel that takes a while for the CAM to start decrypting.
IMPORTANT NOTE: ===============
As of this version, VDR requires the new "multiproto" driver, as available, for instance, from http://jusst.de/hg/multiproto. It also uses additional transponder parameters, so a channels.conf file written with this version will not work with previous versions of VDR. Make sure you run this version in a separate environment, or make backups of your config files in case you want to go back to the previous version!
So far, VDR supports DVB-S2 hardware and can tune to DVB-S2 transponders. It doesn't yet handle H.264 video PIDs, so it should be safe to tune to such a transponder even if you don't have a device that understands H.264.
I am using this version in my regular VDR (with a FF-DVB-S, Budget-DVB-S and Budget-DVB-T card) and everything that used to work appears to still work fine. I was also able to record the AC3 audio track from ProSiebenHD with my TT-S2-3200 card and replay it on my FF-DVB-S card. I also successfully tested recording encrypted DVB-S channels with the TT-S2-3200, so apparently CAM handling also works with that card.
*When reporting problems, please don't reply to this message!* Create a new thread instead, using a descriptive subject!
Have fun!
Klaus
Klaus Schmidinger wrote:
- Implemented handling of DVB-S2 (thanks to Marco Schlüßler and Reinhald Nissl for a patch that was used to implement this). VDR now requires the "multiproto" DVB driver, e.g. from http://jusst.de/hg/multiproto.
Would it be possible to make that optional via compile time define?
cu Ludwig
On 01/27/08 16:25, Ludwig Nussel wrote:
Klaus Schmidinger wrote:
- Implemented handling of DVB-S2 (thanks to Marco Schlüßler and Reinhald Nissl for a patch that was used to implement this). VDR now requires the "multiproto" DVB driver, e.g. from http://jusst.de/hg/multiproto.
Would it be possible to make that optional via compile time define?
I guess so, but I'm not going to ;-) This new driver appears to be stable enough now - at least I've been using it for a few days now without problems.
Klaus
I guess so, but I'm not going to ;-) This new driver appears to be stable enough now - at least I've been using it for a few days now without problems.
The new driver is fine, but what you might find is that new card and features being released into the stock v4l mercurial tree aren't being backported into multiproto - its been fairly static for awhile.
Hopefully your move toward multiproto might kickstart a move towards widespread adoption (i.e. integration with the development tree) and then eventually into the kernel itself.
Still, I'm pleased that VDR now supports S2 "out of the box", shame it doesn't support h264 by default yet though! ;-)
On 01/27/08 16:44, Morfsta wrote:
I guess so, but I'm not going to ;-) This new driver appears to be stable enough now - at least I've been using it for a few days now without problems.
The new driver is fine, but what you might find is that new card and features being released into the stock v4l mercurial tree aren't being backported into multiproto - its been fairly static for awhile.
Hopefully your move toward multiproto might kickstart a move towards widespread adoption (i.e. integration with the development tree) and then eventually into the kernel itself.
I really hope I'll live to see the day when we have *one* DVB driver again.
Still, I'm pleased that VDR now supports S2 "out of the box", shame it doesn't support h264 by default yet though! ;-)
One step at a time...
Klaus
Morfsta wrote:
I guess so, but I'm not going to ;-) This new driver appears to be stable enough now - at least I've been using it for a few days now without problems.
The new driver is fine, but what you might find is that new card and features being released into the stock v4l mercurial tree aren't being backported into multiproto - its been fairly static for awhile.
I have pushed out a tree which is now a merged version of v4l-dvb and the multiproto trees and is available at http://jusst.de/hg/multiproto (As of now, insufficient tests, after the merge, please test)
A point to note is that, in the build (for me 2.6.21) the stk-webcam in the v4l-dvb tree was broken and hence is broken in the updated multiproto tree as well.
You will need to disable the stk-webcam build in that tree, in case you are using an older kernel.
Regards, Manu
Manu,
Firstly, thanks for all your work - it's appreciated.
Is the interface working properly for reading the signal strength, BER and status?
The rotor plugin doesnt return anything and I can't get anything out of VDR-Femon.
Is it working OK with the TT 3200?
BTW I have a TT3200 on order so I can compare the difference between the two cards soon.
Regards,
Morfsta
On Jan 28, 2008 1:46 AM, Manu Abraham abraham.manu@gmail.com wrote:
Morfsta wrote:
I guess so, but I'm not going to ;-) This new driver appears to be stable enough now - at least I've been using it for a few days now without problems.
The new driver is fine, but what you might find is that new card and features being released into the stock v4l mercurial tree aren't being backported into multiproto - its been fairly static for awhile.
I have pushed out a tree which is now a merged version of v4l-dvb and the multiproto trees and is available at http://jusst.de/hg/multiproto (As of now, insufficient tests, after the merge, please test)
A point to note is that, in the build (for me 2.6.21) the stk-webcam in the v4l-dvb tree was broken and hence is broken in the updated multiproto tree as well.
You will need to disable the stk-webcam build in that tree, in case you are using an older kernel.
Regards, Manu
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Morfsta wrote:
Manu,
Firstly, thanks for all your work - it's appreciated.
Is the interface working properly for reading the signal strength, BER and status?
Currently, there is a small confusion. Most drivers in kernel, just report some crap as signal strength, snr etc.
For the STB0899, STM helped so much, alongwith i had some help from one of the Newtec guys, we were able to get the statistics in some proper form, currently a dBm/10 scale is used.
Since this scale is different from the in kernel existing scale of randomness to a standardized one, currently this change might look a bit nonsense to you as it will report different signal statistics as reported by the API.
There will be a need to add one more ioctl, where the user can request the driver to provide the statistics in a relative scale or an absolute scale which can be used for measurements too.
The result would be that and end application can display the statistics like any other commercial STB, in a nice and beautiful way, while being quite accurate (depending on the driver) without any hacks or workarounds to be \ done in the application
(The statistics that you get is very much device specific and not device independant and hence is not very easy for a user application to get proper statistics as of now)
With the change, all statistics related operations can be implemented within the driver such that the user is presented with standard and uniform statistics across multiple devices without the need to do device specific code as done by MythTV etc, where it looks for specific device drivers (really ugly)
The rotor plugin doesnt return anything and I can't get anything out of VDR-Femon.
Is it working OK with the TT 3200?
The statistics is working with the STB0899, maybe i didn't follow what exactly you are looking at. If you can detail a bit, it would be much more helpful. The STB0899 supports TT S2 3200, KNC1 DVB-S2+, KNC1 DVB-S2, Pinnacle PCTV 450e and the VP-1041 as of now and the same signal related stuff is applicable to all.
BTW I have a TT3200 on order so I can compare the difference between the two cards soon.
Currently, the STB0899 is _not_ calibrated for actual statistics. I have requested Azurewave for some sample devices to be sent to STM for proper calibration of the LUT's for the statistics. (Most probably, tomorrow or so STM will receive the samples at Grenoble)
Regards, Manu
Manu
will be possibility to receive from driver the raw statistic, too ?
Igor
-----Original Message----- From: Manu Abraham abraham.manu@gmail.com To: VDR Mailing List vdr@linuxtv.org Date: Mon, 28 Jan 2008 22:22:58 +0400 Subject: Re: [vdr] Multiproto updated Re: [ANNOUNCE] VDR developer version1.5.14
Morfsta wrote:
Manu,
Firstly, thanks for all your work - it's appreciated.
Is the interface working properly for reading the signal strength, BER and status?
Currently, there is a small confusion. Most drivers in kernel, just report some crap as signal strength, snr etc.
For the STB0899, STM helped so much, alongwith i had some help from one of the Newtec guys, we were able to get the statistics in some proper form, currently a dBm/10 scale is used.
Since this scale is different from the in kernel existing scale of randomness to a standardized one, currently this change might look a bit nonsense to you as it will report different signal statistics as reported by the API.
There will be a need to add one more ioctl, where the user can request the driver to provide the statistics in a relative scale or an absolute scale which can be used for measurements too.
The result would be that and end application can display the statistics like any other commercial STB, in a nice and beautiful way, while being quite accurate (depending on the driver) without any hacks or workarounds to be \ done in the application
(The statistics that you get is very much device specific and not device independant and hence is not very easy for a user application to get proper statistics as of now)
With the change, all statistics related operations can be implemented within the driver such that the user is presented with standard and uniform statistics across multiple devices without the need to do device specific code as done by MythTV etc, where it looks for specific device drivers (really ugly)
The rotor plugin doesnt return anything and I can't get anything out of VDR-Femon.
Is it working OK with the TT 3200?
The statistics is working with the STB0899, maybe i didn't follow what exactly you are looking at. If you can detail a bit, it would be much more helpful. The STB0899 supports TT S2 3200, KNC1 DVB-S2+, KNC1 DVB-S2, Pinnacle PCTV 450e and the VP-1041 as of now and the same signal related stuff is applicable to all.
BTW I have a TT3200 on order so I can compare the difference between the two cards soon.
Currently, the STB0899 is _not_ calibrated for actual statistics. I have requested Azurewave for some sample devices to be sent to STM for proper calibration of the LUT's for the statistics. (Most probably, tomorrow or so STM will receive the samples at Grenoble)
Igor wrote:
Manu
will be possibility to receive from driver the raw statistic, too ?
As of now, the STB0899 get's the raw statistics does processing and the processed details are sent to the application.
It's possible to get the same, what you mentioned, just that the mentioned ioctl needs to be in there. The relative scale would be just raw statistics (unprocessed)
Regards, Manu
Igor
-----Original Message----- From: Manu Abraham abraham.manu@gmail.com To: VDR Mailing List vdr@linuxtv.org Date: Mon, 28 Jan 2008 22:22:58 +0400 Subject: Re: [vdr] Multiproto updated Re: [ANNOUNCE] VDR developer version1.5.14
Morfsta wrote:
Manu,
Firstly, thanks for all your work - it's appreciated.
Is the interface working properly for reading the signal strength, BER and status?
Currently, there is a small confusion. Most drivers in kernel, just report some crap as signal strength, snr etc.
For the STB0899, STM helped so much, alongwith i had some help from one of the Newtec guys, we were able to get the statistics in some proper form, currently a dBm/10 scale is used.
Since this scale is different from the in kernel existing scale of randomness to a standardized one, currently this change might look a bit nonsense to you as it will report different signal statistics as reported by the API.
There will be a need to add one more ioctl, where the user can request the driver to provide the statistics in a relative scale or an absolute scale which can be used for measurements too.
The result would be that and end application can display the statistics like any other commercial STB, in a nice and beautiful way, while being quite accurate (depending on the driver) without any hacks or workarounds to be \ done in the application
(The statistics that you get is very much device specific and not device independant and hence is not very easy for a user application to get proper statistics as of now)
With the change, all statistics related operations can be implemented within the driver such that the user is presented with standard and uniform statistics across multiple devices without the need to do device specific code as done by MythTV etc, where it looks for specific device drivers (really ugly)
The rotor plugin doesnt return anything and I can't get anything out of VDR-Femon.
Is it working OK with the TT 3200?
The statistics is working with the STB0899, maybe i didn't follow what exactly you are looking at. If you can detail a bit, it would be much more helpful. The STB0899 supports TT S2 3200, KNC1 DVB-S2+, KNC1 DVB-S2, Pinnacle PCTV 450e and the VP-1041 as of now and the same signal related stuff is applicable to all.
BTW I have a TT3200 on order so I can compare the difference between the two cards soon.
Currently, the STB0899 is _not_ calibrated for actual statistics. I have requested Azurewave for some sample devices to be sent to STM for proper calibration of the LUT's for the statistics. (Most probably, tomorrow or so STM will receive the samples at Grenoble)
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Klaus Schmidinger wrote:
On 01/27/08 16:25, Ludwig Nussel wrote:
Klaus Schmidinger wrote:
- Implemented handling of DVB-S2 (thanks to Marco Schlüßler and Reinhald Nissl for a patch that was used to implement this). VDR now requires the "multiproto" DVB driver, e.g. from http://jusst.de/hg/multiproto.
Would it be possible to make that optional via compile time define?
I guess so, but I'm not going to ;-) This new driver appears to be stable enough now - at least I've been using it for a few days now without problems.
*sigh* messing with kernel stuff sucks. Does a vdr built with the multiproto headers at least also work on vanilla kernels ie stable dvb drivers? That way one would only need to use different headers for building vdr but no extra kernel modules at run time.
cu Ludwig
On 01/27/08 16:54, Ludwig Nussel wrote:
Klaus Schmidinger wrote:
On 01/27/08 16:25, Ludwig Nussel wrote:
Klaus Schmidinger wrote:
- Implemented handling of DVB-S2 (thanks to Marco Schlüßler and Reinhald Nissl for a patch that was used to implement this). VDR now requires the "multiproto" DVB driver, e.g. from http://jusst.de/hg/multiproto.
Would it be possible to make that optional via compile time define?
I guess so, but I'm not going to ;-) This new driver appears to be stable enough now - at least I've been using it for a few days now without problems.
*sigh* messing with kernel stuff sucks. Does a vdr built with the multiproto headers at least also work on vanilla kernels ie stable dvb drivers? That way one would only need to use different headers for building vdr but no extra kernel modules at run time.
I don't know. I just grab the latest driver from http://jusst.de/hg/multiproto and compile it on my SUSE 10.3 system, running the stock SUSE kernel. So just unload all DVB modules that come with the stock kernel and load the ones from the multiproto driver. Works fine for me.
Maybe the fact that VDR now requires the multiproto driver will finally make the various driver branches come together to *one* DVB driver again.
Well, one can at least dream...
Klaus
Klaus Schmidinger wrote:
On 01/27/08 16:54, Ludwig Nussel wrote:
Klaus Schmidinger wrote:
On 01/27/08 16:25, Ludwig Nussel wrote:
Klaus Schmidinger wrote:
- Implemented handling of DVB-S2 (thanks to Marco Schlüßler and Reinhald Nissl for a patch that was used to implement this). VDR now requires the "multiproto" DVB driver, e.g. from http://jusst.de/hg/multiproto.
Would it be possible to make that optional via compile time define?
I guess so, but I'm not going to ;-) This new driver appears to be stable enough now - at least I've been using it for a few days now without problems.
*sigh* messing with kernel stuff sucks. Does a vdr built with the multiproto headers at least also work on vanilla kernels ie stable dvb drivers? That way one would only need to use different headers for building vdr but no extra kernel modules at run time.
I don't know. I just grab the latest driver from http://jusst.de/hg/multiproto and compile it on my SUSE 10.3 system, running the stock SUSE kernel. So just unload all DVB modules that come with the stock kernel and load the ones from the multiproto driver. Works fine for me.
Works fine now, breaks tomorrow. We had the dvb kernel module package long enough and I was so glad when the dvb drivers finally went into the upstream kernel. I'm not going to maintain another kernel module package again.
I just tried a vdr built with the multiproto headers with normal dvb drivers. Doesn't work. That means vdr 1.5.13 is the last version I can build useful packages for atm.
cu Ludwig
* Ludwig Nussel schrieb am 27.01.08, um 17:35 Uhr:
Works fine now, breaks tomorrow. We had the dvb kernel module package long enough and I was so glad when the dvb drivers finally went into the upstream kernel. I'm not going to maintain another kernel module package again.
The same applies for Debian, i was very, very happy when we dropped the dvb-modules-package from the archive and i do not intend to create a package for any (unofficial) kernel module again. (Especially one which could conflict with kernel-modules a official distribution-kernel may ship.)
In the current state, it would not be possible for Debian to ship a vdr version > 1.5.13 in the official archive.
Currently it is not urgent for me as we do not package vdr 1.5.x for the official archive (yet), but i am sure that this change is causing a lot problems for Thomas Günther who provides unofficial packages for 1.5.x.
I really hope that either vdr 1.5.x gets a compile-time-switch to build and run with the vanilla kernel-sources or even better that the multiproto-drivers will be merged into the mainline kernel soon.
Regards, Thomas
Thomas Schmidt wrote: ...
In the current state, it would not be possible for Debian to ship a vdr version > 1.5.13 in the official archive.
But that's acceptable, considering that VDR 1.5.14 is a developer version, not a stable version which is intended to go into a distribution, right?
Lets just hope that kernel DVB and VDR 1.6.0 will be compatible when VDR 1.6.0 comes out. :-)
Carsten.
* Carsten Koch schrieb am 27.01.08, um 17:56 Uhr:
In the current state, it would not be possible for Debian to ship a vdr version > 1.5.13 in the official archive.
But that's acceptable, considering that VDR 1.5.14 is a developer version, not a stable version which is intended to go into a distribution, right?
Yes, of course, i do not plan to upload a developer version into debian unstable unless a release of vdr 1.6.0 is at least somewhere near the horizon. :)
We allready had requests to upload vdr 1.5.x to debian experimental but vdr 1.5.14 is one good argument more for the decision not to do this in the current state of development.
Lets just hope that kernel DVB and VDR 1.6.0 will be compatible when VDR 1.6.0 comes out. :-)
Yes, this would be really helpful. ;-)
Regards, Thomas
On 01/27/08 17:46, Thomas Schmidt wrote:
- Ludwig Nussel schrieb am 27.01.08, um 17:35 Uhr:
Works fine now, breaks tomorrow. We had the dvb kernel module package long enough and I was so glad when the dvb drivers finally went into the upstream kernel. I'm not going to maintain another kernel module package again.
The same applies for Debian, i was very, very happy when we dropped the dvb-modules-package from the archive and i do not intend to create a package for any (unofficial) kernel module again. (Especially one which could conflict with kernel-modules a official distribution-kernel may ship.)
In the current state, it would not be possible for Debian to ship a vdr version > 1.5.13 in the official archive.
Currently it is not urgent for me as we do not package vdr 1.5.x for the official archive (yet), but i am sure that this change is causing a lot problems for Thomas Günther who provides unofficial packages for 1.5.x.
I really hope that either vdr 1.5.x gets a compile-time-switch to build and run with the vanilla kernel-sources or even better that the multiproto-drivers will be merged into the mainline kernel soon.
The latter would be the reasonable step to take, IMHO. Having these different DVB driver branches is something that should end as soon as possible.
Klaus
Klaus Schmidinger wrote:
On 01/27/08 17:46, Thomas Schmidt wrote:
I really hope that either vdr 1.5.x gets a compile-time-switch to build and run with the vanilla kernel-sources or even better that the multiproto-drivers will be merged into the mainline kernel soon.
The latter would be the reasonable step to take, IMHO. Having these different DVB driver branches is something that should end as soon as possible.
Even then distros and kernels of today won't work with newer vdr versions so an option to use the 'old' kernel interface would certainly be appreciated.
cu Ludwig
Klaus Schmidinger wrote:
On 01/27/08 17:46, Thomas Schmidt wrote:
I really hope that either vdr 1.5.x gets a compile-time-switch to build and run with the vanilla kernel-sources or even better that the multiproto-drivers will be merged into the mainline kernel soon.
The latter would be the reasonable step to take, IMHO. Having these different DVB driver branches is something that should end as soon as possible.
The drivers can be merged in to the kernel after quite some tests.
With regards to both the S2 capable drivers there are enough bug reports open. I am not of the opinion of merging drivers while open bug reports still do exist. (You can look at the linux-dvb ML for the same) For both the drivers, many people can say it works for me, but not for everyone.
That said, currently the tree is up to v4l-dvb head and the current kernel merge window is open for 2.6.25, which will be open for some few days more. With the current state, it cannot be merged in for 2.6.25.
Most probably we might be able to make it for 2.6.26 if all goes well. This requires lot more testing and fixing etc.
The current state of different branches (distributed repositories) was the option chosen when Johannes merged the trees and was his decision. Most probably, that will remain the same for quite a long time to come.
Regards, Manu
On 01/28/08 03:01, Manu Abraham wrote:
Klaus Schmidinger wrote:
On 01/27/08 17:46, Thomas Schmidt wrote:
I really hope that either vdr 1.5.x gets a compile-time-switch to build and run with the vanilla kernel-sources or even better that the multiproto-drivers will be merged into the mainline kernel soon.
The latter would be the reasonable step to take, IMHO. Having these different DVB driver branches is something that should end as soon as possible.
The drivers can be merged in to the kernel after quite some tests.
With regards to both the S2 capable drivers there are enough bug reports open. I am not of the opinion of merging drivers while open bug reports still do exist. (You can look at the linux-dvb ML for the same) For both the drivers, many people can say it works for me, but not for everyone.
That said, currently the tree is up to v4l-dvb head and the current kernel merge window is open for 2.6.25, which will be open for some few days more. With the current state, it cannot be merged in for 2.6.25.
Most probably we might be able to make it for 2.6.26 if all goes well. This requires lot more testing and fixing etc.
The current state of different branches (distributed repositories) was the option chosen when Johannes merged the trees and was his decision. Most probably, that will remain the same for quite a long time to come.
Just so I understand this correctly: the driver that is currently in the kernel is *not* able to do DVB-S2, while the driver at http://jusst.de/hg/multiproto *is* able to do it. And these are the only two driver versions we're talking about here, right?
So, if the kernel driver can't do DVB-S2, it will probably become obsolete pretty soon, at least for those who want to receive DVB-S2 channels.
Maybe making VDR require the "multiproto" driver actually gives this driver the necessary boost to be sufficiently tested so that it can be merged into the kernel in the not so far future... ;-)
Klaus
On Mon, Jan 28, 2008 at 01:40:15PM +0100, Klaus Schmidinger wrote:
Just so I understand this correctly: the driver that is currently in the kernel is *not* able to do DVB-S2, while the driver at http://jusst.de/hg/multiproto *is* able to do it. And these are the only two driver versions we're talking about here, right?
So, if the kernel driver can't do DVB-S2, it will probably become obsolete pretty soon, at least for those who want to receive DVB-S2 channels.
Maybe making VDR require the "multiproto" driver actually gives this driver the necessary boost to be sufficiently tested so that it can be merged into the kernel in the not so far future... ;-)
Klaus, you read my mind ;-)
Thank you very much,
Klaus Schmidinger wrote:
On 01/28/08 03:01, Manu Abraham wrote:
Klaus Schmidinger wrote:
On 01/27/08 17:46, Thomas Schmidt wrote:
I really hope that either vdr 1.5.x gets a compile-time-switch to build and run with the vanilla kernel-sources or even better that the multiproto-drivers will be merged into the mainline kernel soon.
The latter would be the reasonable step to take, IMHO. Having these different DVB driver branches is something that should end as soon as possible.
The drivers can be merged in to the kernel after quite some tests.
With regards to both the S2 capable drivers there are enough bug reports open. I am not of the opinion of merging drivers while open bug reports still do exist. (You can look at the linux-dvb ML for the same) For both the drivers, many people can say it works for me, but not for everyone.
That said, currently the tree is up to v4l-dvb head and the current kernel merge window is open for 2.6.25, which will be open for some few days more. With the current state, it cannot be merged in for 2.6.25.
Most probably we might be able to make it for 2.6.26 if all goes well. This requires lot more testing and fixing etc.
The current state of different branches (distributed repositories) was the option chosen when Johannes merged the trees and was his decision. Most probably, that will remain the same for quite a long time to come.
Just so I understand this correctly: the driver that is currently in the kernel is *not* able to do DVB-S2, while the driver at http://jusst.de/hg/multiproto *is* able to do it. And these are the only two driver versions we're talking about here, right?
Umm.. Let me put it this way.
Currently in kernel, everything is defined in terms of modulation. This won't hold good with newer stuff coming up. Newer stuff (devices) can have a single modulation type or multiple modulation types (when looking at a single device itself)
For example:
In kernel as of now, DVB-S is represented by QPSK (This is in fact slightly wrong. DVB-S can use QPSK or BPSK)
Next: for DVB-S2 there is no representation as it is for it in kernel (atm), since DVB-S2 can be 32APSK, 16APSK, 8PSK or QPSK
Also there is another satellite delivery system called DSS which can use BPSK and or QPSK
Another very important aspect is that you can't define DVB-S2 as 8PSK modulation, since there is yet another broadcast system (In the US) which uses DVB-S framing and 8PSK modulation. The important part is that, as you see this has no DVB-S2 framing, but also that instead of the BCH/LDPC for FEC, it uses Turbo Codes.
So, as you see in the 3 cases, having a FE_HAS_QPSK is not enough to define a delivery system, whereas you a need a tag for a collective set of modulations, similar to DVB-T (OFDM) where you have different modulations again.
So eventually: as you see, you can't access a delivery system by a modulation type.
As of now, there are 2 Linux DVB drivers which are DVB-S2 capable * STB0899 (Supports: BPSK, QPSK, 8PSK, 16APSK, 32APSK) * CX24116 (Supports: BPSK, QPSK, 8PSK)
(You might remember the old modulation discussions we had a long time back)
Two more newer DVB-S2 devices that are expected to be supported under Linux are the STV0900 and the STV0903.
Currently, the multiproto tree has the delivery system definitions, such as DVB-S, DVB-S2, .. ..
The drivers which make use of these delivery systems, makes use of the API changes held in there.
So, if the kernel driver can't do DVB-S2, it will probably become obsolete pretty soon, at least for those who want to receive DVB-S2 channels.
True. Not only for DVB-S2, There are other stuff coming out, which will need the multiproto API changes, such as for the newer parameters, which are required for DVB-H. Also additionally we have reserved space for more newer delivery systems such as DVB-C2, DVB-T2 (which will be coming out in a few years) also the existing DMB-T/H delivery system can be added in as well, with much ease, without having the old issues that were visited during the API discussion period.
Other than this, there are some quirks with the current in kernel API such as with regards to DVB-T, that you can't select a Low priority stream. Also for DVB-H, you will need additional parameters. So eventually, it is high time that the in kernel API needs a face lift.
Maybe making VDR require the "multiproto" driver actually gives this driver the necessary boost to be sufficiently tested so that it can be merged into the kernel in the not so far future... ;-)
:) Definitely: Lot of testing is required and user complaints to get things moving in the right direction.
Regards, Manu
On Sun, 27 Jan 2008 16:58:26 +0100 Klaus Schmidinger Klaus.Schmidinger@cadsoft.de wrote:
I don't know. I just grab the latest driver from http://jusst.de/hg/multiproto and compile it on my SUSE 10.3 system, running the stock SUSE kernel. So just unload all DVB modules that come with the stock kernel and load the ones from the multiproto driver. Works fine for me.
Well, multiproto doesn't even compile on a current (2.6.24) kernel .. or I am doing something really wrong.
On Sun, Jan 27, 2008 at 08:32:53PM +0100, Malte Schröder wrote:
Well, multiproto doesn't even compile on a current (2.6.24) kernel .. or I am doing something really wrong.
Well, the VDR community is quiete large, then we'll could make things go to a better situation, from my point of view, we'll have to include multiproto into kernel directly.
I have tried to compil it againt zen kernels, which are certainly very well suited for multimedia :
http://forums.gentoo.org/viewtopic-t-616535-highlight-.html http://forums.gentoo.org/viewtopic-t-641834-postdays-0-postorder-asc-start-0... http://repo.or.cz/w/linux-2.6/zen-sources.git http://zen-sources.org/ http://zen-sources.org/project/issues
I failed... but they are so many people more knwoledged than me...
Ludwig Nussel wrote:
Klaus Schmidinger wrote:
On 01/27/08 16:25, Ludwig Nussel wrote:
Klaus Schmidinger wrote:
- Implemented handling of DVB-S2 (thanks to Marco Schlüßler and Reinhald Nissl for a patch that was used to implement this). VDR now requires the "multiproto" DVB driver, e.g. from http://jusst.de/hg/multiproto.
Would it be possible to make that optional via compile time define?
I guess so, but I'm not going to ;-) This new driver appears to be stable enough now - at least I've been using it for a few days now without problems.
*sigh* messing with kernel stuff sucks. Does a vdr built with the multiproto headers at least also work on vanilla kernels ie stable dvb drivers? That way one would only need to use different headers for building vdr but no extra kernel modules at run time.
AFAICT, the updated headers can be used along with the old drivers without any issues. If not there's an issue with regards to backward compatibility. Can you pleas point out the errors that which you see, when you are using the updated headers and the old drivers ?
Regards, Manu
Manu Abraham wrote:
Ludwig Nussel wrote:
Klaus Schmidinger wrote:
On 01/27/08 16:25, Ludwig Nussel wrote:
Klaus Schmidinger wrote:
- Implemented handling of DVB-S2 (thanks to Marco Schlüßler and Reinhald Nissl for a patch that was used to implement this). VDR now requires the "multiproto" DVB driver, e.g. from http://jusst.de/hg/multiproto.
Would it be possible to make that optional via compile time define?
I guess so, but I'm not going to ;-) This new driver appears to be stable enough now - at least I've been using it for a few days now without problems.
*sigh* messing with kernel stuff sucks. Does a vdr built with the multiproto headers at least also work on vanilla kernels ie stable dvb drivers? That way one would only need to use different headers for building vdr but no extra kernel modules at run time.
AFAICT, the updated headers can be used along with the old drivers without any issues. If not there's an issue with regards to backward compatibility. Can you pleas point out the errors that which you see, when you are using the updated headers and the old drivers ?
I just did a quick test and didn't debug it further. IIRC the only vdr error message was an error from the DVBFE_GET_DELSYS ioctl.
cu Ludwig
On 01/28/08 02:49, Manu Abraham wrote:
Ludwig Nussel wrote:
Klaus Schmidinger wrote:
On 01/27/08 16:25, Ludwig Nussel wrote:
Klaus Schmidinger wrote:
- Implemented handling of DVB-S2 (thanks to Marco Schlüßler and Reinhald Nissl for a patch that was used to implement this). VDR now requires the "multiproto" DVB driver, e.g. from http://jusst.de/hg/multiproto.
Would it be possible to make that optional via compile time define?
I guess so, but I'm not going to ;-) This new driver appears to be stable enough now - at least I've been using it for a few days now without problems.
*sigh* messing with kernel stuff sucks. Does a vdr built with the multiproto headers at least also work on vanilla kernels ie stable dvb drivers? That way one would only need to use different headers for building vdr but no extra kernel modules at run time.
AFAICT, the updated headers can be used along with the old drivers without any issues. If not there's an issue with regards to backward compatibility. Can you pleas point out the errors that which you see, when you are using the updated headers and the old drivers ?
The new headers work fine with the old driver - if the application still uses the old API. I've tested that first thing before I switched to the new API.
However, I don't see how an application actually using the new API could work with the old driver.
At any rate, the patch from Ulrich Richter should work for people insisting to use the old driver.
Klaus
On 01/28/08 18:15, Klaus Schmidinger wrote:
On 01/28/08 02:49, Manu Abraham wrote:
Ludwig Nussel wrote:
Klaus Schmidinger wrote:
On 01/27/08 16:25, Ludwig Nussel wrote:
Klaus Schmidinger wrote:
- Implemented handling of DVB-S2 (thanks to Marco Schlüßler and Reinhald Nissl for a patch that was used to implement this). VDR now requires the "multiproto" DVB driver, e.g. from http://jusst.de/hg/multiproto.
Would it be possible to make that optional via compile time define?
I guess so, but I'm not going to ;-) This new driver appears to be stable enough now - at least I've been using it for a few days now without problems.
*sigh* messing with kernel stuff sucks. Does a vdr built with the multiproto headers at least also work on vanilla kernels ie stable dvb drivers? That way one would only need to use different headers for building vdr but no extra kernel modules at run time.
AFAICT, the updated headers can be used along with the old drivers without any issues. If not there's an issue with regards to backward compatibility. Can you pleas point out the errors that which you see, when you are using the updated headers and the old drivers ?
The new headers work fine with the old driver - if the application still uses the old API. I've tested that first thing before I switched to the new API.
However, I don't see how an application actually using the new API could work with the old driver.
At any rate, the patch from Ulrich Richter should work for people
Sorry, that should have been "Udo".
Klaus
insisting to use the old driver.
Klaus
Klaus Schmidinger wrote:
On 01/28/08 02:49, Manu Abraham wrote:
Ludwig Nussel wrote:
Klaus Schmidinger wrote:
On 01/27/08 16:25, Ludwig Nussel wrote:
Klaus Schmidinger wrote:
- Implemented handling of DVB-S2 (thanks to Marco Schlüßler and Reinhald Nissl for a patch that was used to implement this). VDR now requires the "multiproto" DVB driver, e.g. from http://jusst.de/hg/multiproto.
Would it be possible to make that optional via compile time define?
I guess so, but I'm not going to ;-) This new driver appears to be stable enough now - at least I've been using it for a few days now without problems.
*sigh* messing with kernel stuff sucks. Does a vdr built with the multiproto headers at least also work on vanilla kernels ie stable dvb drivers? That way one would only need to use different headers for building vdr but no extra kernel modules at run time.
AFAICT, the updated headers can be used along with the old drivers without any issues. If not there's an issue with regards to backward compatibility. Can you pleas point out the errors that which you see, when you are using the updated headers and the old drivers ?
The new headers work fine with the old driver - if the application still uses the old API. I've tested that first thing before I switched to the new API.
However, I don't see how an application actually using the new API could work with the old driver.
In the idea that i had, it would look for the API version and issue the ioctls as necessary, similar to what i used in the szap hack. (It was just a hack, for some testing as well as demonstrating the API usage) The hacked szap is here: http://abraham.manu.googlepages.com/szap.c
At any rate, the patch from Ulrich Richter should work for people insisting to use the old driver.
Regards, Manu
Manu Abraham wrote:
Klaus Schmidinger wrote:
On 01/28/08 02:49, Manu Abraham wrote:
Ludwig Nussel wrote:
Klaus Schmidinger wrote:
On 01/27/08 16:25, Ludwig Nussel wrote:
Klaus Schmidinger wrote: > - Implemented handling of DVB-S2 (thanks to Marco Schlüßler and > Reinhald Nissl > for a patch that was used to implement this). VDR now requires > the "multiproto" > DVB driver, e.g. from http://jusst.de/hg/multiproto. Would it be possible to make that optional via compile time define?
I guess so, but I'm not going to ;-) This new driver appears to be stable enough now - at least I've been using it for a few days now without problems.
*sigh* messing with kernel stuff sucks. Does a vdr built with the multiproto headers at least also work on vanilla kernels ie stable dvb drivers? That way one would only need to use different headers for building vdr but no extra kernel modules at run time.
AFAICT, the updated headers can be used along with the old drivers without any issues. If not there's an issue with regards to backward compatibility. Can you pleas point out the errors that which you see, when you are using the updated headers and the old drivers ?
The new headers work fine with the old driver - if the application still uses the old API. I've tested that first thing before I switched to the new API.
However, I don't see how an application actually using the new API could work with the old driver.
In the idea that i had, it would look for the API version and issue the ioctls as necessary, similar to what i used in the szap hack. (It was just a hack, for some testing as well as demonstrating the API usage) The hacked szap is here: http://abraham.manu.googlepages.com/szap.c
Forgot one thing to mention,
The application issues the new ioctls, the dvb-core takes those parameters and converts it into the old format and passes it to the old driver. This way, a driver written the old way will also work, just that it involves a thin layer of translation, also misses some of the newer features introduced.
Another major change in the old -> new driver concept is that, the old drivers were all forced to do a stupid software zigzag, even for hardware that doesn't require it. With the new interface, you can define your custom algorithm in the driver itself, such that it performs really well, just similar to properly written drivers, rather than reverse engineered device drivers.
If you think that your driver needs to be lean and mean, then the new interface is the way to go.
In any case, to make the utmost use of all the features, still you need to know a lot about your hardware, to do that. In fact the more ideas you have, you can implement, unlike the case with the old interface, that even if you know what to do, there was no way to do it, without stripping away quite a lot of fat which will cause another flaming thread for some few years.
Regards, Manu
*sigh* messing with kernel stuff sucks. Does a vdr built with the multiproto headers at least also work on vanilla kernels ie stable dvb drivers? That way one would only need to use different headers for building vdr but no extra kernel modules at run time.
so, what do you mean - "updated multiproto headers" - are the version.h and frontend.h ? only this two files Manu have changed in multiproto.
Igor
AFAICT, the updated headers can be used along with the old drivers without any issues. If not there's an issue with regards to backward compatibility. Can you pleas point out the errors that which you see, when you are using the updated headers and the old drivers ?
The new headers work fine with the old driver - if the application still uses the old API. I've tested that first thing before I switched to the new API.
However, I don't see how an application actually using the new API could work with the old driver.
At any rate, the patch from Ulrich Richter should work for people insisting to use the old driver.
On 28 Jan 2008 Klaus Schmidinger Klaus.Schmidinger@cadsoft.de wrote:
On 01/27/08 16:25, Ludwig Nussel wrote:
Klaus Schmidinger wrote:
- Implemented handling of DVB-S2 (thanks to Marco Schlüßler and Reinhald Nissl for a patch that was used to implement this). VDR now requires the "multiproto" DVB driver, e.g. from http://jusst.de/hg/multiproto.
Would it be possible to make that optional via compile time define?
I guess so, but I'm not going to ;-) This new driver appears to be stable enough now - at least I've been using it for a few days now without problems.
I don't know if there are many people left, but I'm still working with a 2.4.x kernel and cannot use the new drivers (neither HG nor multiproto). This way I'm effectively looked out from VDR...
I would really appreciate a backward compatibility option.
Regards.
On Jan 27, 2008 9:03 AM, Stefan Huelswitt s.huelswitt@gmx.de wrote:
I don't know if there are many people left, but I'm still working with a 2.4.x kernel and cannot use the new drivers (neither HG nor multiproto). This way I'm effectively looked out from VDR...
I would really appreciate a backward compatibility option.
This begs to ask... Why not just upgrade your kernel? There will always be some give & take with updating but that's not necessarily a bad thing.
Hi,
Klaus Schmidinger wrote:
- Implemented handling of DVB-S2 (thanks to Marco Schlüßler and Reinhald Nissl for a patch that was used to implement this). VDR now requires the "multiproto" DVB driver, e.g. from http://jusst.de/hg/multiproto.
if I have only two normal DVB-S cards (one rev 1.3 and one 2.1) can I or must I use that driver too?
Best regards, Matthias
On 01/28/08 17:50, Matthias Fechner wrote:
Hi,
Klaus Schmidinger wrote:
- Implemented handling of DVB-S2 (thanks to Marco Schlüßler and Reinhald Nissl for a patch that was used to implement this). VDR now requires the "multiproto" DVB driver, e.g. from http://jusst.de/hg/multiproto.
if I have only two normal DVB-S cards (one rev 1.3 and one 2.1) can I or must I use that driver too?
If you want to use VDR >= 1.5.14 "as is", you need to use the new driver. With Udo Richter's patch it should be possible to still use the old driver.
Klaus
Hi,
Klaus Schmidinger schrieb:
If you want to use VDR >= 1.5.14 "as is", you need to use the new driver. With Udo Richter's patch it should be possible to still use the old driver.
is there a manual available which explain who to compile all the packages. I tried it yesterday but I always get the error message: dvbdevice.h:19:2: Fehler: #error VDR requires Linux DVB driver API version 3.3!
The new driver was installed.
Best regards, Matthias
is there a manual available which explain who to compile all the packages.
no, I don't know about this manual
I tried it yesterday but I always get the error message: dvbdevice.h:19:2: Fehler: #error VDR requires Linux DVB driver API version 3.3!
please, try to copy the files
from
/multiproto/linux/include/linux/dvb/version.h /multiproto/linux/include/linux/dvb/frontend.h
to
/usr/include/linux/dvb
and recompile the VDR
Igor
Hi,
Igor wrote:
please, try to copy the files
from
/multiproto/linux/include/linux/dvb/version.h /multiproto/linux/include/linux/dvb/frontend.h
to
/usr/include/linux/dvb
and recompile the VDR
ok it was really a -I Problem with the compile process. I edited the Make.config but vdr doesn't seems to use it: DVBDIR = /usr/local/src/multiproto/multiproto/linux/
I modified now the Makefile and added the following lines after the include of the conf file: ifdef DVBDIR INCLUDES += -I$(DVBDIR)/include endif
For plugins which are using the headerfiles from the new driver I had to add the three lines too.
Is that a bug in the VDR Makefile?
Best regards, Matthias
On Tuesday 29 January 2008, Matthias Fechner wrote:
I modified now the Makefile and added the following lines after the include of the conf file: ifdef DVBDIR INCLUDES += -I$(DVBDIR)/include endif
For plugins which are using the headerfiles from the new driver I had to add the three lines too.
Is that a bug in the VDR Makefile?
No, for such purposes there is Make.config.template which should be copied to Make.config (see doc).
After line ### You don't need to touch the following:
add something like (depends on your configuration)
DVBDIR = /usr/local/src/dvb/linux
and all will ok. This file is included by all Makefiles (also by plugins).
Regards,
Ales
Le mardi 29 janvier 2008 à 13:00 +0100, Ales Jurik a écrit :
On Tuesday 29 January 2008, Matthias Fechner wrote:
I modified now the Makefile and added the following lines after the include of the conf file: ifdef DVBDIR INCLUDES += -I$(DVBDIR)/include endif
For plugins which are using the headerfiles from the new driver I had to add the three lines too.
Is that a bug in the VDR Makefile?
No, for such purposes there is Make.config.template which should be copied to Make.config (see doc).
After line ### You don't need to touch the following:
add something like (depends on your configuration)
DVBDIR = /usr/local/src/dvb/linux
and all will ok. This file is included by all Makefiles (also by plugins).
Sorry it doesn't. I RTFM and modified Make.config and I have the error so there is something wrong.
Tony
-----Oorspronkelijk bericht----- Van: vdr-bounces@linuxtv.org [mailto:vdr-bounces@linuxtv.org] Namens Tony Grant Verzonden: dinsdag 29 januari 2008 13:55 Aan: ajurik@quick.cz; VDR Mailing List Onderwerp: Re: [vdr] #error VDR requires Linux DVB driver API > version3.3! (was - VDR developer version 1.5.14)
Le mardi 29 janvier 2008 à 13:00 +0100, Ales Jurik a écrit :
On Tuesday 29 January 2008, Matthias Fechner wrote:
I modified now the Makefile and added the following lines after the include of the conf file: ifdef DVBDIR INCLUDES += -I$(DVBDIR)/include endif
For plugins which are using the headerfiles from the new driver I had to add the three lines too.
Is that a bug in the VDR Makefile?
No, for such purposes there is Make.config.template which should be copied
to
Make.config (see doc).
After line ### You don't need to touch the following:
add something like (depends on your configuration)
DVBDIR = /usr/local/src/dvb/linux
and all will ok. This file is included by all Makefiles (also by plugins).
Sorry it doesn't. I RTFM and modified Make.config and I have the error so there is something wrong.
Tony
[serge pecher] Take care that the lines ifdef DVBDIR ... are under the line INCLUDES =-I ... something with freetype (sorry I don't have a machine in front of me
serge
Hi Tony,
Tony Grant wrote:
Sorry it doesn't. I RTFM and modified Make.config and I have the error so there is something wrong.
I have the same here but if I modify the Makefile like described before the problem is fixed. It seems to me that the Makefile does not use DVBDIR.
Best regards, Matthias
The only thing I did was edit the following line in Make.config:
DVBDIR = /usr/local/src/multiproto/linux
Everything worked fine without any modifying Makefile and so on. One of the most common problems with this is people not using the right path in that line.
On Jan 29, 2008 9:27 AM, VDR User user.vdr@gmail.com wrote:
The only thing I did was edit the following line in Make.config:
DVBDIR = /usr/local/src/multiproto/linux
Everything worked fine without any modifying Makefile and so on. One of the most common problems with this is people not using the right path in that line.
Ps. I'm using a copy of the Make.config example packaged with VDR.
At the end of the file you can clearly see:
### You don't need to touch the following:
ifdef DVBDIR INCLUDES += -I$(DVBDIR)/include endif
Hi,
VDR User schrieb:
Ps. I'm using a copy of the Make.config example packaged with VDR.
At the end of the file you can clearly see:
### You don't need to touch the following:
ifdef DVBDIR INCLUDES += -I$(DVBDIR)/include endif
yes you are right. My buildscript copies the file from a fixed position to the VDR builddir. But I missed to upgrade my own config file. So it is fixed now thx.
Bye, Matthias
-
Ales Jurik -
Carsten Koch -
Gregoire Favre -
Holger Steinhaus -
Igor -
Klaus Schmidinger -
Ludwig Nussel -
Malte Schröder -
Manu Abraham -
Matthias Fechner -
Morfsta -
s.huelswitt＠gmx.de -
serge pecher -
Thomas Schmidt -
Tony Grant -
VDR User