Tvheadend

On the channels where I experience no audio when playing live in Kodi, checking the "Enable PTS/DTS Resync" box makes no difference except that it takes a little longer for the stream to start playing. I just really wish this forum had a way to send private messages, because I could send a couple of example links. It's only the streams that come from one particular root URL that experience the issue, and of those it's only the ones at 1080p. It is not ALL 1080p streams, but all the 1080p streams from that same group of streams (same root URL) have the issue in Kodi when watching live. Absolutely beautiful video, but no sound unless you record the stream and then view the recording. And those particular channels are the ones that have hundreds or thousands of segments prior to the current time, but I don't think that is what causes the audio issue.

Completely gave up on Plex, something in their guide data was screwing up the guide completely, yielding a corrupted XML file. I reverted back to an older backup (from before I tried Plex) and the updated Cabernet to the latest version and continued from there. I may try to implement Plex again someday, but not real soon. Many of their channels are duplicates of those found on PlutoTV, XUMO, and/or SamsungTV anyway.

Do any of you guys happen to know of any good URL Filter strings for XUMO or Samsung TV? I don't really understand how those strings are constructed. and even if I did I know of no way to find out what server(s) are being used by these services for ads or for pauses where commercials should be. SamsungTV in particular has this thing they show where a commercial should be; I don't know if it is part of the program or served separately but if served separately it would be nice to be able to cut that out so it doesn't appear in recordings.

I've tried recording a couple things from XUMO but the recording always seems to start a few seconds after the show begins. Think I'll try changing the Start Time Adjustment from 60 to 45 and try to fine tune it from there.

Other than those things everything is working great, and I am not seeing any issues that really need to get fixed now, which is great. Thanks for this great software!

I found the issue. Cabernet is supplying the wrong codec to the client causing the issue with the audio. I guess the Locast folks never supplied but one codec... that is why it was hard coded in locast2plex. I'll fix it in RC2 (Release Candidate) along with an enhancement.

Well, I fixed the content-type and codecs, but no joy, so its not getting fixed any time soon... sorry. At least we have work arounds

You probably know this but I figured I would give you an update on RC03. I am still getting no audio some M3U channels from Robert's list.

I still get this message in TVHeadend when playing live from Kodi. I do not get this message when recording or when playing from VLC.

tsfix: The timediff for AAC is big (291000), using current dts

I will stick to the workaround of setting the program to record, wait 10 secs and play the recording.

I went through over 100 channels in the US iptv org list and had no issue. No problems with no audio. Everything plays just fine.

try this one

https://cdn87.theus6tv.tk/locals/BayArea/kntv-dt1.m3u8

ok, I was able to get that to show the issue. The issue is TVH needs to use "pass" as a streaming setting (which is used on record), but according to pvr.hts

You can only use "htsp" streaming profiles for kodi.
"pass" and "matroska" are default streaming profiles for http streaming and sush.
So if you create a new profile in tvheadend, make sure you select the htsp streaming profile.

That is why it is having issues. Is there a way to configure htsp to work? I do not know. According to my kodi log, the audio stream type is not supported causing the issue (which is why it is disabled in Kodi). According to the pvr.hts info, you can duplicate the htsp stream, change these settings and then point to that configuration for pvr.hts for testing, but I have not found how. You may be able to run a few tests and see if the configuration can be changed to work.

RC4 tries to handle all the crap coming from providers for the iptv org list. The m3u8 module assumed the provider gave spec compliant m3u8 messages, which does not always happen. My crazy test was to put TVH with 5 streams and do a Force Rescan. Due to all the errors, it took over 15 tuners on the Cabernet side to support the "Force Rescan" without getting too many "All tuners in use" message.

The RC3 with the tuner status on the home page/dashboard is really nice. More enhancements to come in 0.9.5 before it is released.

It takes a while to generate the xmltv.xml message to the client with all the m3u instances and I noticed the process is running at 100%. At some point, Cabernet may have to have some compiled libraries to handle the heavier processing. Could be an optional plugin

I played with various htsp settings in Kodi and tvheadend with no luck. I never could get audio on that problem stream.

I switched all my htsp settings back to how it was originally and tried a different tact. I added the problem stream url directly to tvheadend in a new IPTV network and mux and and it works just fine. It plays the content from 8 hours in the past and the audio worked fine.

I thought maybe cabernet stripping the segments might be causing the no-audio issue to I switched on 'Play All(VOD)' in cabernet but that simply started the stream 8 hours past but again it had no sound.

It is almost like cabernet is changing the stream just enough to confuse tvheadend and Kodi.

So far, I am discovering that the 1080 version does not work with Kodi.

What I did was setup a mux on TVH with the different m3u8 files. (768x432, 1280x720 and 1920x1080). The title of the channel includes a "(720p)" on it, so it may not play at 1080 properly. I also changed the configuration on cabernet for that instance to m3u8redirect, which pushed the m3u8 file directly to TVH and it played directly from the provider.

