PDA

View Full Version : Gaps in the Guide



arrbee99
2019-06-21, 03:25 AM
Just updated the guide and wondering if there should be gaps in it

47119

As I use Emby, I updated the guide in Emby using, I presume, the plugin, and the gaps that show in the NextPVR guide have programs in them in the Emby guide. So assuming the programs in the Emby guide weren't left over from a previous update, shouldn't they show up in the NextPVR guide as well.

sub
2019-06-21, 03:29 AM
Try bumping up the <EPGScanSeconds> setting in c:\users\public\NPVR-data\config.xml

sub
2019-06-21, 03:29 AM
FYI, all going well, I should be able to post that new build tonight, with option to keep the tuner alive for quicker startup.

arrbee99
2019-06-21, 03:46 AM
Thank you. Shall try that.

And thank you for the keeping tuner alive thing as well.

arrbee99
2019-06-21, 04:00 AM
Upped the time to 120 seconds, now some are filled in, some that were filled in are empty e.g. TVNZ2 at 18:00...

47120

I guess this is normal...

47121

arrbee99
2019-06-21, 08:21 AM
Erm, can't find that 'keep digital tuners primed' thing. Any suggestions ?

I should be on the new version, it seemed to install OK and its got that Highlight New Shows thing now.



Excellent - found it.

sub
2019-06-21, 08:44 AM
Erm, can't find that 'keep digital tuners primed' thing. Any suggestions ?

I should be on the new version, it seemed to install OK and its got that Highlight New Shows thing now.



Excellent - found it.Did it help?

Remember you wont get the improvement first time you use the device, but you should get it one subsequent uses. (If it seems to helps, I can look into extending it to be ready before the first use of the device)

arrbee99
2019-06-21, 09:08 AM
Did it help?

Remember you wont get the improvement first time you use the device, but you should get it one subsequent uses. (If it seems to helps, I can look into extending it to be ready before the first use of the device)

Opening in vlc got seriously fast, pretty much like your video, maybe a second, was about 9.

Opening in nextpvr.exe is generally down to 5 to 6 seconds, was about 15.

Opening in localhost thing generally 8-10 seconds, was about 17.

So thats pretty excellent.

Course if you wanted to match vlc...

Extending would also be really nice.

sub
2019-06-21, 10:32 PM
Great - that's sounding like a pretty damn good improvement.

With the web app, it's likely to get down around the 6 second range.

For nextpvr.exe, I get about more like about 2 seconds to start live tv. If you want to post the logs after trying to start live tv in NextPVR, I'll check where your delays are.

(FYI, I am working on some new v5 specific playback components, which will give better times in future, but those changes are still a little way off)

sub
2019-06-21, 10:34 PM
Opening in vlc got seriously fast, pretty much like your video, maybe a second, ...That is how quickly NextPVR will be delivering streams to Emby, so anything over that time is extra delays that Emby is adding.

mvallevand
2019-06-21, 10:38 PM
How is the speed in Emby LiveTV assuming there are HD h264 channels in that satellite you can test

Martin

sub
2019-06-21, 10:39 PM
The DVB-S system here is MPEG2 video, MPEG1 Layer II audio.

The DVB-T system is H.264 video, HE-AAC audio.

mvallevand
2019-06-21, 10:46 PM
Ok then he is stuck with transcoding https://forums.nextpvr.com/showthread.php?61530-Slow-startup&p=536203#post536203 in Emby

Martin

sub
2019-06-21, 10:50 PM
Ok then he is stuck with transcoding https://forums.nextpvr.com/showthread.php?61530-Slow-startup&p=536203#post536203 in Emby

MartinYeah, he'll need to do transcoding for playback in the web app. I know there is a couple places I could improve the startup time in the web app though, so I might be able to trim off a couple of seconds.

Other client types wont need to do that, like VLC, kodi, nextpvr.exe, Emby theatre etc.

