1748 replies to this topic

[christophecvr]

Oh and yes:
All versions of vlc 2.1.3 can handle streams transcoded by Vu+ Solo² or Duo² UNLESS a set of unfucked idiots with ash-tray sized glasses at Debian decided to ship a version of libav from 1965 with your OS ...

Yes it's not only Debian but ubuntu ass well. All vlc problems are solved by just updating libav. I already put I note on that. somewhere.

P.s. for ubuntu 12.04 Lts Just at the gstreamer1.0 ppt and içnstall gstreamer1.0 it will automatically upgrade the libav.

 

The new 14.04 Lts ubuntu should come out this month hopefully there they are working with a bit more up to date libs.

[SpaceRat]

@SpaceRat
 
We're looking into the oe-core merge at the moment, which seams like a better option than disabling the heartbeat or applying the patch.

Disabling heartbeat doesn't exactly sound like the worst option to me.
Google has done it all the time in Android without knowing it's a backdoor (It was active on their servers).

The original reason for disabling heartbeats were WLAN problems ...

[christophecvr]

@spacerat,
Can you offer us a patch we can directly commit using git -am

Just merge openembedded-core, they have updated to OpenSSL 1.0.1g (rather than adding just another patch to 1.0.1e):
http://git.openembed...ctivity/openssl

I think merging the whole latest open-embeded-core is a hell of a job since there is a change that a lott off packages do not work anymore. And they need to be adapted ansd so on ...

Think that that will come with the next pli revidion on 4.

 

However I now just tried and used the latest openssl off current master openembedded-core. which is ver 1.0.1g  and this works perfect for dm8000 (which I build obviousely with the correct dvb-dreambox-mediasink whitout the wrong old useless build break  dts-passtrough patch)

Edited by christophecvr, 19 April 2014 - 12:01.

[Pale-Rider]

 

@spacerat,
Can you offer us a patch we can directly commit using git -am

Just merge openembedded-core, they have updated to OpenSSL 1.0.1g (rather than adding just another patch to 1.0.1e):
http://git.openembed...ctivity/openssl

I think merging the whole latest open-embeded-core is a hell of a job since there is a change that a lott off packages do not work anymore. And they need to be adapted ansd so on ...

Think that that will come with the next pli revidion on 4.

 

However I now just tried and used the latest openssl off current master openembedded-core. which is ver 1.0.1g  and this works perfect for dm8000 (which I build obviousely with the correct dvb-dreambox-mediasink whitout the wrong old useless build break  dts-passtrough patch)

 

 

Difficult but by no means impossible, intact Andyblac did just this about a week ago.

[MiLo]

Just look at master-next branch.

[athoik]

Hello,

 

Commit 0067075b24051b08503be52a9c5a2311b0e6605d deleted DTS passthrough and downmix patch.

The only change done in the basic gst-dreambox-dvbmediasink is related with AC3plus not DTS!
 

Here is the patch for OpenPLi OE to bring back DTS Passthrough and downmix.

 0001-Bring-back-removed-the-DTS-Passtrough-and-downmix-pa.patch   3.12KB   8 downloads

 

 

Here is the removed patch from dvbmediasink (patche created for SRCREV = "7671ff6f07a70151ef183e0f501097de5cf7f1b3").

 

 0001-Handle-DTS-Passthrough-and-Downmix.patch   1.62KB   5 downloads

 

Thanks.

[Erik Slagter]

Committed & pushed. Thanks.

[athoik]

Hi @MiLo,

 

Commit Split out vendor specific overlays introduced new issues because of FILESEXTRAPATHS_prepend.

 

FILESEXTRAPATHS_prepend := "${OPENPLI_BASE}/meta-openpli/recipes-linux/linux/files:"

 

When a patch with the same name exists localy and also on "${OPENPLI_BASE}/meta-openpli/recipes-linux/linux/files:" it will choose the "files" version, resulting in patch not applying.

 

