Posts by Hauke

    Oh, stupid me... I am currently juggling two LibreElec images, because of the Bug I observe (described here), and the music problem is with the rather old kszaq-image (btw. FullHD). The current Beta is not showing the problem. I mixed that up!

    Sorry for the confusion!

    Hi all,


    I use LibreElec on my Le Potato, and just experienced a thing that surprised me: While listening to music from my MP3 library via the network, I startet scrolling the list of videos from one of membranes mediathek-addons. Whenever I used the scroll wheel of my mouse to quickly browse through the entries, the music started stuttering - just very short, but well audible breaks in the sound. I was surprised in many ways: First, Le Potato is a quad-core CPU device, so if a CPU core would be busy playing the MP3, the other three should be idling and take over the scrolling. Second, MP3 is not too demanding for an [email protected] GHz, so I'd not even expected overload if the same core was used. And finally, the scrolling I'd have expected to be offloaded to the GPU anyhow, not really bothering the CPU. Are my assumptions stupid? Is there something I might have done wrong during setup or else?


    Cheers


    Hauke

    Well, even if the bug is not fixed, do not despair: The mainline kernel is around the corner also for Le Potato, and then all problems should be gone. I think only very few devices still use the 3.x kernel, and if you do not own such a device, you're safe now.

    Sorry to say, but I was a bit too fast with my assessment. It is *nearly* flawless. The continuity errors on receiver 2 are gone, but funny as it is, now receiver 1 has occasional continuity errors, but very few. Changed the receiver priority in tvheadend so that receiver 2 is default - fine for the moment. Seems I have to wait for mainline kernel after all :-)

    Hi folks,


    also from my side a lot of thanks for the good work!


    I switched from the now one-year-old kszaq-image for LePotato to 8.95.2 Beta, and have one problem: Some MP4 movies (VLC says: H264 MPEG-4 AVC (part 10)) do not work (they did with the old image). When I start them, there is no sound, picture is lagging, and, when opening the navigation bar, the current position is shown as a negative number (see screenshot).




    Some other MP4's work. As far as I can tell the only difference is the audio track: Those with problems have MP3 sound with 192k, those that work have AAC, both with 48 KHz sampling rate.

    Other things also hint at an audio problem: When I, while the faulty movie stutters along, open the audio settings from the lower right menu and toggle passthrough audio, for a short while audio is OK, but severely offset by seconds, and also the time is displayed correctly. Regardless if passthrough was on or off beforehand - just toggling it does the trick. If I played a faulty movie, stopped it and then started a "good" one, sometimes audio is played way too slow, al voices sounding as if they came directly from the crypt.

    I played around with some audio options, namely passthrough and sample rate adjustment, but nothing seems to help.


    How can I provide helpful information? I can provide example movies upon request.


    Cheers


    Hauke

    Hi guys,


    just updated to LibreELEC (Leia) v8.95.2 BETA on my Potato - and lo and behold! - despite still having kernel 3.14, both tuners of the WinTV dualHD work flawlessly! Not sure what you changed, but it did the trick. Thanks a lot!


    Cheers


    Hauke

    Is there still much interlaced content? Interlacing in my mind is something outdated from SD TV times, when technology was just not fit for full pictures... But I stand to be corrected.


    Whatever - what I am currently thinking about is just letting run my Raspberry in parallel to Le Potato and point the PVR frontend to the TVheadend on Raspberry with kernel 4.18. Not my long term solution, since it eats up another 5W of standby power, but until Le Potato is fit, it might be a solution.

    Hi CvH ,


    I've just seen that the new release is there, and that CrazyCat drivers are in there in the newest version. Thanks a lot for that! Just tested on Le Potato: It is certainly the best experience I yet had with Kodi on LePotato regarding the Hauppauge DualHD card, but it is still not good. When watching a second channel, I still get too many errors to call the experience enjoyable.

    In the meanwhile I tested with Raspberry Pi and the 4.18 kernel, since Hauppauge claims native support for the dualHD stick starting with kernel 4.17, and I can confirm that the DVB-T2 reception is flawless with 4.18, even watching two channels simultaneaously. Raspberry, even 3B+, ist not powerful enough to watch even a single channel in HEVC (German DVB-T2 uses it), but using TVheadend on Raspberry and a Windows machine to watch the channels works totally fine.

    So, I suppose I need to stay patient until LibreELEC on Le Potato is on mainline kernel... According to a tweet by the Le Potato team, they already did a showcase with LibreELEC and mainline recently, so it seems to be close to reality anyhow...


    I really appreciate your efforts! Thanks again!


    Hauke

    Dear all,

    is there a comprehensive guide how to update the CrazyCat TBS drivers? I am using

    • @kszaq's image for amlogic (on Le Potato)
    • a WinTV Hauppauge dualHD DVB-T2 USB stick,
    • The CrazyCat TBS drivers
    • TVheadend 4.3

    and both tuners are properly recognized, but Tuner #1 works nearly fine (once in a while a continuity error) while Tuner #2 only gives jerky video and loads of continuity errors. I seem to understand that the drivers have improved, but for all Googling I seem to be to stupid to get a up-to-date package. Can you help me?


    Side remark: Yes, I am aware of CoreELEC and of the experimental support of Le Potato in the official LibreELEC build, but CoreELEC has very old CrazyCat drivers (by design/on purpose) and only TVheadend 4.2, and the official does not even recognize my TV card and also only has TVheadend 4.2. For DVB-T2 I need TVheadend 4.3, which luckily is in kszaq's image.


    Thanks for help!


    Hauke

    Hi folks,

    just read this post from LibeComputer announcing mainline kernel nearly done - including video acceleration! They refer to this github wiki where an experimental image is available for LibreELEC, and lo and behold, my nasty bug with the crash on huge file copies is gone! Funny enough, at the point where the older kernel crashed, network data rate drops by ~25%, but copy continues. /me is very happy! The image is not final, claiming some playback limitations and bugs, but I am really looking forward to this becoming final.


    Thanks to all contibutors for the great work!


    Hauke

    Hi all,

    have been away for a while - just tried 8.90.1 CoreELEC on Le Potato - the crash issue on large file writes is still there.

    I'm wondering: Does this only bother me? It actually avoids recording, timeshift to disc and any larger media file copy to Kodi. I'd have expected that this is a problem for more people...

    Whatever I can do to provide in terms of insights, logs, UART output... into what's going wrong, just let me know.

    Cheers

    Hauke

    I'm even no longer sure that it is the amlogic network driver after all

    I'm now rather sure that it is not the network driver. I kicked the ethernet from the device tree, it is no longer recognized at boot, and no eth0 shows up at all. So to my understanding the code for it should be completely dormant. Still: Crashes :-(

    I've got the feeling that I have to wait until LePotato mainline kernel includes hardware accel and someone ports LibreELEC to mainline then...


    Or is there any developer here willing to dubug? Would assist by providing whatever logs required, UART output, whatever.


    adamg's latest devel build reports "not compatible with LePotato hardware" - cannot tell if the bug's there.

    I have been working quite a bit on the problem of Le Potato crashing on huge file copy/write operations (see my earlier posts). What I did:

    • I worked my way into compiling LibreELEC - used the official LebreELEC repo and
      PROJECT=Amlogic DEVICE=LePotato ARCH=arm make image
    • I identified the code parts that correspond to the Armbian patches that the Armbian team claims solved the stability issues (all network driver code)
    • I managed to adopt the code to go into the LibreELEC kernel (which wasn't too difficult after all)

    To no avail :-( The crashes still happen. I tried a bit around with a few variations of the code, but I'm afraid my understanding of the depth of network drivers is not sufficient to do more but fumble around. So I've to give up here - my time budget does not allow to learn the intricacies of linux network drivers.

    I also did a DEBUG compile, and read out crash information from the debug UART, but this information is totally inconclusive, the crash practically never happening at the same place - it looks like randomly parts of the OS go down - very confusing and not helpful.

    I'm even no longer sure that it is the amlogic network driver after all: I remebered that in some drawer I had lying around an USB2 Gigabit network adapter (smsc75xx based), which was immediatly recognised and works. But also with this dongle the crash happens, even when I disable the eth0 interface by ifconfig eth0 down. However, my shell script did not involve network directly also, so the picture is inconclusive. And Armbian team confirms that the mentioned two patches (and only these, no other) did the trick for them, and I can confirm that with Armbian the bug is gone.


    Long story short: Can someone tell me how I completely disable the network interface, beyond ifconfig eth0 down? It seems it is not a module, so just blacklisting it does not work. When I really "blocked" the driver, I'll again test with the USB dongle.


    Thanks!


    P.S.: Problem persists in 8.90.5 - but that's expected...

    P.P.S.: If someone wants to follow up: The patches of Armbian go into stmmac_main.c and phy_device.c

    P.P.P.S.: The patches of Armbian address issues with EEE and Autonegotiation functions. Disabling EEE and Auto neg. on the switchport did not solve the issue either, but showed at least one bug in the network driver: The interface went to half duplex, while the switch offered only full duplex. ethtool was needed to change to full duplex. Still, crash happens.

    OK, inserted into

    /LibreELEC.tv/build.LibreELEC-LePotato.arm-9.0-devel/u-boot-a43076c/Makefile

    at top the line

    DEBUG=1

    So now it eval's as boolean if needed...hope that does not break other DEBUG flags. At least, it currently continues compiling.

    The offending file seems to be the

    /LibreELEC.tv/build.LibreELEC-LePotato.arm-9.0-devel/u-boot-a43076c/arch/arm/cpu/armv8/gxl/firmware/acs/Makefile

    but somehow I could not get this debugged - my understanding of Makefiles is not good enough.


    @whoever maintains this repo: Perhaps have a look at some point...

    Dear all,

    I try to complie LibreELEC with the following setup:

    Code
    1. PROJECT=Amlogic DEVICE=LePotato ARCH=arm DEBUG=yes VALGRIND=yes make image


    After several hours of compilation, this happens:

    Code
    1. OBJCOPY u-boot.hex
    2. Makefile:156: *** DEBUG must be boolean. Stop.
    3. make[2]: *** [/home/lux/official/LibreELEC.tv/build.LibreELEC-LePotato.arm-9.0-devel/u-boot-a43076c/Makefile:918: acs.bin] Error 2
    4. make[1]: *** [Makefile:147: sub-make] Error 2
    5. make[1]: Leaving directory '/home/lux/official/LibreELEC.tv/build.LibreELEC-LePotato.arm-9.0-devel/u-boot-a43076c'
    6. Makefile:12: recipe for target 'image' failed
    7. make: *** [image] Error 2

    According to Compile [LibreELEC.wiki] DEBUG=yes is right, but seems to be a problem. Any help?

    Btw.: Compiling without DEBUG/VALGRIND went smoothly beforehand. Same code base.

    Thanks!

    Hauke


    EDIT: Stupid me - there is a path to the Makefile - will have a look myself, but it's gone right now, since I started over with make clean... Argh, think before you write/delete... Long day...