Jump to content


MCelliotG

Member Since 30 Apr 2013
Offline Last Active Today, 01:37
-----

Posts I've Made

In Topic: Channel Bandwidth Speed (download/upload) in User Interface in Open PLI

13 September 2020 - 11:18

What you showed us though was live tv! Which means this is not how the converter works. If it measured the used bandwidth, it wouldn't show anything on a live tv channel since no bandwidth is used.


In Topic: Channel Bandwidth Speed (download/upload) in User Interface in Open PLI

13 September 2020 - 00:27

The answer would be "why would anyone need a reading like this while watching a TV channel?"

Obviously there's a converter somewhere that should constantly download something in the background. That means so many resources lost, increased CPU usage and for what? A meaningless indication using an E2 receiver with functions totally unrelated to such a task.


In Topic: One proc file for detecting the MACHINE in all enigma2 images.

21 July 2020 - 12:13

Let me chime in in the blindscan situation...

The way hardware blindscan is treated in the plugin is simply atrocious.

What separates DMM is that there is no blindscan binary because the drivers return true in this part of the code

def BlindscanMain(session, close=None, **kwargs):
	have_Support_Blindscan = False
	try:
		if 'Supports_Blind_Scan: yes' in open('/proc/bus/nim_sockets').read():
			have_Support_Blindscan = True
	except:
		pass
	if have_Support_Blindscan:
		import dmmBlindScan
		session.openWithCallback(boundFunction(BlindscanCallback, close), dmmBlindScan.DmmBlindscan)
	else:
		session.openWithCallback(boundFunction(BlindscanCallback, close), Blindscan)

Which opens up a whole new different blindscan plugin with fewer options and bad blindscan results, no filters, very poor configurations etc.

This also affects HD51 since gfutures introduced have_Support_Blindscan = True in the Silabs driver, strategically not used in other STBs with Silabs such as SF8008.

This separation is very bad and unfair, all blindscan methods should use the same options.


In Topic: HD51 huge multiboot problem.

22 June 2020 - 19:01

 

OK, guys, PROBLEM SOLVED!!!

What I had to do is flash the 7.3 usb image via USB, fearing I would lose multiboot capabilities. Luckily I did not.

 

What seems to happen is this:

It looks like flashing the usb image and deleting the current partition table the latest OpenATV 6.4 creates if flashed via USB, fixes the multiboot with non OE-A images.

The good thing is that flashing an OE-A image after that in any slot, will retain the table, and compatibility. The only issue is that you cannot boot Mode12 from within OpenATV due to the differences already explained, but in all images the image list is now visible, so no problem for me.

Now, even SDG8 (Zeus) is working properly.

So, long story short, the distribution has nothing to do with the incompatibility, but OpenATV's workarounds do!

Nice things to know, I learned a lot today!

 

Thank you to everyone for your patience and suggestions! :)

There is no reason why any of the OE-A images will not handle bootmode 12 when OpenPli STARTUPS are in use - the code  to handle the multiboot change and different STARTUPS has been there for the last 3 months - if it doesn‘t work in OpenATV its a bug in their implementation

 

They do handle both modes but only when the flash is partitioned with their emmc-recovery image. But once this is done you cannot install any OpenPLI multiboot image on any slot,without getting the no images found problem.

But if you do the other way round, install openpli 7.3 usb first and partition the flash, you can install any image in any slot and everything is visible.

But you cannot reboot to any Mode 12 from inside the OpenATV image anymore, it boots back to OpenATV. But you can boot to any OpenATV/OE-A mode 12 image from the selector of any OpenPLI image.

That means that something is missing on handling the startup files, which makes OpenATV's implementation incompatible towards OpenPLI, but thankfully not the other way around.


In Topic: HD51 huge multiboot problem.

22 June 2020 - 14:52

OK, guys, PROBLEM SOLVED!!!

What I had to do is flash the 7.3 usb image via USB, fearing I would lose multiboot capabilities. Luckily I did not.

 

What seems to happen is this:

It looks like flashing the usb image and deleting the current partition table the latest OpenATV 6.4 creates if flashed via USB, fixes the multiboot with non OE-A images.

The good thing is that flashing an OE-A image after that in any slot, will retain the table, and compatibility. The only issue is that you cannot boot Mode12 from within OpenATV due to the differences already explained, but in all images the image list is now visible, so no problem for me.

Now, even SDG8 (Zeus) is working properly.

So, long story short, the distribution has nothing to do with the incompatibility, but OpenATV's workarounds do!

Nice things to know, I learned a lot today!

 

Thank you to everyone for your patience and suggestions! :)