I’m going crazy for problems recording an Italian IPTV stream (RAI1).
With all the other channels I have I have no problems, with this one after a while I get these error messages in the console:
The thing is random, the recording continues but then it is unusable, because it tries to hang up the stream and this creates a problem in the saved file.
Latest version of TVHeadend Server downloaded from repo for Matrix 19.4 RC2.
To do a test I tried to install TVHeadend on Ubuntu and in that the channel is perfectly recorded without ever problems.
Perhaps this IPTV sends out a particular stream that is misinterpreted in the version of TVHeadend for CoreElec, I say this because recording any other channel always works, but on Ubuntu as I wrote above that channel is recorded correctly.
The mux: pipe:///storage/.kodi/addons/tools.ffmpeg-tools/bin/ffmpeg -loglevel fatal -i “https://mediapolis.rai.it/relinker/relinkerServlet.htm?cont=2606803” -vcodec copy -acodec copy -f mpegts -tune zerolatency pipe:1
I’m trying on another tv-box, an X96Max Plus 2T (uses the same dtb), backing up the CoreElec configuration of the other tv-box and doing the restore, so same global settings, it does the same problem.
SOLVED: but unfortunately not in the Matrix.
With CoreElec 9.2.8 (Leia) and the same settings the recording in that IPTV channel is perfect.
So there is something about the Matrix that bothers him.
I thought it was the different version of FFMpeg, I tried to downgrade only that one but on Matrix there are those problems.
I’m sorry to be left behind, but if there are no problems with Leia I hope they will be solved in the Matrix.
From what I read on the web it could be a problem in the new kernel, which 9.2.8 Leia doesn’t have.
Continuing to investigate today I tried LibreElec “Matrix version” and the problem is exactly the same.
So it should be understood if it is the fault of TVHeadend Server that has something that gives it problems with the Matrix, or vice versa.
Have you gotten to try installing the docker linuxserver/tvheadend service?
It has the advantage that it does not depend on the CE/LE version, although it does depend on the kernel. It is updated very frequently, the last time eleven days ago, and it includes its own ffmpeg.
In case you want to try, this is my installation ssh command:
Good idea to use docker, I hadn’t thought about it!
Already installed and started the container with some modifications.
The problem is that it doesn’t see the DVB-T2 USB adapter, while the addons version finds it.
Anyway test us with that mux in the container, thanks!
I managed to get everything working, only the EPG is missing which I don’t quite understand how to configure it now since TVHeadend is not a plugin, so it doesn’t have the settings.xml where I could enter the url for the internal grabber: http://www.epgitalia.tv/xml/guide.xz
I was also able to get the internal EPG to work via a modified tv_grab_file.
So I always scheduled a recording on that offending stream and the error is the same:
Working all within docker now seems impossible to me but still has problems. @cubimol why not with Leia, and without the docker container?
Maybe in the Matrix some process stops streaming for a moment and gets corrupted, I’m thrilled.
However, this is proof that it does not depend on TVHeadend, the problem lies either in the kernel or something in the operating system, even in LibreElec.
Could you try in your tvbox?
Just an observation, TVHeadend has evolved the way it filters streams over time. I have consistently found that the earlier TVH version of 4.2 tunes marginal Muxes better than later versions - ie all the current 4.3 versions have much worse problems with continuity with poor signals resulting in pauses and glitches in playback.
Every time I have attempted to use one of the 4.3 versions I have reverted back to 4.2 in a few days. Sometimes newer isn’t better.
Absolutely agree, staying up to date doesn’t always solve problems.
But on CoreElec V9.2.8 (Leia) I always use TVHeadend V4.3 and there is no such problem, so I don’t consider it a TVH issue.
Unfortunately however 9.2.8 does not see my DVB dongle, while with Matrix it works.
[ 1516.302104@2] usb 1-2.1.3: New USB device found, idVendor=0572, idProduct=689a
[ 1516.302112@2] usb 1-2.1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 1516.302114@2] usb 1-2.1.3: Product: USB Stick
[ 1516.302118@2] usb 1-2.1.3: Manufacturer: Gen
[ 1516.302120@2] usb 1-2.1.3: SerialNumber: 2017.12.09
[ 1516.302906@2] usb 1-2.1.3: Unsupported device
So with Matrix I have that problem with that particular stream but the usb dvb works, on Leia the usb dvb doesn’t work but the stream records it well.
Could we have an intermediate version between Leia and the Matrix?
I leave you my scripts that I use to be able to integrate the Pluto TV and Samsung TV playlists into tvheadend, and convert them to something that tvheadend understands. Perhaps with this your continuity errors will disappear. They work very well for me.
FFMPEG
#!/bin/sh
# pipedffm3u.sh script for pipe playlist with ffmpeg to tvheadend
# ffmpeg default location in '/usr/bin' change to your convenience
if [[ -z $1 ]]; then
echo "PLAYLIST ERROR!"
else
sed '/#EXTM3U/s/http/TEMP/' $1 > $1.pipedff.m3u
sed -i '/#EXTINF/!s/http/pipe:\/\/\/usr\/bin\/ffmpeg -user_agent "okhttp\/4.9.0" -re -i "http/' $1.pipedff.m3u
sed -i '/#EXTINF/!s/$/" -c:v copy -c:a aac -f mpegts pipe:1/' $1.pipedff.m3u
sed -i '/#EXTM3U/s/TEMP/http/' $1.pipedff.m3u
sed -i '/#EXTM3U/s/" -c:v copy -c:a aac -f mpegts pipe:1//' $1.pipedff.m3u
fi
STREAMLINK
#!/bin/sh
# pipedslm3u.sh script for pipe playlist with streamlink to tvheadend
# streamlink default location in '/usr/bin' change to your convenience
if [[ -z $1 ]]; then
echo "PLAYLIST ERROR!"
else
sed '/#EXTM3U/s/http/TEMP/' $1 > $1.pipedsl.m3u
sed -i '/#EXTINF/!s/http/pipe:\/\/\/usr\/bin\/streamlink --http-header "User-Agent=okhttp\/4.9.0" --url "http/' $1.pipedsl.m3u
sed -i '/#EXTINF/!s/$/" --stdout --default-stream best --ffmpeg-audio-transcode aac --ffmpeg-copyts/' $1.pipedsl.m3u
sed -i '/#EXTM3U/s/TEMP/http/' $1.pipedsl.m3u
sed -i '/#EXTM3U/s/" --stdout --default-stream best --ffmpeg-audio-transcode aac --ffmpeg-copyts//' $1.pipedsl.m3u
fi
make the script executable "chmod +x /storage/.config/iptv/pipedffm3u.sh
find out where ffmpeg is with ‘which ffmpeg’
change the ‘/usr/bin’ directory inside the script to your ffmpeg directory with the warning to write '\/' instead of the ‘/’ character because you are inside a ‘sed’ command
copy your ‘playlist.m3u’ to /storage/.config/iptv
run the command ‘/storage/.config/iptv/pipedffm3u.sh /storage/.config/iptv/playlist.m3u’
you will get a new file ‘/storage/.config/iptv/playlist.m3u.pipedff.m3u’
inside tvheadend create a new network with playlist ‘file:///storage/.config/iptv/playlist.m3u.pipedff.m3u’
Yes, I understood how your script thinks, it was enough for me to adapt the mux only of that problematic channel but I can confirm that the problem remains.
The mux with your system becomes:
@cubimol if I play the mux it has no audio or video problem, the problem is recording.
Even during the play of the mux I have those constant errors but the reproduction is perfect.
I can’t watch the stream because I don’t live in Italy
the stream is of type ‘hls’, it is an HTTP-based adaptive bitrate streaming like Pluto TV and Samsung TV which can malfunction with tvheadend.
My advice is to use the service hls-proxy with the original playlist and create a second playlist to import into tvheadend. I use five playlists with hls-proxy on ports 33300-33400-33500-33600-33700 which are added to tvheadend using the pipedffm3u.sh script I discussed earlier. When my server starts up it runs another IPTV content synchronization/update script. hls-proxy can also be used directly with http://<hls-proxy-server>:<port> from a PC or smartphone. Try the linux-armv7 version (I use linux-x64).
Another alternative that I have not tried is to use pipe with streamlink, I have heard that it works with hls url!.
