Login at Kodi Home

margro · 2013-12-15, 14:46

(2013-12-09, 22:52)karatekickz Wrote: Thanks for all of your great work on this margro. I read the thread but wasn't clear. Would these changes you made effect the speed of loading from a Upnp Video source? Currently, when accessing my HDHomerun Prime (cablecard) via DLNA/Upnp under videos it is very quick, all under 2 secs (details below).
Thanks again for your great work. I look forward to your feedback on these numbers. I would also love for anyone else to post their numbers specifically with TVHeadend.

Well the changes are currently limited to PVR Live TV channels and only for PVR addons that do not have their own demuxer, but deliver a mpegts stream to XBMC.
This means that it does not affect the switch times of TVHeadend or VDR/XVDR.
For DLNA/Upnp: not sure if it will result in a speed-up. Depends on the actual stream transport. If it is mpegts, then it might work.
Your 2 sec is probably as fast as we can get it. For me with MediaPortal as backend it went down from 10 s to around 2 s.

keisuji · (This post was last modified: 2013-12-29, 14:09 by keisuji.)

I am using Mediaportal 1.5 backend for live tv and I have installed margros latest build (Frodo 12.3) done on 26-12-2013 with channel switching improvements. I can´t activate the pvr live tv everytime i try it xbmc stops and i need to restart it. For me it looks like XBMC can´t import the channel send from media portal.

Debug Log: http://pastebin.com/f8Fi4dQi

CV8R · 2013-12-31, 14:33

I am using Argus and not Mediaportal but this looks like a similar issue with Margros latest.

I am using Argus 2.2 for live tv and I have also installed margros latest build (Frodo 12.3) done on 26-12-2013 with channel switching improvements. The xbmc application crashes on startup as the PVR is activated and collecting EPG and the TV recordings. I dont get the opportunity to run the debug log before it fails. I have to reinstall the 12.2 version. If you can advise how to run debug I will provide but I do not get the opportunity to use the xbmc interface. I could try disabling the Argus PVR in 12.2 upgrading to 12.3 then enabling debug and re-enanbling the PVR plugin if it will help. Note, official 12.3 works fine but slow channel changes again.

Is there a topic for Margros PVR fast channel change feedback or should we post here?

Cheers CV8R

margro · 2013-12-31, 18:20

Hmm, I've no idea why the official build works fine and my build fails on EPG import for both of you... Works fine here.

@keisuji: Can't see anything weird in your log files. I have to add more debug logging to the addon to figure out if the addon is problematic or my XBMC build.

sdalton · 2014-01-01, 01:29

All of these changes sound great - I haven't transitioned to Gotham yet, but I'll have to give it a look!

I just recently added a network tuner to my setup, so I've just set up XBMC with MythTV as my backend. I was thinking about this and had an idea which could potentially speed up channel changes and provide some nice timeshift functionality for those with 3+ tuners.

Could XBMC rapidly shift between tuners as an alternate way of channel switching? If so, you could have a rolling set of tuners saving streams +/- 1 channel from your currently selected channel in your present channel group. This could extend outward on all available tuners (up to a user specified number) so that you're already pretuned to those channels and actively recording them. In this scenario, channel changing speed would be limited only by the speed at which XBMC could switch to the other tuner feed, and you'd be able to timeshift backwards to watch whatever had been on the next/previous channel for some period of time.

Has anyone tried this before?

Of course with 3 tuners, rapidly going in one direction would hit the limit of tuning speed as the trailing end of streams is dropped to acquire those in the upcoming direction. But when combined with a channel group that's less or equal to ones tuner count, you could effectively not only rapidly channel switch, but timeshift back as far as your buffer allowed on all channels.

All of this would of course eat up more resources, but if the benefits were worth it, many might opt for that approach.

scarecrow420 · 2014-01-01, 06:21

I guess it depends if your focus is only live viewing or recording or what (because recording obviously uses tuners too)

sdalton · 2014-01-01, 06:39

Indeed - recordings would of course need to override live tuners. That said, for channel surfing when nothing is scheduled, or for people with 4 or 6+ tuners setups, it may be preferable to them sitting idle.

It may also be that switching between tuners has its own costs and potentially could even take longer than tuning to another channel. I haven't dug into the code to try out this idea (yet) so I'm just throwing it out there for people who are familiar with it to consider. But on its face, it seems like it could potentially be a nice feature to have.

