[CommanderROR]

I think I know what he is "ranting" about:


SAT>IP is a standard. You just buy a "Server" device, and get all the satellite TV converted to IP signals. All you really need on the other end is a client. TVHeadend is mostly a server, and it's pretty complicated. I used it for a while with Sat Tv.
So, you need the Sat IP server, the TVheadend server and then the XBMC plugin. Of course you can run TvH server and client on one machine, but it's not really practical.
What we need is a plugin, or even better native support for the protocol in XBMC so that we can search for channels and everything right inside XBMC without workarounds or intermediate devices/software.

Sadly, nobody has made that attempt yet.

[negge]

Nobody has done that because it's a complete waste of effort. As I've explained earlier your software needs to handle everything a standard DVB software would except for the hardware part.

[CommanderROR]

Sorry, but I have to disagree.
It's not a waste of time at all, it's probably the only way to get "real" LiveTV supporz into XBMC. Of course your software has to handle a lot of stuff, like you said, everything besides hardware, but it's the same for VDR, TVHeadend and all the others. They even have to deal with all the hassle of hardware support, to a certain degree at least.
The main difference is, that you need only one component for Sat>IP, everything is done on the client side. So instead of working on, for example, a TVHeadend server and a client plugin, you do kust the client software and include all the actual work there, recording and everything. This means you need slightly more processung power on the client, but that's it. I really can't see any other disadvantages.

What it really takes is a serious recinsidering of XBMC itself. It's still mostly a media player, and not a full-blown home theatre device, and LiveTV is still "hacked" into it and mostly reliant on the backend. I don't know whether there are any plans to change that. If there are, then SAT>IP is the way to go.

[Namerp]

The whole pvr part of xbmc seems to be a hacked together piece of software, without easy usage in mind (it is getting better but slow, very slow).

Sat>IP is great, but at the moment only real usable through VDR.
The the XBMC PVR part is near not usable for the average users (at least the setup), also a lot things won´t work like aspected. Sometime I question my self, if the developers have ever used a normal receiver/TV.

The importance of pvr for the xbmc project, i believe, cloud be measured with this comment (skins in the repo don´t need to have the pvr part):
Martijn: PVR is not a requirement for repo. A lot of people don't use it.

[negge]

It's not a waste of time at all, it's probably the only way to get "real" LiveTV supporz into XBMC. Of course your software has to handle a lot of stuff, like you said, everything besides hardware, but it's the same for VDR, TVHeadend and all the others

This is exactly what I was talking about, namely all the features of VDR/tvheadend/anything would have to be reimplemented if XBMC somehow shipped with built-in live TV support using SAT>IP. SAT>IP is a low-level protocol and only abstracts the hardware interface, nothing else.

The main difference is, that you need only one component for Sat>IP, everything is done on the client side. So instead of working on, for example, a TVHeadend server and a client plugin, you do kust the client software and include all the actual work there, recording and everything. This means you need slightly more processung power on the client, but that's it. I really can't see any other disadvantages.

Separating the backend from the frontend means you can have multiple clients all sharing one PVR backend, which means you'll only have to configure it once. Both you and Namerp seems to have been ignoring this very important part of how XBMC is designed to work completely.

What it really takes is a serious recinsidering of XBMC itself. It's still mostly a media player, and not a full-blown home theatre device, and LiveTV is still "hacked" into it and mostly reliant on the backend. I don't know whether there are any plans to change that. If there are, then SAT>IP is the way to go.

I wouldn't say it's "hacked in", live TV is complicated since there are many different systems out there and supporting all of those within XBMC would be a tough job that no one has time for, plus there's the duplication of functionality I talked about earlier.

@Namerp: of course we have all used a standard TV. The idea is of course to make XBMC easier to use, it just takes time and there's no general consensus on how things should be so there will always be someone who's disappointed.

[tco.]

From my point of view Live TV is the weak point @ xbmc. As end user it is extremely difficult to find the right pvr for my needs as well as to manage the set up of the pvr and server. The advantage of xbmc is that it is cool ?;-) and nearly usable on any platform. So if there would be an add on who picks up the broadcasted sat>ip stream I could easily watch TV on all devices.
IPTV Simple is a good approach. But it would be much easier to select only the sat>ip transmitter and use the device itself. I guess IPTV & SAT>IP is the future rater than a TV card within a Desktop PC.

Looking forward to a sat>ip pvr :-)

[dreamcat4]

