Posts by Schreibwaise

    There is not everything gold at Tvh, ofc but it just works, gets proper developed and has a ton of functions and is an feature complete replacement of VDR (server side). And I guess the most single pro is a good working web admin interface.

    Probably you are right, and I'm biased here. I did set up Tvh two or three times and the web interface has been driving me crazy. But it's probably just me not understanding how it is supposed to get used :)


    But I do not use any advanced or sophisticated features, so going with vdr is just straight forward for me. Might change in the future of course.

    We like to keep LibreELEC as slim as possible. And really, not every Kodi user will use NFS server and MySQL by default.


    I still hope that at least an NFS server will make its way into LibreELEC. The "bloat" really is neglectable and there is also a political/philosophical dimension: Without Linux and Open Source there would not be a LibreELEC at all and so it is sad to see Linux users being treated as second class citizens :(


    If being "slim" is really the top priority, then LibreELEC should drop support for ext4 and use NTFS for storage :)


    (Yes, I know that at least user space nfsd is available as an addon...)

    btw is there some docker or something that allows to test it ?

    as far as I understand you need other "infrastructure" too to make it work, I like to test it and ofc document

    What do you mean? The vdr plugin magicamun is trying to build?


    Honestly, I have no idea. I do not use that plugin myself. Following this thread mainly for learning more about the buildsystem. And with your very valuable comment it was already worth it!

    it is very likely that you leak host system versions and packages if doing so :)

    there is no single reason to do it that way besides saving 25 characters typing/pasting :)


    btw do not remove the strip stuff from your 8.2 build, there is no proper stripping at LE8.2 - you need to manually enforce it

    Yes, I understand. It could explain that my arm builds are so much more stable than my x86_64 builds :) Big thank you!!!


    As for the stripping: I just copied the stuff from the pre-9.x tree and adapted the package.mk files. But it seems that somewhere during the build the debug information got stripped nevertheless. Does not really matter anyway :)

    ./scripts/create_addon vdr-addon

    this is nothing you should do, unexpected things may happen as it takes host stuff into the build


    PROJECT=Generic ARCH=x86_64 scripts/create_addon vdr-addon is the correct cmd to build an addon since at least LE7

    PROJECT=Generic ARCH=x86_64 is the default and always works for me. I only specify these values when building for non-x86_86 hardware such as arm.


    After thinking more about it, I think you are right and I should explicitly specify these values always. Thanks for pointing this out! Maybe I was just lucky that it always worked, but I cannot be sure the correct compiler and linker was used.

    Maybe you could check for differences between your tree and mine:


    Create a test branch:


    Code
    1. git checkout libreelec-8.2
    2. git branch test
    3. git checkout test

    Get the diff from here and apply:


    Code
    1. patch -p1 < /tmp/vdr-2.3.8-le-8.2

    Then check the differences:

    Code
    1. git diff -r <your-branch> -r test

    Maybe you unintentionally changed something else during your backporting.

    Just did a test build of LE 8 with vdr patched to 2.3.8 and it was successful running these commands:


    Code
    1. ./scripts/build vdr-addon
    2. ./scripts/create_addon vdr-addon
    3. l target/addons/8.2/Generic/x86_64/service.multimedia.vdr-addon/
    4. total 4428
    5. drwxrwxr-x 2 linux linux 4096 Mar 18 15:12 resources/
    6. -rw-rw-r-- 1 linux linux 4529052 Mar 18 15:12 service.multimedia.vdr-addon-8.2.105.zip

    Sorry I missed your question, I don't know I'm afraid, I don't use this addon but I do compile the latest versions of all the addons each time I do a new release and visualization.shadertoy was last updated on 1st Feb.

    Last time I tried no visualization was working for me on HTPC (only tried goom and projectM), so I do not think this is a problem of shadertoy or the architecture.

    It's odd though that your remote suddenly starts lagging. My first guess is that kodi is busy and can't immediately process the remote events. I've been experiencing this on my RPi1 when kodi is updating addons after startup - top shows kodi.bin using all CPU resources and after a minute or so when addons have been updated things (CPU usage and remote response) are back to normal.

    Are we talking about this remote?


    If yes, it would be interesting to know whether the control-LED is still working when the remote starts to become unresponsive.


    I do not think the problem is in kodi. At least I was having a very mysterious problem on one of my LE systems. I know that kodi is not busy at this time but it felt like the USB port got temporarily disabled.


    As I still had a DIJ receiver at hand and found some no-name remote in a drawer, I finally gave up with the USB remote on this specific system and am now using this other remote on the serial port. Works like a charm. Only issue I ran into was with setserial. The busybox developers decided that it would be a clever idea to rename the option for disabling the uart from "none" to "unknown". Which seems to serve no other purpose than rendering the helpful system log messages useless and confusing people :(

    Without dtb.img it started well, playing videos well. But looks IR doesn't work for Beelink GT1 Ultimate.

    Is it possible to fix IR problem?

    Thank you!

    You do not provide enough information on what exactly is failing. Have a look at this great tutorial. Worked perfectly for me. What is the output of ir-keytable? If you get an error message about missing /sys/class/rc/rc0/, your hardware probably is not detected correctly which could point to the missing/wrong dtb.

    Just checked: The kernel that gets used by current head (4.14.24) already knows about the device ID and the firmware files are present as well. But it is still not recognized. As I'm mainly using wired network only I do not have that much experience with this WLAN stuff so I cannot really help much except doing some testing :(