produno · 2014-01-01, 12:33

Im pretty sure changing tuners takes longer than an actual channel change on the same tuner. At least from what ive read anyway.

CV8R · 2014-01-02, 01:46

Quote:I am using Argus and not Mediaportal but this looks like a similar issue with Margros latest.

I am using Argus 2.2 for live tv and I have also installed margros latest build (Frodo 12.3) done on 26-12-2013 with channel switching improvements. The xbmc application crashes on startup as the PVR is activated and collecting EPG and the TV recordings. I dont get the opportunity to run the debug log before it fails. I have to reinstall the 12.2 version. If you can advise how to run debug I will provide but I do not get the opportunity to use the xbmc interface. I could try disabling the Argus PVR in 12.2 upgrading to 12.3 then enabling debug and re-enanbling the PVR plugin if it will help. Note, official 12.3 works fine but slow channel changes again.

Is there a topic for Margros PVR fast channel change feedback or should we post here?

Cheers CV8R

Figured out how to create the log file - RTFM..

Log File: http://xbmclogs.com/show.php?id=104497

nonob · 2014-01-04, 16:42

Hi,
I recently updated my official xbmc from 12.2 to 12.3.

Does this official 12.3 build include the slow channel switching ?

If not, will be included in gotham ?

Thanks

Talguy · 2014-01-05, 00:13

@margro, I tried your Gotham build dated 12/30/13 and man is that way faster than your frodo 12.3 build. I couldn't stick with it as it was starting to scrash on me due to a skin and wasn't allowing me to change the skin. I really hope this branch gets included in official builds. I also hope that we can get channel change speeds to be equivalent with Windows Media Center. WMC matches the channel change speed of my Comcast DVR.

I just changed a few channels using your 12.3 build with the WMC pvr addon and counted an average of 5 second channel change time. This isn't build but I still hope we can get it lower as I'm a live TV-aholic and like to channel surfer, especially if I'm flipping between two shows to avoid watching commercials.

sdalton · 2014-01-06, 04:47

(2014-01-01, 12:33)produno Wrote: Im pretty sure changing tuners takes longer than an actual channel change on the same tuner. At least from what ive read anyway.

I'm not positive that's the case in the scenario I'm describing, largely because this is more analogous to switching between recordings. At least in Gotham, using the MythTV backend (I'm on linux), you can see all of your recordings, even current live TV that is happening on the backend. Switching between these is nearly instant, far less than a second. Unless I'm missing something, I'm not sure why you couldn't design a frontend to switch channels on the tuners intelligently and swap between the recordings accordingly. That said, there certainly could be technical issues I'm unaware of.

Perhaps this thread isn't the proper place to discuss this, but it seemed like Margro was doing a lot to address channel switch time, so I figured it was worth a shot to bring up.

Javlin · 2014-01-06, 12:49

Just tried the new build and man does it cut down on channel changing speed. Was like waiting for youtube to load before, now its a matter of seconds while it buffers. Good work man solid effort.

Hope this code gets merged into Gotham so we don't need to be dependent on special builds. Would you care to comment on this margo?

Cheers

margro · 2014-01-06, 22:23

@sdalton: switching across tuners won't really help. The current delays in the offical XBMC builds are unrelated to tuning times. It is the stream detection of the ffmpeg library that always analyses toe stream for 5 sec before the actual playback starts. Add to that the 2-5 sec from the backend for the actual tuning and CAM decoding (in case of encrypted channels) you have the 7-10 sec switching delay that most people report.

@nonob: yes the official 12.3 build has only "slow channel switching". The changes found in my builds are not yet accepted upstream and will probably not even be part of the upcoming XBMC. Gotham.

@javlin: the changes are still under review and Gotham is already in a feature freeze state, so they won't be included in Gotham unless a miracle happens Wink

See for the current state of the discussion: PR3590.
Note that even without my changes, channel switches in Gotham will be 1-3 sec faster than in the official Frodo 12.3 build due other changes from Elupus in commit 4153310f31. This is mainly visible when using the MediaPortal addon in FFMPEG mode (RTSP streaming).
You can test this already using the current nightlies.

nonob · 2014-01-07, 11:59

Ok, thanks.