sub
2019-06-21, 10:51 PM
BTW, I have discovered some DVB-T H.264 broadcasts are also no great for web playback, so end up requiring transcoding anyway. ie depends on encoding profile and whether they've used advanced options (MBAFF/MPAFF etc). H.264 stuff that was originally encoded for the web, like IPTV source, is always safe.

arrbee99
2019-06-21, 10:51 PM
Great - that's sounding like a pretty damn good improvement.

With the web app, it's likely to get down around the 6 second range.

For nextpvr.exe, I get about more like about 2 seconds to start live tv. If you want to post the logs after trying to start live tv in NextPVR, I'll check where your delays are.

(FYI, I am working on some new v5 specific playback components, which will give better times in future, but those changes are still a little way off)

Thanks for the info. Impressive you say it will be getting even faster...

Anyway, here, I hope, is a log.

Played tvnz1 in nextpvr.exe - 17 sec to start but first one played, so normal. Played tvnz1 again - 5 sec, tvnz2 - 5 sec, tv3 - 7 sec, bit slower but changing frequencies I presume.

I'll ask about times in Emby, hopefully they'll have a look.

sub
2019-06-21, 11:17 PM
How is the speed in Emby LiveTV assuming there are HD h264 channels in that satellite you can test

MartinFYI, after this message, I thought I'd experiment with our local H.264 channels, to see how quickly they'd start in the web app with only transcoding the audio (keeping the original H.264 stream). Some of the channels didn't work (probably because of the broadcasters encoding options), but those that did work were starting somewhere in the 3-5 second range...pretty nice.

arrbee99
2019-06-21, 11:39 PM
Posted by me on Emby sub -

'So far in Chrome (hence transcoding for me) start up times have improved to about 9 seconds and in Theater they've dropped to an awesome 2 seconds :) Never been that fast since I started using Emby / NextPVR.



Will have to have a go on Shield / Fire TV soon.'

mvallevand
2019-06-22, 12:17 AM
FYI, after this message, I thought I'd experiment with our local H.264 channels, to see how quickly they'd start in the web app with only transcoding the audio (keeping the original H.264 stream). Some of the channels didn't work (probably because of the broadcasters encoding options), but those that did work were starting somewhere in the 3-5 second range...pretty nice.

This is why I like the option of ffprobe details in cached_info for web browsing. The theory is it might not always work, but the video stream is typically pretty reliable.

Martin

arrbee99
2019-06-23, 12:53 AM
Back on the OT, did this 10 minutes ago, reckon I should increase the guide scan time to 3 minutes ?

47141

sub
2019-06-23, 04:18 AM
Back on the OT, did this 10 minutes ago, reckon I should increase the guide scan time to 3 minutes ?You shouldn't have to. 90 seconds should cover it. You might something else going on I need to look at though. (lots of new code in v5, and absolutely the possibility of bugs to be worked through)

How is the CPU usage while it's updating the EPG?

arrbee99
2019-06-23, 04:29 AM
You shouldn't have to. 90 seconds should cover it. You might something else going on I need to look at though. (lots of new code in v5, and absolutely the possibility of bugs to be worked through)

How is the CPU usage while it's updating the EPG?

Well if you mean for nextpvrserver it was idling at about 1%, went up to about 4% when starting updating, dropped back to about 2 to 3% mostly. Did spot a jump to almost 8%. So nothing drastic I presume.

sub
2019-06-23, 05:15 AM
Ok. Not to do with CPU usage then.

I'm usually using the DVB-T EPG here. I'll the DVB-S a bit later to see whether I see similar gaps.

arrbee99
2019-06-23, 05:18 AM
Merci.

arrbee99
2019-07-10, 09:28 PM
Just did a guide update. Still seem to be a few gaps...

47222

Just for dvb-s apparently, m3u's seem OK.

In the logs, it did a guide refresh (though it only did it for iptv), then I played some channels, then I did the guide refresh again, and it did the dvb-s channels as well this time.

sub
2019-07-10, 09:55 PM
Ok - I'll check this later.