Posts by s3n0

Hi.

I usually use a softcam client for everything, only CCcam v2.3.0. For softcam server purposes, I prefer to use OSCam - always the current version.

However, everything also depends on which DVB encoding system you use (which CAID)... which softcam communication protocol... how the specific decoding card behaves, etc. etc. etc. .

I use the two listed softcams for the IRDETO system. They proved to be the best for me.

If I tried to use other versions of CCcam as clients, communication stopped working within a few hours or days. A restart of the softcam server was necessary. I thought it was a softcams compatibility error. So, I tested it as a softcam client, also using OSCam. However, it did not help. I also tried different versions of CCcam as softcam clients, but that didn't help either. Only what I mentioned above proved true. So I've been using this "set" for a long time and it works without problems.

/// EDIT :

If you need to use only one softcam exclusively, as a client, e.g. for remote connection, I recommend OSCam despite everything. If you do not plan to combine different softcams and if you will only use one softcam (in one own set-top box), then you should rather use this OSCam. It is a multi-protocol softcam and has a very nice Web-GUI and also a lot of setting options.

Hi. The administrator of the softcam server will be able to advise you with this problem. Only he knows what is happening on the server... he sees the debug... he knows the coding systems used... he knows the configuration of the server... and he can check where the problem is. You have to contact him and not random people who unfortunately don't know anything about the softcam server you are connecting to. Also, the correct configuration of the softacm client for you is best advised only by the softcam server administrator.

Hi.

I don't have and don't use dpkg manager, so I can't advise you with dpkg installation manager.

The problem arises when unpacking the DEB installation package in your used Enigma2 - Peter Pan distribution. I don't know where the problem might be, because the DEB-package with the plugin works almost everywhere.

Copy it to the "/tmp" folder and try the following in Linux Shell. Try to get debug information...

dpkg -D2 -i /tmp/enigma2-plugin-extensions-chocholousek-picons_5.0.231225_all.deb

...or just unpack the package...

cd /tmp
dpkg --unpack /tmp/enigma2-plugin-extensions-chocholousek-picons_5.0.231225_all.deb

It could easily be some kind of Enigma2 error. I don't know exactly (I don't remember) how the debug is obtained from these systems. I think it is done via "journalctl":

journalctl --since "1 hour ago"        # the contents of the system log will be displayed from the current time, 1 hour backwards

////////// EDIT:

I noticed that you are using an old version of the plugin. That is not good ! Download and install the latest plugin package (https://github.com/s3n0/e2plug…usekPicons/released_build). The old one (5.0.221007), if it is installed, let it be uninstalled.

Quote from mouadhada

Hi, why picons are not longer updated on the plugin ?

Hi. Picons continue to be updated. Approximately every 15 days ...... when there is enough free time. If you open the website https://picon.cz/ , the dates of the last updates are displayed in the right part of the website.

I don't see problems in assigning SNP <-> SRP, but in creating a suitable filename for a specific channel, because even if the definition for creating a file name is clear, it may not always be exact (it may not always be the same). There are many similar channel names which, when converted to a file name, will be the same.

Also, using lameDB is not easy, because there is a big mess (inconsistencies) in the content of these files. I have already tried to use lameDB more than once, but some important information is wrong there. LameDB ver.5 is a bit more polished, but something was missing there too. I don't remember what exactly. It is not possible to create a good mapping of SRC (ServiceReferenceCode) to file names, according to DVB channel names. For example, some people use reception from 3 channels at the same time, where there are often 2-3 identical names of the resulting file (after shortening the channel name) for always a different picon. I don't remember exactly, but during various experiments with lameDB file, I always ended up running into an unsolvable problem. That's why I use lameDB files really minimally. For example, some channel names officially present in lameDB are found more than once only because there is an SD version and also an HD version (according to the channel resolution). The first situation is often that the channel names are the same, but the HD and SD channel icons are different. Second, as far as I know, the formula for shortening channel names also includes deleting the final letters "HD" placed separately (after an empty space). Simply put, a lot of problems arise when creating these "abbreviated" channel names.

Hi.

I don't know what exactly you mean.

You have to specify - what doesn't work, what you want to achieve, ... and also how the ChocholousekPicons plugin is related to this, etc. .

It makes the process a bit more complicated if I were to add it to a plugin. There would have to be some kind of conversion table. Someone must then constantly take care of this table and maintain it ( chocholousek - picon designer). And then these symbolic lines... I don't know, um, if it won't cause problems, for example. in some Enigma2 SKINs or in some drivers for the front LCD display... or something similar.

By now, you should be able to find at least one SNP pikon color design that chocholousek (picon designer) put in there. They are background / color picons: "SNPtransaprent". They are probably only available in "220x132" resolution (I don't know exactly, because I don't follow the available picon designs... this is always handled by chocholousek himself).

Quote from BanjoXo71

Just want to update that i reflashed OpenBH 5.3, this time round i used the very latest picon ipk from github and all is installed and fully updated now. Its weird because i had other plugins that was the same such as ipchecker but with the new install that also worked to. Something must have happened [not sure what] but it fixed itself.

Thanks for a great add on :)

