Posts by sihy

  • Datetime Not Updating ?? only via ssh

    I've had this issue, tried all the good stuff suggested by the LE team above, couldn't get it working. Think it might be related to a connman bug.

    In short, using option 42 on your DHCP server to provide ntp server IP adress(es) should fix it, but if you can't configure your router then you could try 'systemctl edit connman.service' and use the following (DHCP option 42 and this is working for me anyway, YMMV):

    NB I use LogLevelMax to reduce entries from connman in the system journal, you might want to comment this out so you can see the ntp logging to check it's working.

    If you don't reboot afterwards you'll need to systemctl daemon-reload and systemctl restart connman to see if it works.

    Cheers,

    S

  • Problem with latest RPi 4B board revision (1.4) produces errors

    No worries.

    I don't know what your setup is but I'm using a workaround at the moment that might fit if you are using a similar setup.

    I'm using a custom compiled LE9.2.6 for x86_64 (intel NUC) with patches for ffmpegx, tvheadend and the intel_vaapi driver to 2.4.1 (from memory) - I can give you the patches I use for this if you know how to compile LE and are using an intel based server. It enables me to use HEVC vaapi encoding (with bug fixes in the 2.4.1 driver) and TVH 4.3 with a recent commit earlier this year. This streams to 3 raspberry pi LE TVH clients.

    A custom codec and stream profile can then be used in TVH which will transcode and de-interlace in hardware to 50 frames per second HEVC which is then used by the recalcitrant pi4. It uses hardly any resources on the NUC and the pi4 gets HEVC which the MMAL decoder will decode without any issues.

    The drawback is the live TV buffer isn't as quick to move through (but pausing is obviously still 'normal'), and recordings using the pass profile still suffer as they won't be transcoded at the server when played. If you use the new profile to record then any new recordings would be HEVC and play OK tho.

    Good luck, fingers crossed LE10 gets HW de-interlacing fairly soon.

    ATB

    Simon

    Edit:

    PS - Altho sometimes h264 will play provided no FF/RW is attempted even that can be temperamental despite my brief testing above where I said it worked OK.

  • Problem with latest RPi 4B board revision (1.4) produces errors

    Here you go. Just did a fresh install 9.2.8 with one addon - TVHeadend, tested very briefly.

    Playing 1080i live it's OK (as I say only briefly tested).

    Playing a recording of Channel 5 (Hellboy broadcast sometime within the last week 1080i h264 bt709 8-bit yuv420p): works until you attempt to skip forward, then the player freezes.

    I can still ssh into the box - I've done so while the video player is still frozen (and blank) on the display - here is the full log.

    link to logs

    Obvs I don't hold out much hope for a fix (otherwise I'd have done this before!) as someone from the LE team has previously said LE9 is now a dead end, all resources to LE10.

    Anyway, you never know, it might be useful.

    PS

    On further investigation I have the same problem with 720p h264 i.e. I'm getting the same issue with progressive as well as interlaced. 720p hevc on the other hand seems to play just fine, so it looks like it's the MMAL h264 decoder.

    Cheers,

    S

  • LE so broken on RPi4 it's actually useless

    I've had issues with a new Rpi4.

    Works great with completely clean installs of LE10b3 and nightly, but no de-interlacing is a deal breaker for me as I pretty much exclusively use the Rpis as TVHeadend front ends to view live TV and recordings around the home.

    A completely clean install of LE9.2.6(or 7) works a lot of the time with most material except MMAL hardware decoded 1080i h264. This will often freeze the player when starting so either a spinning circle is permanently seen or the UI just tears to blazes and freezes. Sometimes the back button will enable navigating the UI overlay so the Reboot option can be found and executed, sometimes not. Sometimes playback will start OK but then freeze as above when skipping forward/backward.

    LE9.2.6 works perfectly on an older Rpi4, as does turning off hardware MMAL decoding on the new one, but then the frame drops are horrendous.

    Essentially it seems this new Rpi4 is unable to play 1080i h264 reliably with Kodi 18 or 19. As the hardware decode in LE10 works (albeit without de-interlace) I'm not sure it's a physical hardware problem, my guess would be a firmware issue, perhaps related to a new Rpi4 board revision?

    Guess I'm watching SD on this box until Kodi 19 gets hardware de-interlace :|

    PS tried all the usual swapping power supplies/SD cards to known good ones, eliminating everything except the pi ;)

  • Building ffmpegx fails for dependency x265

    Thanks CVH.

    I noticed in the log at lines 78

    -- Looking for strtok_r

    -- Looking for strtok_r - not found

    and (x265) param.cpp checks if strtok_r is defined, and if not re-defines it. It looks like it's not finding that previous definition for some reason, so uses it's own and it's re-definition is declared differently so the error flags up. I just patched param.cpp to be the same as the toolchain def (i.e. static to extern) and it compiles OK.

    I haven't got around to testing it yet so it might not work (object method v class method? * ) but when I get around to it I'll update here to say if the workaround works.

    * dunno, might be total BS, too lazy to look at code structure

    Cheers,

    Simon

  • Building ffmpegx fails for dependency x265

    Trying to build ffmpeg-tools with
    PROJECT=Generic ARCH=x86_64 scripts/create_addon ffmpeg-tools

    is failing building ffmpegx's dependency x265.

    Building x265 on it's own with

    PROJECT=Generic ARCH=x86_64 scripts/build x265

    fails with the error:

    /home/simon/AdditionalStorage/git/http://LibreELEC.tv/build.LibreELEC-Generic.x86_64-9.2-devel/x265-3.2/source/common/param.cpp:57:14: error: 'char* strtok_r(char*, const char*, char**)' was declared 'extern' and later 'static' [-fpermissive]

    static char* strtok_r(char* str, const char* delim, char** nextp)

    The full output is here: pastebin link

    ffmpeg-tools builds successfully on the same machine (Arch Linux) for the RPi4 - is it something to do with the x86_64 compiler? Maybe the settings for the ARM compiler are more relaxed?

    Any help gratefully received,

    Cheers,

    Simon

  • Python script.module addon not working in built addon

    Hi cvH.

    I downloaded your zipped addon for TVH 4.3 (I assume this is your work! link to addon) and checked the contents to see if it had the fanart scripts included and couldn't find them. I didn't actually install and use your addon, so maybe they are included but just not in the bin directory, or maybe I missed it, it was just a quick look.

    I built a TVH4.3 addon (using some info you gave somebody else on a thread here somewhere I think) and included them, the (pretty poor admittedly) instructions are above and thought you might be interested in case you decided to include the fanart in a future edition.

    Cheers,

    Simon

  • Python script.module addon not working in built addon

    For anyone else finding this ....

    I couldn't get the $PYTHONPATH environment variable to work, so I just applied patches to tv_meta_tmdb.py and tv_meta_tvdb.py to append the paths as above.

    In order for the grabbing to work tvhmeta also needs to be copied into the addon's bin folder (it's in the support directory). It also needs the paths patched with the above.

    Note that this all works through localhost HTTP connections so make sure you have an API key to authenticate with the movie database and also permissions for 127.0.0.0/24 to access your tvh server (if you use a password only setup then you also need to supply --user and --password in the recording config additional command line options for tvh).

    Note also that despite what tvh help says only the movie database works, not the tv database so you only need an API key for that.

    Anyway, it now seems to be working - I don't have any errors (except it saying 'We have both image and fanart_image already', when it doesn't), but I still don't have any art either. Sigh.

    Edit:

    This is an issue with the upstream. I patched tvhmeta with pastebin-link to make it work.

    CvH you might be interested in this as you supply a TVH4.3 addon.

  • Python script.module addon not working in built addon

    It's a python path problem.

    Adding the following:

    sys.path.append('/storage/.kodi/addons/script.module.requests/lib/')

    sys.path.append('/storage/.kodi/addons/script.module.urllib3/lib/')

    sys.path.append('/storage/.kodi/addons/script.module.chardet/lib/')

    sys.path.append('/storage/.kodi/addons/script.module.certifi/lib/')

    sys.path.append('/storage/.kodi/addons/http://script.module.idna/lib/')

    in the tv_meta_tvdb.py (tvheadend) script prior to the import requests statement fixes it.

    $PYTHONPATH is empty.

    Politely asking for a piece of advice from the (LE) coders out there...

    What's the best way to solve this question - should I just patch the tv_meta_*.py scripts with the above at LE addon compile time, or is there a better way?

    Setting any global python $PYTHONPATH is probably bad because that assumes the script.modules are installed which they might not be. Maybe a systemd service edit for service.tvheadend42.service to set PYTHONPATH for TVH only, but would that work because python has already started? And it would need incorporating into the addon at compile time. Can $PYTHONPATH be changed at any point, or does something to do with python (I know nothing about python!) need to be restarted so $PYTHONPATH can be set with the new values?

    Have I missed something with the kodi script.module addons, is that the root cause? All the other modules apart from requests are dependencies for requests anyway, so why doesn't the requests module know the paths to it's own dependencies?

    Is this a kodi question? ;)

    Any input appreciated, cheers.

  • Python script.module addon not working in built addon

    I've been successfully using the tvheadend42 addon built from the git repository checked out to 9.2.0, patched to compile to tvheadend version 4.3.

    In order to use the fanart scraping feature for recordings, I built the tvh addon again with a couple more tweaks. The built in tvh python scripts were copied to the tvh addon by including

    cp -P $PKG_BUILD/lib/py/tvh/tv_meta_* $ADDON_BUILD/$PKG_ADDON_ID/bin

    in the tvheadend package.mk. These scripts require the 'requests' module so I included a dependency in the tvheadend addon.xml

    <import addon="script.module.requests" version="2.22.0"/>

    The tvh addon built and installed successfully and it pulled in the required script.module.* addons which are all showing in /storage/.kodi/addons, and showing in the Kodi GUI "Addons/Manage dependencies" with ticks.

    However the tv_meta_* scripts fail with

    Code
    Traceback (most recent call last):
