202 replies to this topic

[littlesat]

And that is relatively new... once chosen languages cannot be rechosen multiple times as it does not make sense....

[majidnourollahi]

when you download a 4k video from you tube in pli 7 it cant be played and watched.

 

PLEASE CONSIDER THIS ISSUE IN PLI 7.1 

[littlesat]

On which box....
The hardware should support the YouTube codex

[WanWizard]

On which box...

 

See his signature.

 

Afaik the latest broadcom sdk has disabled a few old codecs, including VP8 (and maybe VP9) which are in use by Youtube. If this is the issue, nothing much we can do about it, please complain with VU+.

[twol]

Cannot multiboot from OpenPli  RC 7.1 to OE-A Image on h7/hd51 both images running latest zgemma rootdirectory code.

OE-A images use STARTUP_1 thru 4 for h7/hd51

Receiver crashes during boot up and is totally locked out from any access .. I am assuming because the code writes old format STARTUP_x into STARTUP

 

The reverse is handled so you can boot to OpenPli, just cannot get back.

Edited by twol, 21 May 2019 - 14:54.

[betacentauri]

OE-A uses different startup file names like PLi. Not really good...

 

Which disk.img did you install? OE-A one or PLi one? Or better please post which startup files are present on the box and please check whether ALL include  rootsubdir=linuxrootfsX.

Edited by betacentauri, 21 May 2019 - 16:39.

[twol]

h7 receiver
Usb flashed latest OpenVix - so boot is using rootsubdir. STARTUP names are STARTUP_1 thu 4
Flashed OpenATV latest into slot 2 and OpenPli rc 7.1 into slot 3.... ALL using rootsubdir
Can flip between OpenViX and OpenATV . Can boot to OpenPli . Crashes on boot to OpenATV or OpenViX
OpenPli SystemInfo for h7 is:
SystemInfo["canMultiBoot"] = SystemInfo["HasRootSubdir"] and (1, 4, "mmcblk0", False)

FlashOnline coded added by zgemma 1st checks canMultiboot (which is False)
.. then checks STARTUP names used by OpenPli ...... this fails
So code then writes a startup using OLD format.....
startupFileContents = "boot emmcflash0.kernel%s 'root=/dev/mmcblk0p%s rw rootwait %s_4.boxmode=1'\n" % (slot, slot * 2 + 1, model)

Zgemma are aware of formats used by OE-A so should have handled this situation

Edited by twol, 21 May 2019 - 17:10.

[betacentauri]

Second check is for "/tmp/startupmount/STARTUP_LINUX_4_BOXMODE_12" which is not present. Third check is for file "/tmp/startupmount/STARTUP_LINUX_4". This file should be present and then this is executed:

elif os.path.isfile("/tmp/startupmount/STARTUP_LINUX_4"):
   shutil.copyfile("/tmp/startupmount/STARTUP_LINUX_%s" % slot, "/tmp/startupmount/STARTUP")

https://github.com/O...shImage.py#L483

 

Where is the error?

[betacentauri]

Ah, damn now I see. The files are called STARTUP_X

[betacentauri]

So changing these 2 lines (https://github.com/O...ge.py#L483-L484)

elif os.path.isfile("/tmp/startupmount/STARTUP_LINUX_4"):
    shutil.copyfile("/tmp/startupmount/STARTUP_LINUX_%s" % slot, "/tmp/startupmount/STARTUP")

into

elif os.path.isfile("/tmp/startupmount/STARTUP_4"):
    shutil.copyfile("/tmp/startupmount/STARTUP_%s" % slot, "/tmp/startupmount/STARTUP")

should be sufficient, or? Can you test that twol?

 

Do we harm other boxes with this? As far as I can see no, but would be good if someone can confirm.

Edited by betacentauri, 21 May 2019 - 17:44.

[twol]

unfortunately we have to add the elif as the h9Combo (thank you zgemma!) uses the STARTUP_LINUX_1 thru 4 (thankfully on both OpenPli and OE-A meta), so we need both elif tests.
I f someone can run a build, I can get it tested (unfortunately I no longer have a hd51/h7) ... we don‘t need feeds as we just need to test.
Would be nice to get OpenPli 7.1 out so we can get through these issues with the zgemma boxes.

[betacentauri]

Yes, right . Why does every manufacturer reinvent the wheel...

I can create PR tomorrow.

[twol]

Yes, right . Why does every manufacturer reinvent the wheel...
I can create PR tomorrow.

Because they think they know better than the “others“
Thanks again - appreciate your help on this issue which should never have arisen - this is really a manufacturer‘s issue (in my view!)

[WanWizard]

I can create PR tomorrow.

 

PR for 7.1-rc please, I'll merge it back into develop.

[betacentauri]

Sure

[betacentauri]

Please merge: https://github.com/O...igma2/pull/2147

[WanWizard]

Done, and merged back.

[littlesat]

I think these kind of patches is something we need to avoid.... Brrr.... 

Edited by littlesat, 23 May 2019 - 09:12.

[jamu]

Did a couch-flash to 7.1rc on my VU+ UNO 4K SE. The flash itself worked fine, but restoring auto backup settings failed to download any plugins, which resulted in a largely default system.

 

Looking at the autorestore log in /home/root, at the top you could see errors about resolving "downloads.openpli.org" -- which would seem to indicate that the network was not up at the time the auto backup restore was launched. I'm connected with ethernet to a Google Wifi disc directly.

 

Network obviously worked fine afterwards without any manual configuration, as I was able to telnet into the device and look at the logs. Internet was also fully functional at that time, and I was able to install backupsuite plugin manually to restore my previous working image.

 

Is this a known problem? Feels like some sort of race-condition in bringing up the network, and trying to use it too quickly before the network is fully up.

[WanWizard]

Logical, if you connect via wifi, you need to configure your ssid and password to be able to connect (assuming your AP doesn't allow public access).

 

These values are in the backup, but won't be available until after the restore, which is sort of a chicken and egg situation.

 

It might be possible to see if we can adapt the restore procedure, restore the network configuration, restart the network, and restore the rest. It's something we need to look at, and won't be available for 7.1-release.