Posts by Sepp

  • 8.95.1 on WeTek play: Video calibration not persistent

    Workaround:

    1) # systemctl stop kodi

    2) edit /storage/.kodi/userdata/guisettings.xml

    3) insert at the right position a new resolution element, e.g. something like this:

    The important part is the "720x576 @ 50.00i - Full Screen" part, which is needed for 576cvbs.

    4) # systemctl start kodi


    Interesting enough, it seems you have to do this just once. From now on, you can do Video Calibration via the GUI and it will be stored and persists.


    I consider this as a bug.

  • 8.95.1 on WeTek Play 1: Multimedia Keys not working

    Hi,

    I have a problem with not all buttons (on keyboard, remote control, ...) being properly recognized. Same setup/configuration/hardware worked for LE7 and LE8 flawlessly.

    For what I've narrowed it down, it seems to be limited to the "multimedia keys".

    All keys are properly recognized by the OS, as you can see for the examples of the "next" and the "red" key with two different input sources:

    E.g., here you see the correctly recognized "next" button in the Kodi log:

    Code
    01:12:17.839 T:3001021296   DEBUG: CLibInputKeyboard::ProcessKey - using delay: 400ms repeat: 80ms
01:12:17.843 T:2639397744   DEBUG: Thread Timer start, auto delete: false
01:12:17.856 T:3011207088   DEBUG: Keyboard: scancode: 0xa3, sym: 0x00b0, unicode: 0x0000, modifier: 0x0
01:12:17.858 T:3011207088   DEBUG: HandleKey: next_track (0xf0ba) pressed, action is noop
01:12:18.110 T:2639397744   DEBUG: Thread Timer 2639397744 terminating
01:12:18.129 T:3011207088   DEBUG: Keyboard: scancode: 0xa3, sym: 0x00b0, unicode: 0x0000, modifier: 0x0

    And here the non-functional "red" button in the Kodi log:

    Code
    01:14:37.301 T:3011207088   DEBUG: Keyboard: scancode: 0x00, sym: 0x0000, unicode: 0x0000, modifier: 0x0
