Tvheadend

Well if you were running pure Linux I would say to set up a cron job that runs once a day (using the sudo crontab -e command) and let it run a shell script that downloads the file using wget, and then moves it to a location where tv_grab_file (see below) can find it.

For example your shell script might look something like:

#!/bin/sh
wget (whatever)honeybee.it(/whatever)
mv ~/listings/filname.xml /home/hts/.xmltv/tv_grab_file.xmltv

And then you would need to install the tv_grab_file script from from https://raw.githubusercontent.com/Rigolo/tv-grab-file/master/tv_grab_file into the /usr/bin directory (as root) and make it executable and then (probably after a reboot) select it as your one and only grabber module in the Tvheadend EPG Grabber Modules tab.

Then under the EPG Grabber tab in the Internal Grabber box you can set up a schedule to make Tvheadend run the tv_grab_file grabber once a day. So if for example your cron job runs at 3:30 AM, you would want Tvheadend's grabber to run shortly thereafter. So you'd use something like

40 3 * * *

in that box to have Tvheadend grab the downloaded xml file 10 minutes after the download script runs (at 3:40 AM in the above example).

What I don't know is if you are using a full version of Linux in this "Windows subsystem for Linux", if not then some of this may not work.

Note that Linux permissions can trip you up in this process, for example you may need to set the /home/hts/.xmltv directory to be world writeable or your attempts to move the downloaded xml file into that directory could fail. An alternate approach is to modify the line "cat ~/.xmltv/tv_grab_file.xmltv" in the tv_grab_file script and change it to point to the path and filename of your downloaded file, but in that case that file must be world readable or it will fail (because Tvheadend runs as the hts user, not as your user). Also both of the scripts (the one that downloads your schedule info, and the tv_grab_file script) must be executable. And note that the tv_grab_file script and the tv_grab_file.xmltv file are two different files (some people get confused by the naming similarity, but tv_grab_file.xmltv is just the filename of the xml file that the tv_grab_file script expects to see, unless you modify the tv_grab_file script to look for some other filename for the XML file).

Having said all that, there may be an easier or better way to do this, but I am certain the above will work provided the download XML file is in a format that Tvheadend understands, and provided that "Windows subsystem for Linux" supports all this.

You can always modify the tv_grab_file script to download the file to a temporary location, and then cat the downloaded file to Tvheadend.

For a reference: https://github.com/nurtext/tv_grab_file_synology/blob/master/src/remote/tv_grab_file

That repository contains tv_grab_file scripts geared towards the limited userspace on Synology NASes, but you could probably easily modify the remote script for use with WSL.

I got it to work with Roberts modified tv_grab_file. Thanks

K shea felt a little to advanced for me but thanks for your input.

Best Regards

https://tvheadend.org/issues/5063

If there is a lot of people have interest, feature will be added, I hope so.

saen acro wrote:

https://tvheadend.org/issues/5063

If there is a lot of people have interest, feature will be added, I hope so.

How is that different than what Tvheadend already does with the XMLTV socket? If enabled, Tvheadend will create a socket on disk that you can write directly to, and Tvheadend will import the XMLTV data that is written to the socket.

You can use curl, socat or netcat to write to a Unix socket.

Can you do this on embedded system?
I use lot of "cheap then tuner" devices to get streams
there is no space for xmltv package

saen acro wrote:

Can you do this on embedded system?
I use lot of "cheap then tuner" devices to get streams
there is no space for xmltv package

Yes. The point is that the xmltv.sock socket allows you to directly write your XMLTV data into Tvheadend. No grabber needed whatsoever. (You do need a way to read the XMLTV data, but most embedded devices tend to have cat and curl, so there are no extra dependencies.)

If space is a requirement, why are you asking for a feature to be added that will ADD to the size of the program, when it already does what you need?

Jimmy Lindberg wrote:

I got it to work with Roberts modified tv_grab_file. Thanks

K shea felt a little to advanced for me but thanks for your input.

No problem, and you're welcome. Just happy to hear you got it working.

Robert Cameron wrote:

Yes. The point is that the xmltv.sock socket allows you to directly write your XMLTV data into Tvheadend. No grabber needed whatsoever. (You do need a way to read the XMLTV data, but most embedded devices tend to have cat and curl, so there are no extra dependencies.)

