Persian Prince

Actually you are now getting to the real painpoint...
 
Slot 0 is a recovery slot and is also used as a backup mechanism when you insert a USB stick with a specific file on it on the USB. It contains also the directories that contain the other 'slots'. So it needs special handling and when you 'break' it you can lost all the other slots. I did not decide anything, I just mentioned the fact. So that is also why it is not recommendable to flash it online. And yes when it is an option, we are aware of it, but users will make the mistake as they do not know, lost slots or event think they brick their box (unless they can restore it with flashing via USB).
 
I recommend to put it on hold and sleep on it for a moment as I prefer a 'real' solution. Actually what VIX is trying to do, making it a real kind of recovery 'image' is the best option we have. From the first time the idea came up my feeling was I miss a recovery image, but it may take some time to get it done somehow.
 
A few line of codes can indeed arrange you can flash slot 0, but the code is full of exceptions we should try to avoid. And when the slot 0 is a real recovery thing instead of a full image with enigma2 functionality is what I think we should prefer. As longer I think about it making slot 0 a kind of normal slot for the user is for me more and more not a good approach. It always somehow 'breaks' the recovery 'mind of thing'.

Just to let you know we have cmd images for all devices on https://images.openvision.dedyn.io for more than 2 years.

No enigma2
No GUI
No python (optional)
Less than half in size
OSCam pre-installed
Network only and command line

I suggest try boot a RPi with qemu first: https://images.openv...i/raspberrypi2/

All OV repos are public again: https://openvision.tech/?p=210

https://github.com/O...e-core/pull/904

 

Backup Suite change URL for PLi.

 

It's better for you to fork/import this to https://github.com/e2openplugins and maintain it there so you could have access to it.

 

The master branch will be dropped in OV sources soon.

 

Regards,

Persian Prince

Just a suggestion... put the complete 'new' stuff to the already existing proc folder /proc/stb/info.... it already exists... but can now get 'more info'... So just extend the existing - not create/hack a new one, where we somehow 'never' can agree a good name for (as there is already a folder for it why create a different?)

+

For multi-boot it would be fine to have a file in /etc that gives and image description (short) in the first row and an extended in the following rows.

 

Try it yourself, try it on Zgemma HiSilicon for example and you'll understand the problems.

 

We should avoid existing folders and to be more specific we should avoid existing folders created by main STB drivers.

As I said they never answer and just sell something.

 

I know some users did the same like you and all said they will never buy Vu+ again.

Best kernel support: Edision 4K

 

Best response and customer behaviour via email: GigaBlue (something Vu+ get 0 in our cases)

 

Backup is running, it detected my H9.2S fine.

So my fix worked, thanks for the test now I will push some other fixes regarding case sensitive to be sure about future fuck-ups

For ipk you can try https://forums.openp...d-generator-10/

 

And for python examples you could check github for .py sources

Hello everyone,

 

We store MACHINE name in "/etc/openvision/model" (Open Vision images) so we could use it in shell and other places which we can't use getBoxType, do you keep machine names somewhere in PLi?

 

I can provide a kernel module to create

 

/proc/stb/info/enigma2model

 

for example to store the MACHINE name from OE, if you're agree with this we could use it instead of

 

/proc/stb/info/hwmodel
/proc/stb/info/gbmodel
/proc/stb/info/boxtype
/proc/stb/info/vumodel
/proc/stb/info/azmodel

 

to check one proc file globally for all in all places, even reduce checks in enigma2 itself.

 

The reason behind this is https://github.com/O...e-core/pull/841 which made BackupSuite not compatible with PLi as we're using full machine names like "vuduo" instead of "duo" in the new "lookuptable.txt"

 

https://github.com/O...upsuite.sh#L214 returns "duo" for you so the new "lookuptable.txt" won't understand it.

 

Regards,

Persian Prince

Guys the problem is because of recent multilib changes and we're investigating it.

 

ls command problem solved for all images (was ok for Open Vision but not recent custom builds like PLi develop ...)

 

And report problems here: https://github.com/O...kupSuite/issues

 

Check the new version if you can compile from the sources.

Glad to hear that you like our images

 

It's not hard to enable multilib in PLi's OE but it's a decision PLi team should take not anyone else, I can help if they want and enable multilib in PLi's develop branch.

 

But keep in mind Open Vision isn't a PLi based image (not for months). It's a different flavor like ViX and ATV.

 

We only use PLi's enigma2 but with so many many differences.

Thanks, I forgot to change the makefile.am. I wonder why the travis.ci build succeeded though...

 

Your welcome

 

Travis compiles all python files and won't check any Makefile.am but in OE you need to tell what files you want to be installed.

https://github.com/O...igma2/pull/2355 (Makefile.am: Install Hex2strColor.py)

 

related to https://github.com/O...00c9257f104e143 and https://github.com/O...b2be49cde6f3873

 

https://github.com/O...igma2/pull/2354 (PliExtraInfo.py: Add Verimatrix)

 

related to https://forums.openp...dpost&p=1128980

Thanks was my mistake

 

No worries we all are losing our eyes

 

Thank you for your great new changes.