Speed up NextPVR

[arrbee99 1551]

This has been touched on in this thread -  https://emby.media/community/index.php?/topic/57485-atv-livetv-failure/page-11 post216.

 

Would like to ask that if possible the NextPVR app / plugin could be speeded up. I compared the start up times for 3 TV 'functions' on 3 devices - 

 

ET, direct play -

 

NextPVR plugin 8 sec

Mediaportal plugin 4 sec

Emby Hauppauge 8 sec

 

Chrome, transcoding - 

 

NextPVR plugin 13 sec

MediaPortal plugin 10 sec

Emby Hauppauge 8 sec

 

FireTV, 2nd gen

 

NextPVR plugin 14 sec, occasional timeout - 30 sec plus.

MediaPortal plugin 4 sec

Emby Hauppauge 8 sec

 

All playing the same channel.

 

On FireTV Stats for nerds gives - 

 

for NextPVR plugin -

 

 

for MediaPortal plugin -

 

 

for Emby Hauppauge feature -

 

 

Particularly for the Fire TV I think it would help if it could get the Original Media Info as it might help it to direct play and hence start quicker.

 

Would prefer to stick with the NPVR plugin as - its available and can hopefully be improved, its from New Zealand and there isn't much of that, its the only one (for me) that gathers decent TV program artwork.

 

If anyone wants logs please let me know - server / transcoding / Fire TV ?

[Luke 37024]

We're going to need community help with this. Obviously if punchten can do it with the media portal plugin then it can also be done with next pvr, so it's possible.

[sub3 64]

arrbee99, if you use VLC player, and open a network stream like the following, how quickly are you seeing video?

http://server:8866/live?channel=3

(replace "server" with the ip address of the NextPVR machine, and "3" with the channel number you want to watch)

Edited May 23, 2018 by sub3

[arrbee99 1551]

 

arrbee99, if you use VLC player, and open a network stream like the following, how quickly are you seeing video?

http://server:8866/live?channel=3

(replace "server" with the ip address of the NextPVR machine, and "3" with the channel number you want to watch)

 

 

Generally between 5 and 7 seconds, just trying the one channel (TVNZ 1)

 

Edit - Doing similar thing with Mediaportal is also about 5 sec.

Edited May 23, 2018 by arrbee99

[sub3 64]

What device are you using? DVB-T/DVB-S?

 

When I do the same here, I'm typically seeing about 2-4 seconds. This is with DVB-T.

 

VLC is typically adding about 1 second or so of what you see. 

 

In theory, Emby should be able to be in about the same time range with it's direct play.

Edited May 23, 2018 by sub3

[arrbee99 1551]

dvb-s using Hauppauge pci-e card. No dvb-t here. 

 

It would be nice if could be a bit faster but its not too far off MP on the PC. This main thing is it would be nice if it could get faster using ET and particularly on the Fire TV. Am guessing it can't get the Original Media Info and doesn't like it.

[arrbee99 1551]

Often find though the first time you play a channel its slower than the send time. e.g. I just played NZ Prime in ET and it took 12 sec to start using MediaPortal, played it again a minute later and it took 4 seconds.

[jordy 284]

Question (might be a dumb one tho ): do the media specs change frequently on OTA broadcasts?. I personally see that in AUS all SD channels are transmitted in MPEG2 format and ALL HD channels in H264. My DVB-S tuner card always produces a 20Mb/s stream. Why then can't Emby capture and retain the transmission specs for each channel on the 1st time it is played and then use them on subsequent plays. Would this not speed up switching/playback thereafter? If the transmission criteria changes and playback fails then a refresh of the channel specs could be performed to correct.

[arrbee99 1551]

Question (might be a dumb one tho ): do the media specs change frequently on OTA broadcasts?. I personally see that in AUS all SD channels are transmitted in MPEG2 format and ALL HD channels in H264. My DVB-S tuner card always produces a 20Mb/s stream. Why then can't Emby capture and retain the transmission specs for each channel on the 1st time it is played and then use them on subsequent plays. Would this not speed up switching/playback thereafter? If the transmission criteria changes and playback fails then a refresh of the channel specs could be performed to correct.

 