The problem with that method is that I have yet to find instructions that clearly and concisely show how to use it. I don't need to know the theory behind it, I don't need to really know anything at all except that if I have an xml file called something.xml, I do whatever to get Tvheadend to read the file in. If there's a page that explains that (or better yet, a video) and it's not written by a developer (I think software developers in most cases are genetically incapable of writing documentation that can be easily understood by regular users), I'd be really interested. If it involves a bunch of additional Linux-y stuff then I'll stick with the method I'm using now.

(I really do appreciate the work that developers do, especially the Tvheadend developers, it's just that most of them write documentation in a way that only other developers can really understand.)

Xmltv require 200+ mb of space!

There is a people using TP-Link router to receive operator multicast IPTV
and link with epg.xml or json for EPG.
Wondering where to put xmltv stuff on 32mb storage?

saen acro wrote:

Xmltv require 200+ mb of space!

There is a people using TP-Link router to receive operator multicast IPTV
and link with epg.xml or json for EPG.
Wondering where to put xmltv stuff on 32mb storage?

Quite some time back when I was first starting out I had a somewhat similar situation, and what I did was run the script that produced the .xml file on another system, then at the end of the script it used sshfs (I think it was) to copy the file to the system with limited storage. Then I just used the tv_grab_file grabber to import the xml file into Tvheadend. As long as you have enough storage to hold the completed xml file, there's no law that says it has to be generated on that system. You can do that on any other Linux machine on your network (and if you don't currently have another Linux machine, I suppose you could run Linux in a virtual machine such as VirtualBox).

But if the size of the .xml file itself exceeds your storage space, then you may just be out of luck!

That's why XML/JSON importer is better
TVH read file from ram and store it to compressed epgdb.
Short and simple, without need of extra user knowledge.

1. Using socat:
   

   cat tv.xml | socat - UNIX-CONNECT:/path/to/xmltv.sock
   

1. Using netcat (from the nmap project):
   

   cat tv.xml | nc -w 5 -U /path/to/xmltv.sock
   