Hi.

Good... nice if it works.

Probably there was some error with the update - the previous beta / alpha test version became the official released version... but in the case of Enigma2 test-versions, I already saw that the directories for the plugins were in different paths than usual.

Also, the error could happen when you use a multiboot and it uses symbolic links to directories with plugins (and when these symbolic links or paths are lost for some reason).

Hard to say really since you didn't create a debug file ;-).

Quote from Melgas

Hello, chocholousek

I have been searching picons without success (HISPASAT 30W):

Sport TV + and 1, 2, 3, 4, 5, 6 and NBA Sport TV.

Picon transparent SAT 220X132 HISPASAT (30W).

Picon transparent Cable 220X132 ZON + MEO (Portugal).

Thank you very much.

Display More

Hi.

You're on the wrong thread... to support specific picons, you have to use the picon thread and not the enigma2 plugin thread :).

Post

RE: Picons by Chocholoušek

DTT ITALIA + SAT 9°E

CANALE 232 ( STUDIO + HbbTv )

1_0_1_FA9_107_217C_EEEE0000_0_0_0 - 1_0_1_FA9_107_217C_5A0000_0_0_0

Azzurra

Jan 16th 2024

There are many ways to debug the Enigma2.

In every Enigma2 distribution, you can find it elsewhere in the GUI MENU.

Of course, it can also be done through a terminal connection (PuTTY application, using Telnet or SSH protocol).

In OpenATV you can find it in:

GUI MENU > Settings > System > Debug

And there... turn on the debug log and reboot the set-top box.

