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 #881 peteru

  • Senior Member
  • 36 posts

+5
Neutral

Posted 15 June 2015 - 08:19

enigma2 "coding standards" are anti-pythonesque. IMNSHO having tabs in Python code is madness. In fact, using tabs in any source code could be considered anti-social behaviour. :P

 

But +1 for at least making the code self consistent. Mixture of spaces and tabs is totally unacceptable.


"Beauty lies in the hands of the beer holder."

 


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

  • PLi® Core member
  • 46,960 posts

+541
Excellent

Posted 15 June 2015 - 14:17

Merge request:

I'm not a big fan of whitespace fixes, but for xmltvimporter/EPGImport it is really necessary.
The code is almost unreadable unless one makes insane adjustments to the editor.
A mixture of spaces, tabs, "half tabs", trailing whitespaces and so on ...

attachicon.gif0001_xmltvimport-whitespace.patch

You might need to search and replace the path specs inside the diff/patch, as I made the patch against persian pro's OpenPLi-Github.
Sorry about that, but I would have preferred simply creating a pull request on Github ...

What whitespace did you replace the existing whitespace with?


* 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 #883 Erik Slagter

  • PLi® Core member
  • 46,960 posts

+541
Excellent

Posted 15 June 2015 - 14:22

enigma2 "coding standards" are anti-pythonesque. IMNSHO having tabs in Python code is madness. In fact, using tabs in any source code could be considered anti-social behaviour. :P

 

But +1 for at least making the code self consistent. Mixture of spaces and tabs is totally unacceptable.

Then at least we agree on one thing, mixing of tabs and spaces is evil.

 

I don't think "anti-pythonesque" is bad (for the C code, at least ;))

 

I think using spaces for indenting in any code is anti-social behaviour. Using tabs means every 1 tab is 1 indent, no confusion possible. If I want to have the indents 8 wide (heaven forbid...) I can arrange for that by setting the tab width to 8 and nobody will notice. Using spaces, everyone uses another indent width (most seen 2,3,4) which is annoying and also very difficult to change afterwards.

 

So, I don't understand what so many people have something against the tab. Probably just a "less than perfect" editor?


Edited by Erik Slagter, 15 June 2015 - 14:22.

* 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 #884 peteru

  • Senior Member
  • 36 posts

+5
Neutral

Posted 15 June 2015 - 16:32

If tabs are used properly, then they are mostly fine. However, a lot of people and also a lot of text editors will not do the right thing and will mix tabs and spaces with the assumption that the width of the tabs is some arbitrary x.

 

Only using spaces removes the ambiguity, but most importantly it makes it less likely for above mentioned people and tools to create a mess.

 

I too would prefer tabs, but only if they are used properly. Unfortunately as we have seen, people can't be trusted to do it right.

 

One thing that may help is the use of modelines, but the lack of standards and varied editor support probably wouldn't make it practical. I prefer the legible modelines used by kate component over the cryptic vim style:

# kate: replace-tabs on; indent-width 4; remove-trailing-spaces all; show-tabs on; newline-at-eof on;
# -*- coding:utf-8 -*-


"Beauty lies in the hands of the beer holder."

 


Re: merge requests for PLi's git #885 WanWizard

  • PLi® Core member
  • 68,625 posts

+1,739
Excellent

Posted 15 June 2015 - 16:46

So because some people are morons (when it comes to setting up their editor properly), the rest of the world should follow them?

 

Luckily in some editors fixing it is a piece of cake: in Geany for example: Ctrl-A, tab, shift-tab. Problem solved. ;)

 

Only problem with that is that probably your python won't run anymore, due to it's dependence on proper indentation (whitespace relevance, another horrible invention).


Currently in use: VU+ Duo 4K (2xFBC S2), VU+ Solo 4K (1xFBC S2), uClan Usytm 4K Pro (S2+T2), Octagon SF8008 (S2+T2), Zgemma H9.2H (S2+T2)

Due to my bad health, I will not be very active at times and may be slow to respond. I will not read the forum or PM on a regular basis.

Many answers to your question can be found in our new and improved wiki.


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

  • Senior Member
  • 1,030 posts

+65
Good

Posted 15 June 2015 - 18:16

What whitespace did you replace the existing whitespace with?

Tabs of course.

Because I couldn't agree more with your argument that tab is the best char to indent with:
If someone needs 8 chars width to recognize a different indentation level, be it, just set your tab width to 8 and you will have ultra-easy to see indentation levels.
When you are happy with two chars for an indentation level, set the tab width to 2 and you are all set.

