My tvheadend epggrab cron jobs worked fine up until the recent October update to VERSION_ID=“2017.10-1”.
The cron job that has successfully run until now uses the following command:
/bin/cat /home/osmc/xmltv.xml | /bin/netcat -w 5 -U /home/osmc/.hts/tvheadend/epggrab/xmltv.sock
This command can be run in a simple shell script executed manually and it executes fine. I have also tested successfully using socat:
/bin/cat /home/osmc/scripts/xmltv.xml | /usr/bin/socat - UNIX-CONNECT:/home/osmc/.hts/tvheadend/epggrab/xmltv.sock
Yet socat when called from crontab fails also. I have verified that the owner of the scripts match the tvheadend service (u: osmc, g: video).
The cron entry is:
05 05 * * * /home/osmc/scripts/tvheadend_xmltv-sock.sh
And the script, of course, contains the command listed above (with a proper shebang header).
Can you identify what has changed in osmc or tvheadend that is preventing the cron job from working?
I suggest that you append this to your cron entry >/home/osmc/epggrab.log 2>&1 and let us know what it produces.
I started to capture cron log output several days ago – the cron entry in full is:
05 05 * * * /home/osmc/scripts/tvheadend_xmltv-sock.sh >> /home/osmc/scripts/tvheadend_xmltv-sock_log.txt 2>&1
The reason I didn’t include the log.txt is because the file is empty! It was written once on the first run following appending the log output to the cron job …
ls -ll ~/scripts/tvheadend_xmltv-sock_log.txt
0 Nov 2 05:05 tvheadend_xmltv-sock_log.txt
So, ?
By restricting the information you provide, such as the fact that you already capture to a log but chose to remove it from the crontab entry you posted, you simply prolong this matter. The output from the ls command is similarly redacted and doesn’t show the full information that you would have seen. Perhaps it really does have a size of zero bytes.
Sorry, not trying to prolong nor make things difficult. Here’s the output of ls, un-redacted:
ls -ll ~/scripts/tvheadend_xmltv-sock_log.txt
-rw-r–r-- 1 osmc osmc 0 Nov 2 05:05 /home/osmc/scripts/tvheadend_xmltv-sock_log.txt
I can assure you that the file is empty …
So the job runs at 05:05 and produces an empty file. But why is the date 2 November?
I suggest you: add some debug lines to the script. Something along the lines of:
echo "Starting script" $(/bin/date)
<your shell script>
echo "Script ends" $(/bin/date)
and post the full script.
I also noticed that in the first post the netcat command is using an upper-case -U, whereas it should be lower-case for a UDP connection.
The date is fixed to 11/2 because the log file was written just once, when the cron job ran the first time since adding the >> output to log file.
This lack of file write after the initial run (w/log output) mirrors the output when run manually from cli – there is no output returned.
Thanks for the debug script details, I’ll give it a try.
Respectfully,
I see. So we might have a situation where a successful run of the command produces no output and a run that fails for a reason that is currently unknown also produces no output.
On further reflection, I did notice one other anomaly in your first post. The first command runs /bin/cat /home/osmc/xmltv.xml whereas the second command runs /bin/cat /home/osmc/scripts/xmltv.xml.
Correct. Now, the quirky thing is, the EPG data is now being correctly updated, without any changes to the script(s)!
The anomaly you mentioned is just that I moved my scripts to a sub-folder in /home/scripts to better organize the system (and forgot to copy & paste in the updated file path in my initial post). The cron job was updated accordingly, so there was no issue there (and the issue began prior to the file system reorganization).
My instinct is that there was an internal db issue localized to tvheadend alone. Or a random conflict or lack of available resources at the time the cron job runs that was impacting importing the data to xmltv.sock via the UNIX socket.
Also, regarding your comment earlier on the netcat -U option, it’s use is correct in that it specifies to use UNIX-domain sockets and has been executing properly for nearly 2 years. At this point, I have transitioned to using the socat method instead, and if results continue to be successful, will stick with socat.
I also noticed other odd behavior, in that the EPG data, after a manual run of the grab and import scripts, would revert at a non-determinable point to a previously imported xml value set. I suspect that a restart of the tvheadend.service should rememdy any further issues encountered.
I’m going to consider this resolved. Thank you for your time and input.
Thank you for the comprehensive update. I’m glad it’s now considered to be resolved.
There is just one thing that I found odd/curious. You mention:
but OSMC’s version of nc/netcat is v1.10-41 and doesn’t have the -U option. By chance, I checked a copy of Raspbian and it is using an OpenBSD version of netcat by default, which does have the -U option (though the “traditional” version 1.10-41 is also there). So would I be correct in surmising that you installed the package netcat-openbsd, rather than netcat?
You are precisely correct, sir! I was intending to comment on that, but it slipped my mind. 
I switched to the openbsd version for the UNIX sockets and ssh over socks proxy capabilities …
1 Like