That would be good, unless its happening already. Wonder what the answer is....

[sub3 64]

Often find though the first time you play a channel its slower than the send time. e.g. I just played NZ Prime in ET and it took 12 sec to start using MediaPortal, played it again a minute later and it took 4 seconds.

In NextPVR the first play of a channel is slower, because it loads the device into the process. Subsequent attempts to view a channel don't have to take that hit, so are quicker. MediaPortal is probably seeing a similar thing.

Edited May 24, 2018 by sub3

[sub3 64]

Question (might be a dumb one tho ): do the media specs change frequently on OTA broadcasts?. I personally see that in AUS all SD channels are transmitted in MPEG2 format and ALL HD channels in H264. My DVB-S tuner card always produces a 20Mb/s stream. Why then can't Emby capture and retain the transmission specs for each channel on the 1st time it is played and then use them on subsequent plays. Would this not speed up switching/playback thereafter? If the transmission criteria changes and playback fails then a refresh of the channel specs could be performed to correct.

Channels very rarely change the broadcast settings. Emby probably just needs to know if it's H.264 or MPEG2 video. It could usually cache this info (NextPVR's front end does this).

 

That said, the complication comes when a user might have a channel that can come from multiple source, so could get a different video codec depending on the tuner used. For example, a user in the UK might get Channel 4 as MPEG2 over DVB-T, or H.264 over DVB-T. 

Edited May 24, 2018 by sub3

[arrbee99 1551]

In NextPVR the first play of a channel is slower, because it loads the device into the process. Subsequent attempts to view a channel don't have to take that hit, so are quicker. MediaPortal is probably seeing a similar thing.

 

Interesting. 'Loads the device into the process' - would you know how sticky this is / how long it lasts / what causes it to be reloaded ? and can it be made to last longer ?

[arrbee99 1551]

Also, in your reply to Jordy, if the NextPVR front end caches the broadcast settings, do you know if its passed on in the NPVR plugin - possibly not looking at the first picture in the first post ?

 

Also, would that complication you mentioned matter very much - as I'm experimenting a bit at the moment I get TVNZ 1 from NextPVR plugin, MediaPortal Plugin, built-in Emby Hauppauge function and IPTV and they all have different channel numbers, which would all have (or could have) their own info cached.

[Luke 37024]

Channels very rarely change the broadcast settings. Emby probably just needs to know if it's H.264 or MPEG2 video. It could usually cache this info (NextPVR's front end does this).

 

Yea we do this per channel, however there's no probing for next pvr. I've had to turn it off in the plugin because it seems the next pvr stream urls are not intended to have multiple consumers. At least that's my observation. What i mean by multiple consumers are ffprobe, followed by an emby ffmpeg process to transcode it, or an emby direct grab of the contents to send to an emby app, or an emby app hitting the next pvr url directly.

 

Every-time in the past when we've tried to turn on probing to improve nextpvr, users have almost immediately reported problems. Usually rikiwi, arrbee99 and/or jordy. Most recently was probably 2-3 months ago. 

[sub3 64]

Interesting. 'Loads the device into the process' - would you know how sticky this is / how long it lasts / what causes it to be reloaded ? and can it be made to last longer ?

In NextPVR's case, it actually runs the a new NDigitalHost.exe process when you first try to use the device (after a reboot or restarting the recording), and then that process loads up the BDA drivers for the device. That process stays running, with BDA drivers loaded from then on (unless the process crashes, or recording service is restarted).

[sub3 64]

Yea we do this per channel, however there's no probing for next pvr. I've had to turn it off in the plugin because it seems the next pvr stream urls are not intended to have multiple consumers. At least that's my observation. What i mean by multiple consumers are ffprobe, followed by an emby ffmpeg process to transcode it, or an emby direct grab of the contents to send to an emby app, or an emby app hitting the next pvr url directly.

 

