270 replies to this topic

[rhinoceros]

Isn't this not skin related... the new screens are not alligned with this skin.... And chicken and egg story.....

A work-a-round could be to define a custom screen so foreign skins do not steal the screen by an old style but now crashy screen.... We can add the new screenname in the plugin itself... or in skin_default.xml... so a foreign skin cannot steal it anymore,

Another solution is alter all those third party skins .... this is somehow not done....

There is indeed a chicken and egg issue here. Should we move the screen definition here in the skin, all third-party skins will fail until they too have supplied a screen definition. If we do not move it in the skin, all other skins will need to live with the Magic-SD design ...

Since this is a SystemPlugin, I feel we should move the screen definition into the skin (skin_default.xml). But that will need to be a coordinated effort to avoid breaking other skins ...

Edited by rhinoceros, 29 February 2012 - 14:47.

[mirakels]

Since the new positioner patches have been applied by Mirakels, the dish icon shown during a move of the rotor does not blink/flash anymore.
The old code used to flash the dish image once per second.

yes but te new code shows a countdown timer and from/to info. If things are correct, the default skin and PLi-HD skin are adapted for that.
Other skins might just show a static dish until the movement is finished. (the flashing picture does not add any additional info. The flashin is just a time and is no indicator for movement in itself!)

[mirakels]

Isn't this not skin related... the new screens are not alligned with this skin.... And chicken and egg story.....

A work-a-round could be to define a custom screen so foreign skins do not steal the screen by an old style but now crashy screen.... We can add the new screenname in the plugin itself... or in skin_default.xml... so a foreign skin cannot steal it anymore,

Another solution is alter all those third party skins .... this is somehow not done....

There is indeed a chicken and egg issue here. Should we move the screen definition here in the skin, all third-party skins will fail until they too have supplied a screen definition. If we do not move it in the skin, all other skins will need to live with the Magic-SD design ...

Since this is a SystemPlugin, I feel we should move the screen definition into the skin (skin_default.xml). But that will need to be a coordinated effort to avoid breaking other skins ...

If you ask me: let's just update the default-skin. littlesat can update the PLi-HD skin. Other skins just have to follow....
Openpli is a moving image so we cannot limit ourselves because skins are not up to date.
It would be nice however if we could find some way to communicate such skin requesting changes proper.

[Dimitrij]

@rhinoceros
Excellent work .
Patch LNB is also useful.
Everything is working correctly.
Maybe I'll do the localization?
Many users with no knowledge of English would be difficult to sort out the settings.
At the same time, and little changed on the default screen.

Edited by Dima73, 29 February 2012 - 17:30.

[rhinoceros]

If you ask me: let's just update the default-skin. littlesat can update the PLi-HD skin. Other skins just have to follow....
Openpli is a moving image so we cannot limit ourselves because skins are not up to date.
It would be nice however if we could find some way to communicate such skin requesting changes proper.

I fully and totally agree. It was the communication about the skin change request that I was concerned about.

[rhinoceros]

@rhinoceros
Excellent work .
Patch LNB is also useful.
Everything is working correctly.
Maybe I'll do the localization?
Many users with no knowledge of English would be difficult to sort out the settings.
At the same time, and little changed on the default screen.

OK thanks, in that case we should commit the patch.
Localisation will be much appreciated. If you can engage there, please do.

Edited by rhinoceros, 29 February 2012 - 18:29.

[adri]

Since the new positioner patches have been applied by Mirakels, the dish icon shown during a move of the rotor does not blink/flash anymore.
The old code used to flash the dish image once per second.

yes but te new code shows a countdown timer and from/to info. If things are correct, the default skin and PLi-HD skin are adapted for that.
Other skins might just show a static dish until the movement is finished. (the flashing picture does not add any additional info. The flashin is just a time and is no indicator for movement in itself!)

The static dish icon is not really pretty either.
It would be nice if extra countdown timer and info can be shown regardless of the skin used.

[halflife]

is it possible to see picture immediately when I move dish to the rigth position like it was on enigma1? I was test latest pli image and have a crash only if I previously was on some dvbt usb channel. If I watch channel from dvbs tuner, and start positione setup, no crash ( for now ).

 enigma2_crash_1330595156.log   16.87KB   5 downloads

[Dimitrij]

