Tvheadend

There is a pull request to incorporate TS. But maintainer never merged it. You can have it using my tree https://github.com/EricV/tvheadend or the original author tree https://github.com/EkASs/tvheadend/commits/dvr_rawts although this one is a bit outdated. My branch also adds back TS http streaming using pull request at https://github.com/andoma/tvheadend/pull/71

NB: you need to manually remove /home/hts/.hts/tvheadend/dvr/config* and then recreate recording category to use either ts or mkv.

William Sun wrote:

Hi all,

I just want to have the recordings to be output as .ts file instead of .mkv file because VLC player cannot recognize the subtitle format of the recordings from tvheadend. It is shown as "undf" for subtitles. Is output to ts file possible or is there anyway I can view the recordings with VLC?

This is because the DVB subtitles are added as S_DVBSUB to the .mkv. This is a new Subtitle stream that is currently not recognized by (most) media players. There have been discussions with various developers, but so far this new subtitle stream has not yet made it into VLC.

Eric Valette - wrote:

There is a pull request to incorporate TS. But maintainer never merged it. You can have it using my tree https://github.com/EricV/tvheadend or the original author tree https://github.com/EkASs/tvheadend/commits/dvr_rawts although this one is a bit outdated.

NB: you need to manually remove a config file and then recreate recording category to use eitehr ts or mkv.

There is a specific reason why the .ts recording option is not in the main branch. A decision was made to only support the .mkv media container to incorporate the meta-data about the recording in the recorded file it self.

By the way, I found my apartment's DVB frequency is different from the internal (I live in Hong Kong) and some channels are not found. (I used to watch TV with VLC directly by using w_scan to generate the .conf file to include all the channels) Is there any way I can either add the channels manually or let tvheadend to scan the channels manually?

You can always manually add the missing muxes directly into tvheadend from the Multiplexes tab under the dvb adapter. If they are added then tvheadend can scan them and add the services on this muxes.
The internal list of muxes is taken from the dvb_apps projects set of initial_tuning files. You can find the latest list here:
http://linuxtv.org/hg/dvb-apps/file/37781d27a444/util/scan/dvb-t/hk-HongKong