Eg. mips-refactor-clearpage-and-copypage.patch (http://sourceforge.n...copypage.patch, http://sourceforge.n...-copypage.patch)

 

I guess adding FILESEXTRAPATHS_append is the correct way to keep compatibility.

[athoik]

Or just rename it? mips-refactor-clearpage-and-copypage.patch -> dmm-mips-refactor-clearpage-and-copypage.patch

[MiLo]

When a patch with the same name exists localy and also on "${OPENPLI_BASE}/meta-openpli/recipes-linux/linux/files:" it will choose the "files" version, resulting in patch not applying.

I guess adding FILESEXTRAPATHS_append is the correct way to keep compatibility.

You're correct, "append" is the better option here. Local versions should have precedence.

An alternative is to remove the central include and copy the patches to the layers.

I also forgot to move the machine.conf to vendor-specific locations.

[athoik]

An alternative is to remove the central include and copy the patches to the layers.

 

Yep, that would nice too.

 

find meta-* -type f | xargs fgrep mips-refactor-clearpage-and-copypage
meta-dream/recipes-bsp/linux/linux-dreambox_3.2.bb:                     file://mips-refactor-clearpage-and-copypage.patch \
meta-vuplus/recipes-bsp/linux/linux-vuplus-3.1.1.inc:   file://mips-refactor-clearpage-and-copypage_311.patch \
meta-vuplus/recipes-bsp/linux/linux-vuplus-3.3.8.inc:   file://mips-refactor-clearpage-and-copypage.patch \

 

Actually "files/mips-refactor-clearpage-and-copypage.patch" should move into vuplus 3.3.8 and "files/mips-refactor-clearpage-and-copypage_311.patch" into vuplus 3.1.1, since those files related only with one machine (they are not global files).

[Taapat]

Looking at enigma startup log I see two errors.

 

The first is the same as I have already asked a pull request in skin-PLiHD.
I am using the latest libpng 1.6.12 in my SH4 receiver. I have error:

[SKIN] parsing embedded skin <embedded-in-'Screensaver'>
libpng warning: ICCP: Incorrect known sRGB profile. 

Looking at the changes in the libpng code I see that in libpng 1.6.2 has added the warnin. The error is also in earlier versions, but there's no warnin in the console.
I found that the error is due to anniversaryOpenPLi.png. I am using:

pngquant --ext .png --force 256 anniversaryOpenPLi.png
optipng -o7 anniversaryOpenPLi.png 

That so anniversaryOpenPLi.png have the correct sRGB profile and optimized.

 

The second error is:

[Skin] Error: {} dTV-HD-Reloaded/skin.xml: color 'secondBG' must be # Aarrggbb or valid named color. Please contact the skin's author! 

Color secondBG used in ScreenSaver and AudioSelection but not defined in my skin.
I think the colors used in the enigma, it is necessary to define in skin_default.xml. Ask to specify it in all skins in my opinion is wrong. As I understand, if it defined in the basic skin, then skin_default.xml will not be used, and will not conflict.

 

I attach two patch that corrects these small errors.

Attached Files

•  0001-Convert-anniversaryOpenPLi.png-with-pngquant-to-set-.patch   43.94KB   6 downloads
•  0001-Add-color-secondBG-in-skin_default.xml.patch   804bytes   7 downloads

[captnoord]

FIxed mem leak because of mismatching allocation and deallocation in 'lib\gdi\picload.cpp'

 

see attached path file

 

Attached Files

•  fixed-memory-leak-picload.patch   761bytes   26 downloads

[captnoord]

FIxed possible buffer overflow in 'lib/service/servicefs.cpp'

 

Attached Files

•  fixed-possible-buffer-overflow.patch   1.25KB   19 downloads

[captnoord]

Fixed possible case of python vs c++ mixup in 'lib/service/listboxservice.cpp'

 

Attached Files

•  fixed-possible-cpp-python-mixup.patch   3.25KB   35 downloads

[Erik Slagter]

I think these patches need some discussion before they can be applied:

- some changes in functionality are in an area I don't have sufficient expertise in, so we must wait for others to accept

- some changes are purely cosmetic

  * these should be separated from the functional changes

  * not all of them follow the style enigma2 has been programmed in (erm... as far as it's consistent)

  * when not really really necessary we prefer to not touch other's code

 

I'll quote some parts that imho require discussion shortly and then you can comment as well, of course.

[littlesat]

I do not see any real functionality changes....

[captnoord]

If required I can describe exactly what is changed and why it is needed.

The 'enigma2' style is far from consistent, I can if required reformat the
entire file to make it consistent.

There are no functional changes done, you might say that the last patch
changes the flow of setCurrent. But I think its correct.

[ims]

I do not see any real functionality changes....

 

about patch on #555 ... see original .cpp:

bool eListboxServiceContent::setCurrent(const eServiceReference &ref)
{
    int index=0;
    for (list::iterator i(m_list.begin()); i != m_list.end(); ++i, ++index)
        if ( *i == ref )
        {
            m_cursor = i;
            m_cursor_number = index;
            if (m_listbox)
                m_listbox->moveSelectionTo(cursorResolve(index));
                return true;
            break;
        }
    return false;
}

when "*i == ref" then it finisthing always the loop and returns "true".

May be, it has not effect in  global but code is wrong.

Edited by ims, 31 July 2014 - 18:21.

[littlesat]

I think that part should be...   ...so in fact it was wrong as it is now...

 

 

bool eListboxServiceContent::setCurrent(const eServiceReference &ref)
{
    int index=0;
    for (list::iterator i(m_list.begin()); i != m_list.end(); ++i, ++index)
        if ( *i == ref )
        {
            m_cursor = i;
            m_cursor_number = index;
            if (m_listbox)
            {
                m_listbox->moveSelectionTo(cursorResolve(index));
                return true;
            }
            break;
        }
    return false;
}

Edited by littlesat, 31 July 2014 - 18:35.