For the m3u8redirect, it sent the 1080 m3u8 URL to TVH and when played through Kodi, it had no sound. This basically meant it was outside of Cabernet's streaming service and has to do with the url selected when playing through htsp.

The 1920 m3u8 url setup in a static mux in TVH had the same results. There was no audio in Kodi.

The 720 m3u8 url played the audio just fine in Kodi.

Not sure how to tell, but I suspect Kodi is receiving the 720 stream when given the choice of all of the resolutions. Will look into it more.

If this becomes the case; where each channel may require a specific resolution to play, we could make the change to the channel editor, but we really need to see if that is the case.

G Kazaroth wrote:

For the m3u8redirect, it sent the 1080 m3u8 URL to TVH and when played through Kodi, it had no sound. This basically meant it was outside of Cabernet's streaming service and has to do with the url selected when playing through htsp.

This is where it gets really puzzling then. Because, as C Island noted, "I added the problem stream url directly to tvheadend in a new IPTV network and mux and and it works just fine. It plays the content from 8 hours in the past and the audio worked fine." This was my experience also.

When you tried your experiment, did it also start playing the video from much earlier or did it start with "now"?

If it started with "now" then I wonder if you'd have the same result using m3u8redirect and not throwing away any packets at the start. If you do get sound then, I would wonder what is in that first packet (or first several packets) that makes Kodi play the audio. If you still do not get sound, then I would wonder how the stream coming out of Cabernet differs from the stream that is received directly. In other words, if you are doing m3u8 redirect and NOT removing any packets from the stream, it should look identical to Tvheadend and to Kodi as if you used the stream from the original source.

Obviously in the end you want to be able to throw away the "old" packets and to still be able to play (or at least record) the 1080 stream. But if it plays with audio in Kodi when you don't throw away the "old" packets, then maybe the solution would be to keep the first one or two packets, then throw away all the ones in the middle until you get to "now". If it doesn't play with audio that way, then the question is, what's different about the original stream vs. the stream coming out of Cabernet?

Personally I'd rather have to start recording, wait several seconds, and then start playing back the recording to get 1080p and sound than to have to watch 720p while knowing that 1080 is available. But what has puzzled me all along is that VLC plays these fine, starting at "now" and with both video and sound. So it may well be that Kodi is doing something weird, I just don't know what. It is a very strange problem indeed!

Oh, forgot to mention, if you are saying that m3u8redirect just tells Tvheadend/Kodi to play the original stream (not even going through Cabernet at all) then I would wonder if there is some difference between an IPTV static network and an IPTV automatic network in Tvheadend that is causing the issue? Because when you put the original link in an IPTV static network, it plays both video and audio, just from the past. So what would be different about having essentially the same link in an IPTV automatic network? Is there some difference in how the MUXes are created? I just keep thinking that something has to be different somewhere!

I have confirmed that using the top level m3u8 URL for the station causes the non-1080 one to play. I did one test and it played the 480 version without audio in Kodi. On another system, it played the 720 version with audio. So, it seems that this channel requires the specific resolution to be played and it is between a low res and a high res (probably on purpose by the provider).

The question that needs to be answered: How to set the resolution to use instead of using the default (best resolution). This can be done at the instance or channel level. I figure we could have it be empty for use best and if set will use the best resolution up to the width defined. So 720p would be 1280 and 1080p would be 1920. There are bad and good points to each. One issue is that you can record the higher level resolution, but not play live (although I am not sure if it is sending 720 over the 1080 stream).

As for Sean, you are using the top level m3u8 file containing all 3 resolutions and your interface is making a choice on what to play. I am using each of the resolutions for testing to see what is happening. It is at the resolution level that the problem is defined. When using the m3u8redirect, it sends the m3u8 URL to tvh and Caberent stops the tuner. This is because TVH is responsible for playing directly from the provider. Of course, TVH will play as it normally does, starting 8 hours back. Cabernet has no control over what TVH does. Also, VLC plays live fine because it is playing through the HTTP interface and not the HTSP interface. That is also why recording it through TVH also works. It is the use of HTSP that is causing the issue, but I am not aware of the exact reason.

New info. It is not resolution based; instead, it seems to work only the first time through TVH.

Enter either the top m3u8 or any of the 3 resolution m3u8s into TVH directly. Play the stream through Kodi and it will work. The resolution seems to vary if you use the top level m3u8. Then stop and try to play it again. This time, you will get the TVH error "tsfix: The timediff for AAC is big (291480), using current dts". It does not matter which stream you start. Even the 1080 works the first time. So, it really looks like this stream is a big mess. I tested Kodi on Ubuntu and Windows with the same effect.