This bug was fixed.
And soon will the new interface.

[halflife]

after update from today, gs again! 3 days ago was ok

Attached Files

•  enigma2_crash_1330755645.log   16.87KB   3 downloads

[rhinoceros]

The patch is not (yet) committed. Alternatively, you can copy the .py file manually from post #98

[rhinoceros]

For the willing and daring. Here is a version with support for the (re-)calculate command since this question keeps coming up now and then.
WARNING: THE (RE-)CALCULATE COMMAND IS UNTESTED BY ME. I am not willing to risk this with my own rotor setup. There is a confirmation messagebox before the (re-)calculation starts, so inadvertent button presses should do no harm.

Apart from this, there are minor cosmetic improvements.

Since the repo is not (yet) updated it seems with the patch in post #98, the diff included here is cumulative, i.e. it includes that patch.

Attached Files

•  plugin.zip   12.94KB   41 downloads

[mirakels]

@rhinoceras: what are the risk with the recalculate option? Can it destroy the motor?
The message now only asks for confirmation to recalc. But maybe the message should be more informative about the consequences of. recalcs.

You're not into git yet to generate formatted git patches? If not maybe you can specify a proper message and I'll integrate it into the patch and commit it...

[goedi]

For the willing and daring. Here is a version with support for the (re-)calculate command since this question keeps coming up now and then.
WARNING: THE (RE-)CALCULATE COMMAND IS UNTESTED BY ME. I am not willing to risk this with my own rotor setup. There is a confirmation messagebox before the (re-)calculation starts, so inadvertent button presses should do no harm.

Apart from this, there are minor cosmetic improvements.

Since the repo is not (yet) updated it seems with the patch in post #98, the diff included here is cumulative, i.e. it includes that patch.

It crashes when I start the plugin, so I couldn't test the recalculate command.

Crashlog attached.

Regards, Goedi

Attached Files

•  enigma2_crash_1330789567.log   16.86KB   3 downloads

[rhinoceros]

@goedi,
I don't think this crash has anything to do with the Positioner Setup. There were several issues last week, most - if not all - of those were solved, I believe. I would suggest you update to the most recent version then try the Positioner Setup again. Myself I am using a baseline of 23 feb. I have not had any crash yet.

[rhinoceros]

@rhinoceras: what are the risk with the recalculate option? Can it destroy the motor?
The message now only asks for confirmation to recalc. But maybe the message should be more informative about the consequences of. recalcs.

You're not into git yet to generate formatted git patches? If not maybe you can specify a proper message and I'll integrate it into the patch and commit it...

Well, there is no other risk than that you may loose the positions you already memorised. That's all. Anyway, most semi-professional rotors do not implement this command in any case, so nothing would happen. Worst case is that it is implemented wrongly or that there is a bug in the code or the way it is transmitted by SEC to the rotor. Again that means loss of data or wrong data in the position memory. Nothing catastrophic, but I spent time to finetune some 40+ satellites and I do not want to do that all over again.

Regarding git, I had not really tried again. I guess I was looking for a step by step for the installation of a command-line version of git. Somehow a gui is also required I saw. I need to install in Windows since that is all I have. I'll try again asap. Thanks for your patience with me.

[rhinoceros]

You're not into git yet to generate formatted git patches? If not maybe you can specify a proper message and I'll integrate it into the patch and commit it...

In fact, the message presently says: "This will (re-)calculate all positions\nAre you sure?". It's really what I wanted to warn the user for.

Edited by rhinoceros, 3 March 2012 - 19:15.

[Dimitrij]

@mirakels

The patch module Dish.
-Save the last position of the motor in the configuration filе(thanks for the idea vlamo).
-Minor cosmetic changes.

[Dimitrij]

@rhinoceros
And if the user has two rotor (motor)?
What if ...
It can be read as a number of the tuner at the opening of the plug.
P.S.However, I do not understand this.

[Robinson]

One question.
When the rotor moves from one position to another, a satellite icon is displayed along with "from" and "goto" positions. This is a very nice feature!
However, the time counting down (I assume it shows approx. when the dish arrives at "goto" position.) seems to be totally wrong. For example, moving from 13E to 28E it estimated to take some 16-17 seconds (I don't remember exactly.) but in fact it took only about 5 seconds.
Anyway, great job! Thanks.