Does TVHeadend Support m3u8 format?

G Kazaroth

Locast provides a m3u8 format for each channel. Currently, I process the m3u8 through ffmpeg and pipe that into tvheadend (which works). Instead of proxying the stream, it would be nice to have tvheadend directly process it and remove the overhead of the proxy. When I redirect the m3u8 to tvheadend, it will play the first *.ts file (about 6 seconds) and stop. When I use the redirect with Emby and VLC client, they correctly process the m3u8 and play the stream. Note, Plex does not support m3u8 or redirect streams.

- Is TVHeadend suppose to process m3u8 files correctly?
- If not, is this something that TVHeadend has as an enhancement in the issues list?

- If not, would TVheadend be interested in having the enhancement added to the issues list?

Thank you for your support.

Flole

G Kazaroth wrote:

> - If not, would TVheadend be interested in having the enhancement added to the issues list?

The longest issue list is worth nothing if nobody is working on it. So if you want to work on it then feel free to add it if it's not already there, otherwise there is no real benefit from adding it.

G Kazaroth

Thanks for the reply. So the answer is that it does not support m3u8 and is not planned at this time. Not an issue. Appliance will assume it is not supported and provide proxy service and not re-direct.

Hiro Protagonist

Was just playing with a .m3u8 link on the weekend. TVH was quite happy with it.

Saen Acro

Flole Systems wrote:

> The longest issue list is worth nothing if nobody is working on it. So if you want to work on it then feel free to add it if it's not already there, otherwise there is no real benefit from adding it.

user#14626
Stop with this mantra, distinguish user and programmer/developer!
Here ask users, end users of the software.
Users want working features or enhancement's.
End users are not programmers to add features.
Do not set them to be a programming developer's, they are not.

Flole

For this software this separation no longer exists as there are no active developers. Everyone is a user at this point and that makes every user a developer aswell. So there's no point in making someone hoping to get a new feature while there's nobody who can implement it. Sure, you can tell everyone to open a feature request but what's the point? That doesn't get it fixed faster or whatever.

If users want enhancements they should move to paid software with a support contract. Tvheadend can not offer this at the moment as there are 0 developers. It's sad but that's the truth.

Tvheadend is open source software, the entire point of that is that everyone can enhance the code in case they need a feature which isn't there at the moment. Or maybe someone knows someone who enjoys contributing to open source software and wants to implement it. I talked to someone about why he doesn't contribute and the answer was basically "the feature I need is already scheduled for 4.4 so I'll wait for that". I don't know why you want users to be under the impression that they can just drop a feature request and then it'll be implemented soon when that's clearly not the case.

Other projects simply reject all feature requests with a comment that currently no feature requests are accepted unless the requester wants to be assigned to it.

Long story short: We should stay honest and don't give anybody the impression that adding a feature to the feature request list makes any difference. It doesn't. Not at all.

Saen Acro

Flole Systems wrote:
> For this software this separation no longer exists as there are no active developers. Everyone is a user at this point and that makes every user a developer aswell. So there's no point in making someone hoping to get a new feature while there's nobody who can implement it. Sure, you can tell everyone to open a feature request but what's the point? That doesn't get it fixed faster or whatever.
>
> If users want enhancements they should move to paid software with a support contract. Tvheadend can not offer this at the moment as there are 0 developers. It's sad but that's the truth.
>
> Tvheadend is open source software, the entire point of that is that everyone can enhance the code in case they need a feature which isn't there at the moment. Or maybe someone knows someone who enjoys contributing to open source software and wants to implement it. I talked to someone about why he doesn't contribute and the answer was basically "the feature I need is already scheduled for 4.4 so I'll wait for that". I don't know why you want users to be under the impression that they can just drop a feature request and then it'll be implemented soon when that's clearly not the case.
>
> Other projects simply reject all feature requests with a comment that currently no feature requests are accepted unless the requester wants to be assigned to it.
>

> Long story short: We should stay honest and don't give anybody the impression that adding a feature to the feature request list makes any difference. It doesn't. Not at all.

user#14626 connect me on mail, to explain privately about how some simple changes that can help to our not so small community.
Some of us have experience in other directions with can help to this project.

G Kazaroth

Since someone indicated that it worked, I did some more testing. The purpose of this forum item is to give people information on the m3u8 protocol. After doing tests, it seems that the m3u8 is present in tvheadend code; however, it is not working consistently. When it fails, the error is consistently in the debug log as "m3u url: '(null)', "m3u contents parsing failed". A scan of all channels showed that out of 44 channels, 13 parsed the m3u8 file successfully. Additional testing showed that re-trying the passed ones may not work a second time leading to a random chance of working. I did find one channel that seemed to work consistently and also found that those listed as failed would periodically work, but not very often. Also, in all cases, the first m3u8 grab by tvheadend always works. It is the followup re-grab of the same m3u8 file to get additional video streams that fails. Once a regrab works, it seems that it will continue to work.

Changing the "Stream" to "webtv-h264-aac-mpegts" seem to make things consistently work although the CPU requirements were significantly higher.

End result is that this seems to be a bug, so it would need someone that is interested in working it to resolve. I have not worked C/C++ in decades so, not really interested in trying to setup the environment and making code changes. For me, I can better control the service name that tvheadend uses by not using the m3u8 re-direct.

Saen Acro

G Kazaroth wrote:
> Changing the "Stream" to "webtv-h264-aac-mpegts" seem to make things consistently work although the CPU requirements were significantly higher.
>

> End result is that this seems to be a bug, so it would need someone that is interested in working it to resolve. I have not worked C/C++ in decades so, not really interested in trying to setup the environment and making code changes. For me, I can better control the service name that tvheadend uses by not using the m3u8 re-direct.

So after transcode it work?
Do you try to copy video and transcode audio, internally without spawn profile..

clint jones

I run several M3u8 muxes sometimes the format comes in weird and I have to use a pipe.

this works

https://shls-mbc2-prod-dub.shahid.net/out/v1/b4befe19798745fe986f5a9bfba62126/index_1.m3u8

Clint