Jump to content


Photo

merge requests for PLi's git


  • Please log in to reply
1748 replies to this topic

Re: merge requests for PLi's git #541 christophecvr

  • Senior Member
  • 3,131 posts

+140
Excellent

Posted 13 April 2014 - 14:17

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.



Re: merge requests for PLi's git #542 SpaceRat

  • Senior Member
  • 1,030 posts

+65
Good

Posted 13 April 2014 - 14:29

@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 ...
1st box: Vu+ Ultimo 4k 4xDVB-S2 FBC / 2xDVB-C / 1.8 TB HDD / OpenATV 6.2
2nd box: Gigablue Quad 4k 2xDVB-S2 FBC / 2xDVB-C / 1.8 TB HDD / OpenATV 6.2
testing boxes: Vu+ Duo² + AX Quadbox HD2400 + 2x Vu+ Solo² + Octagon SF4008
Sats & Pay-TV: Astra 19.2°E + Hotbird 13°E with Redlight / SCT HD / SES Astra HD- / Sky V14 / 4th empire propaganda TV
Card-Server: Raspberry Pi + IPv6-capable oscam
Router: Linksys WRT1900ACS w/ LEDE + Fritz!Box 7390

Re: merge requests for PLi's git #543 christophecvr

  • Senior Member
  • 3,131 posts

+140
Excellent

Posted 19 April 2014 - 12:00

@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.


Re: merge requests for PLi's git #544 Pale-Rider

  • Senior Member
  • 126 posts

+6
Neutral

Posted 19 April 2014 - 12:50

 

@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.



Re: merge requests for PLi's git #545 MiLo

  • PLi® Core member
  • 14,042 posts

+298
Excellent

Posted 19 April 2014 - 13:25

Just look at master-next branch.
Real musicians never die - they just decompose

Re: merge requests for PLi's git #546 athoik

  • PLi® Core member
  • 8,458 posts

+327
Excellent

Posted 11 May 2014 - 10:38

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.


Attached File  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").

 

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

 

Thanks.


Wavefield T90: 0.8W - 1.9E - 4.8E - 13E - 16E - 19.2E - 23.5E - 26E - 33E - 39E - 42E - 45E on EMP Centauri DiseqC 16/1
Unamed: 13E Quattro - 9E Quattro on IKUSI MS-0916

Re: merge requests for PLi's git #547 Erik Slagter

  • PLi® Core member
  • 46,951 posts

+541
Excellent

Posted 11 May 2014 - 11:09

Committed & pushed. Thanks.

* Wavefrontier T90 with 28E/23E/19E/13E via SCR switches 2 x 2 x 6 user bands
I don't read PM -> if you have something to ask or to report, do it in the forum so others can benefit. I don't take freelance jobs.
Ik lees geen PM -> als je iets te vragen of te melden hebt, doe het op het forum, zodat anderen er ook wat aan hebben.


Re: merge requests for PLi's git #548 athoik

  • PLi® Core member
  • 8,458 posts

+327
Excellent

Posted 13 May 2014 - 20:37

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.


Wavefield T90: 0.8W - 1.9E - 4.8E - 13E - 16E - 19.2E - 23.5E - 26E - 33E - 39E - 42E - 45E on EMP Centauri DiseqC 16/1
Unamed: 13E Quattro - 9E Quattro on IKUSI MS-0916

Re: merge requests for PLi's git #549 athoik

  • PLi® Core member
  • 8,458 posts

+327
Excellent

Posted 13 May 2014 - 20:53

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


Wavefield T90: 0.8W - 1.9E - 4.8E - 13E - 16E - 19.2E - 23.5E - 26E - 33E - 39E - 42E - 45E on EMP Centauri DiseqC 16/1
Unamed: 13E Quattro - 9E Quattro on IKUSI MS-0916

Re: merge requests for PLi's git #550 MiLo

  • PLi® Core member
  • 14,042 posts

+298
Excellent

Posted 14 May 2014 - 06:33

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.
Real musicians never die - they just decompose

Re: merge requests for PLi's git #551 athoik

  • PLi® Core member
  • 8,458 posts

+327
Excellent

Posted 14 May 2014 - 09:24

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).


Wavefield T90: 0.8W - 1.9E - 4.8E - 13E - 16E - 19.2E - 23.5E - 26E - 33E - 39E - 42E - 45E on EMP Centauri DiseqC 16/1
Unamed: 13E Quattro - 9E Quattro on IKUSI MS-0916

Re: merge requests for PLi's git #552 Taapat

  • PLi® Core member
  • 2,332 posts

+120
Excellent

Posted 1 July 2014 - 22:34

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



Re: merge requests for PLi's git #553 captnoord

  • Member
  • 22 posts

+10
Neutral

Posted 30 July 2014 - 18:17

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

 

see attached path file

 

Attached Files



Re: merge requests for PLi's git #554 captnoord

  • Member
  • 22 posts

+10
Neutral

Posted 30 July 2014 - 18:28

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

 

Attached Files



Re: merge requests for PLi's git #555 captnoord

  • Member
  • 22 posts

+10
Neutral

Posted 30 July 2014 - 18:47

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

 

Attached Files



Re: merge requests for PLi's git #556 Erik Slagter

  • PLi® Core member
  • 46,951 posts

+541
Excellent

Posted 31 July 2014 - 13:56

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.


* Wavefrontier T90 with 28E/23E/19E/13E via SCR switches 2 x 2 x 6 user bands
I don't read PM -> if you have something to ask or to report, do it in the forum so others can benefit. I don't take freelance jobs.
Ik lees geen PM -> als je iets te vragen of te melden hebt, doe het op het forum, zodat anderen er ook wat aan hebben.


Re: merge requests for PLi's git #557 littlesat

  • PLi® Core member
  • 56,123 posts

+685
Excellent

Posted 31 July 2014 - 17:15

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


WaveFrontier 28.2E | 23.5E | 19.2E | 16E | 13E | 10/9E | 7E | 5E | 1W | 4/5W | 15W


Re: merge requests for PLi's git #558 captnoord

  • Member
  • 22 posts

+10
Neutral

Posted 31 July 2014 - 18:03

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.



Re: merge requests for PLi's git #559 ims

  • PLi® Core member
  • 13,605 posts

+210
Excellent

Posted 31 July 2014 - 18:19

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.

Kdo nic nedělá, nic nezkazí!

Re: merge requests for PLi's git #560 littlesat

  • PLi® Core member
  • 56,123 posts

+685
Excellent

Posted 31 July 2014 - 18:35

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.

WaveFrontier 28.2E | 23.5E | 19.2E | 16E | 13E | 10/9E | 7E | 5E | 1W | 4/5W | 15W



2 user(s) are reading this topic

0 members, 2 guests, 0 anonymous users