Re: [vdr] [PATCH] Old DVB API patch for VDR-1.5.14
Udo Richter wrote: Asking myself if I want to build kernels and drivers for 4 different PCs or try my luck with an old DVB API patch for vdr-1.5.14, I've chosen the latter. The attached patch implements fallback for VDR in case no multiproto DVB driver headers are available. Nice, thanks! I wouldn't use the term emulate though. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] xineliboutput with xxmc: slow OSD
Hi, I am experimenting with xineliboutput using the xxmc video driver for the local sxfe frontend on an EPIA-M1 board with CLE266. I have the OpenChrome Drivers installed. MPEG2 HW decoding seems usually to work, I get around 25% CPU usage. However, when I bring up VDRs OSD everything becomes painfully slow. Why is that? Are there any setup options I can use to make the OSD work decently? Thanks, -- Ondrej ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] [ANNOUNCE] Clock Plugin 0.0.10
Hello, there is a small update for the clock plugin available. The new version can be found here [1] 2008-01-28: Version 0.0.10 (thanks to Tobias Grimm) - Some corrections to avoid Warnings during make. [1] http://vdr.aistleitner.info/vdr-clock-0.0.7.tgz Greetings, Mario ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] xineliboutput with xxmc: slow OSD
Le lundi 28 janvier 2008 à 09:44 +0100, Ondrej Wisniewski a écrit : I am experimenting with xineliboutput using the xxmc video driver for the local sxfe frontend on an EPIA-M1 board with CLE266. I have the OpenChrome Drivers installed. MPEG2 HW decoding seems usually to work, I get around 25% CPU usage. However, when I bring up VDRs OSD everything becomes painfully slow. Why is that? Are there any setup options I can use to make the OSD work decently? There is a problem with xine, the openchrome driver and VDR. You are too slow - I am seeing 9-12% CPU with current openchrome even with this bug. I am using vdr-xine rather than xineliboutput Cheers Tony -- ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] [ANNOUNCE] vdr-rotor support patches for VDR-1.5.14
I got the following error when compiling 1.5.14 with h264 patch
applied and your VDR diff from the tgz: -
g++ -g -O2 -Wall -Woverloaded-virtual -Wno-parentheses -c -DREMOTE_KBD
-DLIRC_DEVICE=\/dev/lircd\ -DRCU_DEVICE=\/dev/ttyS1\ -D_GNU_SOURCE
-DVIDEODIR=\/video\ -DCONFDIR=\/video\
-DPLUGINDIR=\./PLUGINS/lib\ -DLOCDIR=\./locale\
-I/usr/include/freetype2 -I/root/multiproto/linux/include device.c
device.c:793: error: prototype for âeSetChannelResult
cDevice::SetChannel(const cChannel*, bool)â does not match any in
class âcDeviceâ
device.h:255: error: candidate is: eSetChannelResult
cDevice::SetChannel(const cChannel*, bool, cDevice*)
device.c: In member function âeSetChannelResult
cDevice::SetChannel(const cChannel*, bool)â:
device.c:813: error: call of overloaded âSetChannel(const cChannel*,
bool)â is ambiguous
device.h:255: note: candidates are: eSetChannelResult
cDevice::SetChannel(const cChannel*, bool, cDevice*)
device.c:793: note: eSetChannelResult
cDevice::SetChannel(const cChannel*, bool)
make: *** [device.o] Error 1
The following patch fixes it: -
--- device.c2008-01-28 10:33:00.0 +
+++ device.c.new2008-01-28 10:32:47.0 +
@@ -790,7 +790,7 @@ bool cDevice::SwitchChannel(int Directio
return result;
}
-eSetChannelResult cDevice::SetChannel(const cChannel *Channel, bool LiveView)
+eSetChannelResult cDevice::SetChannel(const cChannel *Channel, bool
LiveView, cDevice *SpecificSourceDevice)
{
if (LiveView) {
StopReplay();
I'll test the functionality of the new rotor + patches shortly. I had
a brief look through the output, should it now be able to scan DVB-S2
transponders?
Thanks
On Jan 27, 2008 11:05 PM, Reinhard Nissl [EMAIL PROTECTED] wrote:
Hi,
the attached patch is based on these files:
vdr-rotor-0.1.4-vdr1.5.tgz
rotor-0.1.4-vdr-15.12.diff
For simplicity a patched version is attached too.
NOTES:
- I couldn't test with a real rotor device
- I couldn't test with a FF card
Have fun!
Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:[EMAIL PROTECTED]
___
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] [ANNOUNCE] VDR developer version 1.5.14
Well, multiproto doesn't even compile on a current (2.6.24) kernel .. or I am doing something really wrong. You must be. Compiles and runs fine here with a plain vanilla 2.6.24 kernel (i686) and the latest multiproto tree. Regards, Holger ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] vdr-rotor support patches for VDR-1.5.14
Seems that I spoke too soon - I get a problem running rotor on my
system after compilation: -
vdr: ./PLUGINS/lib/libvdr-rotor.so.1.5.14: undefined symbol:
_ZN7cDevice13SwitchChannelEPK8cChannelPS_
Whatever I try I can't seem to fix it. Reverting back to my old
version of rotor works fine.
On Jan 28, 2008 10:34 AM, Morfsta [EMAIL PROTECTED] wrote:
I got the following error when compiling 1.5.14 with h264 patch
applied and your VDR diff from the tgz: -
g++ -g -O2 -Wall -Woverloaded-virtual -Wno-parentheses -c -DREMOTE_KBD
-DLIRC_DEVICE=\/dev/lircd\ -DRCU_DEVICE=\/dev/ttyS1\ -D_GNU_SOURCE
-DVIDEODIR=\/video\ -DCONFDIR=\/video\
-DPLUGINDIR=\./PLUGINS/lib\ -DLOCDIR=\./locale\
-I/usr/include/freetype2 -I/root/multiproto/linux/include device.c
device.c:793: error: prototype for âeSetChannelResult
cDevice::SetChannel(const cChannel*, bool)â does not match any in
class âcDeviceâ
device.h:255: error: candidate is: eSetChannelResult
cDevice::SetChannel(const cChannel*, bool, cDevice*)
device.c: In member function âeSetChannelResult
cDevice::SetChannel(const cChannel*, bool)â:
device.c:813: error: call of overloaded âSetChannel(const cChannel*,
bool)â is ambiguous
device.h:255: note: candidates are: eSetChannelResult
cDevice::SetChannel(const cChannel*, bool, cDevice*)
device.c:793: note: eSetChannelResult
cDevice::SetChannel(const cChannel*, bool)
make: *** [device.o] Error 1
The following patch fixes it: -
--- device.c2008-01-28 10:33:00.0 +
+++ device.c.new2008-01-28 10:32:47.0 +
@@ -790,7 +790,7 @@ bool cDevice::SwitchChannel(int Directio
return result;
}
-eSetChannelResult cDevice::SetChannel(const cChannel *Channel, bool LiveView)
+eSetChannelResult cDevice::SetChannel(const cChannel *Channel, bool
LiveView, cDevice *SpecificSourceDevice)
{
if (LiveView) {
StopReplay();
I'll test the functionality of the new rotor + patches shortly. I had
a brief look through the output, should it now be able to scan DVB-S2
transponders?
Thanks
On Jan 27, 2008 11:05 PM, Reinhard Nissl [EMAIL PROTECTED] wrote:
Hi,
the attached patch is based on these files:
vdr-rotor-0.1.4-vdr1.5.tgz
rotor-0.1.4-vdr-15.12.diff
For simplicity a patched version is attached too.
NOTES:
- I couldn't test with a real rotor device
- I couldn't test with a FF card
Have fun!
Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:[EMAIL PROTECTED]
___
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] xineliboutput with xxmc: slow OSD
Le lundi 28 janvier 2008 à 12:07 +0100, Ondrej Wisniewski a écrit : There is a problem with xine, the openchrome driver and VDR. You are too slow - I am seeing 9-12% CPU with current openchrome even with this bug. I am using vdr-xine rather than xineliboutput snip that was not the answer I was hoping for ;-) Are you saying that there is a bug regarding OSD usage with the combination xine, openchrome and VDR? Can you explain a little more? Any ways around that? Sorry I forgot to say I am using Fedora Core 8. There is an issue with libxcb and threads - it is fixed in OpenSuze10.3 says Reinhard. With the OSD I have increase in CPU load and, in the terminal I am running Xine from, warning that I don't have enough colors etc. Can't zap from horizontal to vertical polarization. Screen goes blue and VDR restarts I am currently using the multiproto driver linked from the 1.5.14 announcement. Regarding CPU load I need to check that again at home. I was reporting the overall CPU load on my PC. I should probably check just the consumption of VDR and sxfe. To complicate things the VDR get's it's videostream using streamdev-client from the server box. OK 26% total on M1 is about the same as mine xine 11% average X 3-4% vdr 3-4% + other proccessus Tony -- ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.5.14
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 ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.5.14
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 ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.5.14
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 ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] [PATCH] HVR4000(lite) support for multiproto
Great thanks to Manu and Klaus for their latest updates. The attached patch adds HVR4000 support to it. It has been tested successfully together with kernel 2.6.24 on i686 using VDR 1.4.7 (DVB-S only) and VDR 1.5.14. Regards, Holger multiproto-hvr4k-2008-01-28.patch.bz2 Description: BZip2 compressed data ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Multiproto updated Re: [ANNOUNCE] VDR developer version 1.5.14
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 [EMAIL PROTECTED] 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 ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.5.14
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 ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.5.14
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 ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] vdr-rotor support patches for VDR-1.5.14
I demand that Morfsta may or may not have top-posted... Seems that I spoke too soon - I get a problem running rotor on my system after compilation: - vdr: ./PLUGINS/lib/libvdr-rotor.so.1.5.14: undefined symbol: _ZN7cDevice13SwitchChannelEPK8cChannelPS_ Whatever I try I can't seem to fix it. Reverting back to my old version of rotor works fine. c++filt says cDevice::SwitchChannel(cChannel const*, cDevice*). Maybe you need to recompile something...? [snip; don't top-post] -- | Darren Salt| linux or ds at | nr. Ashington, | Toon | RISC OS, Linux | youmustbejoking,demon,co,uk | Northumberland | Army | URL:http://www.youmustbejoking.demon.co.uk/progs.packages.html I don't suffer from insanity: I enjoy every minute of it. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.5.14
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 ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.5 .14
*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. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] vdr-rotor support patches for VDR-1.5.14
On Jan 28, 2008 5:15 PM, Darren Salt [EMAIL PROTECTED] pedantically wrote: c++filt says cDevice::SwitchChannel(cChannel const*, cDevice*). Maybe you need to recompile something...? [snip ; don't top post] Nope, it's all compiled - just doublechecked with fresh source: - vdr-1.5.14 vdr-rotor-0.1.4-vdr-1.5.14.tgz vdr-1.5.14-h264-other-rotor.diff vdr-1.5.14-h264-syncearly-framespersec-audioindexer-fielddetection-speedup.diff ./vdr -Protor vdr: ./PLUGINS/lib/libvdr-rotor.so.1.5.14: undefined symbol: _ZN7cDevice13SwitchChannelEPK8cChannelPS_ Could be the mismatch between device.c and device.h in eSetChannelResult SetChannel. I don't know. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Multiproto updated Re: [ANNOUNCE] VDR developer version 1.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) Regards, Manu ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.5.14
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 ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] CoreAVC + xineliboutput there is an howto?
Hi all man, there is a lot of time that im trying to make work correctly dvb-s2 but Ive not understand how to make work coreavc, there is any sep-by-step or similar howto or wiki??? Bye and tnx a lot for your biggest work ;-) _ La mia Cartella di Posta in Arrivo è protetta con SPAMfighter 197 messaggi contenenti spam sono stati bloccati con successo. Scarica gratuitamente SPAMfighter http://www.spamfighter.com/lit ! ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
