Re: [vdr] Restricting a particular dvb card from tuning to channels with a selected modulation
hello guys yes i do think this is a good idea... as with different tuners they could be used for other lnbs like c -band and ku i could only use my s2/s card for services on a c and ku setup then tune and record from different types of services... then each tuner could live on a fixed satellite if you wanted On 10/29/09, Timothy D. Lenz wrote: > There is the isue whereone tunner might be connected to an LNB on a rotor > and another to a fixed. Knowing how the tunner can tune > wouldn't help then. > > - Original Message - > From: "Klaus Schmidinger" > To: > Sent: Thursday, October 29, 2009 1:13 AM > Subject: Re: [vdr] Restricting a particular dvb card from tuning to channels > with a selected modulation > > >> On 10/28/09 23:15, Petri Helin wrote: >> > Hi, >> > >> > I have an USB DVB-C card (Reddo dvb-c, actually a relabelled Tongshi >> > box), which works very well with the current Linux driver excluding >> > channels with QAM-256 modulation. Would it be easy to check >> > FE_CAN_QAM_256 in vdr before trying to use a device to tune to a >> > particular channel? In such a case I could deactivate FE_CAN_QAM_256 in >> > the drivers. I am using VDR 1.7.9, if it makes a difference. >> >> Checking the frontend capabilities is certainly the right thing to do, >> and I will see that this gets implemented. >> >> Klaus >> >> ___ >> vdr mailing list >> vdr@linuxtv.org >> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr > > > ___ > vdr mailing list > vdr@linuxtv.org > http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr > ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Restricting a particular dvb card from tuning to channels with a selected modulation
There is the isue whereone tunner might be connected to an LNB on a rotor and another to a fixed. Knowing how the tunner can tune wouldn't help then. - Original Message - From: "Klaus Schmidinger" To: Sent: Thursday, October 29, 2009 1:13 AM Subject: Re: [vdr] Restricting a particular dvb card from tuning to channels with a selected modulation > On 10/28/09 23:15, Petri Helin wrote: > > Hi, > > > > I have an USB DVB-C card (Reddo dvb-c, actually a relabelled Tongshi > > box), which works very well with the current Linux driver excluding > > channels with QAM-256 modulation. Would it be easy to check > > FE_CAN_QAM_256 in vdr before trying to use a device to tune to a > > particular channel? In such a case I could deactivate FE_CAN_QAM_256 in > > the drivers. I am using VDR 1.7.9, if it makes a difference. > > Checking the frontend capabilities is certainly the right thing to do, > and I will see that this gets implemented. > > Klaus > > ___ > 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] Restricting a particular dvb card from tuning to channels with a selected modulation
On Thu, Oct 29, 2009 at 1:13 AM, Klaus Schmidinger wrote: > On 10/28/09 23:15, Petri Helin wrote: >> Hi, >> >> I have an USB DVB-C card (Reddo dvb-c, actually a relabelled Tongshi >> box), which works very well with the current Linux driver excluding >> channels with QAM-256 modulation. Would it be easy to check >> FE_CAN_QAM_256 in vdr before trying to use a device to tune to a >> particular channel? In such a case I could deactivate FE_CAN_QAM_256 in >> the drivers. I am using VDR 1.7.9, if it makes a difference. > > Checking the frontend capabilities is certainly the right thing to do, > and I will see that this gets implemented. This still doesn't resolve a major problem for North Americans. The situation is that the 2 biggest dvb-s providers use a modified modulation, 8psk turbo-fec. There is only one device that is capable of tuning this but unfortunately the device has to pretend to be a dvb-s2 device to do so. Apparently the v4l guys (from what I was told) didn't want to allow 8psk turbo-fec in dvb-s because it's a non-standard modulation. So the problem becomes that VDR sees a dvb-s stream and the frontend of say a nexus-s will say its capable of receiving it, even though that dvb-s stream may contain the 8psk turbo-fec which a nexus-s can not tune. I believe the best way to handle this situation is by allowing the user control over what devices may be used to tune what channels. VDR can't be smart enough to figure it out due to incorrect & bad design in v4l. Another strong reason to allow this to be configured at the user-level is what if the the user has 2 devices...both able to tune a channel but the signal is weak. Tuner 1 can tune it fine but tuner 2 has problems because of the weak signal. VDR is simply going to ask a free tuner 'can you tune this?', whereas the best scenario would be for the user to say 'use tuner 1 for this channel'. I can think of two ways to better deal with this; adding a new field in channels.conf, adding a tuneroverride.conf By adding a new field.. If the value is "*" then it means any device may tune it. If its an integer, then the values listed represent which devices should be used. For example: :*: use any device :2,3: use only device 2 or device 3 By using a tuneroverride.conf you can specify which devices to use with certain channels. If the channel isn't contained in tuneroverride.conf then VDR just uses it's own logic to figure it out (the capability check). The good thing about this method is you can create a simple shell script to auto-generate the tuneroverride.conf file using key indicators in the channels.conf... The file structure would be very simple: : This is really the only way to satisfy _everyones needs_, by ultimately allowing the user to control device priorities. PLEASE take this into serious consideration as it's been a long standing problem that's only getting worse with more and more transponders move to 8psk turbo-fec. Best regards, Derek ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] xineliboutput: sxfe-reconnect doesn't work
Hi, On Do, Okt 29, 2009 at 03:59:27 +0200, Theunis Potgieter wrote: > On 29/10/2009, Halim Sahin wrote: > > Hi, > > > > > > On my machine sxfe wasn't able to reconnect after a vdr restart any way. > > I am interested to know if this is a setup problem or another problem in > > current devel branch of xineliboutput. > > > > Autoreconnect of remote fe's would be really useful :-). > > BR. > > > The --reconnect switch does not do this? No :-(. BR. halim ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] [OT] Compilation of dxr3player
Hello Sorry if this post is not directly related to VDR. I'm currently updating my VDR config after a disk change. I can't get dxr3player 0.11 compile with gcc 4.3.3 (Slack 13) /usr/lib/gcc/i486-slackware-linux/4.3.3/../../../../include/c++/4.3.3/bits/stl_vector.h:490: erreur: 'const class DefaultAllocatorTemplate >' has no member named 'max_size' I tried the cvs with the following commands : cvs -d:pserver:anonym...@dxr3player.cvs.sourceforge.net:/cvsroot/dxr3player login cvs -z3 -d:pserver:anonym...@dxr3player.cvs.sourceforge.net:/cvsroot/dxr3player co -P dxr3player Compilation aborts : g++ -DHAVE_CONFIG_H -I. -I../../.. -I../../../src/lib -I../../..-g -O2 -Wall -W -include /home/vdruser/dxr3player/config.h -fno-rtti -fno-exceptions -MT Config.o -MD -MP -MF .deps/Config.Tpo -c -o Config.o Config.cc Config.cc: In destructor 'Config::~Config()': Config.cc:310: erreur: 'mediaDirectory' was not declared in this scope Did anyone succeed in compiling dxr3player with gcc 4.x.x ? Thanks Damien ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] Broken CAM handling with TechniSat TechniCAM and ORF Digital Card
Hi, my setup : Ubuntu Karmic 9.10 vdr-1.7.9 xinelib 1.2 hg kernel 2.6.31 my DVB hardware : TechnoTrend TT3200 + Budget CI my problem : Two weeks ago i upgraded my VDR from 1.7.0 to 1.7.9 and discovered that the CAM handling with the TechniSat TechniCAM and ORF Digital Card is broken. The Decryption starts and stops after two seconds. Reverting back the changes in ci.c,pat.c and pat.h to the version of vdr 1.7.8 solves the problem temporarily. How can i help debuging the real problem in vdr 1.7.9 and fixing it ? Happy Penguin Edgar (gimli) Hucek ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] xineliboutput: sxfe-reconnect doesn't work
On 29/10/2009, Halim Sahin wrote: > Hi, > > > On my machine sxfe wasn't able to reconnect after a vdr restart any way. > I am interested to know if this is a setup problem or another problem in > current devel branch of xineliboutput. > > Autoreconnect of remote fe's would be really useful :-). > BR. > The --reconnect switch does not do this? ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] xineliboutput: sxfe-reconnect doesn't work
Hi, On Do, Okt 29, 2009 at 08:37:55 +0200, Theunis Potgieter wrote: > i have found this to happen too. I also get where vdr-sxfe locks up. > Vdr is fine but restarting vdr-sxfe the only way of fixing that. Last > night I restarted vdr on purpose while vdr-sxfe was running, it did > take a while for vdr-sxfe to become functional again. I had to press > channel up/down before a picture was displayed. On my machine sxfe wasn't able to reconnect after a vdr restart any way. I am interested to know if this is a setup problem or another problem in current devel branch of xineliboutput. Autoreconnect of remote fe's would be really useful :-). BR. Halim > On 10/29/09, Halim Sahin wrote: > > Hello, > > Xineliboutput from cvs > > Sxfe as remote frontend doesn't reconnect when vdr restarts. > > It says that it can't get data from the server but it doesn't try to > > reconnect. > > Tcp transport was used. > > Any idea what's wrong? > > BR. > > Halim > > > > > > -- > > Halim Sahin > > E-Mail: > > halim.sahin (at) t-online.de > > > > ___ > > vdr mailing list > > vdr@linuxtv.org > > http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr > > > > -- > Sent from my mobile device > > ___ > vdr mailing list > vdr@linuxtv.org > http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr -- Halim Sahin E-Mail: halim.sahin (at) t-online.de ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Restricting a particular dvb card from tuning to channels with a selected modulation
On Thu, Oct 29, 2009 at 10:13 AM, Klaus Schmidinger wrote: > On 10/28/09 23:15, Petri Helin wrote: >> Hi, >> >> I have an USB DVB-C card (Reddo dvb-c, actually a relabelled Tongshi >> box), which works very well with the current Linux driver excluding >> channels with QAM-256 modulation. Would it be easy to check >> FE_CAN_QAM_256 in vdr before trying to use a device to tune to a >> particular channel? In such a case I could deactivate FE_CAN_QAM_256 in >> the drivers. I am using VDR 1.7.9, if it makes a difference. > > Checking the frontend capabilities is certainly the right thing to do, > and I will see that this gets implemented. > > Klaus > Thanks! -Petri ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Restricting a particular dvb card from tuning to channels with a selected modulation
On 10/28/09 23:15, Petri Helin wrote: > Hi, > > I have an USB DVB-C card (Reddo dvb-c, actually a relabelled Tongshi > box), which works very well with the current Linux driver excluding > channels with QAM-256 modulation. Would it be easy to check > FE_CAN_QAM_256 in vdr before trying to use a device to tune to a > particular channel? In such a case I could deactivate FE_CAN_QAM_256 in > the drivers. I am using VDR 1.7.9, if it makes a difference. Checking the frontend capabilities is certainly the right thing to do, and I will see that this gets implemented. Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Restricting a particular dvb card from tuning to channels with a selected modulation
On 29/10/2009, Petri Helin wrote: > Hi, > > I have an USB DVB-C card (Reddo dvb-c, actually a relabelled Tongshi box), > which works very well with the current Linux driver excluding channels with > QAM-256 modulation. Would it be easy to check FE_CAN_QAM_256 in vdr before > trying to use a device to tune to a particular channel? In such a case I > could deactivate FE_CAN_QAM_256 in the drivers. I am using VDR 1.7.9, if it > makes a difference. > > Of course at the moment the proper solution would be to modify the > channels.conf to se a preselected card to tune to a particular channel, but > in this case there are two drawbacks with it. 1) I have more than one card > that I can use for QAM-256 channels and would like to use them all, and 2) > channels woth QAM-256 are also encrypted and I have yet to figure out how to > set both the CA code and the number of the card in the "Conditional access" > parameter in the channels.conf. > > Actually now that I think of it... How about separating the explicit card > selection and conditional access by introducing a new paremeter in the > channels.conf that could be used to preselect the card(s) that can tune to > the selected channel? > > > -Petri Is this not related to the sourcecap patch? ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
