Re: [vdr] Request for rotor/actuator support integration to vdr
On 22.01.2011 20:31, Timothy D. Lenz wrote: VDR being a euro program where FTA sat is far more common should have really good support built in. I agree and awaiting too native rotor support in the vdr core. br, Arthur ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Request for rotor/actuator support integration to vdr
Hi, Sorry I don't like such requests where the step implementing this would be the third step before doing the first one. Afaik rotors are controlled by diseqc commands. What about a flexible configuration and creation of diseqc.conf directly in vdr? Controlling a rotor would be the next step! Just my two cents. BR. Halim ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Request for rotor/actuator support integration to vdr
On Sun, Jan 23, 2011 at 8:56 AM, Arthur Konovalov art...@gmail.com wrote: I agree and awaiting too native rotor support in the vdr core. I would also love to see native rotor support. The plugin crashes all the time with yavdr and is virtually unusable. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Request for rotor/actuator support integration to vdr
Hello, I would also love to see native rotor support. The plugin crashes all the time with yavdr and is virtually unusable. IMHO it depends on how those rotors are controlled. If they are controlled via DISEQ and VDR, for whatever reason, fails to send the required DISEQ commands, then VDR should be fixed to be able to do so. If rotors have to be controlled using a completely different protocol, then this IMHO better should keep in a plugin for one simple reason: Just like the plugin, the rotor support in VDR itself will have to be fixed and updated in future. Someone will have to do this and as Klaus most probably doesn't have or use a rotor, I think he doesn't want to do that. Yours Manuel -- () ascii ribbon campaign - against html mail /\- gegen HTML-Mail answers as html mail will be deleted automatically! Antworten als HTML-Mail werden automatisch gelöscht! Neu: GMX De-Mail - Einfach wie E-Mail, sicher wie ein Brief! Jetzt De-Mail-Adresse reservieren: http://portal.gmx.net/de/go/demail ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Request for rotor/actuator support integration to vdr
Al 23/01/11 09:56, En/na Arthur Konovalov ha escrit: On 22.01.2011 20:31, Timothy D. Lenz wrote: VDR being a euro program where FTA sat is far more common should have really good support built in. I agree and awaiting too native rotor support in the vdr core. What I'd like to see is that core vdr is more friendly to steerable dishes (be they implemented natively or via a plugin): vdr currently doesn't know that the dish is not pointing at the correct satellite, and that leads to some problems - the channels can be wrongly updated (NIT/PAT/PMT of the wrong satellite), I currently workaround that by setting Setup.UpdateChannels at 0 while the dish is moving, but it's ugly and it's not a complete solution (I think it shouldn't be processing section filters at all while the dish is moving). - when the position is reached, sometimes vdr doesn't show anything until I switch to a different transponder. Or if it does it doesn't find the dvb subtitles (until I switch to a different transponder). - unattended recordings are problematic since while the dish is moving obviously there's no data. I have a patch that sets a bigger timeout for the first packet, but, again, that's not a perfect solution. Bye -- Luca ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Request for rotor/actuator support integration to vdr
Once you have the rotor setup and locations stored in the rotors memory, you can already control it with with the conf as it is: S95.0W 9 V 10750 t V W15 [E0 31 6B 0E] W20 [E0 31 6B 0E] W20 [E0 10 38 FC] W5 v S95.0W 9 H 10750 t V W15 [E0 31 6B 0E] W20 [E0 31 6B 0E] W20 [E0 10 38 FC] W5 V S97.0W 9 V 10750 t V W15 [E0 31 6B 0F] W20 [E0 31 6B 0F] W20 [E0 10 38 FC] W5 v S97.0W 9 H 10750 t V W15 [E0 31 6B 0F] W20 [E0 31 6B 0F] W20 [E0 10 38 FC] W5 V S99.0W 9 V 10750 t V W15 [E0 31 6B 10] W20 [E0 31 6B 10] W20 [E0 10 38 FC] W5 v S99.0W 9 H 10750 t V W15 [E0 31 6B 10] W20 [E0 31 6B 10] W20 [E0 10 38 FC] W5 V But it's extreamly hard to set it up with out support for getting it to those positions and then saving them to the rotor. For that you need support for USALS. And then vdr would know to sent the rotor to 97w with S97.0W from that entry. Also, better can tell you signal str when fine tuning position and then store that location locally in the file instead of relying on the rotor memory which is not the best thing to do. Some STB's can also monitor the signal level when the rotor is close and automaticly stop it at the best spot. AS well allow scanning tp's ether by manual entry of each or with blind scan. There are a few new cards that support hardware blind scan and as more cards use chips like the Montage M88DS3000, more cards will support blind scanning. People don't ask for blindscan support because up till now, there where only a couple old cards that supported it. On 1/23/2011 4:01 AM, Halim Sahin wrote: Hi, Sorry I don't like such requests where the step implementing this would be the third step before doing the first one. Afaik rotors are controlled by diseqc commands. What about a flexible configuration and creation of diseqc.conf directly in vdr? Controlling a rotor would be the next step! Just my two cents. BR. Halim ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Request for rotor/actuator support integration to vdr
btw, here is a collection of pdf's on rotor function: http://www.eutelsat.com/satellites/4_5_5.html On 1/23/2011 9:57 AM, Manuel Reimer wrote: Hello, I would also love to see native rotor support. The plugin crashes all the time with yavdr and is virtually unusable. IMHO it depends on how those rotors are controlled. If they are controlled via DISEQ and VDR, for whatever reason, fails to send the required DISEQ commands, then VDR should be fixed to be able to do so. If rotors have to be controlled using a completely different protocol, then this IMHO better should keep in a plugin for one simple reason: Just like the plugin, the rotor support in VDR itself will have to be fixed and updated in future. Someone will have to do this and as Klaus most probably doesn't have or use a rotor, I think he doesn't want to do that. Yours Manuel ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Request for rotor/actuator support integration to vdr
On 01/23/11 20:37, Timothy D. Lenz wrote: btw, here is a collection of pdf's on rotor function: http://www.eutelsat.com/satellites/4_5_5.html On 1/23/2011 9:57 AM, Manuel Reimer wrote: Hello, I would also love to see native rotor support. The plugin crashes all the time with yavdr and is virtually unusable. IMHO it depends on how those rotors are controlled. If they are controlled via DISEQ and VDR, for whatever reason, fails to send the required DISEQ commands, then VDR should be fixed to be able to do so. If rotors have to be controlled using a completely different protocol, then this IMHO better should keep in a plugin for one simple reason: Just like the plugin, the rotor support in VDR itself will have to be fixed and updated in future. Someone will have to do this and as Klaus most probably doesn't have or use a rotor, I think he doesn't want to do that. Yours Manuel ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr There is also patch for vdr-core (http://www.linuxtv.org/pipermail/vdr/2010-March/022561.html) from Seppo Ingalsuo. It is working for me for very long time without any problem, it allows to combine diseqc gotoxx command with standard diseqc commands (switches) in diseqc.conf. If Klaus needs somebody to test any new implementation of gotoxx into vdr-core I'd do my best. Regards, Ales ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Request for rotor/actuator support integration to, vdr
:·) :·) I would also like some support for rotors in vdr, I can offer Klaus a free sat dish and an old rotor if that would motivate him... Klaus, as a minimum in vdr core we need the ability to specify a ´lapse value´ between a diseq command being sent (for non rotor users this would be zero, I´d imagine) and vdr tuning to a transponder or trying to add new channels. So in short if this value say was set to 30 seconds, then vdr would not add new channels or try to tune to a transponder. That would allow the rotor to do its job (with the existing diseqc.conf ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Request for rotor/actuator support integration to, vdr
Fixed number would help a little, but would get anoying and be in the way a lot of time. Going from one sat to the next is with in 2-3 sec's. It's when you need to do a full swing you run into collecting from the wrong sat. On 1/23/2011 2:31 PM, Arturo Martinez wrote: :·) :·) I would also like some support for rotors in vdr, I can offer Klaus a free sat dish and an old rotor if that would motivate him... Klaus, as a minimum in vdr core we need the ability to specify a ´lapse value´ between a diseq command being sent (for non rotor users this would be zero, I´d imagine) and vdr tuning to a transponder or trying to add new channels. So in short if this value say was set to 30 seconds, then vdr would not add new channels or try to tune to a transponder. That would allow the rotor to do its job (with the existing diseqc.conf ___ 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