I know about that plugin. Won't really help with a rotor. Different setup. Actuators are for BUD's, Dishes over 1.2m though they have come out with small dish systems. Normally A small dish rotro uses DiSEqC sent up the cable to control the motor. The rotor plugin is for that, but current versions are patched versions of a plugin that is no longer supported and always had a few problems. I list both because some people do have bud's. Supporting both would give vdr and advantage ober STB's instead of being handycaped in the control area. I think all STB's have support for DiSEqC rotors. I have a very cheap one I use for aligning the rotor and it has much better support then what the hacked plugins provide.

VDR being a euro program where FTA sat is far more common should have really good support built in. It does a better job with switches then boxes in the way it lets you mix and match/stack them by allowing you to set the command strings, but to make use of that with a rotor, you have to have it pre-setup so you can include the goto commands in the string.

On 1/22/2011 5:56 AM, YUP wrote:

Hi,

What about actuator plugin from Luca http://ventoso.org/luca/vdr/ (wiki page in German is here http://www.vdr-wiki.de/wiki/index.php/Actuator-plugin , use google translate to translate)?

Yarema

2011/1/22 Timothy D. Lenz <tlenz@vorgon.com mailto:tlenz@vorgon.com>

Time to bump this request again

_______________________________________________
vdr mailing list
vdr@linuxtv.org <mailto: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

I could be wrong about this but it seems I remember this subject coming up some time ago and Klaus mentioning rotor support is on his todo list. My apologies if I've got that backwards.

On Sat, Jan 22, 2011 at 10:32 PM, Timothy D. Lenz tlenz@vorgon.com wrote:

That would be nice, I thought he said he wasn't interested in doing it because of lack of interest. I tried to get the subject going again because there are people who would want it, but it seems most of those that would use it are not programmers and rely on others to write it. There are also a lot of people who use vdr that are not on the list. So it's up to use "few" to speak loud :)

You couldn't be more right about there being a lot of VDR users who don't make use of the mailing list. I know a large number myself and have tried to encourage them to participate here. It's hard for developers to really identify the needs/wants when people don't speak up. I've found the mailing list to be very useful and helpful, along with pretty much every developer I've contacted about various VDR related things. I wish more people would speak up, especially the NA VDR users -- there are tons of them but you'd never know it if you only read the mailing list.

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

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 99999 V 10750 t V W15 [E0 31 6B 0E] W20 [E0 31 6B 0E] W20 [E0 10 38 FC] W5 v S95.0W 99999 H 10750 t V W15 [E0 31 6B 0E] W20 [E0 31 6B 0E] W20 [E0 10 38 FC] W5 V

S97.0W 99999 V 10750 t V W15 [E0 31 6B 0F] W20 [E0 31 6B 0F] W20 [E0 10 38 FC] W5 v S97.0W 99999 H 10750 t V W15 [E0 31 6B 0F] W20 [E0 31 6B 0F] W20 [E0 10 38 FC] W5 V

S99.0W 99999 V 10750 t V W15 [E0 31 6B 10] W20 [E0 31 6B 10] W20 [E0 10 38 FC] W5 v S99.0W 99999 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

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

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

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