1. Using curl:
   

   cat tv.xml | curl -d @- -m 5 -X POST --unix-socket /path/to/xmltv.sock http://google.com
   

   
   (The http://google.com website is just a placeholder, since it doesn't ever actually get contacted. However, curl needs to try to connect to something. You might be able to replace google.com with localhost or 127.0.0.1; in the end it doesn't matter, because all communication is outgoing through the socket.)

Are those one-liners simple enough to understand? socat and netcat can both be statically compiled into rather small independent binaries, so they ought to be suitable for embedded use.

Similarly, a simple/plain tv_grab_file script can leverage cat and/or curl to achieve the same results.

Robert Cameron wrote:

1. Using socat:
   [...]

1. Using netcat (from the nmap project):
   [...]

1. Using curl:
   [...]
   (The http://google.com website is just a placeholder, since it doesn't ever actually get contacted. However, curl needs to try to connect to something. You might be able to replace google.com with localhost or 127.0.0.1; in the end it doesn't matter, because all communication is outgoing through the socket.)

Are those one-liners simple enough to understand?

Not in the slightest. This is what I mean about the way developers write documentation (I don't know if you are a developer, but your conception of "simple" is different from that of a typical user).

First, in all of your examples, you use "/path/to/xmltv.sock", but there is no directory called "path" off the root directory so obviously you intend for a real path to "xmltv.sock" to be used. But WHERE is xmltv.sock? Is it even installed by default in Tvheadend? Does anything need to be done to enable it? You are assuming that the typical user will both understand that something needs to be substituted there, and okay, that's rather obvious. But you are also assuming that the user will know where to find this "xmltv.sock". I would have no idea where it is. Is it part of Tvheadend? Part of the operating system? Something that has to be installed? And how would I find that path? I have read a couple of posts where the path "/home/hts/.hts/tvheadend/epggrab/xmltv.sock" is given but when I look in the "/home/hts/.hts/tvheadend/epggrab" directory there are only two things there, a directory called "xmltv" and a file called "config".

Then you seem to be using programs called socat, nc, and curl, each with various options, but you don't really explain the options so I don't know if any of them need to be modified, or can be used as is, assuming the aforementioned "/path/to/" substitution is taken care of. Now I usually check to see if a program is installed by typing "which (program_name)" at the command prompt, and if I type "which socat" I get no result, so that first line would fail. "which nc" returns /bin/nc, so whatever nc is I assume it's installed, it just would be great to know what the options mean. "which curl" returns "/usr/bin/curl" so again I assume that is installed. But, that may not be true on all systems.

socat and netcat can both be statically compiled into rather small independent binaries, so they ought to be suitable for embedded use.

And what does that have to do with anything? Also, when you use the word "compile", that's usually where I stop reading. I have had very little success compiling software in Linux (my tuner card's drivers are the one exception, fortunately).

Similarly, a simple/plain tv_grab_file script can leverage cat and/or curl to achieve the same results.

Huh? I thought the point of this was to avoid using the tv_grab_file script.

Many people (especially new users) might try using your simple one-liner verbatim and when they don't work, assume you don't know what you are talking about and move on. I appreciate that you are trying to simplify it to one-liners, but you also need to explain things like how to find that "xmltv.sock" and any other substitutions that may need to be made. I'd personally be inclined to try the one that uses "nc" first, since "socat" doesn't appear to be installed on my system and I get the sense that the use of curl is in a manner not quite intended (due to the http://google.com thing).

Make it work on SH4 cpu @450Mhz 64Mb storage 128Mb ram.

Have you even bothered to check any of the man pages or existing documentation? Perhaps the reason some of these examples seem a bit sparse is that they are filled with filler/example/boilerplate text use to illustrate the usage, not to serve as a definitive guide for all users.

In the examples above, the tv.xml was implied to mean the name of the XMLTV-formatted guide infomration residing on disk. Likewise, the /path/to/xmltv.sock is used to show where one would input the full and absolute path to where Tvheadend creates the the socket it listens for XMLTV data on. If you bothered to check your installation of Tvheadend, you will see that under "Configuration > Channel / EPG > EPG Grabber Modules" there is an "External: XMLTV" item in the "EPG Grabber Name" list. Then, under that item's "Parameters" pane, under the heading "Settings", you'll find an item labeled "Path:". On my machine, this is /home/hts/.hts/tvheadend/epggrab/xmltv.sock; where that socket may exist on your machine is unknown to me. Hence, when using sample filenames and paths, it is fairly common in examples to see something like: /this/is/the/full/and/absolute/path/to/this/file.ext. (Likewise for the tv.xml file: I have no idea if you store your XMLTV data in a file called tv.xml, but it ought to be obvious that that file represents the XMLTV data file.)

The socat command looks pretty self-explanatory: Use cat to pipe the data from tv.xml to the standard input of socat, which in turn will take the data it receives on the standard input (the - file input option) and outputs it to a Unix Domain Socket that exists at /path/to/xmltv.sock).

Similarly, the netcat command is pretty simple: Use cat to pipe the data from tv.xml to the standard input of netcat (invoked by the command nc), which in turn will take the data it receives on the standard input (the - file input option) and outputs it to a Unix Domain Socket that exists at /path/to/xmltv.sock, waiting up to 5 seconds for data to be received before it times out (the -w 5 option).

I can understand how the curl command might need a bit more explanation, but it's really rather convoluted and re-appropriating the command to do something it wasn't ever really supposed to do. Both socat and netcat embody the idea of applications on *nix systems: Do one thing and do it well.

The answers to what all of the command line options mean could easily have been found by browsing the man pages of the commands in question. When encountering any new command, browsing its man page should be the first thing you do so you understand what the command is doing. Blindly following directions and cut-and-pasting from the internet is a surefire way to invite disaster.

I don't know if the options I provided for the examples commands would need to be changed, or if other options would be necessary. However, if you browsed the man page, you could easily find the answer.

Also, if you are building an image for use on an embedded device, I (rather foolishly, in hindsight) assumed that you had some knowledge and familiarity with the command line, man, and command options. I'll take the blame on that account for assuming more than I should have.

However, the examples were meant to merely be skeleton examples, not a full and complete step-by-step howto tailored to your needs.

xmltv.sock cannot be used without xmltv package
do

apt remove xmltv

apt install xmltv
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following additional packages will be installed:
  libauthen-sasl-perl libclass-factory-util-perl libclass-inspector-perl libclass-methodmaker-perl libclass-singleton-perl libcommon-sense-perl libconvert-binhex-perl libdata-dump-perl libdate-manip-perl libdatetime-format-builder-perl
  libdatetime-format-iso8601-perl libdatetime-format-strptime-perl libdatetime-locale-perl libdatetime-perl libdatetime-timezone-perl libdigest-hmac-perl libemail-address-perl libemail-find-perl libemail-valid-perl libexporter-lite-perl
  libexporter-tiny-perl libfile-chdir-perl libfile-listing-perl libfile-slurp-perl libfont-afm-perl libhtml-form-perl libhtml-format-perl libhtml-fromtext-perl libhtml-tableextract-perl libhtml-tree-perl libhttp-cache-transparent-perl
  libhttp-cookies-perl libhttp-daemon-perl libhttp-negotiate-perl libhttp-server-simple-perl libio-sessiondata-perl libio-socket-inet6-perl libio-socket-ssl-perl libio-stringy-perl libjson-perl libjson-xs-perl liblingua-preferred-perl
  liblist-moreutils-perl liblog-tracemessages-perl liblwp-protocol-https-perl libmailtools-perl libmime-tools-perl libmodule-implementation-perl libmodule-runtime-perl libnet-dns-perl libnet-domain-tld-perl libnet-http-perl libnet-ip-perl
  libnet-smtp-ssl-perl libossp-uuid-perl libossp-uuid16 libpackage-deprecationmanager-perl libpackage-stash-perl libpackage-stash-xs-perl libparams-classify-perl libparams-util-perl libparams-validate-perl libparse-recdescent-perl
  libregexp-common-perl libsoap-lite-perl libsocket6-perl libsub-install-perl libtask-weaken-perl libterm-progressbar-perl libterm-readkey-perl libtext-bidi-perl libtie-ixhash-perl libtk-tablematrix-perl libtry-tiny-perl libtypes-serialiser-perl
  libunicode-string-perl libwww-mechanize-perl libwww-perl libwww-robotrules-perl libxft2 libxml-dom-perl libxml-libxml-perl libxml-libxslt-perl libxml-namespacesupport-perl libxml-parser-perl libxml-perl libxml-regexp-perl libxml-sax-base-perl
  libxml-sax-expat-perl libxml-sax-perl libxml-treepp-perl libxml-twig-perl libxml-writer-perl libxml-xpathengine-perl libxmlrpc-lite-perl libxmltv-perl libxrender1 perl-tk xmltv-gui xmltv-util
Suggested packages:
  libgssapi-perl libhtml-element-extended-perl libcrypt-ssleay-perl uuid libscalar-number-perl libapache2-mod-perl2 libmime-lite-perl libnet-jabber-perl libauthen-ntlm-perl libunicode-map8-perl xml-twig-tools libtext-kakasi-perl liblinux-dvb-perl
The following NEW packages will be installed:
  libauthen-sasl-perl libclass-factory-util-perl libclass-inspector-perl libclass-methodmaker-perl libclass-singleton-perl libcommon-sense-perl libconvert-binhex-perl libdata-dump-perl libdate-manip-perl libdatetime-format-builder-perl
  libdatetime-format-iso8601-perl libdatetime-format-strptime-perl libdatetime-locale-perl libdatetime-perl libdatetime-timezone-perl libdigest-hmac-perl libemail-address-perl libemail-find-perl libemail-valid-perl libexporter-lite-perl
  libexporter-tiny-perl libfile-chdir-perl libfile-listing-perl libfile-slurp-perl libfont-afm-perl libhtml-form-perl libhtml-format-perl libhtml-fromtext-perl libhtml-tableextract-perl libhtml-tree-perl libhttp-cache-transparent-perl
  libhttp-cookies-perl libhttp-daemon-perl libhttp-negotiate-perl libhttp-server-simple-perl libio-sessiondata-perl libio-socket-inet6-perl libio-socket-ssl-perl libio-stringy-perl libjson-perl libjson-xs-perl liblingua-preferred-perl
  liblist-moreutils-perl liblog-tracemessages-perl liblwp-protocol-https-perl libmailtools-perl libmime-tools-perl libmodule-implementation-perl libmodule-runtime-perl libnet-dns-perl libnet-domain-tld-perl libnet-http-perl libnet-ip-perl
  libnet-smtp-ssl-perl libossp-uuid-perl libossp-uuid16 libpackage-deprecationmanager-perl libpackage-stash-perl libpackage-stash-xs-perl libparams-classify-perl libparams-util-perl libparams-validate-perl libparse-recdescent-perl
  libregexp-common-perl libsoap-lite-perl libsocket6-perl libsub-install-perl libtask-weaken-perl libterm-progressbar-perl libterm-readkey-perl libtext-bidi-perl libtie-ixhash-perl libtk-tablematrix-perl libtry-tiny-perl libtypes-serialiser-perl
  libunicode-string-perl libwww-mechanize-perl libwww-perl libwww-robotrules-perl libxft2 libxml-dom-perl libxml-libxml-perl libxml-libxslt-perl libxml-namespacesupport-perl libxml-parser-perl libxml-perl libxml-regexp-perl libxml-sax-base-perl
  libxml-sax-expat-perl libxml-sax-perl libxml-treepp-perl libxml-twig-perl libxml-writer-perl libxml-xpathengine-perl libxmlrpc-lite-perl libxmltv-perl libxrender1 perl-tk xmltv xmltv-gui xmltv-util
0 upgraded, 101 newly installed, 0 to remove and 0 not upgraded.
Need to get 11.2 MB of archives.
After this operation, 84.6 MB of additional disk space will be used.
Do you want to continue? [Y/n]

saen acro wrote:

xmltv.sock cannot be used without xmltv package

That is patently false. The xmltv.sock is merely a socket that Tvheadend creates to listen for incoming XMLTV data. It does not rely upon any external dependencies, merely that data written to the socket be properly formatted.

Also, while the xmltv (and similarly named) packages provided in most OSes repos does require MANY Perl dependencies, not all of the, are strictly required. If you only need a single grabber, you can manually configure the utilities when you build them and only use a subset of those packages.

Also, there are other packages/utilities that can output XMLTV formatted data that are not a part of the XMLTV project.

Robert Cameron wrote:

Have you even bothered to check any of the man pages or existing documentation?

Oh, but indeed I have and that still doesn't quite make your explanation, nor that of K Shea completely make sense to me.

I am not a complete linux noob, but I will also admit I'm not star player. I can get around, chmod a thing or two here or there, play with nano if I have to and change configurations here and there. On the other hand, I'm still pretty lost with most of the language. I am, however, a complete tvheadend noob, and have used it to reacquaint myself with linux and the pain that it inevitably brings and the glory of finally figuring something out.

Let's start with your suggestion to make sure I understand it. I can set up a cron job that would take regularly run this script

#!/bin/sh
wget -O /path/to/tv.xml https://internet_location_url/epgfile.xml
cat /path/to/tv.xml | socat - UNIX-CONNECT:/path/to/xmltv.sock

and then I would also have to run the external grabber xmltv and set it up on a recurring run inside of tvheadend.

That should do it? I am unclear about this last part. Once I get the information to the socket using the "cat" command, do I need to do the additional part of running the external grabber in tvheadend, or does it happen automatically once I get the information to the socket?

enguiring minds want to know, look forward to your reply.

K Shea wrote:

Well if you were running pure Linux I would say to set up a cron job that runs once a day (using the sudo crontab -e command) and let it run a shell script that downloads the file using wget, and then moves it to a location where tv_grab_file (see below) can find it.

For example your shell script might look something like:

#!/bin/sh
wget (whatever)honeybee.it(/whatever)
mv ~/listings/filname.xml /home/hts/.xmltv/tv_grab_file.xmltv

And then you would need to install the tv_grab_file script from from https://raw.githubusercontent.com/Rigolo/tv-grab-file/master/tv_grab_file into the /usr/bin directory (as root) and make it executable and then (probably after a reboot) select it as your one and only grabber module in the Tvheadend EPG Grabber Modules tab.

OK, I get the first two lines, but I don't understand why I have to install the tv_grab_file script. In that script I see where wget goes out and finds the egp.xml file on the internet. Why do I have to do this twice? First in the script you wrote, and then install and run this second script. I am confused and would appreciate if you could explain further. Thanks.

Tom Johnson wrote:

#!/bin/sh
wget (whatever)honeybee.it(/whatever)
mv ~/listings/filname.xml /home/hts/.xmltv/tv_grab_file.xmltv

And then you would need to install the tv_grab_file script from from https://raw.githubusercontent.com/Rigolo/tv-grab-file/master/tv_grab_file into the /usr/bin directory (as root) and make it executable and then (probably after a reboot) select it as your one and only grabber module in the Tvheadend EPG Grabber Modules tab.

OK, I get the first two lines, but I don't understand why I have to install the tv_grab_file script. In that script I see where wget goes out and finds the egp.xml file on the internet. Why do I have to do this twice? First in the script you wrote, and then install and run this second script. I am confused and would appreciate if you could explain further.

You don't have to do it twice. There are two steps involved:

1) Download the data from the internet into a file on your local device - that's what the quoted script is doing.
2) Import the data from the file on your local device into TVHeadend - that's what tv_grab_file does.