Then trigger an error, and after the error occurs, a record is also created in the debugging file. Next, connect via an FTP connection and copy the debug file (folder /home/roots/logs) to the PC from the set-top box. Next, insert this file into the discussion or into my private message (due to possible personal data in the debugging file... even though... they probably won't be there anymore).

When you get the debug file, turn off debugging in OpenATV again. That's because it might slow down the Enigma2 a bit.

You have to contact the creators of OpenBH, let them fix the BUG. Unfortunately, I don't know OpenBH and I don't use it. I only know and use OpenATV and OpenPLi.

As I have already written to you twice, you must provide me with a debug file. Otherwise, I won't find out where the problem is in the case of your OpenBH.

OpenATV 7.4 is still not the official version! You can only get to it by manually changing the version number in the URL ! Change "/current/" in the URL address to the value "/7.4/" and you will see these T E S T versions ! This is a secret procedure and normally inaccessible to inexperienced users. These test-versions are intended (again repeating ! and I won't be anymore !) for developers, testers and experienced IT users !!!

The official URL for downloading the current released OpenATV edition is here:

https://www.opena.tv/downloads/

...or...

https://images.mynonpublic.com/openatv/current/

I can't help you without the debug file. Sorry. :-/

I would have to install the OpenATV that you own - I don't know which one, but I assume that the official OpenATV 7.4 has already been released (it is no longer just a development version). Then next I have to start debugging on this installed image.

But I guess that the error will be somewhere in upgrading the OpenATV 7.4 develop version to the new (full) released 7.4 version.

If I remember correctly, the developer versions use different directories for plugins. After you update to the official version, these old directories will remain there. And maybe that's the problem. That the upgraded official OpenATV can no longer find the plugin in the right directory. And now I'm just guessing the cause of the possible problem. I don't know if that's true. Maybe reinstalling the plugin or checking that there is a proper "plugin.py" file (i.e. module) and path to it would help:

# INSTALL - the latest released version of the plugin:

# (Warning ! The plugin configuration will be deleted !)

wget -qO- --no-check-certificate "https://github.com/s3n0/e2plugins/blob/master/ChocholousekPicons/online-setup?raw=true" | bash -s install

# or:

curl -LJs "https://github.com/s3n0/e2plugins/blob/master/ChocholousekPicons/online-setup?raw=true" | bash -s install

Also, the need for the ".py" / ".pyo" / ".pyc" files present may be different for the development version and for the official released version. The develop version should contain all of the listed ones (I'm not sure, but it probably does).

/////////EDIT:

So I'm adding info !

The official version of OpenATV 7.4 has not yet been released. ONLY version 7.3 is still available for download - as stable / released version. OpenATV 7.4 version is intended for testers and not for novices and amateurs ! As of today, version OpenATV 7.4 has still not been officially released.

If you are using version OpenATV 7.3, then you probably did something wrong, because in my case (Chocholousek Picons 5.0.231225), with my OpenATV 7.3 (up to date) everything works OK.

I repeat again that I need a debug file from you. Otherwise I won't find the error. The error should be / will be recorded in more detail in the debug file.

However, I still think that you are using the 7.4 version intended for developers / testers ... and there is a small problem in it.

Hi.

Thanks for the bug report. It's really weird.

It would help to turn on debugging in Enigma2 + reboot. And send me created debug log file... here... into the discussion... or via a private message - of course, only after the error appears, so that it is written into the debug file.

In the last OpenATV, which version do you mean exactly? I have OpenATV 7.3 and there is no problem.

It looks like somewhere (I don't know where) the module "Plugins.Extensions.ChocholousekPicons.plugin" is being imported as the plugin. Probably in Enigma2 code. And this algorithm subsequently fails... I don't know why.

Your last post is the same idea as:

- I can get water in a glass ! How do you take water into a glass ?

If you know that, then why are you asking ? If you knew that... if you at least read the "article" about installing Oscam manually... you would find out how to diagnose Oscam startup.

Simply start by using the man-page for Oscam:

/usr/bin/oscam --help

(you must know the correct name of the Oscam binary)

You can also try to restart or start the Softcam, using the "init.d" shell-script. Maybe this action will tell you something more about the problem:

/etc/init.d/softcam restart

If it doesn't work, the problem will be in the compatibility of the libraries (probably in ATV 7.4 there are new libraries and the old ones are removed and therefore it is necessary to add symbolic links - to old libraries, to start new libraries... but compatibility is never one hundred percent guaranteed). However, you will see an error about the libraries when you try to start Oscam manually (in the terminal connection to the set-top box).

Do I really have to remind you of all this? You write nonsense here about some non-functional Oscam, but you don't write anything about WHY Oscam doesn't want to start. First write why it doesn't want to start. Then ask for a solution to the problem. You don't even know where the problem is. So why are you asking about a solution to a problem that you yourself cannot identify and determine?

OpenATV 7.4 is currently still under development ! Do not use this OpenATV 7.4 if you are not an experienced user !

Why the hell are you using it ?! These test versions (beta / alpha - development versions) are intended exclusively for developers or experienced IT experts. Not for people who can't deal with stupid Oscam (I mean it honestly and no offense... please).

You can also install Oscam manually (if you have the appropriate Oscam binary file). Instructions on how to do this can be found, for example, at the begin of my startup init.d shell-script or also in a small and brief article.

Oh... OK... so, it's good that there is the same standard and service reference codes. But that depends on chocholousek , whether he will create picones for the USA as well. He already has a lot to do :-/. Maybe a donation would be useful or someone who can donate Chocholousk for his work, for example from the USA :-).

However, I can't really say... that what and how. Making picons is Chocholousk's hard work. You have to contact him and he will tell you himself... whether he has free time, willingness, resources for service reference codes, ... etc. ... for the creation and care of other picons :-/.

Hi cpr43 .

This is more of a question for the creator and designer of the picons - a question for chocholousek . I am just a plugin developer for these beautiful picons from Chocholousek, which are available in all the most popular image resolutions.

I really don't know if Chocholousek has the desire and free time to create picons even for satellites on the North American continent (USA). That would probably also mean reworking the plugin for changing the US / EU locations.

What are the service reference codes and standards in the USA for satellite reception ? Are they the same as in Europe ? Does this mean that DVB-S2 is used there for satellite TV reception ?

If you want to make a CFE boot-loader backup, I also own a Vu+ Solo SE V2, so I could make a CFE backup. But I don't know how to do it in Linux Shell... or if it's even possible in Linux Shell.

I wouldn't bother with that. I would buy a new device. For example, Vu+ Zero 4K.

Damage to the CFE-bootloader code block is unlikely, as the CFE bootloader itself works OK. CFE booloader already reports the error - when it is booting. So it's probably not a bug in the CFE bootloader itself.

I have a bootloader for Vu+ Solo SE (also V2 is the same) in my PC, but I don't know where I got it from. Of course, it is flashed by hardware - via RS232. The flashing procedure should also be sufficient via a USB memory stick (it is the same procedure as when flashing Enigma2).

So I thought... that maybe you used the wrong firmware... and changed the names of the folders to your liking... and then overwrote the firmware in your device with a bad version, intended for a different type of Vu+.

That's right, there are some errors at the end of the CFE log.

However, you asked about flashing procedures, and when the CFE bootloader responds and can load files from a USB memory stick, the error lies elsewhere.

The cause can be any HW problem. For example, problems with internal flash memory or RAM. It may not be a directly faulty part of the cells / blocks in the memory modules, but it can be, for example, the power supply of the memories. The cause can be, for example, "cold connections" on the PCB (poor connections). It's hard to say where the error is. It could be anything else.

You should buy a new set-top box when you have these hardware problems.

Or try asking on some Vu+ focused discussion forum.

Hi hecha71 .

The standard method of flashing the set-top box via an inserted USB memory stick - does not work ? I mean this method (valid for all Enigma2 firmwares): https://wiki.openpli.org/Recei…ow_to_flash_Vu.2B_Solo_SE

Note for OpenATV firmware:

In case of using OpenATV firmware, delete the file named "splash.bin" from USB memory stick. This file will rewrite the logo of the Vu+ device that you see immediately after turning on the set-top box to the ATV design (you will see the ATV advertisement after turning on the set-top box). So it is better to delete this one file.

According to the attached log file, CFE works and normally searches for and tries to flash firmware from USB memory devices:

CFE initialized.
USB: New device connected to bus 2 hub 1 port 1
USB: Resetting device on bus 2 hub 1 port 1
USB: [Transfer error: 5]
USB: Device disabled due to communication error!
USB: Bus 3 Hub 1 port 1 in overcurrent state...not re-enabling power
waiting for usb...done
checking usb
No Priority Usb
checking front key
readFrontKey 0 0
Checking usbdisk0:/vuplus/solose/ignore.update......NO
Checking usbdisk0:/vuplus/solose/force.update......NO
Checking usbdisk0:/vuplus/solose/cfe_cfe_auto.bin......NO
Checking usbdisk0:/vuplus/solose/root_cfe_auto.bin......NO
....NO
Checking usbdisk0:/vuplus/solose/splash_cfe_auto.bin......NO
Checking usbdisk0:/vuplus/solose/kernel_cfe_auto.bin......NO