File "/storage/.kodi/addons/service.tvheadend42/bin/tv_meta_tvdb.py", line 29, in <module>
import requests
ImportError: No module named requests

    and if I type 'python' at the command prompt and type help ("modules") none of the addon modules are listed. A test python script with 'import requests' also fails.

    What have I done wrong? :dodgy:

    Cheers,

    Simon

  • [Solved] iptables_helper generates error when not tethering

    A trivial error appears in the system journal generated by iptables_helper when no tethering is in use:

    Apr 11 17:28:38 LibreELEC iptables_helper[258]: grep: technology/wifi: No such file or directory

    Apr 11 17:28:38 LibreELEC iptables_helper[258]: grep: technology/ethernet: No such file or directory

    Apr 11 17:28:38 LibreELEC iptables_helper[258]: Error 'tether': Invalid argument

    Apr 11 17:28:39 LibreELEC iptables_helper[258]: Error 'tether': Invalid argument

    I applied a patch to iptables_helper that removed the error - see pastebin

    Cheers,

    Simon

  • [Solved] Building 9.2.0 fails at binutils

    Building LE 9.2.0 for Raspberry Pi 4 on Arch Linux x86_64 the build fails for binutils with the following error (see this pastebin link for full log).

    I've built the current RPi4 master, v9.1.501 and v9.1.502 on this machine without any issues and the images work just fine.

    I used 'git checkout 9.2.0'.

    I tried a 'make distclean' but the issue remains.

    Assuming it's me that's doing something wrong (I'm definitely not an expert here), any ideas where I'm going wrong and how to fix it?

    Cheers,

    Simon

  • Tvheadend nightly builds for LE

    Unfortunately it sees the HDHomerun quad tuner but won't find some of the services from some of the muxs - ah well, back to the drawing board!

    Also, a test recording started then stopped after a minute or two with the SNR for the tuner at 0%. Reverted back to TVH4.2 and all seems back to normal. I guess I should just leave the compiling to the experts!

    Cheers,

    Simon

    Edit:

    For anyone else finding this, the TVH43 HDHomerun issue can be fixed with the patch here: Bug #5689: Low signal channels cannot be tuned in HDHomeRun - Tvheadend