Posts by emveepee

    I referred you back to NextPVR because you have a habit of leaving these threads dangling. If two threads deal with problems at 47 minutes they are linked no matter what you feel and as I posted on the Kodi forum I do not relate this problem to 720p. It certainly might be the addon or possibly LE the but this takes logs to investigate which you don't include.,

    Sorry if I take defensive to your continued references to Krypton but were are working on Nexus now. Both the server and Kodi API's have changed completely, and there is no going back. My involvment

    Thanks for the kind words and I have adjusted my attitude by changing my user block lists.

    Martin

    For problem #1 I've already told you the timeshift logic has changed https://forums.nextpvr.com/showthread.php…56141#pid556141 I am not sure why you don't get it and keep asking this question. Did you follow my suggestion here https://forums.nextpvr.com/showthread.php…56458#pid556458 to reduce the timeshift buffer size? You never responded.

    The other problem clearly requires your Kodi debug logs. However this seems to be a duplicate post of this problem https://forums.nextpvr.com/showthread.php…58166#pid558166 and it is not clear why you don't pursue it there because that problem was a backend problem.

    Martin

    Trying that setting for libjpeg-turbo didn't work

    Code
    ../libtool: line 7486: cd: libjpeg-turbo: No such file or directory
    libtool:   error: cannot determine absolute directory name of 'libjpeg-turbo'

    Since it is found during configure I suspect it is a link error and their build process doesn't know about libjpeg-turbo.

    Martin

    The reason libgdipluis is needed is some GDI primitives are not implemented in netcore itself (except in Windows) so netcore looks for the library and fails.

    Thanks for the readme instructions that would have save save me time yesterday. I don't use giflib so I will leave it out,it seems to complicated.

    Installing to the addon should work, I will check that out. I can just move in libtiff and libexif to match the build

    For libjpeg-turbo configure finds it for the build but it is missing at link time. I'll try your settings.

    Martin

    A couple days ago I asked a question a question on documentation but it was overlooked or wasn't related enough to the original post so there was no replies

    I want to make GitHub - mono/libgdiplus: C-based implementation of the GDI+ API to go with the Netcore binaries. Since that time and after searching through many other packages I know found out how to use PKG_TOOLCHAIN="autotools" and have started with this commit that I hope to submit as a PR

    Add libgdiplus · emveepee/LibreELEC.tv@64b9b77 · GitHub

    But I still have other questions.

    1 This is a binary to go with netcore so rather then the /usr/lib the lib for netcore might make more sense however there are potentially multiple netcore LTS versions so that becomes complicated. What is the best location for libraries like this? I can use LD_LIBRARY_PATH to find it.

    2. There are a other libraries that can be use with libgdiplus, (right now I only need and can test libjpeg and libpng but I figure make it complete)

    - libexif is not installed by default how do I force it?

    - giflib is a manual build, how can I compile it?

    - What location should be used for these libraries that are also not in /usr/lib

    3. Is there a better way of finding libjpeg-turbo in the package?

    Thanks in advance


    Martin

    Fortunately here in North America we just need fixed channels 2-36 for Digital ATSC but in supporting NextPVR i certainly see the mess in DVB world, and it varies greatly by distro too.

    I haven't heard back from sub (the author) but I have been able to hack the binary, which is not open source and substitute /storage/usdvb for /usr/share/dvb and unzip a dtv-scanning folder there. Scanning was then possible and I can play LiveTV in Kodi and watch externally via ffplay so I know digital playback is possible on the RPi4 class. For my purposes that is probably good enough so I don't need to try that mount command. I probably would have just re-squashed SYSTEM and added it there if I knew the command line.

    I would be grateful if you could package it is as addon I and would be more than willing to provide feedback and help testing on many platforms (wishing for an H2+ though). On some platforms Direct play in Kodi etc will be ok, but the biggest challenge is the ffmpeg requirement for creating HLS file for streaming to a web browser. There will be need to be custom patches for various platform. For devices that can't transcode h264 fast enough, I couldn't get 1x on the RPi4 with h264_v4l2m2m, it will only be able to remux IPTV. Feel free to open a conversation on this when you have time. I can share the hacked module with you if it will help.

    Martin

    No I use NextPVR (and I am the prime contributor to pvr.nextpvr) which is why I felt that the table should not be linked to the backend. I wrote these steps CoreElec and LibreElec as native host for NextPVR which work for the most part with HDHR and IPTV devices but right now the dtv-scanning-table is hardcoded to the standard location. I have asked the NextPVR author to look into changing that but was hoping something was possible in the mean time.

    Docker is also possible, but users may have difficulty with mapping /dev devices and on memory constrained systems Docker might be overkill.

    I do suggest that linking /usr/share to /storage/usr/share (or something similar) would provide a general flexible solution, not just for PVR. Then it is just a matter of downloading the crazycat69 or tvheadend zipfiles


    master.zip

    tvheadend.zip


    Martin

    Two questions

    1. Is there any way to create a folder in /usr ie, /usr/share/dvb manually in v10 without a full build of LibreElec?

    2. As an enhancement can the dtv scanning table be created as a standalone package or included in dvb-tools rather then included in the PVR server program? It seems odd to link it to a backend.

    Thanks.

    Martin

    installs and works smooth for me! Thanks again to both of you!

    Great thanks for the feedback and the follow up. I have never seen a report on that problem before but it seems users tend to just complain and say "I will use the older version it works fine" (even though it has the same code) Thanks to vpeter for the good catch it is unlikely I would ever have looked deeply at that module.

    The PR has been submitted and this may or may not be the final version of 3.3.14 If anyone needs to build this on another platform here is the change I used for this build

    Martin