Posts by s3n0

    jhon32:


    WTF ?!


    I've written in several consecutive posts that the firmware is probably irreversibly damaged, as I've also written that I don't have this problem.


    Also I've written ... that the firmware doesn't belong to me. I'm not an interviewer. I did not write the initial question. You don't have to show me anything to try :). And I repeat once again the sentence you quoted but did not read:


    Quote

    ... I don't have a full-fledged Linux ...

    Hi.


    According to the Open-Source code (official), in one of the following directories:


    https://trac.streamboard.tv/os…owser/trunk/oscam.c#L1662


    You can also work on physical Oscam config-files directly via the Oscam-Webif - via the "Files" menu. There you will also see the contents of "oscam.server" and you can even edit and save it if needed.


    If you use a modified, modified, special Oscam, then unfortunately the file name may be different ... for example, for NCam the file name is valid as: "ncam.server", "ncam.config", etc. .


    You can also use the Shell (command-line) to search some files:

    find / -name "oscam.server"

    Guys, why do you write such complicated procedures ? :)


    There are only 4-5 values, which you just need to copy from the file "oscam.server", to the file "/etc/CCcam.cfg" :) but in a different format. A fifth value (key) is also required for the Newcamd protocol - Open atv 6.2 latest stable oscam . That's all.


    It's really simple. You don't need any tools above. You need some text editor only and some tool with a external FTP connection. Both things together in one, you have it, for example, in the file manager - Total Commander.

    As I wrote, it will probably not be possible.


    Although I don't know this compressed file-system (CramFS) from Linux, the file information, in this short "cut out" firmware, is probably just a reference to the location of the disk where the data is to be stored. However, part of the firmware (disk) with the stored data of these files is probably missing - it is not the complete firmware that is backed up, but only a short part of it.


    So it probably won't be possible.


    But maybe I'm wrong. I don't know CramFS well, as I wrote.

    Hi.


    This is probably a bug of the tuner software driver from the set-top box manufacturer, developed for Enigma2. Or maybe it's the fault of Enigma2 itself. If you leave the tuner and start watching another source, Enigma2 should interrupt (release) the tuner.


    For example, this can be done, for testing purpose, using the OpenWebif API, via the shell:

    wget -qO- "http://127.0.0.1/api/zap?sRef=0"

    If, on the other hand, you want to zap some channel, then write the SRC code of a specific channel there, such as:

    wget -qO- "http://127.0.0.1/api/zap?sRef=1:0:19:3731:C8E:3:EB0000:0:0:0:"

    Of course, this is just to test the functionality - with the help of the OpenWebif API and your problem will not solve this.


    Write which Enigma2 you specifically use and which build/version is it.


    Or write more information about the Oscam. If the problem really only concerns Oscam, then there may be a problem in Surflock or a similar problem - if you start decoding two channels or more at the same time, the card will "lock" for a while and may only help if the card (Oscam) is restarted.


    If it is not a Surflock or similar feature, then there may be a problem with the DVBAPI user. This DVBAPI user is in charge of using Oscam as a client, not just as a server. Do you have the DVBAPI settings OK ? Try adding it if you don't have it, in the "oscam.conf" file, under the dvbapi section, write: boxtype = dreambox (I don't know if it will help).

    Hi.


    I don't know the SECA system. But I'll try to advise you.


    You could also write the name of your DVB provider, to search for configurations on the Internet, in case it still doesn't work for you. Certainly, various oscam-configurations for SECA mode can be found on the Internet.


    Packets regarding decoder cards can be divided into two groups, namely EMC and EMM. EMCs are designed to decode a DVB stream and EMMs are command packets. EMM packets need to be written to the card. You probably didn't set them to write to the card (AU - AutoUpdate). You can also see in the log that you have invalid date of entitlements, so it is not possible to prove anything. This should be resolved by enabling AU (allow to write EMMs to your card) - https://wiki.streamboard.tv/wiki/OSCam/en/AU.


    The "oscam.server" and "oscam.user" files (https://wiki.streamboard.tv/wiki/OSCam/en) may be sometimes important for the Oscam configuration - especially if you want to use AU feature.


    Back up + delelte all your current config files for now... and try a clean configuration:

    Because your notepad++ is weird or misconfigured. PeaZip archiver is used for other purposes ... these CramFS formated files can also be opened in a 7-zip archiver. Simply put, PeaZip understands this file as a standard archive (see file properties). Notepad++ understands it as a text file (with detection of an incorrect code page, as the format of the binary file is unknown / incorrect according to Notepad++).


    Use only proven tools for working with compressed CramFS !

    Hi.


    This is probably an incomplete and corrupt file (compressed filesystem - CramFS).


    It is not possible to unpack it with the help of "7z" archiver and also with "fsck.cramfs" command:



    Code
    root@vusolose:/media/hdd/e2# fsck.cramfs --extract=/media/hdd/e2/unpack dreamup-backup-dm500s-TE28F640.img
    fsck.cramfs: file extends past end of filesystem
    fsck.cramfs: crc error


    EDIT:


    Maybe you could use the "binwalk" tool https://www.refirmlabs.com/rev…rs-firmware-with-binwalk/ , but unfortunately I don't have a full-fledged Linux machine available at the moment. I only have a depleted set top box with Enigma, where the binwalk tool does not exist on Enigma's feed servers :).

    Hi.


    I tested the Ncam 10.8 build: "Copyright (C) 2015-2020 Updated and patched by RAED (Fairbird) and Open Vision Developers".


    I tested it as a softcam-client, on the CCCAM protocol (switched from the default 2.0.11 to 2.3.0). I tested the mipsel version on the Vu+ Solo SE V2 device (OpenATV 6.4). Everything ran stably and without problems. If I test the latest original Oscam 11689 in this way, it will turn off after a few hours (the whole oscam process will crash and be freed from linux memory). However, Ncam 10.8 (by RAED) works in the client position, on the CCCAM protocol completely correctly (mipsel, Vu+ Solo SE V2, OpenATV 6.4).


    Of course, crash of the Oscam-11689 (as a softcam-client) can also be in small deviations of different libraries and their functions. BTW, I am using original Oscam build by @juli13.

    .atari.


    One of the examples that I noticed as a big problem in the connection of two Oscams (in the primary box as an Oscam server and in the secondary box as an Oscam client, CCCAM connection). Here is it:


    =============================================

    Problem with large times in case of ECM requests:


    (on the Oscam softcam side, which is in the position of cccam-client)

    =============================================


    If I initialize Oscam as a softcam-server on the main box

    + initializing Oscam as a softcam-client on the secondary box,

    and as a communication softcam protocol I will use CCCAM,

    then there is a problem with too large ECM response times (approx. 200-3000 ms),

    on the Oscam softcam side, in the position of cccam-client, in the secondary box.


    I tried to solve this in several standard ways.

    Restarting the Oscam server and restarting the Oscam client did not help.

    Changes in the cccam version of the communication softcam protocol do not help either.

    They do not help any other configuration changes on both sides.


    However, one trick will help here, as I have found so far:

    ---------------------------------------------------------------------------------

    On the secondary box side, I switch the softcam from Oscam to Cccam (v2.3.0, mipsel) - just for a few seconds.

    Then back again - I switch the softcam from the temporary Cccam, again to Oscam.

    And from now on, the ECM responses in the secondary box (via Oscam) will be normal again - i.e. approx. 80-90ms.


    I don't know why.

    Apparently the Cccam-mips-2.3.0 softcam (in client position - on the secondary box) will start sending some "correct" packets via the CCCAM protocol.

    It will probably send something to the softcam server that it cannot send to Oscam softcam as a cccam client.

    As if this special setting was set by this Cccam-softcam client, in the Oscam-softcam server, via a regular old functional reliable CCCAM protocol.

    And then the ECM responses are OK again (approx. 80-90 ms).


    -------------------------------------------------------------------------------------

    --- devices: Vu+ Solo SE V2 & Formuler F4-Turbo (mipsel chipset at both of them)

    --- enigma: OpenATV 6.4

    --- softcams: Oscam 11689 & CCcam v2.3.0

    --- DVB: SAT / IRDETO

    Hi.


    Do you mean CacheEx ? If so ... have you activated and set the whole CacheEx principle correctly? A configuration guide + some examples, here:

    OSCAM Cache-EX Tutorial v2.0


    Some configuration items have been changed ... check that you have them correctly:

    https://wiki.streamboard.tv/wi…n/Config/oscam.conf#Cache


    Example:

    Code
    [cache]
    max_time = 15
    max_hit_time = 25
    max_count = 5000
    cacheexenablestats = 1

    You will probably need to use this on both sides - for both Oscams.

    Hi.


    Does anyone know the difference between the two configuration items mentioned (in the oscam.conf file) ?


    I searched for info on the internet but I didn't find anything specific ... and even on Wiki-Streamboard there is no specific info for these items.


    If I use the configuration item httppiconpath = /path-to-picons to specify the path to ordinary PNG picons (according to SKIN), then I do not see any picons in Oscam Webif. But if I use the item httptpl = /path-to-picons, which points to the TPL (template/base64) picons, then the picons are visible in Oscam Webif.


    I assumed that httppiconpath is for PNG files, but that's probably not the case. I don't know what this httppiconpath folder is for.


    Of course, I also use the necessary configuration item httpshowpicons = 1. But that's probably irrelevant. I always use this configuration item.


    So what is the difference between the two configuration items ? Is it just for historical reasons that there are two and for the same purpose ?


    Thanks.