139 replies to this topic

[WanWizard]

@Huevos,

 

Is this better? https://github.com/O.../satellites.xml

[Huevos]

I think you are pretty close. -08 and -09 have a leading zero.

And your west slots are not quiet in natural order e.g. -9 should come before -8.

And by the way I convert all PLS codes and modes to gold as that is what enigma now uses internally.

[littlesat]

The first east then west order was an invention that was already there since the custom software dr. Overflow on the good old d-box.... dmm took the same order with enigma1 that time...

Edited by littlesat, 9 August 2018 - 20:27.

[Huevos]

On closer inspection there are a few more problems.

 

1) Something is failing when reading FEC. 129.0W is a good example of a major failure to read FEC but it is a common problem in the file currently on the repo.

2) Some transponders are completely missing. e.g. 121.0W, 11990H, 12016V. Not sure if this is intetional but I'm guessing not.

3) You are replacing "&" in the satellite names with "..". Should be "&".

4) Something weird going on with the satellite names. Lyngsat: "Star One C1 & Eutelsat 65 West A", satellites.xml: "Eutelsat 65 West A..Star One C1".

5) 61.0W, transponders not listed in frequency order, nor Lyngsat order, may be the same on some other satellites, e.g. 3.0E has the same problem.

6) Transponders missing when the frequency exists on more than one beam. e.g. 4.8E, Sub-Sahara 11747 V 27500 and Europe BSS 11747 V 30000. (On closer inspection it seems to be tagged on the end, but the frequency order is a mess).
 

The above problems seem to be recurring throughout the file. While they are there it makes it hard to run a diff on it to find other problems.

[WanWizard]

Check. Will be something for after the weekend.

[Huevos]

And if you did want to convert PLS values here are the functions ported to Python.

def gold2root(gold):
	if gold >= 0x3ffff:
		print "[gold2root] gold code invalid %d, returning default.\n" % gold
		gold = 0;
	g = 0
	x = 1
	while g < gold:
		x = (((x ^ (x >> 7)) & 1) << 17) | (x >> 1)
		g += 1
	return x

def root2gold(root):
	if root > 0 and root < 0x40000:
		g = 0
		x = 1
		while g < 0x3ffff:
			if root == x:
				return g
			x = (((x ^ (x >> 7)) & 1) << 17) | (x >> 1)
			g += 1
		print "[gold2root] input invalid %d, returning default.\n" % root
		return gold2root(0x1); # when input is wrong just return default gold value

Edited by Huevos, 10 August 2018 - 00:29.

[IanSav]

Hi,

 

For future reference, which one repository should I direct my pull requests for all future updates of the Australian terrestrial data?

 

Regards,

Ian.

[Huevos]

Probably better off sending PRs to oe-alliance-tuxbox-common where the file is maintained and then Abu can send a PR from time to time. The main problem is the folder structure of these repos is different so it is impossible to cherry-pick and needs to be updated manually meaning the commit details are lost.

[IanSav]

Hi Huevos,

 

Okay, as the Australian data is updated I will file pull requests with the OE-Alliance repository.  (The updates were occurring very frequently but have now settled down.  Still when I get an update I will pass it on.)

 

As for the differences between the repositories, I cleaned up the OE-Alliance repository and was about to make the equivalent fixes to the OpenPLi repository when the first half of the job was reverted.  If I would have been given the opportunity to complete the task then both repositories should have been directly comparable.

 

Regards,

Ian.

[WanWizard]

What is the problem with just copying the xml over?

[Huevos]

What is the problem with just copying the xml over?

Yes, of course you can do that but you have to make sure any commits made to the PLi copy are not lost in the process. Whereas if we could cherry pick we could sync the file in both directions and the details such as the original commit author, etc would not be lost in the process.

 

Not really sure why the folder structure is different or why PLi sees a need to send the grabber logs to the repo. Anyway it is what it is.

[Abu Baniaz]

What is the problem with just copying the xml over?

Some PRs are only sent to PLI, so copying will overwrite those changes.

As mentioned before, there are changes to layout which were questioned. Please decide the format you want to use and I'll adopt it.

It would be better to get rid of logs IMO or change folder layout by removing sub folder.

Sent from my Moto G (5S) using Forum Fiend v1.3.3.

[WanWizard]

We're in charge of merging any PR's, so if we agree that we will (automatically?) merge the cable and terrestrial xml files, we can do so? And redirect any PR's to the OE-A repo? I don't see the problem.

 

Also, what else is in the repo is not really relevant to updates to those two files?

[Abu Baniaz]

Also, what else is in the repo is not really relevant to updates to those two files?

But cherry picking commits is not possible, so the history won't show the changes and  we'll have to just replace the file as you said.

 

Can we also "squash and merge" instead of just plain merging requests please?

[WanWizard]

What history are you talking about? it is only about changing a single file, and the changes show up as a commit diff. I don't really care about the commit history, if we want to see that, we can check the upstream OE repo.

 

We "squash and merge" by default, unless a PR contains non-related commits (which should not happen) that need to be kept seperate.

[WanWizard]

I can see if I can make changes to make upstream pulling possible, but I'm travelling the next few weeks, so that has to wait until I'm back home.

[Token]

Openpli 7.3 on VU+ Solo2 (Kernel 3.13.5):

 

root@vusolo2:~# opkg upgrade

Upgrading tuxbox-common from 3+git289+5e0b745-r0.0 to 3+git309+843d4e3 on root

Downloading http://downloads.ope...e3-r0.0_all.ipk.

Segmentation fault

 

Upgrading tuxbox-common from 3+git289+5e0b745-r0.0 to 3+git309+843d4e3 on root

*** Error in `opkg': corrupted double-linked list: 0x00d9ca80 ***

Aborted

 

Please compare an repair this!

 

Thank You!

Edited by Token, 20 August 2021 - 11:43.

[Frenske]

We noticed there error more often but due to lack of available free time 7.3 won’t be repaired for a while.

[Token]

Can you describe the error in more detail, and is it possible to fix this bug manually?

Or is there a workaround?

 

P.S.:

Same Error on Openpli8!

Edited by Token, 20 August 2021 - 12:25.

[WanWizard]

Did you do an opkg update before that?

 

they error says

Upgrading tuxbox-common from 3+git289+5e0b745-r0.0 to 3+git309+843d4e3 on root
Downloading http://downloads.openpli.org/feeds/openpli-7-release/all/tuxbox-common_3+git309+843d4e3-r0.0_all.ipk

which is a sign there's something odd with the package index.
 

Tested it on OpenPLi 8 last night, and no issues?