Difference between revisions of "Problems and Solutions"

Revision as of 16:04, 16 April 2021

Alternative numbering mode

Are you confronted with channellist (bouquet) that don't start with the number 1, then enable this and it will. Goto Main Menu -> Setup -> System -> GUI Settings -> User Interface and enable "Alternative numbering mode"

Brand\Vendor related

Vu⁺ related

Cable Scan issue's?

There is bug with the VU+ drivers so that a scan can not be completed if tuner D is used.

This is the issue: input3 and input2 have no input3_choices or input4_choices so the Enigma2 doesn't try to initialize them.

/proc/stb/tsmux/input1_choices:CI0 CI1 A B
/proc/stb/tsmux/input0_choices:CI0 CI1 A B
/proc/stb/tsmux/input3:A
/proc/stb/tsmux/input2:A
/proc/stb/tsmux/input1:B
/proc/stb/tsmux/input0:AA simple solution is to initialize them manually.

Temporary solution until reboot

echo -n C >  /proc/stb/tsmux/input2
echo -n D >  /proc/stb/tsmux/input3

Note: VU+ should add input2_choices and input3_choices nodes.

Temporary Solution, that still works after a reboot: Install the IPK files that are posted at: https://forums.openpli.org/topic/49214-vuplus-duo2-dvb-t2-tuner-nim-tt3l10-stopped-working/page-3#entry701207 Reboot the receiver, and the scan problems are solved.

Restore Splash screen for Factory bootlogo

The file that can be found at the forum (see below) will place the original factory bootlogo back on your receiver. The content of the file needs to be placed on a USB pen drive. The file contains splash screens for the models: duo2, solo2, solo4k, solose, ultimo, ultimo4k, vuduo4k, uno, uno4k, uno4kse, zero, zero4k and the Duo 4K SE You do not have to pick one of the bootlogo's, your receiver selects only the file that must be needed.

So the following steps must be taken:

1. place the content of the zip file on the USB pendrive
2. reboot your receiver
3. flash the 'image' (this wil take a few seconds)
4. when the flash is completed, remove the USB pendrive
5. restart your receiver

duo2, solo2, solo4k, solose, ultimo, ultimo4k, vuduo4k, uno, uno4k, uno4kse, zero and the Duo 4K SE

Note: for some reason Vu+ changed the name of the splash file introducing the Vu Duo 4K SE from splash_cfe_auto.bin to splash_auto.bin

Download splash file: https://forums.openpli.org/index.php?app=core&module=attach&section=attach&attach_id=134711

Amiko related

Restore Splash screen for Amiko Viper Combo HDD

Source: https://forums.openpli.org/topic/56843-flash-amiko-viper-combo/#entry1179308

Edision related

Restore Splash screen for Edision

Source: https://forums.openpli.org/topic/47499-splash-for-edision-os-mega/#entry652041

ET6000

Install bootloader

Unpack the zip and place the et6x00 folder with its contents on an usb stick. Flash this as if it were an image. Here is the link to the bootloader for the ET6000 Here is the link to the bootloader for the ET6000

Source: https://forums.openpli.org/index.php?app=core&module=attach&section=attach&attach_id=132322

ET7000

Install bootloader

Unpack the zip and place the et7x00 folder with its contents on an usb stick. Flash this as if it were an image. Here is the link to the bootloader for the ET7000

Source: https://forums.openpli.org/index.php?app=core&module=attach&section=attach&attach_id=132262

Zgemma related

Restore Splash screen for Zgemma

Source: https://forums.openpli.org/topic/41521-boot-screen/#entry549387

CI module with softcam (eg. OScam), so using both and making them work together

If for some reason you want to use a CI module and OScam, you will probably run into error messages. The problem or better the errors are there because CI modules are designed to work standalone. So if you want to make them working together, best practice is using the "Commoninterfaceassignment plugin”. So to let a CI work together with a softcam download and install "Commoninterfaceassignment plugin" which is located in the system section of the Plugin browser. After installing the plugin goto Menu-> Setup -> SoftCam/CI -> Common Interface Assignment and define every channel for this CI module, that you have a subscription for. Enigma2 (OpenPLi) will then send all the other channels to the Softcam (OScam) and not to the CI module.