Tom Johnson wrote:

Let's start with your suggestion to make sure I understand it. I can set up a cron job that would take regularly run this script

#!/bin/sh
wget -O /path/to/tv.xml https://internet_location_url/epgfile.xml
cat /path/to/tv.xml | socat - UNIX-CONNECT:/path/to/xmltv.sock

and then I would also have to run the external grabber xmltv and set it up on a recurring run inside of tvheadend.

That should do it? I am unclear about this last part. Once I get the information to the socket using the "cat" command, do I need to do the additional part of running the external grabber in tvheadend, or does it happen automatically once I get the information to the socket?

No, you do not need to run an external grabber in this scenario. The 'cat' line in the script writes the data to TVHeadend - that's all you need to do.

Tom Johnson wrote:

Robert Cameron wrote:

Have you even bothered to check any of the man pages or existing documentation?

Oh, but indeed I have and that still doesn't quite make your explanation, nor that of K Shea completely make sense to me.

You do realize you replied to a 5 month old thread, right? The original participants probably aren't still reading it.

But anyway, this link may or may not help your understanding: https://freetoairamerica.wordpress.com/2014/12/03/some-hints-for-getting-free-to-air-satellite-channels-into-the-electronic-program-guide-in-kodi-or-xbmc-or-another-frontend/

