65 replies to this topic

[Bag58]

@Rob van der Does

 

Too bad that the Ka band cannot be excluded, though. That would be a nice improvement of that site.

For he rest I agree fully with you, that is exactly how I do it as well, since I'm only interested in Ku-band. The good thing using that site is that you can also filter out any satellite positions you cannot see with your dish, keeping the size of the file down.

 

However I was answering a question about the splitting of bands on a satellite by adding a position 1 tenth of a degree away to split the bands on the satellite, and possible reasons to do that. If someone has both a C-band LNB/dish and a Ku-band LNB/dish, I think he would need to have two separate satellites to be able to handle both bands. And that is exactly what can be done by having that split.

 

@Robinson

 

You asked for reasons to make such splits, amd I simply mentioned some. I agree with you that there will not be many people combining several bands in their installations.

[Huevos]

Let me give you a couple of examples.

 

There is a fleet of satellites at 19.2E.

The entries in satellites.xml show:

<sat name="19.2E Astra 1KR/1L/1M/1N Ka Band" flags="1" position="194">
<sat name="19.2E Astra 1KR/1L/1M/1N Ku Band" flags="1" position="192">

 

or at 5W:

 

<sat name="5.0W Eutelsat 5 West A C Band" flags="1" position="-51">
<sat name="5.0W Eutelsat 5 West A Ku Band" flags="1" position="-50">

 

Why are they split into 2 different entries in the file?

Quite simple really. You can only have one LNB, per tuner, per position. So the only way to have one tuner able to scan multiple bands is to have multiple positions.

[Huevos]

@Rob van der Does

 

Too bad that the Ka band cannot be excluded, though. That would be a nice improvement of that site.

There isn't Ka band on my site. You must be confusing it with a different site. And right now there are enough users or DTH channels to justify adding it.

Edited by Huevos, 22 July 2015 - 23:00.

[Bag58]

@Huevos

 

You're right. I just checked and did not find any Ka-band transponders. I was under the impression they were there, since the 9.0 E contains Ka-sat in it's name.

[janejak]

KA-Sat at 9E is for internett over satelitte see http://www.tooway.com/

[Huevos]

@Huevos

 

You're right. I just checked and did not find any Ka-band transponders. I was under the impression they were there, since the 9.0 E contains Ka-sat in it's name.

Names are according to Lyngsat.

 

KaSat only has 1 Ka DTH transponder and that can only be received in the RoI. And now 19E has a couple of transponders for people who want porn in 3D.

 

Main problem with Ka is you can't cover the whole band with one LNB. Currently there are 4 LNB types to cover the complete band so in theory you would need 4 different positions, one for each segment of the band.

Edited by Huevos, 23 July 2015 - 15:24.

[Robinson]

I know /etc/enigma2/satellites.xml is not updated with an online update but is it also possible to make /etc/tuxbox/satellites.xml not to be updated with an online update?

[Bag58]

Why would you want that? Just put your file in /etc/enigma2. If that one exists, the system will use that one and not look at the other location.

[Robinson]

Just as an extra protection against possible satellite positions which might damage my dish if it hit the wall or any other obstacle.

If my /etc/enigma2/satellites.xml somehow got damaged the PLi one would be used automatically, which I would like to avoid.

[Bag58]

So, if I understand you correctly, you want the standard satellites.xml in OpenPLi to not be updated through the update procedure because you might get a problem with your user file in /etc/enigma2. And that way leaving all users, who are not experts and cannot put in their own satellites.xml (and I think there are thousands of such users), with a more and more outdated version of that file. They would need to perform a complete flash to get the new file, or learn how to put in their own file. No disrespect intended, but don't you agree with me, that this is just a tiny bit selfish?

[Robinson]

Not a bit.

I never said I wanted all users not to be able to update the file during online update.

I just wanted to find a way to disable it for myself, which seems to be possible thanks to a private message I received from andres66.

Edited by Robinson, 10 August 2015 - 21:43.

[Bag58]

In other words, you want the installation of an updated satellites.xml to be optional. That already sounds a lot better.  

[athoik]

I just wanted to find a way to disable it for myself, which seems to be possible thanks to a private message I received from andres66.

Did you tried the following?

opkg flag hold tuxbox-common

[Robinson]

Oh no. The advice from andres66 was more complicated.

So after this command my satellites.xml at /etc/tuxbox/ will no longer be updated?

And what if I wanted to update it again, would there be a similar command to undo the "hold" flag?

[Huevos]

Just as an extra protection against possible satellite positions which might damage my dish if it hit the wall or any other obstacle.

Are you serious? That is what hardware and software limits are for. And hardware limits can't get deleted/overwritten by accident so they are the most important.

[athoik]

Oh no. The advice from andres66 was more complicated.

So after this command my satellites.xml at /etc/tuxbox/ will no longer be updated?

And what if I wanted to update it again, would there be a similar command to undo the "hold" flag?

 

Hold suppose to prevent a package from beign updated.

 

http://wiki.blue-panel.com/index.php/OPKG_%28en%29
http://wiki.openwrt.org/doc/techref/opkg

	Set package on hold 
Prevent an update of a package (using the flag hold).
 
flag <flag> <pkgs> Flag one or multiple package(s). Only one flag per invocation is allowed. Available flags:
hold • noprune • user • ok • installed • unpacked

 

Setting flag back to installed will allow to update again (I guess).

[Robinson]

Are you serious? That is what hardware and software limits are for. And hardware limits can't get deleted/overwritten by accident so they are the most important.

I'm not going to climb high, remove the dish with the motor and spend a lot of time setting it up again with a help of someone else (installation by one person is impossible) so that is why I'm looking for easy solutions.

[Huevos]

No software solution can replace hardware limits. Software solutions are just not safe.

[Rob van der Does]

Even if your system-file satellites.xml would get corrupt (for whatever what reason; never happened in my life), you would still require 'new' (wrong) satellites to be assigned to your tuner(s) in the tunerconfig before your dish would be able to hit the wall.

[Robinson]

Rob, I was talking about the one in /etc/enigma2 getting corrupt or accidentally removed.

In such  case the one in /etc/tuxbox would be used, which I would rather avoid.