Live TV progress

[softworkz 3338]

7 minutes ago, emveepee said:

IPTV to tuner comparison testing is equally not fair.

I thought, @arrbee99's example was IPTV. 
Also, the end of the video is showing tuner playback (with transcoding).

[softworkz 3338]

10 minutes ago, emveepee said:

Technically It is not much different than streaming a previously transcoded recording

It's quite different in a number of ways.

But - sure - you can "tune" more quickly because it's always behind in time, so there's an amount of stream data that you can get quickly whereas with real tuners, you need to wait a bit until a certain amount of data has aggregated.

Edited November 13, 2022 by softworkz

[emveepee 112]

1 minute ago, softworkz said:

It's quite different in a number of ways.

I think anyone who has used IPTV Simple or most Android clients know how have fast IPTV can be.  I am strictly talking media delivery speed thought and not the backend work which doesn't have that much overhead (in ms) for buffering, queueing etc.  I am certainly not trying to take anything away from your effort, just saying they are different.

Martin

[softworkz 3338]

3 minutes ago, emveepee said:

I think anyone who has used IPTV Simple or most Android clients know how have fast IPTV can be.  I am strictly talking media delivery speed thought and not the backend work which doesn't have that much overhead (in ms) for buffering, queueing etc.  I am certainly not trying to take anything away from your effort, just saying they are different.

Yes. Please see my edit.

[arrbee99 1560]

Those videos were using dvb-s. These are also using dvb-s but they should both be using direct play with the correct Emby Theater and NextPVR -

 

 

[softworkz 3338]

The examples at the end of my video above were from DVB-C - but with ffmpeg transcoding. Without transcoding, it's about 400ms faster, which means similar to NextPVR - but then, it's still in the browser with HLS streaming, unlike the other.

[Guest CodeCat5]

3 hours ago, emveepee said:

Even with my obvious bias towards NextPVR, I don't think comparing a direct play client with a browser client is fair I would do this example in Home Theatre or between two Android clients with direct play in Emby.

 

2 hours ago, emveepee said:

IPTV to tuner comparison testing is equally not fair.  Technically It is not much different than streaming a previously transcoded recording except the bandwidth is typically low.

For me, personally, I've mostly just compared Emby on client devices (Shield and various Rokus). IMO It's just not a good experience on Rokus, and I'd say the Shield is barely passable at this point. I'm also only comparing my OTA antenna since I don't use any IPTV services (would be awesome to integrate something like Pluto, but otherwise OTA is my only concern). I know direct play is a lot faster, but if you want to use DVR functions or pause something that's direct played then it's clunky and takes several button presses - something that simply requires pressing pause with Plex or Channels DVR. While I don't really know what's required on the backend to handle transcoding and such for live TV so that DVR functions will work, I do know that Channels DVR, Plex, Jellyfin, and (IIRC) Kodi all seem to handle these functions senselessly and can tune a channel in a fraction of the time that it takes Emby.

[emveepee 112]

16 hours ago, softworkz said:

The examples at the end of my video above were from DVB-C - but with ffmpeg transcoding. Without transcoding, it's about 400ms faster, which means similar to NextPVR - but then, it's still in the browser with HLS streaming, unlike the other.

Great.  The ffmpeg looks low so I assume that is only transcoding audio, with h264 video and remuxing to HLS.  As I noted earlier Emby has a significant advantage over NextPVR because NextPVR does not have smart transcoding, it will also transcode h264 if the audio need transcoding so Emby will always "win" those races.

[softworkz 3338]

9 minutes ago, emveepee said:

Great.  The ffmpeg looks low so I assume that is only transcoding audio, with h264 video and remuxing to HLS

I think I said it in the video, it's MP2Video (to H264), but only SD and the CPU is fast. What happens there is totally different from what Emby does normally. There's no probing, MPEGTS streams and HLS muxing is handled by the server, not ffmpeg, and so many other things are totally different.....but I can't tell all the secrets now, even though I'd love to  