This code however had blanks for indentation in one line, tabs in the next, followed by a mixture of both in the third line ..
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 #887 SpaceRat

  • Senior Member
  • 1,030 posts

+65
Good

Posted 15 June 2015 - 18:20

BTW:
This error still exists in the PLi code, probably due to the unreadable indentation:
https://github.com/o...0ea88db7a12459e
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 #888 Erik Slagter

  • PLi® Core member
  • 46,960 posts

+541
Excellent

Posted 16 June 2015 - 12:36

I'll have a look shortly, can't do it right now. Please remind me if I forget.


* 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 #889 christophecvr

  • Senior Member
  • 3,131 posts

+140
Excellent

Posted 17 June 2015 - 08:09

enigma2 "coding standards" are anti-pythonesque. IMNSHO having tabs in Python code is madness. In fact, using tabs in any source code could be considered anti-social behaviour. :P

 

But +1 for at least making the code self consistent. Mixture of spaces and tabs is totally unacceptable.

About python I don't what's the best tabs or spaces.

 

About c and c++  the best way is tabs (here the working off code does not depend on indenting). But it's easier to program and makes source more readable.

 

It's evident that a mix should not be used. Most off programmers are using 4 spaces tabs.



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

  • PLi® Core member
  • 46,960 posts

+541
Excellent

Posted 17 June 2015 - 11:19

BTW:
This error still exists in the PLi code, probably due to the unreadable indentation:
https://github.com/o...0ea88db7a12459e

I think somebody with a more thorough knowledge of Python should fix the whitespace felonies there...


* 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 #891 Erik Slagter

  • PLi® Core member
  • 46,960 posts

+541
Excellent

Posted 17 June 2015 - 11:32

Merge request:

I'm not a big fan of whitespace fixes, but for xmltvimporter/EPGImport it is really necessary.
The code is almost unreadable unless one makes insane adjustments to the editor.
A mixture of spaces, tabs, "half tabs", trailing whitespaces and so on ...

attachicon.gif0001_xmltvimport-whitespace.patch

You might need to search and replace the path specs inside the diff/patch, as I made the patch against persian pro's OpenPLi-Github.
Sorry about that, but I would have preferred simply creating a pull request on Github ...

Applied. It applies cleanly, no issues. 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 #892 Persian Prince

  • Senior Member
  • 1,982 posts

+247
Excellent

Posted 18 June 2015 - 18:34

 
for easy read/download/fork ...

Open Vision sources: https://github.com/OpenVisionE2


Re: merge requests for PLi's git #893 peteru

  • Senior Member
  • 36 posts

+5
Neutral

Posted 21 June 2015 - 15:03

Maybe I'm not very good at reading between the lines, but what exactly are you suggesting?

 

Obviously the links above have a lot of repositories, but now what?


"Beauty lies in the hands of the beer holder."

 


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

  • Senior Member
  • 1,030 posts

+65
Good

Posted 21 June 2015 - 15:29

It's just a service from Persian Prince ...

As all devs with a clear mind use github, having other teams stuff on github as well makes it easer to merge and push/pull.

 

We have re-forked the xmltvimporter to oe-a for example:

https://github.com/o...gin-xmltvimport

 

The original fork

https://github.com/o...nce/XMTV-Import

contains unneccessary code drift but also some nice fixes, so I decided it would be better to re-play the history of the first fork on a new fork so that in the end we have the good diffs from both (PLi and andy/oe-a).

 

 

Sadly OpenPLi is still not actively using Github, which would make it much easier for others to create pull requests for fixes (Instead we are still creating patches and uploading them here ... brrrr), but at least we can now easily cherry-pick from PLi thanks to Persian Prince's repos.

 

It's always a shame to see rather small developer communities wasting ressouces in the way PLi does within the E2 community.


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 #895 WanWizard

  • PLi® Core member
  • 68,625 posts

+1,739
Excellent

Posted 21 June 2015 - 17:51

Sadly OpenPLi is still not actively using Github,...
 
Yet, it is being worked on.

Currently in use: VU+ Duo 4K (2xFBC S2), VU+ Solo 4K (1xFBC S2), uClan Usytm 4K Pro (S2+T2), Octagon SF8008 (S2+T2), Zgemma H9.2H (S2+T2)

Due to my bad health, I will not be very active at times and may be slow to respond. I will not read the forum or PM on a regular basis.

Many answers to your question can be found in our new and improved wiki.


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

  • Senior Member
  • 3,131 posts