Oh yes, and I do realize this is still very much an open question for many, many people trying to use TVheadend with IPTV networks. The instructions to date are about as clear as mud.

So, I came across this thread due to the internet search "TVheadend epg from url", and I expect several other people will as well. I've spent about 2 weeks figuring things out, running through OpenElec, LibreElec because they have a built in grabber to grab from url's (and learning that the wget function in OpenElec/Libreelec does not accept redirects, whereas wget in Ubuntu based distros do). So, my additions and comments here are to make sure that other people may get another clue on how to do this from my struggles.

Sean Micklem wrote:

But anyway, this link may or may not help your understanding: https://freetoairamerica.wordpress.com/2014/12/03/some-hints-for-getting-free-to-air-satellite-channels-into-the-electronic-program-guide-in-kodi-or-xbmc-or-another-frontend/

Oh, meant to mention, yup, came across this and many that refer to this Grabber. It doesn't exist in the ubuntu version of TVheadend, and the only place I found it was on the LiberElec version. And the Libreelec version of wget doesn't allow for redirects which makes it useless for many, many url's. So I appreciate your reference, but it doesn't quite work.

Note to others, if you cannot get LiberElec to load on your computer because it's too old and needs a legacy boot from your usb, install instead OpenElec from the 5 series, using the USB creation method there. Then take the the kernal and services files from the LiberElec distro (don't use the Iso, use the other download) and put them in the update and reboot. Instantly updated to the latest LibreElec version on your old machine.