[emveepee 112]

Sorry I muted the video but for transcoding speed that is why I wanted to see a RPi4 example.

Hust as long as you don't use the ffmpeg code in Emby, secrets are fine. NextPVR is closed source too so all of this would have to be done from the standards, which isn't worth it for a few 100ms.  TVHeadend has faster tuning then NextPVR but it doesn't have the limitations imposed by closed source.

In general my opinion is 5 second tuning is fine anyway, I think when you use a PVR channel surfing is just old school, there is far more important stuff needed in PVR.

Martin

[softworkz 3338]

6 hours ago, emveepee said:

so all of this would have to be done from the standards, which isn't worth it for a few 100ms

There are many other reasons than tuning time.

6 hours ago, emveepee said:

TVHeadend has faster tuning then NextPVR

It's probably not even TVHeadend, but rather Win vs. Linux. Unfortunately, tuning is quite a bit slower on Windows.

7 hours ago, emveepee said:

In general my opinion is 5 second tuning is fine anyway

That's interesting. For me, any delay is an annoyance. I have an LG TV which tunes as fast as normal for those gagdets, but every few channel switches it decides to hang for about 2-3s and that alone is upsetting me regularly..

[arrbee99 1560]

5 seconds might possibly be OK if it was the norm, but not when some manage it in a tenth of the time.

[emveepee 112]

Here in Canada we depend on digital STB for many channels and 3-5s is the norm via the remote.   OTA ATSC is faster for sure.

For real use and I actually run NextPVR on Linux and don't see much difference for tuning over BDA drivers.  TVHeadend has an excellent demux and it is tweaked with Kodi for playback, and that (curently) can't be beat and it is superior to simple http.  TVHeadend users complain that NextPVR is too slow.

I feel NextPVR with BDA to DirectShow is why it so fast on Windows, with the secret sauce for multi-rec, timeshift, tuner management and back to back playback being the main overhead.  Oddly Roku users don't seem to mind the 20s it takes to buffer legit live TV.

Martin

[softworkz 3338]

14 minutes ago, emveepee said:

For real use and I actually run NextPVR on Linux and don't see much difference for tuning over BDA drivers. 

Just to be clear: what I'm talking about is 250-400ms by which BDA is slower. This is consistent across tuner models and even reproducible when forwarding a USB tuner on Windows to a Linux VM and accessing it from Linux (and switching between these).

I know why it happens and I also know how it can be worked around, but doing so will not work universally with all tuners in the same way, and that is a can that you don't want to open - at least not at an early stage like this.

[emveepee 112]

The @arrbee99 example looked like he probably is running in "primed" mode on NextPVR meaning the BDA driver doesn't get shutdown/reopened after the first use.  In NZ with many channels on on frequency that makes sense but with devices like HDHR's in BDA mode it is awful.  Live TV to Emby would also have been primed, however there is no guarantee he didn't change to another frequency making the demo unfair.

Martin

Edited November 15, 2022 by emveepee

[softworkz 3338]

The TVnext examples at the end were with a Hauppauge USB tuner using BDA on Windows and there was no "priming" used.  

HDHR are supported in two ways: Via BDA and low-level HDHR API (the way how their BDA drivers are interfacing with their devices).

[arrbee99 1560]

I did have "primed" on, cause I'm going to use the fastest available. I'm in  a satellite only area, so no dvb-t tuner for me. I had NextPVR app and Theater app in windows open on screen at the same time, played TV News on NextPVR, stopped and carried on with TV News in Theater.

[cncb 17]

I still don’t get it.  If it is so great and ready to go, what is the resistance to releasing a beta?

[arrbee99 1560]

Nobody gets it. Its excuses not reasons.

[neik 837]

3 hours ago, arrbee99 said:

Nobody gets it. Its excuses not reasons.

Then maybe it's about time for @Luke to enlighten us...

[bungee91 98]