Since Cabernet is suppose to clean up messes, I will take a look at the PTS Resync using ffmpeg and see if there is something about the audio that is missing. For everyone, I am currently using the ffmpeg command options:

-nostats -hide_banner -loglevel fatal -i pipe:0 -fflags +flush_packets+genpts -avioflags +direct -f mpegts -c copy pipe:1

If we could figure out how to get the direct stream into TVH without an issue by modifying the ffmpeg options, it would be an easy fix.

Also, if I turn on VOD and PTS Resync for the instance, it will play the channel (starting 8 hours back) with audio.

A few days ago I tried editing your python code to modify ffmpeg in an attempt to recode the audio. I think I tried this command but it didn't work. Maybe I coded it incorrectly

-nostats -hide_banner -loglevel fatal -i pipe:0 -fflags +flush_packets+genpts -avioflags +direct -f mpegts -c:v copy -c:a aac pipe:1

I tried it and it does the same thing without the -c options. No audio if not VOD.

Check this out. Added code to play the first segment of the list before playing the last 3 segments. Guess what??? audio played and the PTS Resync took care of the delays. It was strange playing the first 6 seconds and then skipping to the end, but it shows the audio ATSC data is available in the first segment.

a bit weird but GREAT that it worked.

Considering you already insert ATSC segments when needed can you insert a good audio ATSC data segment based on the first segment of the stream?

Yea, that is what I am thinking. Currently, Cabernet grabs what it can get from the PMT and PAT ATSC messages without checking what it has. Probably should make sure to get a video and audio codec before Cabernet thinks its good. Then, we can save that off for re-transmission, as Cabernet currently does. Only minor issue is the 0-9 counter in the ATSC messages. It has this counter and it goes from 0-9 for each msg type and then resets the counter. TVH does look at it, but not sure how hard. We send the same counter each time and TVH could ignore the message. The issue we have is the main stream is also sending the message with counters. I thought I could send it BEFORE sending any streams, which should be accepted by TVH. Anyway, yea, you have it right.

Only additional note. While testing the channel, I noticed the download of each segment from the provider is taking as long or longer than the duration of the segment, itself. Normally, Cabernet can catch up to the new segments coming in, but this channel is having some delay issues from the provider. It could be the time of day, but just thought I would mention.
Example: It took 6 seconds to download the segment and 0.2 seconds to process it (including the PTS Resync)

G Kazaroth wrote:

Check this out. Added code to play the first segment of the list before playing the last 3 segments. Guess what??? audio played and the PTS Resync took care of the delays. It was strange playing the first 6 seconds and then skipping to the end, but it shows the audio ATSC data is available in the first segment.

