[LEDE-DEV] Kodi

Stijn Tintel stijn at linux-ipv6.be
Wed Mar 15 23:34:14 PDT 2017


On 15-03-17 13:45, Mirko Vogt wrote:
> On 03/15/2017 11:57 AM, Daniel Engberg wrote:
>> Hi,
> Huhu,
>
>> While I applaud your achievement I'd don't see such projects viable in
>> terms of maintainability and longevity.
> Applauds from me as well! I started doing so with XBMC a couple of years
> ago and eventually gave up..
Thanks! Took me about a week, mostly because I only fixed the issue
breaking make -jN with N > 1 near the end of that week. Parallel build
works fine now, and I'm actually impressed with how fast it builds.
>> Pulling in Kodi will result in lots of external packages and
>> dependencies to make it usable in a reasonable way.
> Sorry, but I totally disagree.
> I always saw (and still see) OpenWrt/LEDE as a toolchain and Linux
> embedded distribution - *not* just for routers.
This is even mentioned in the very first section on
https://lede-project.org/
>
> Me and few others already started very early to get it running on rather
> unusual devices (landline phones, mobile phones, digital picture frames,
> even (mini) notebooks (OLPC, Qi NanoNote, etc.)).
>
> Almost a decade ago by now we ported Xorg and all it's dependencies to
> OpenWrt/LEDE. Later on GTK, enlightenment and its EFL stack, Qt and what
> else. Although the xorg-feed is not in a good shape anymore (and I
> rather discourage anybody from using Xorg if there's no real need for a
> windowing system), lot's of stuff remained, is still maintained and used.
> The new video feed is supposed to be kind of a reincarnation of the
> outdated xorg feed.
Where can I find this Xorg feed? I looked for it but was unable to find
it. Probably didn't look hard enough.
> I highly encourage approaches like those and don't see any need for
> forcing OpenWrt/LEDE being only a router distribution.
> This only counts of course, if one approach doesn't interfere with the
> other. So let's come to your concrete issues:
>
>> There are several issues with this:
>>
>> * In general binary size > performance and/or functionality pretty much
>> always takes priority, this is a major issue when it comes to multimedia
>> (ffmpeg and friends comes mind).
> I fail to see in which way additional packages - in this case:
> dependencies for Kodi - do add size/performance issues the existing
> device configurations.
>
>> * It's more or less duplicating work already done by projects like
>> LibreELEC, OSMC etc.
> Then all work for OpenWrt / LEDE is duplicated work already done by
> Gentoo (emerge build instructions), Debian (deb rules-file),
> OpenEmbedded, you name it...
I tried OpenELEC in the past, and while it worked without much issues, I
didn't quite like the fact that it runs everything as root, and that
it's near impossible to do anything else than kodi with the device.
Haven't tried LibreELEC, but it looks like it still has the same
limitations. I have no experience with OSMC.

In fact, I did not intend to use my RPi0W as a media player at all, but
then I figured using HDMI would much improve the sound quality compared
to A2DP (which is currently my only other option at this location).
Sure, if it's just for audio I can use mpd as well, but I would still
have to watch stuff on my tablet.

For me it is all about using my favorite embedded distro with all its
awesomeness, and running my favorite media center software on top of it,
while still being able to use the device for something else.

>
>> * You'll need to import a lot more of 3rd party libs and applications to
>> make it a viable/reasonable user experience and there's a overall
>> concern about build performance of the buildbots.
> I heard that buildbot performance argument quite often. Back then, I
> eventually gave up, excluded the xorg-feed from the default feeds.conf
> and problem solved.
> Funny enough however, the discussion comes up every now and then again.
> Last time - without me re-initiating it nor taking sides - quite a few
> people who're participating at OpenWrt/LEDE for a long time by now,
> tried to encourage me to migrate the video feed into the packages feed.
>
> Right now I'm fine with having the extra video feed and maybe will open
> up the discussion about having it enabled by default some day. So, no
> additional build time (for now).
I feel there's enough interest in having Kodi on LEDE, so I'll try to
clean up my work and publish it at least somewhere. Whether it will
eventually end up in packages or somewhere else, is a decision that can
be made when it is ready. Personally I don't like having too many
different feeds, as I think it is confusing for users, and it seems to
give people the idea that maintaining their own feed is a good idea.
Seen too many feeds already with a few packages that would be
interesting to have in the packages feed, but people never bothered
submitting them. I'd rather have a few feeds with a well defined set of
rules, and a lot of people working on them, than having packages
scattered over numerous mini feeds, many of which people don't even know
about.
>
>> * Will anyone properly maintain all packages? We're already now
>> struggling keeping the current repo somewhat up to date and
>> maintainable, adding very niche packages certainly won't help.
> This is indeed arguable, but come on, the situation got *a lot* better
> over the past years and we can always kick out packages which are not
> maintained anymore. No need to deny porting efforts because some day it
> might not be maintained anymore...
I don't think the current situation is very relevant. I am never going
to maintain packages I don't use, so whether or not I decide to maintain
Kodi and dependencies doesn't change anything for those packages. What
we do need is better rules. But that discussion is off-topic here, feel
free to start a new thread for this.
> If concerns however outweigh the benefit I see, I'm more than happy to
> host Kodi and its dependencies in the video feed and risk it not being
> enabled in feeds.conf.default anytime soon.
Thanks, I'll keep the offer in mind.

Stijn




More information about the Lede-dev mailing list