Worry not, I'll give a easy line by line way to do this in a different post, but wanted to give a quick and dirty if you're running into this problem.

Tom Johnson wrote:

Sean Micklem wrote:

But anyway, this link may or may not help your understanding: https://freetoairamerica.wordpress.com/2014/12/03/some-hints-for-getting-free-to-air-satellite-channels-into-the-electronic-program-guide-in-kodi-or-xbmc-or-another-frontend/

Oh, meant to mention, yup, came across this and many that refer to this Grabber. It doesn't exist in the ubuntu version of TVheadend, and the only place I found it was on the LiberElec version. And the Libreelec version of wget doesn't allow for redirects which makes it useless for many, many url's. So I appreciate your reference, but it doesn't quite work.

Go back and read the article again. Tvheadend does not include that particular grabber in any version and never has, you need to download tv-grab-file from https://github.com/Rigolo/tv-grab-file and install it by following the instructions. If it's in LibreElec it's because they added it, and they probably did that because they will not let you do anything from a Linux command line so if they hadn't put something in, user would not have been able to.

LibreElec and Openelec suck in my opinion because they try so hard to keep their users from doing anything at all that might require going to a Linux command prompt, which seems great at first glance but sooner or later you are going to want to do something that requires going to a Linux command prompt and on those distributions you just can't, by design. To each their own but I would never run either of those and would not advise anyone else to do so either.