Crash logs

Crash logs are generated during a system crash, also known as a GSOD (green screen of death). The log can give insight to the probable cause of the crash. If you want help with the content of the file, you can post it on our forum. The crash log file is named like in the example below:

enigma2_crash_3891289128.log

The location of the crash log file when there is a HDD (Harddisk) present

Normally the crash.log file is stored in the root of the HDD so in

/media/hdd

The location of the crash.log file without any HDD (Harddisk) present

Normally the crash log file is stored in the

/home/root

How to get the crash log file

If you don't want to use the command line or telnet to get the crash.log file, you can grab it using your favorite ftp client or just use a (internet)browser. On how to do this take a look here accessing files on your receiver.

Debugging Enigma

Debugging from the menu

As of OpenPLi 7.1 you can start debug mode from the menu, if you press the on/off key and hold it and a menu will appear which has the option to select Restart enigma in debug mode, this will make the receiver restart and debug mode will be running in the background (you won't see this).

Now you can start or test anything you think is not right or for some reason want to know what is happening in the background. Once you have tested what you wanted to test you can press the on/off button and hold it, a menu will appear which has the option to select Restart enigma in normal mode.

Don't forget to do this, as debugging uses CPU power and it creates a debug file that keeps on growing as long as your debugging. The debug file that is created during debug is located at,

/home/root/enigma.20190901.debuglog

you can grab it using your favorite ftp client or just use a browser, on how to take a look here accessing files on your receiver.

Debugging from the command line

If you want to debug and want to know what is happening in Enigma, you can start your receiver in debug mode with the following command:

root@<receiver>: init 4
root@<receiver>: ENIGMA_DEBUG_LVL=4 enigma2

To stop: Press CRTL-C. Enigma will halt. Then start enigma with:

root@<receiver>: init 3

Or reboot the receiver with:

root@<receiver>: reboot

Note: For debugging gstreamer with read actions stuff use: ENIGMA_DEBUG_LVL=4 GST_DEBUG=*soup*:6,*dvb*:6 enigma2

For easier reading (Less logging) use:

ENIGMA_DEBUG_LVL=4 GST_DEBUG=*soup*:4,*dvb*:4 enigma2

Writing debug log to a USB stick

If for some reason your receiver reboots your debug log might be gone. Then plugin a USB stick in your receiver and use the command below, which writes the debug log to and USB stick

ENIGMA_DEBUG_LVL=4 enigma2 | tee /media/usb/enigma.log

Dual tuner problems

When your receiver has more than one tuner slot with 2 different tuners types, for instance DBV-T and DVB-C and you swap these tuners, then you might probably need to manually clean the nim entries in the settings file and then reconfigure the tuner and perform a scan.

Flickering dashed line in screen

When you see a dashed flickering line on the "top" of the screen, you can cover this by pressing the menu when you are in the bouquetlist and select "cover dashed flickering line for this service".

Or you can also install the plugin: Blackout Blind (enigma2-plugin-extensions-blackoutblind)

Freeze, Lock, Halt, Hang of OpenPLi and what to do, to gain control again over your receiver

When this happens, never (well only as a real last resort!!!) switch off the power or pull the power plug, this will -in time- certainly destroy the filesystem on which OpenPLi is running and as by-catch this may also destroy the filesystem of your HDD (when installed). So the best way is to login with Telnet and type:

root@<receiver>: init 4

This stops Enigma2 (operating system) gracefully, waiting for all it's components to stop and places Enigma2 into a "sleep" mode and then type:

root@<receiver>: init 3

This wakes enigma from the "sleeping" state and restarts the GUI (Graphical User Interface).

Harddisk Check

Harddrives will fail, that's just a question of time, so a check from time to time is prudent,certainly when you have switched it off using the power switch or pulled the plug, as this will mess-up the filesystem. (btw it can also be a USB stick but it has to be formated ext3 or 4). When a internal drive is present you can check it using the menu. Main menu -> Setup -> System -> Expert Settings -> Harddisk -> Filesystem check.

It needs some xpert to explain what to do if the hardrive is busy and umount does not do the trick.

I cannot record with my receiver or recording with a Zapper (eg. Vu Zero / Vu Solo Se / Zero 4K)

By default some Vu⁺ boxes are a zapper, meaning you can not record with it. If you want to record with it, you can install the "pau" plugin/extension. It is located in the extensions section of the plugin browser.

HbbTV and Kodi problems

HbbTV applications, browsers and Kodi make use of functionality of the SoC (the "processor") that is not required for enigma ("watch TV"). This functionality is in the SoC, but must also be made accessible/available for applications (which include browsers and Kodi). The supplier does this by means of the drivers, the sources of which are not available (also known as "closed source"). Because the interface to those drivers is not known (and we also have no sources) it cannot be otherwise than that the supplier also supplies the applications (Kodi, browsers ...). Sometimes they do, sometimes they don't, it depends on the supplier. The form in which these applications are offered is usually also without source, at least in part. This means that we are completely dependent on the supplier for the whole, if we have no sources, we cannot do anything. Especially if we move to a newer version of OE, this can cause problems and we have seen this for years, at various levels. Sometimes we manage to get it all going, but often not.

Short summary: for applications such as Kodi and HbbTV OpenPLi is completely dependent on the supplier as in Vendor, OpenPLi cannot do anything about that, so OpenPLi cannot guarantee HbbTV and Kodi. If it works: Great! If it doesn't work then the supplier did not consider it necessary to offer it to the user in working order. Sad but true.

Missing menu items or changing the access level of the configuration menu

As of OpenPLi 7.0 during a fresh flash (so no backup used) during the Installation you will be asked which suer mode you want to use. Here you can choose between 3 different user modes; Normal, Advanced or Expert. Each mode will reveal more options in the Menu, so if you are missing menu items, then you can change the user mode in the menu go to Main Menu > Setup > System > Expert settings > User Mode.

Movies or media files not playing

To play a certain movie or media file a codec (COder/DECoder) is needed. When a movie file won't play in OpenPLi this codec might be "missing" and sadly there is no way to add this missing codec, because opposite to a personal computer, which can install missing codecs, a STB (SetTopBOX)/receiver uses codecs from within the chip, so if the codec needed for a certain movie file is not in the chip of the receiver you are using, it cannot play it and you cannot add this missing codec, as you cannot add anything to a silicon chip.

So if you have a movie that can't be played, the only thing you can try, is to re-code it. For this you can use programs like Handbrake. A good choice would be h264 or h265 as the video codec and mp2, mp3 or ac3 as an audio codec.

Please Note: Files like AVI and MKV are containers and say nothing about the CODEC needed to play whats inside them!!

Mountmanager Problems

Here are some solutions when you run into problems with mounting\sharing a medium (HDD) in your network.

Autodetection

As of OpenPLi 7.2 CIFS config has SMB version and security protocol autodetection, so that you no longer have to start looking for whether options have to be given, they are now entered automatically, so practically it means that the suggestions below should not be needed anymore, the system will try all options until one settings works!!

Older vs newer Kernel

Note: This only accounts for OpenPLi versions below 7.2, as of version 7.2 SMB and SEC protocols are auto detected,so please do enter anything in the options:

When your box uses a kernel 3.x (Menu-Information-About) and you want to mount something that has a kernel 4.x your CIFS share might fail, even though you entered the data carefully, but there is a solution.

The solution is simple, you can try the following; If you make a mount with Mountmanager, change the "mount options" from "rw" to "rw, sec=ntlm", this will lower the security standard from ntlmv2 (default with kernel 4.x and up) to ntlm.

Now exit and re-mount or Reboot your box and if this was the cause, you can now access your share.

Older vs newer SMB Protocol

Note: This only accounts for OpenPLi versions below 7.2, as of version 7.2 SMB and SEC protocols are auto detected,so please do enter anything in the options:

There are several versions of the SMB protocol, v1, v2.0, v2.1 and v3. (see https://blogs.technet.microsoft.com/josebda/2013/10/02/windows-server-2012-r2-which-version-of-the-smb-protocol-smb-1-0-smb-2-0-smb-2-1-smb-3-0-or-smb-3-02-are-you-using/ for more in-depth information).

Recently, due to several security issues, an action has been ongoing to disable the unsafe SMBv1, not only in Windows, but also in NAS systems like Synology for example. Windows has the option to cycle through all available and allowed protocols, when you want to connect to a share, so you as a user don't notice anything and don't know which protocol is used. But the Linux kernel driver doesn't. It connects using the version it has been configured with, and if you, as a user, need a different version, you will need to specify this in the mount options.

Up to kernel v4.13 (at the moment of writing all supported receivers), the default was SMBv1, after that, the default has been upgraded to SMBv3. So if your box has a kernel older than 4.13, and your "server" doesn't support SMBv1, you need to specify the version on the mount. Likewise, if your box runs 4.13 or higher, and your "server" doesn't support SMBv3, you also need to specify the version on the mount.

The solution is to change the SMB version used to mount, to do this in Mountmanager change the "mount options" from "rw" to "rw, vers=3.0" or whatever version you want to mount. You might have to try a few, if you don't know which one your server supports, always start with the highest version.

This is a good overview on this subject: https://www.happyassassin.net/2017/11/03/linux-kernel-4-13-and-smb-protocol-version-fun/

The same is true for the authentication mechanism used to setup a share/mount. This used to be NTLM, but in Kernel 3.8 the default has changed to NTLMv2, as Windows no longer supports NTLM (also because of security issues). So depending on the version and configuration of Windows (especially Windows Server), you might need to specify an alternative mechanism on the command line too.

Note: For the Dutch, also have a look here https://forums.openpli.org/topic/71313-bestaande-en-werkende-cifs-mounts-werken-nu-niet-meer-in-72rc/page-5#entry1114216

So as explained above, if the protocol version that the box uses differ from the server side, then no connection is possible without additional actions.

   If you have a server that does not support SMBv2, you can force a connection to SMBv1 on the box by adding vers=1.0 to the mount options
   If you have a server that does not support NTLMssp, you can change it by adding sec=ntlmv2 or sec=ntlm to the mount options on the box

What works is a matter of trying, you may even need both. See below is an example on connecting to a Synology that "still" uses Samba version 1 and security NTLM:

Multiboot crash - Boot loop

If you make use of multiboot and somehow get stuck at boot, by let's say a GSOD (Green Screen of Death) you can try to login your box/receiver with telnet and try the following:

mkdir /tmp/t
mount /dev/mmcblk0p1 /tmp/t
cd /tmp/t

Because the Edision OS mio ... uses mmcblk1... this throws an error and you can try this:

mount /dev/mmcblk1p1 /tmp/t
cd /tmp/t

You should then see in this directory several startup files. If you eg want to start image in slot 1 do

cp STARTUP_1 STARTUP

If you want to start image in slot 2 then

cp STARTUP_2 STARTUP

And so on, then reboot the box.

Reset lost password

In case you have lost your box password or someone else has been so 'funny' to create a password without having informed you, there are several ways to solve this issue.

Install the "setpasswd" plugin

Easiest way is to install a plugin and reset or delete your password. Goto Main menu -> Plugin browser and press the green button "download plugins" goto systemplugins and goto setpasswd and press ok on your remote to install it. After you installed goto Main menu -> Setup -> System -> Change Root Password and press the red button to delete it.

Using the command line method 1

I assume that you still have access via Explorer with \\boxname or \\ipaddressbox. If not, then the only 'solution' to get access again is to flash your box which is actually not a solution.

1. Go to the map /etc where you find the file shadow.
2. If you owe another Enigma2 box then go to the map \etc and copy there that file 'shadow'.
3. Go to the box with the unknown password and paste the just copied file from the other box over your present version of shadow.

Using the command line: method 2

There is a second scenario to solve this.

1. Go to the map /etc where you also find the file passwd.
2. Select and edit the file passwd with right mouse button and select a proper editer. I use Notepad ++
3. In this file the line: root: x: 0: 0: root: / root: / bin / sh or something as root: EIfidfjeSAEFKEOlasdf5ewr3rWEW: 0: 0: root: / root: / bin / sh is the actual PW. The Password field is x or the encrypted string EIfidfjeSAEFKEOlasdf5ewr3rWEW
4. Delete the x or the string The line is now following: root :: 0: 0: root: / root: / bin / sh
5. Save / overwrite this file and exit Notepad ++.

Satellites.xml returning-over-and-over

The default satellites.xml is in the image, and is under version control. So it will be overwritten everytime you do an update.

This is the standard situation:

-rw-r--r--    1 root     root        531573 Jun  6 02:01 /etc/tuxbox/satellites.xml   
lrwxrwxrwx    1 root     root            26 Jun  9 19:28 /etc/satellites.xml -> /etc/tuxbox/satellites.xml
lrwxrwxrwx    1 root     root            26 Jun  9 19:28 /usr/share/satellites.xml -> /etc/tuxbox/satellites.xml
lrwxrwxrwx    1 root     root            26 Jun  9 19:28 /usr/share/tuxbox/satellites.xml -> /etc/tuxbox/satellites.xml

You see that /etc/tuxbox is the file that is provided by the image and is versioned, the others are not present by default, and are symlinked to the versioned file.

If you have a custom file, you should place it in /etc/enigma2, and it will take precedence over the system file in /etc/tuxbox. If you don't, and overwrite the system file, it will be removed and overwritten with a new system the next time you run an update.

Splash screen replacement

The splashscreen is written in a limited reserved space of flash. We believe that the splash screen is not intended to be image specific, it should just show the manufacturer and/or box type information. The dimensions and type of splash file supported by the bootloader, differ per brand, and possibly even per box. We advice to stay away from that, leave the splash screen to the bootloader, and the manufacturer.

If by some reason, let's say another image, has changed it, you can restore it to the one from the manufacturer. Do a search on the OpenPLi site using Google and type:

splash screen site:openpli.org

For the Edision jump to Restore Splash screen for Edision

For the Vu⁺ jump to Restore Splash screen for Vu

For the Zgemma jump to Restore Splash screen for Zgemma

Time, if you have problems getting the correct time

There are 2 solutions, if somehow you don't have the right time on you receiver, using the internet or use the transponder of a satellite.

Internet

Here you install a plugin called Systemtime, it is in Main menu > Pluginbrowser > Download plugins > Systemplugins and uses NTP, just like your desktop PC, to get the time from an internet time server, so after installing it, it will be in Main menu > Setup > Sytem and there are various settings.

Satellite

OpenPLi will, at startup retrieve the time from a transponder, so if you have a satellite setup, it is wise to make use of the Startup service. By doing so and choosing a reliable transponder (=channel) you will always have the right time. For the Dutch, choosing an NPO channel will be a good choice.

Unsupported receiver! How to request OpenPLi team to support a new receiver brand or model?

When your receiver is not supported by OpenPLi and you want it to be supported, what now? So before we can support any type of receiver, there have to be a few requirements met:

1. It must be an opensource receiver. - So not closed source.
2. It must be an Enigma2 receiver. - As we only support OpenEmbedded (Yocto project) boxes running Enigma2. This is essential of course as Enigma2 is the operating system that OpenPLi runs on.
3. The manufacturer/vendor has to ask us, so not the other way around! - As in the manufacturer/vendor has to mail OpenPLi to request support for this type/brand of receiver.
4. The manufacturer/vendor has to provide us (as in the OpenPLi team) with a functioning BSP layer. - A BSP (Board Support Package) contains, among other things, the drivers needed to build OpenPLi for your receiver.
5. We need interaction with the development team of the manufacturer/vendor. - The manufacturer needs to create the BSP and we need to be able to report and get driver bugs fixed, which is the reason we NEVER accept requests from end-users, we ONLY accept support requests from the manufacturer/vendor!

USB memory sticks working or not

When you want to use an USB memory stick, lets say for flashing your box with OpenPLi, there is no way of telling your stick might work, it's trial and error! Because the USB detection system in the bootloader of your receiver is very simple, there are 2 things to consider:

1. It has a short device detection time, which is as it should be, because a long device detection time could result in an annoying long booting procedure. This (short device detection) causes devices whose detection takes (too) long (usb3 devices, large sticks) not to be seen in time.
2. It takes the first device that is found and if you've connected multiple devices, chances are that it's not the device you want to use.

Generally speaking, small old USB sticks with less than 1Gb have a bigger change to work.