Hello. I have created a rudimentary shell script that can auto-generate a .m3u playlist file from tvheadend config dir. The idea is you use tvheadend to scan for services, then it populates a folder at /usr/local/etc/tvheadend/networks/<UUID>/muxes/*. With json files.

My script scans the muxes dir of a network and creates one channel for each unmapped service. So long as the service has a name associated with it. Unfortunately the output still leaves a lot to be desired because it traverses the muxes and directories in UUID alphabetical order... and there is no lookup of channel numbers. No lookup of tvheadend channel tags. etc.

Another important missing thing is that I haven't done anything for the EPG (at all). So there is no EPG data either.

https://gist.github.com/dreamcat4/8d14cf27977963c4f1cb

Zapping is really slow on my official gotham version of xbmc. But it works!
Could not get the streams to play at all in kodi 15-ALPHA nightly build (using the same m3u file).

We really need to solve the zapping problem on official builds. I have asked about that on the other thread.
http://forum.kodi.tv/showthread.php?tid=...pid1898660

[negge]

The zapping is faster in Helix. If your streams don't work there you should file a bug report on trac.kodi.tv and add FernetMenta as CC.

[dreamcat4]

The zapping is faster in Helix. If your streams don't work there you should file a bug report on trac.kodi.tv and add FernetMenta as CC.

Thanks negge

[dreamcat4]

Ok. I try "Playlist Loader" add-on now in Helix. Which works and accepts the same .M3U playlist file channel list. My sat>ip stream urls will play now. However it still takes a long time to load / buffer any new MPEG2 DVB-S SD stream from the sat>ip box. It seems 10 seconds exactly. This is like a timeout value…

When I try opening HD streams (DVB-S2 1080i H264). They are faster to load. Which seems to be exactly 5 seconds.

It's not something I'm sure why it happens. But it seems like there is some pre-set timeout value that is too long before the stream will start playing. Or the sat>ip stream URL is incorrect?

They all look like this:

#EXTINF:-1 tvg-logo-id="" tvg-logo="" tvg-name="ITV" group-title="www.itv.com",ITV
http://192.168.1.22/?src=1&freq=11053&sr...,2324,9080


For Inverto IDL 400 / GSS.Box / Telestart Digibit R1

[negge]

@dreamcat4 why don't you just use the tvheadend addon if you've already configured tvheadend anyway? Zapping will be a million times faster too. In any case, you should probably file a bug report on trac.kodi.tv if zapping takes 10 seconds for your particular streams. Include a sample stream as well.

[dreamcat4]

@dreamcat4 why don't you just use the tvheadend addon if you've already configured tvheadend anyway? Zapping will be a million times faster too. In any case, you should probably file a bug report on trac.kodi.tv if zapping takes 10 seconds for your particular streams. Include a sample stream as well.

Thanks negge. I have taken a log and attached that to a new ticket #15728 at http://trac.kodi.tv/ticket/15728.

The reason I want to have this is because being on a dual-boot system, sometimes our local tvheadend server is unavailable. But not only that, I think it is useful to have a fail-over for any future times when our version tvheadend may become broken, or being upgraded / moved to new hardware etc.

Not only that, it is valuable for some other xbmc users. Who do not have tvheadened at all, and wish to watch live streams direct from their sat>ip box. In those cases, I can generate a UK .m3u file for ASTRA satellite from my own tvheadend config, and then they can just load up the same .m3u file directly into their xbmc. Which works because the channels / frequencies in the URL links are the same for the whole UK. It's the same sattelite.

Ideally we would want to see the similar functionality as elgato's sat>ip app. It's kindda possible already, with playlist loader + ftv guide + m3u file. Just these damn zapping speeds which (for me) are just as slow as it was on helix as was on gotham. I don't understand the problem really because either the sat>ip box is causing the delay. Or xbmc is. Yet clearly the elgato sat>ip app does not suffer any such zapping delays but of course it uses probably the sat>ip rtsp protocol. Including the rtsp teardown, re-using the same connection when zapping, etc.

There is also a feature request going for true (proper) sat>ip support. Which of course would be better, as .m3u playlist is an optional part of the spec for sat>ip devices, not all consumer sat>ip devices actually support it. But not much interest yet by any possible xbmc developers, who presumably don't have such sat>ip receivers or (like you say negge) are using tvheadend pvr addon instead.

[negge]

No one wants to reinvent the wheel, that's why there's no dedicated SAT>IP addon for Kodi. I suggest you get a Raspberry Pi to run tvheadend on or something if you want to dual-boot without losing PVR functionality.

[Starscream]

How many streams can be handled by one Pi?
And are all clients down, if this Pi with TvHeadend crashes?
I will get killed by my wife if i am not @ home and none of the TVs work for days while i am away.

So it should be a solution, which can be handled by a user, not by a specialist.

[dreamcat4]

I think we can take negge's comment to mean rPi or equivalent HTPC / micro server. As tvheadend can run on many platforms. It all depends how many streams / how much bandwidth you need to handle simultaneously at the same time.

Certainly there are a whole lot of different products which potentially *could* be used to run tvheadend on. Not forgetting NAS boxes which run linux, etc. Banana Pi has a bit more juice than the rPi. Another new one is the Fitlet, which is due to be coming out next month.

But whichever hardware it's still always going to be true that tvheadend is not a very simple to configure for many non-technical user. Who would be able to just loading up some pre-defined .m3u file in xbmc. Of course you don't get PVR and other advanced functions that way.

For me, my ideal situation would be to run tvheadend inside of a Docker container, on an x64 based ubuntu system. Slowly working towards that goal but it is still a but far off with a lot of faffing around. So something else quick and dirty in the meantime would be great way to fill that gap.