Every-time in the past when we've tried to turn on probing to improve nextpvr, users have almost immediately reported problems. Usually rikiwi, arrbee99 and/or jordy. Most recently was probably 2-3 months ago. 

You can have as many connections to NextPVR streams as you like, but you have to uniquely identify each client session, so it can track their usage and know when a resource is no longer required. If you don't identify the stream, it's assumed to be the "default" session ID. 

 

ie, you can start multiple VLC with URLs like:

http://127.0.0.1:8866/live?channel=1&client=123

and

http://127.0.0.1:8866/live?channel=2&client=124

and 

http://127.0.0.1:8866/live?channel=3&client=125

 

These will all be treated as separate sessions (123,124 and 125).

 

If a later request comes in for:

http://127.0.0.1:8866/live?channel=2&client=123

then it knows client 123 no longer needs channel 1, and now needs channel 2. etc. 

 

So it's pretty basic. Emby just needs to add "&client=<Emby-sessionID>". The Kodi addon uses a string like "&client=KODI-<GUID>"

 

You can always ask me if you're making changes and having issues with the NextPVR side of things. I'm pretty sure previous changes have probably been Emby side problems though, because Kodi etc is using the same interfaces without any major issues. 

Edited May 24, 2018 by sub3

[sub3 64]

Also, would that complication you mentioned matter very much - as I'm experimenting a bit at the moment I get TVNZ 1 from NextPVR plugin, MediaPortal Plugin, built-in Emby Hauppauge function and IPTV and they all have different channel numbers, which would all have (or could have) their own info cached.

I'm only talking about the situation where you have a single channel (say TVNZ1) available from multiple sources (say DVB-T and DVB-S). If you've got them as separate channels in you NextPVR guide, with different channel numbers etc, then you don't need to worry about this. ie, the complication was when the multiple sources of different types have been merged into a separate channel. (ie, in the NextPVR Settings->Channels tab, you've selected two channels, right clicked, and selected merge...which then allows recordings or live tv requests for that channel to come from whichever source is available)

Edited May 24, 2018 by sub3

[Luke 37024]

Curious though, what would happen with a video player that sends multiple requests to the video url and we have no way of preventing that and making the client unique?

 

I don't have a ready example of that to back that up but we do see that from time to time.

[sub3 64]

A video player is fine to request the same url multiple times with the same session id. It's not uncommon for a video play to read a chunk at the start of a recording, then the end of the recording (trying to guess at duration etc).

 

If you're trying to do multiple things at the same time though, like recording BBC1 and BBC2 at the same time, these need to be using different "&client=x" to identify each session (otherwise the first recording will start, then stop when the second recording starts, because it'll think the default session has changed channels).

Edited May 24, 2018 by sub3

[arrbee99 1551]

Anything I can do to help this, only as a user unfortunately, logs or something ?

[Luke 37024]

Being able to probe it would help a great deal but everytime i turn that back on for next pvr it is almost immediately followed by issue reports. Usually about streaming getting terminated, things of that nature.

[arrbee99 1551]

Fair enough.

 

Excuse the ignorance, but if probing upsets it, could it just be told for Live TV the video is mpeg 2 and the audio is aac or whatever. Or would it have to be told for every channel, or every program. Suppose nothing is ever simple, you have to think about 'but what if this happens' etc.

[sub3 64]

Being able to probe it would help a great deal but everytime i turn that back on for next pvr it is almost immediately followed by issue reports. Usually about streaming getting terminated, things of that nature.

 

I'm happy to look at some NextPVR logs if you're having issues. 

[Luke 37024]

Ok, here's a version of the plugin with it enabled, which @@arrbee99 can test on and report back. Thanks.

MediaBrowser.Plugins.NextPvr.zip

[arrbee99 1551]

Have had a quick go. Haven't got it to play anything yet. Not sure if its to do with this probing thing or with this  https://emby.media/community/index.php?/topic/59945-old-tv-channels/#entry588504 stuff. Will carry on and send some logs later.