+140
Excellent

Posted 26 June 2015 - 10:04

I just added a patch which enables cuesheet support for movies who uses servicemp3 . (mkv,wmv,mpeg and ...)

 

This is a general patch should work for all gst versions. With this applied we can set cuts by these movies just like by the recorded once. (ts movies)

 

The patch is in toppic :

 

http://forums.openpl...-71#entry495856



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

  • PLi® Core member
  • 56,275 posts

+691
Excellent

Posted 26 June 2015 - 13:05

I can only push it when someone confirm there are no botlenecks with Gstreamer 0.1... Sorry for that.... But due to lack of time I'm not able to verify it myself....

 

Would be nice to have graphical subtitles enabled aswell ;)


Edited by littlesat, 26 June 2015 - 13:06.

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


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

  • Senior Member
  • 3,131 posts

+140
Excellent

Posted 26 June 2015 - 14:43

I can only push it when someone confirm there are no botlenecks with Gstreamer 0.1... Sorry for that.... But due to lack of time I'm not able to verify it myself....

 

Would be nice to have graphical subtitles enabled aswell ;)

 Really no problem,

 

This patch is experimental, I really hope that a lot off persons testers who build there own image do test it truly out.

 

I'm shure that left and right some improvements must be made. It's the first code I implemented in c++ enviroment. The base code comes well out off servicedvb.cpp  adapted to servicemp3.cpp.

some things like time_shift are taken out since we do not use it in servicemp3.cpp.

 

I well made it like this , since i'm shure it will work in the older gst-010 also.

 

My second thing I will do later on is using the cuesheet for movies who have a chapter info toc. I'm currently thinking (and experimenting to find out the best way to do oh yess I took back my old programming courses with my notes about a flow chat's. Programming was in pascal :P i'm an old chap.   )

 

And yes the graphical suported subtitles are on the program. ;)

But in a later stage.

 

I think it's a good thing to first develop the basic core enigma2 media player to support all. If that player which actually work's very good and is pretty stable and that's the good thing since its real enigma2 core player won't suffer from new kernels glibs,gcc or new kernels the extra plugins can be made to really use the core player. No extra things like implementation off own sinks own gst version will be required anymore.

 

I'm eager on reports off possible bugs and or botlenecks so they can be solved. Also possible c++ better ways is very welcome.

 

This patch is very fundamental and iff ok a very big and ussefull add , however must be tested very good . I tested it on two boxes (dm8000 and vuduo2) and it does work really great. But I well have my personal gst-1.5.1 image. Which on it is more performant then the base gst-0.10 images from pli4.



Re: merge requests for PLi's git #899 Persian Prince

  • Senior Member
  • 1,982 posts

+247
Excellent

Posted 27 June 2015 - 06:40

 

More :

 

https://github.com/OpenHyperCube

https://github.com/OpenTechnomate

https://github.com/OpenDMM


Open Vision sources: https://github.com/OpenVisionE2


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

  • Senior Member
  • 3,131 posts

+140
Excellent

Posted 28 June 2015 - 14:40

Ter info I added in last message two very important and actually they are real upgrades off enigma2 base movie player patches.

 

I well only tested on gstreamer a pli4 image with gstreamer-1.5.1. But the code should work fine as well on gst-0.10.

 

I well think that the hack #define GSTREAMER_SUBTITLE_SYNC_MODE_BUG must be removed asap out off enigma2 even for gst-0.10.

 

All my test shows that this hack may perhaps have a bennific thing in very very limited situations.

 

But the hack on it does make a bug which is huegh very very big in all other situations. It even degrades the base enigma2 player to a unstable player with a severe bug instead off the smal which it is supposed to solve.

 

It just cause the movie to resume always from the very beginning. Does not respect resume position.

 

If due to the bug sync is lossed for subtitles, the user normally just have to push yellow button, the audio menu shows up the scope (cursor) will be on the current used audio stream. Just push ok button and resync process start. Before You can blink with you're eyes the movie is back on track and sync for audio,video and subsink. And all ok.

 

Due to this patch the movie will resume from start which is completely wrong.

 

Read last post patches for introduction off cue sheet and chapter support in gst-1 topic. I did not limit those patches to gst-1 , since I think it will work fine in gst-0.10 images (if #define GSTREAMER_SUBTITLE_SYNC_MODE_BUG is disabled).

 

Topic :

http://forums.openpl...ndpost&p=496075


Edited by christophecvr, 28 June 2015 - 14:43.



0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users