[loggio]

Hi there,

This post is more directed @ Margro and Dushmaniac....

I've taken small footage showing the difference in channel switching time using MediaPortal FFMPEG ADD-ON on my single seat setup.

Using Margro's 10.1 Dharma version and ffmpeg add-on, channel changes take about 2 seconds... sometimes not even that. Using TSreader is exactly the same... no difference in speed at all. It's working great!

See Here:
http://www.youtube.com/watch?v=Us_K5T08xpM


Using the latest windows binary from Opdenkamp however tells a rather less impressive story, using the EXACT same setup, channels take about 5-6 seconds to switch, sometimes longer.

See Here:
http://www.youtube.com/watch?v=3qrRrMi0ud0



Not sure what's changed, but ever since the api change with the pre eden builds, there has certainly been a step backwards in performance for me. But i don't know if it's the Add-on or the PVR side of XBMC itself

Your thoughts?


Cheers,
Loggio.

[Mettbrot]

Hi there,

i haven't tried Opdenkamps's PVR Build, but i experience the same problems with margos pvr build.
In addition the AddOn freezes if i press one of the arrow keys. I think they should be used for timeshifting, like in the video-mode but that does not work at the moment...

Thanks for keeping up the good work, i am glad with watchin TV on Windows XBMC now, no matter what the problems are ;-)

[loggio]

They will 'timeshifting' eventually. At the moment however that is not possible. Up and Down keys are suppose to change channels but this also does not work with mediaportal addon. I'm not sure how timeshifting will be handled... Maybe xbmc could record it's own timeshifting file and use that? Not sure what the plans are for this.

[opdenkamp]

this has nothing to do with performance, but rather a change in how buffering is handled. at this time, the buffer will be filled up to 5% by default when changing channels, where xbmc just waited for a fixed time before.

now this 5% might be a bit too much, but it's set to 5% to be on the safe side so you don't get stuttering, even on a slow machine. I'll finetune the code later so it uses a variable length, so the default value van be set to something lower than 5%.

you can change the minimum buffer level via advancedsettings:

Code:

<advancedsettings>
  <pvr>
    <mincachelevel>X</mincachelevel>
  </pvr>
</advancedsettings>

change that X to the desired value. default is 5.

timeshift is something for the future. if channel switching doesn't work, it's a bug in the mptv add-on.

[loggio]

Ahh that explains it!!

I'll give this a try.

Yeah, i'm sure it's been brought up with Margro before about channel changing. Though i never use the up and down arrows anyway, i mapped my "guide" button on my remote to bring up the channel list OSD so i can cycle through that to change, sort of like what the "up and down" arrows do inside MCE... Much better that way i think.

[loggio]

@dusmaniac

I just added an advancedsettings.xml to my directory
WINDOWS

C:/users/username/appdata/roaming/xbmc/userdata/

i pasted exactly what you had in there and changed value X to many things... 0, 1, 10 ... nothing changes :S

My log file even says that it's loaded the settings... Though my channels still take 5-7 seconds to load. Are you sure this is the problem?

[loggio]

Can anyone else try this and report back?

[opdenkamp]

pastebin a full debug log please.

[loggio]

Sure.

Here, http://pastebin.com/2PZWMNxE

Cheers.

[opdenkamp]

your build is outdated.
use the pvr-ppa branch and it should work fine.

if it still doesn't work, please provide another debug log.

[loggio]

this might seem stupid lol, but where do i get latest PPA branch build for windows?

[opdenkamp]

I forgot to do a windows build last time. Building it yourself is pretty easy. There's a complete manual on the wiki for that.

I'll publish new linux and windows builds later (somewhere in this week), which can be found on the site in my signature.

[margro]

Here, http://pastebin.com/2PZWMNxE

You pastebin log shows clearly which part of the TVServer->XBMC->Screen chain is the bottleneck here: the stream detection inside the ffmpeg library
(See the time difference between lines 515-519: 6 seconds for av_find_stream_info).

FFMpeg's stream detection for RTSP streams is still terribly slow, even with the new version in the pre-Eden builds. My Dharma builds contain a few hacks to speed-up the detection a bit, but it breaks audio for some people, so I won't use them anymore for newer builds.

The MediaPortal (TSReader) addon does not use RTSP streams and the detection there should take a shorter time.
I'm currently investigating how to move the stream detection and demuxing to the addon itself in order to speedup this part but it may take a while before this is finished.

[loggio]

dushmaniac,

i click on the link in your name -
"personal website (incl. Windows builds of XBMC-PVR): [link]"

it takes me here http://lars.opdenkamp.eu/

Where exactly are the windows builds? i don't know what i'm looking at lol... forgive me for sounding ignorant.

cheers,
Loggio.

[opdenkamp]

meh, wrong site linked (nice picture, isn't it ). I'll fix it.