01:14:37.301 T:3011207088   DEBUG: GetActionCode: Trying Hardy keycode for 0xf200
01:14:37.301 T:3011207088   DEBUG: Previous line repeats 2 times.
01:14:37.301 T:3011207088   DEBUG: HandleKey: long-0 (0x100f200, obc-16838913) pressed, action is
01:14:37.581 T:3011207088   DEBUG: Keyboard: scancode: 0x00, sym: 0x0000, unicode: 0x0000, modifier: 0x0

    For testing purpose, I already did various tests with eventlircd stopped (stopping kodi, stopping eventlircd, starting kodi again): no change.

  • 8.95.1 on WeTek play: Video calibration not persistent

    Hi,

    I started to test the new LE9 beta on a WeTek Play 1 and stumbled over a couple of issues. After investing two days of digging through the code and being stuck now, here the documentation of the potential bugs. I will open an individual thread for each issue:

    On every restart of Kodi, the Video Calibration is lost. This holds true for rebooting, as well as for stopping and restarting Kodi via systemctl.

    The install is a clean install (storage wiped completely).

    The only special thing might be, that I'm using the CVBS output, by creating the file "disp_cap" in the userdata directory with the content of "576cvbs".

    Maybe linked to this bug discussion:

    Video calibration won’t survive a reboot (bump!) - Kodi - CoreELEC Forums

  • LE8 on WeTeK OpenELEC: Freeze because of memory leak?

    codesnake: Good!

    As promised, I tried to produce useful logs. Doing so, I realized that the freeze always seems to occure around the overflow of dts_in/pts_in in CAMLCodec:: Decode. There is this 32 signed int value, and when it exceeds 0x7FFFFFFF things go wrong.


    Here the log for watching PVR with tvheadend client when the memory increase happens:

    And here with the YouTube plugin:

    I've also seen that the code in AMLCodec.cpp which should handle this overflow gracefully was changed between Jarvis and Krypton.

    Maybe it's here to search?

  • LE8 on WeTeK OpenELEC: Freeze because of memory leak?

    Any news?

    On my side I did some more tests:

    First I installed the TVHeadend server add-on on the WeTek and changed the configuration of the TVHeadend client, so that I see the local TV stream and not the one of the remote server.
    Result: Same thing. Approx. 400 minutes everything works well, and then memory usage goes up until everything is too late.


    Then I installed the YouTube plugin and started a video 10 hours long (Cantina Band: Play that same song! :D ).
    Result: Kodi again freezes, but this time without memory usage increasing! The freeze also _seems_ to take place after approx. 400 minutes. Unfortunately, again all useful logs were lost due to the powercycle and/or the freeze. I will try to reproduce and somehow produce useful logs.

    Any ideas? Any advice?


    Cheers,
    Sepp

  • LE8 on WeTeK OpenELEC: Freeze because of memory leak?

    Hello,

    did some more investigations and wrote a script to log the memory usage of the "kodi.bin" process.

    I did two runs now, and interesting enough, memory usage is always constant for a long time. But then, always after 400 minutes, memory usage starts to increase over some minutes until all memory is used up.

    Test procedure was: Reboot -> start monitoring script -> go to live TV -> watch first channel in fullscreen -> don't touch anymore

    Attached you find the results. One plot over the full time and one detailed plot for the "crawl up time" for each run.

    Any ideas?


    Cheers,
    Sepp

  • Tvheadend client not working in Wetek Play 8.0.0

    Hi,

    sometimes the configuration files really really mess up (at least this was the case with 7.0).

    So if you just "uninstalled" the plugin, in my experience this might not be enough.

    Do a backup and then do a "hard reset" (LibreELEC Settings -> System -> Reset to Defaults -> Reset LibreELEC to defaults) and start anew.

    If it still does not work, only then I would start to worry.


    For the future: Do regular backups. If it happens again, just restore the last working backup.

    Cheers,
    Sepp

  • LE8 on WeTeK OpenELEC: Freeze because of memory leak?

    Hi,

    so I *tried* to make a more decent set of logs.

    Problem is, that when things finally go wrong, things a quite screwed up and one can't just use the samba logfile feature.

    So here is what I did:
    1) Rebooted
    2) Switched on LiveTV
    3) opened one SSH terminal with "journalctl -f"
    4) opened second SSH for "top" and later control
    5) waited for things to screw up
    6) when system was finally total stuck, I used the second terminal to kill kodi with "killall -9 kodi.bin". This took about 5 minutes just to accept the keystrokes.
    7) Tried to create the logfiles, but they were to big to be processed on the available "disk space"
    8) copied away "kodi.old.log" (nearly 1 GB!) and deleted it
    9) executed "createlog"
    10) found out, that in the created ZIP file also data from journalctl was lost.

    So here is what you get now:
    - a full logfile ZIP-ball created after things screwed up and KODI was manually killed, with "kodi.old.log" missing and crippled journalctl data
    - a separate zip-file with "kodi.old.log" -> ZIPPED 70 MB, TOO BIG TO UPLOAD
    - a separate zip-file with the trace of "journalctl -f" followed on a remote ssh terminal


    If you need more, please tell me.


    Sepp


    EDIT: Ok, I uploaded the big "kodi.old.log" to a one-click-hoster. Please find the file here:

    kodi.old.log.zip | Uloz.to

  • LE8 on WeTeK OpenELEC: Freeze because of memory leak?

    Hi,

    last week I installed the new LibreELEC 8.0.0 release on one of my WeTeK OpenELEC boxes.

    To narrow things down and to be sure I wiped the complete box and the *only* plugin I installed is the "Tvheadend HTSP client 3.4.18.1".

    The Tvheadend server is *not* running on the box, but I'm streaming from a Tvheadend server on a RPi in the network.

    After several hours, it seems that Kodi is using up all the memory and the box either locks up or suffers from severe swapping with a load going up to 18 and above.

    To reproduce, one just has to boot up the box (using the default skin), start LiveTV and wait for some hours. No switching/GUI usage required to crash the system.

    Attached see two "top" screenshots - one with severe swapping and one with a died box - as well as a "journalctl -f" trace of a died box.

    I will add more logs if required/later.


    TIA,
    Sepp