If this list is incomplete then you can submit an updated list to the linux-media mailing list
(http://vger.kernel.org/vger-lists.html#linux-media)

Hope this helps ....

Hein

There is a specific reason why the .ts recording option is not in the main branch. A decision was made to only support the .mkv media container to incorporate the meta-data about the recording in the recorded file it self.

That's the typical answer that neglects user base. I agree MKV is better. But MKV encoding was plain wrong at the time of the patch and maintainer did take ages to fix it. And providing MKV and TS is better than MKV alone.

Anyway, people can use my tree.

And why is mkv better for streaming BTW? if I test ts streaming with vlc maplyer, mplayer2 it simply works. With MKV taht has been applied only mplayer works and that only if I increase the buffer size. Mplayer2 and VLC 2 just fails. Again do you consider your user base?

Eric Valette - wrote:

That's the typical answer that neglects user base. I agree MKV is better. But MKV encoding was plain wrong at the time of the patch and maintainer did take ages to fix it. And providing MKV and TS is better than MKV alone.

Eric you know as well as me that currently we need to find more maintainers that work the code. As you can see has there been an increase in the number of patches that are committed to tvheadend so it is moving in the right direction. And the decision to only support mkv as the storage container format has been discussed before and it was decided to stick to that. So any patch that could improve the mkv muxes is always welcome.

Eric Valette - wrote:

And why is mkv better for streaming BTW? if I test ts streaming with vlc maplyer, mplayer2 it simply works. With MKV taht has been applied only mplayer works and that only if I increase the buffer size. Mplayer2 and VLC 2 just fails. Again do you consider your user base?

I never said that mkv is better for streaming ... it is a better format for recording tv shows because it can also contain the meta data about the tv show in the same file. That is something that is not possible with a raw transport stream recording.

But ... Google and others are heavily pushing WebM as a format to stream video content, and that format is based on mkv. So I would guess that mkv streaming could be just as good as .ts streaming.
But .. the main task of tvheadend is creating recordings, and streaming real time live tv ... not streaming completed recordings .. those can be watched with "normal" media players.

Hein

Hein Rigolo wrote:

Eric you know as well as me that currently we need to find more maintainers that work the code.

Sure. But a patch to add ts recording is work that has been done by someone else.

And the decision to only support mkv as the storage container format has been discussed before and it was decided to stick to that. So any patch that could improve the mkv muxes is always welcome.

Well I did not write myself the patch that fixed H264 stream in mkv because I know about nothing about H264 internals but I asked a friend of mine that did H264 encoder in the past to fix it. It did cost me a bottle of wine and a HTPC for test (that still did not came back). So I contributed to fix mkv recording yes. If people want ts recording because they wants to read their recording on a low cost TNT adapters that is able only to read TS from a USB disk, that's fine with me.

The pull request is still open. Its better open than close as people can see it but a comment saying why it will not be applied is also fine. It may help you to discover usage for the recordings that you missed. My HTPC use e-sata disk and I can move the esata disks and read them with non PC software.

And why is mkv better for streaming BTW? if I test ts streaming with vlc2 mpalyer, mplayer2 it simply works. With MKV that has been applied only mplayer works and that only if I increase the buffer size. Mplayer2 and VLC 2 just fails. Again do you consider your user base?

I never said that mkv is better for streaming ... it is a better format for recording tv shows because it can also contain the meta data about the tv show in the same file. That is something that is not possible with a raw transport stream recording.

But ... Google and others are heavily pushing WebM as a format to stream video content, and that format is based on mkv. So I would guess that mkv streaming could be just as good as .ts streaming.
But .. the main task of tvheadend is creating recordings, and streaming real time live tv ... not streaming completed recordings .. those can be watched with "normal" media players.

You miss a point. What you record may be played by other devices that may not know how to correctly play MKV. This is the case for most tv sets and low cost TNT adapters with USB storage that just dump the TS and read it back.

I do not use TS myself but if people want it enough to supply patches, I would accept them.

Eric Valette: ts recording - all audio and subtitle track works perfect, with mkv dont work audio and subtitle - crap

thanks!

I have now no more problem with mkv recording myself except the subtitle language "undf" in vlc. I suppose you already posted a snapshot of the TS and the mkv generated if you want it fixed? mkmerge v5.4.0 do now a good job at converting ts to mkv.

BTW: SCT_ISAUDIO(t) macros still lacks EAC3.

My iptvbox dosen`t work with ts stream from https://github.com/EricV/tvheadend

https://www.lonelycoder.com/redmine/issues/900

Maybe ts from tvheadend not real ts?

.ts - all OK
.mkv - subtitle is "showed" (strange, EricV branch ?) but with bad chars...

RoboSK - wrote:

.ts - all OK
.mkv - subtitle is "showed" (strange, EricV branch ?) but with bad chars...

Do you get audio with my branch? If I read the first post, you did not even get audio with upstream.

-i now dont have access to channel with this audio problem - and all old recording is deleted...
-another problem is with no way (for me) re-encoding mkv to small file (h26x) - all program what i try fail..., .ts not testes but i dont except problems

edit:
someone tested this ?
https://github.com/perexg/tvheadend/commit/c3349bf6c5c34bf1d1261c79ce39f7bd03f35511

thanks

RoboSK - wrote:

-i now dont have access to channel with this audio problem - and all old recording is deleted...
-another problem is with no way (for me) re-encoding mkv to small file (h26x) - all program what i try fail..., .ts not testes but i dont except problems

You should as codec are the problem and codec don't really change between ts and mkv only the container. I had hard time simply converting .ts to mkv when I was using vdr or when the tvheadend H264 mkv layout was plain wrong. YMMV. And MKV is the defacto standard for container today.

edit:
someone tested this ?
https://github.com/perexg/tvheadend/commit/c3349bf6c5c34bf1d1261c79ce39f7bd03f35511

As I can't test it myself, I'm reluctant to put it in my branch. I have only dvb-t at home.

someone tested this ?
https://github.com/perexg/tvheadend/commit/c3349bf6c5c34bf1d1261c79ce39f7bd03f35511

ok, test by me - works perfect, channel played 6-7W, stop playing "0"-1W
Tevii S660 USB

Eric, great job with your patch !

Now my recordings can be played on my Sony Bluray player & PS3 as well as my LG TV - makes the whole program much more useful.

The only issue I've found is that using a Silcondust HDHomerun Dual Tuner (DVB-T) I can only record one program at at time. It says that an adapter is not available, even though it sees two adapters and only one is in use. It will allow the second recording if it's on the same mux.

the latest github version (fdf89b2) from https://github.com/andoma/tvheadend.git doesn't display this behaviour.

I'm using your version (8d124f7) from https://github.com/EricV/tvheadend

Any chance that it's just slightly out of date and that you could update it ?

Cheers

I use hdhomerun also and did not experience this problem but as I have a double USB tunner, not sure I ever recorded 4 things at the same time (3 I'm sure). In addition, I do not see in the missing patches, what should correct the problem. I'm OK to push the delta but cannot guaranty it will fixe the problem.

BTW: there has been a small period during which ts recording was broken as a whole due to missing patches after ts streaming speed-up. Its now fixed.

--eric

Eric Valette - wrote:

I use hdhomerun also and did not experience this problem but as I have a double USB tunner, not sure I ever recorded 4 things at the same time (3 I'm sure). In addition, I do not see in the missing patches, what should correct the problem. I'm OK to push the delta but cannot guaranty it will fixe the problem.

BTW: there has been a small period during which ts recording was broken as a whole due to missing patches after ts streaming speed-up. Its now fixed.

--eric

I have updated my branch up to last andoma change. Just did a compile. Tell me if its works for you.

Hey,

I have been trying to record to .ts using this build and for some reason the PID's of the file can't all be indentified like they should be. When I open it up in ProjectX for example it says Video PID -n/a for example.

I am trying to run a post process script that extracts teletext subtitles to text format and the PID's need to be identified for it to work.

.ts recordings made via other apps such as from mythtv show all the PIDs

Anyway around this?

Stupid question. For .ts support do I just build from the git source ot do i have to install the basr program first?

Kryspy

I am encountering a strange problem.
I was using GIT version 66a18e5 which I compiled on Apr 09.
I did that to finally be able to record directly to TS.

Today I thought to give the latest version a try and to see progress/improvements. Normally I just link to the version I'd like to have and restart my init script.

First thing I learned is that TS recording was removed again from andoma's version (or did I get that wrong?).
Then I found Eric's version to continue the TS option in his version. So I gave that a try as well. I moved my old DVR configs before.

But within the DVR configuration there is no more option to choose/set MKV or TS. So I reverted back to my previous version, which kept untouched. Still no option for format and file extension. So I copied my configs back (which still include format settings) but of course the settings are still not available.
Recordings are done fine as TS files, so it's working.

I still have a backup of the last 30 days of my system partition but honestly, I can't find which files might influence this. I deleted /usr/local/share/tvheadend from my system and tried again my April version but still no luck here.

Can anybody help me here?

Markus
PS: I tried clearing the cache/using different browsers to avoid cache issues, btw.

Markus Bonet wrote:

First thing I learned is that TS recording was removed again from andoma's version (or did I get that wrong?).

It has never been included.

But within the DVR configuration there is no more option to choose/set MKV or TS. So I reverted back to my previous version, which kept untouched. Still no option for format and file extension. So I copied my configs back (which still include format settings) but of course the settings are still not available.
Recordings are done fine as TS files, so it's working.

That's a bug I have seen too that can be cured by:
1) Removing the config file but also the automatic recording that may contain old reference to dvr config entries,
2) Rebooting to be sure you use the correct tvheadend (and not left over from previous aborted tentative)
3) recreating the config

Depending on how you install tvheadend (package, install) you may end up using a wrong binary...

Eric Valette - wrote:

It has never been included.

So git-66a18e5 might have been already one of your versions? Is there a way for me to find out? Because this version definately records to TS but wouldn't show me the options in the UI.

That's a bug I have seen too that can be cured by:
1) Removing the config file but also the automatic recording that may contain old reference to dvr config entries,
2) Rebooting to be sure you use the correct tvheadend (and not left over from previous aborted tentative)
3) recreating the config

Depending on how you install tvheadend (package, install) you may end up using a wrong binary...

Thanks for these hints, I will give that a try.

So git-66a18e5 might have been already one of your versions? Is there a way for me to find out? Because this version definately records to TS but wouldn't show me the options in the UI.

I am pretty sure I checked that version out using git.
Funny though, there is a built binary:

ll build.Linux/tvheadend
-rwxr-xr-x 1 markus users 2373434 9. Apr 18:53 build.Linux/tvheadend

Which is identical to the version I am currently running (git-66a18e5):
[root@homeserver tvheadend_cur]# diff build.Linux/tvheadend /usr/local/bin/tvheadend
[root@homeserver tvheadend_cur]# ps -ef|grep tvhead
markus 7792 1 0 17:43 ? 00:00:02 /usr/local/bin/tvheadend -u markus -C -f

But if I call "make clean" and "make", it will fail like this:
make: *** No rule to make target `/home/markus/tvheadend/src/dvr/mkts.c', needed by `build.Linux/src/dvr/mkts.o'. Stop.

I really don't get it...
Markus

Markus Bonet wrote:

So git-66a18e5 might have been already one of your versions? Is there a way for me to find out? Because this version definately records to TS but wouldn't show me the options in the UI.

But if I call "make clean" and "make", it will fail like this:
make: *** No rule to make target `/home/markus/tvheadend/src/dvr/mkts.c', needed by `build.Linux/src/dvr/mkts.o'. Stop.

I would suggest to recone my repository of do a git reset --hard at least!

https://github.com/EricV/tvheadend/blob/master/src/dvr/mkts.c is still there in the git tree.

Eric Valette - wrote:

I would suggest to recone my repository of do a git reset --hard at least!

OK, this helped. After make clean, make finished w/o problems.
Size of the binary now is different, but the version reported is still the same (git-66a18e5). Although there were some system upgrades (kernel etc.) in between. Can't tell if this influences the size of the binary.

And finally: the options are back in the UI!