I had a feeling that just might work, though it seems strange that it does, but it's by far preferable to no audio! Also, I had no idea those m3u8's contained three different resolutions, but would definitely prefer to always play the best resolution (as long as it doesn't exceed 1920x1080), even if it does mean I get six seconds of old video at the start.

G Kazaroth wrote:

Yea, that is what I am thinking. Currently, Cabernet grabs what it can get from the PMT and PAT ATSC messages without checking what it has. Probably should make sure to get a video and audio codec before Cabernet thinks its good. Then, we can save that off for re-transmission, as Cabernet currently does. Only minor issue is the 0-9 counter in the ATSC messages. It has this counter and it goes from 0-9 for each msg type and then resets the counter. TVH does look at it, but not sure how hard. We send the same counter each time and TVH could ignore the message. The issue we have is the main stream is also sending the message with counters. I thought I could send it BEFORE sending any streams, which should be accepted by TVH. Anyway, yea, you have it right.

Only additional note. While testing the channel, I noticed the download of each segment from the provider is taking as long or longer than the duration of the segment, itself. Normally, Cabernet can catch up to the new segments coming in, but this channel is having some delay issues from the provider. It could be the time of day, but just thought I would mention.
Example: It took 6 seconds to download the segment and 0.2 seconds to process it (including the PTS Resync)

I wonder if you got lucky and the 1st segment contained the ATSC audio data 'this time'. I say this because when I was doing my testing the other day I turned on VOD and started the stream from the beginning and I found the stream still had no audio. Either way, if you can capture the ATSC with audio data and play that before the streams that seems like a good idea.

Figured it out. It is not going to be easy, but possible. The issue is audio and video packets are being transmitted in clumps, so the start of the segment has tons of video without any audio. Then, it has tons of audio without any video. In this one case, the video started at time index 126,000 and ended at time index 363,000 (~2.5 seconds later). The audio time index started at 354,000 and ended at 367,000. The delta between the start of the video time index and the initial audio time index is the issue. (The reason for the TVH error "tsfix: The timediff for AAC is big (289560), using current dts").

The answer is to trim the front of the stream, until the start of the video index is near the start of the audio index. In this case, there was a video packet with a PTS of 354,000 (exact same as the start of the audio index). The atsc module does not currently track the audio and video packets, but will need to do this to understand exactly where to cut the first video segment and send a partial segment.

G Kazaroth wrote:

The answer is to trim the front of the stream, until the start of the video index is near the start of the audio index. In this case, there was a video packet with a PTS of 354,000 (exact same as the start of the audio index). The atsc module does not currently track the audio and video packets, but will need to do this to understand exactly where to cut the first video segment and send a partial segment.

Glad you figured that out. Just as an aside, if you are using Tvheadend with a satellite TV tuner card (to receive free-to-air satellite signals on C-band or Ku-band) then in the tuner options there is a setting to "Skip initial bytes" which does exactly what it says, it throws away the first however many bytes you specify of the received transport stream. And if you don't use it, there is a much higher likelihood of getting bad recordings. Typically I have set it to 1,000 times the size of the input buffer, which is 188000 bytes, so I skip the first 188000000 bytes (which in practice can be anywhere from a fraction of a second to a few seconds of the stream, depending on the level of compression I suppose). But you only see that setting for a satellite TV tuner; it doesn't even appear for an ATSC tuner such as a HDHomeRun.

If they had a similar setting at the network level, that might make it easier to deal with this issue, but they don't.

Release Candidate RC05 has the USTVGO plugin. Includes the EPG from USTVGO. Recommend enabling PTS Resync for this plugin.

In general, you will get an HTTP 404 error when the channel is not allowed without the VPN thing USTVGO sells. I found about 31 of 88 channels are available without the VPN. I have had some interesting tests when a channel works and then later gets a 404 error. More testing is needed.

I did compare the stream with the actual channel and found it to be about 60 seconds behind an antenna broadcast.

A few more enhancements to include before these updates are released.

The audio/video issue is a big change and will take more than this release cycle. The design is to go into the stream and pick and remove specific packets out of the stream while keeping the rest in tact. I have the MPEG-TS PES packet code, but will need to implement it.

Hold off on upgrading just yet. I found the ustvgo site has some bad data, which is why many use a manual lookup table. The next release should have many more channels that are active. If you have upgraded, you will need to do a refresh since the data will change. Will go over that with the next update.

With the changes, the channel list contains 93 channels of which only 4 are getting 404 errors. Finishing up patch.

Cabernet 0.9.5.0-RC07
Looks like I was able to get all 93 channels to be active. If you have not enabled ustvgo, then no changes, just upgrade. If you have enabled the ustvgo, then do the following
From the Data Mgmt section:
- Reset Channel Data

Reset Edits: Yes
Plugin: USTVGO

- Reset EPG Data:

Plugin: USTVGO

- Reset Scheduler Tasks:

Plugin: USTVGO

From Scheduled Tasks, Restart Cabernet.

It will take a while to run. You can check the status on the home page or on the scheduler task list. Once it is done, you can go to TVH and add the network. Recommend 2 tuners in TVH with 4 or 5 tuners in Cabernet. There are two types of channels... Those with multiple days of EPG and those with 4-6 hours. (from ustvgo). Probably could use a zap2it guide to get multiple days, but for now it is short. At least there are not too many on the short list.

NOTE: My EPG in TVH got real messed up and I had to delete all lines from the grabber area and re-import (twice). If Kodi's EPG looks wrong, try that.

Hi,

I want to add multiple M3U instances. I have SamsungTV working and want to add Plex. Below is the config file portion for the two M3U instances. I'm not certain on the syntax for the 2nd. If the syntax is correct, then I have a different issue. The channel editor in cabernet shows a single M3U tab. All the entries are for SamsungTV. I set this up yesterday with 0.9.5.0-RC05.

[m3u_default]
label = M3U SamsungTV
enabled = True
channel-m3u_file = https://i.mjh.nz/SamsungTVPlus/us.m3u8
epg-xmltv_file = https://i.mjh.nz/SamsungTVPlus/us.xml.gz
epg-min_refresh_rate = 180
channel-start_ch_num = 1000

[m3u_default_plex]
label = M3U Plex
enabled = True
channel-m3u_file = https://i.mjh.nz/Plex/us.m3u8
epg-xmltv_file = https://i.mjh.nz/Plex/us.xml.gz
epg-min_refresh_rate = 180
channel-start_ch_num = 200

Thanks for the assist.

Try RC08 and see if the M3Us load.

Note: I would have named them

[m3u_samsungtv]

[m3u_plex]

but the names you have will work fine.

Both M3Us load with RC08. Thanks. Some channels, e.g. Hallmark Movies & More, from SamsungTV do not play when opening channels.m3u from VLC.

On another note, I also have USTVGO setup and can see all 93 channels in the editor, however, no thumbnails appear. Is that expected?