Just to chime in, this is the single most important addition to Emby to me. The amount of work spent on the ATV replacement, and subtitles in general make me . Looking forward to hearing about a round of testing or release.

[JayG7800 2]

I just took a look at the tvnext spreadsheet and am quite impressed with the list!  I do want to make sure a couple of my scenarios are possible with the tvnext implementation:

- Ability to have separate tuners (ie: two separate HDHR's) have separate channel lists AND also separate EPG Guide data (ie: different zip codes) possibly from different sources

   Example: I live in a location with access to both USA and Canadian local channels.  This means I have to use a Canadian postal code to get the Canadian channel listing from Gracenote/SchedDirect), but use a separate US zip code to get the US channel list and data.

- Ability to capture FM stations from Hauppauge tuners that support FM radio.  It would be nice if the screen showed the channel's logo or something of that nature.  EPG guide could just show the radio station's name or whatever.

- The ability to use different types of sources for different tuners.  Example: Use built-in guide data from Gracenote for Tuner 1, XMLTV files for Tuner 2.

 

Thanks!

[softworkz 3338]

3 minutes ago, JayG7800 said:

 Example: I live in a location with access to both USA and Canadian local channels. 

Why can't both tuners receive both signals (US+CA)?

 

2 minutes ago, JayG7800 said:

- Ability to have separate tuners (ie: two separate HDHR's) have separate channel lists AND also separate EPG Guide data (ie: different zip codes) possibly from different sources

There are no restrictions. You can have 7 tuners, and 11 guide sources and everything can be freely assigned .You can merge identical channels from multiple tuners into one, you can keep them separate - whatever you like.

 

7 minutes ago, JayG7800 said:

- Ability to capture FM stations from Hauppauge tuners that support FM radio

No, that's not supported. Only digital TV is supported. Digital Radio channels are supported (this might include channels that are normally/primarily broadcasting over FM.
But analog reception is not supported, neither for TV nor Radio.

10 minutes ago, JayG7800 said:

- The ability to use different types of sources for different tuners.  Example: Use built-in guide data from Gracenote for Tuner 1, XMLTV files for Tuner 2.

Yes, not just per-tuner but per-channel

[JayG7800 2]

On 12/23/2022 at 10:11 PM, softworkz said:

Why can't both tuners receive both signals (US+CA)?

No, that's not supported. Only digital TV is supported. Digital Radio channels are supported (this might include channels that are normally/primarily broadcasting over FM.
But analog reception is not supported, neither for TV nor Radio.

Yes, not just per-tuner but per-channel

I live in a rather remote area between two TV markets.  Montreal stations are near 0 degrees, while Vermont, USA stations are at 180 degrees.  Because of this, and also because both markets have both UHF and VHF stations, I have 4 separate antennas and 4 separate tuners to maximize signal strength.  

 

I understand regarding FM radio, however, there are a few Hauppauge tuners that do support FM radio.  It used to be a nice feature back in SageTV, and would still be a nice feature in Emby.  There is a script that lets this functionality work via NextPVR - I could use this again (adding the channels in via xteve), but the issue I had with Plex was that I did not have a source for EPG for the FM channels, so I had to map them to totally incorrect channels, causing their channel names and programming to be incorrect.  It would be nice to be able to do something like this, even if it required a customized XMLTV file.  

 

Anyway, thank you for the reply, and I look forward to trying this out, either in beta or when released!

[softworkz 3338]

I know those Hauppauge cards, but they are discontinued. Anyway, this wouldn't be doable easily because it doesn't fit into the modeling we have. Everything is different in the whole chain from tuner to "screen"/playback. It start's with a different driver model, the tuning/channel scanning process is different, and the signal that needs to be handled and processed is different. A lot of work for little value IMO. And for a tiny audience, because those receiver cards don't seem to have been a big success. 
There's a plugin model for tuner providers, so in case somebody would want to develop a tuner provider for this, it might be doable, but it will take significant effort.