Kodi Community Forum

No problem. I can fork it again and work further with you. The goal is to have something good working at the end.

Ofc, our goal is the same, though this method could cost you some time

Builds for maverick and karmic from the master branch are now on my ppa. The location can be found in my sig.

Thanks dushmaniac. I removed your dharma-pvr and add master-pvr. Now EPG is colored. There is no more crash on channel manager and group manager. Only thing after installing new packages xbmc not autostart. But i think i can fix this. Thanks again.

Gujs Wrote:No problem. I can fork it again and work further with you. The goal is to have something good working at the end.

Hi,
good to hear, really loving XBMC with pvr functionality. It is great for progress if you and Dushmaniac can work together and *keepingmyfingerscrossed* share the work involved to fix and evolve the addon.
Is there anyway to get some sort of list of things to-do in the open? So we can discuss the requirements etc? Or am I trying to go to fast and would it be better to wait for the Eden release?
thanks,
Ruud.

dushmaniac Wrote:martdj: I only fixed the vs2008 files after the merge. the vs2010 files are on my todo list.

Ah, that explains it. I'll see if I downgrade to VS2008 or just wait a bit more.

Schumi Wrote:Thanks dushmaniac. I removed your dharma-pvr and add master-pvr. Now EPG is colored. There is no more crash on channel manager and group manager. Only thing after installing new packages xbmc not autostart. But i think i can fix this. Thanks again.

the EPG should be coloured when using Dharma-pvr too if you upgraded recently (< 1 week).
Nobody reported that crash you're talking about and I never saw that happening here. If it happens in master too, please report it
xbmc not autostarting is probably because "xbmc=autostart" has to be present in your kernel command line when booting or you forgot the install the xbmc-live package.

Ruud Wrote:Is there anyway to get some sort of list of things to-do in the open? So we can discuss the requirements etc? Or am I trying to go to fast and would it be better to wait for the Eden release?

pvr is scheduled for eden indeed and dharma hasn't been finalised yet, but you're free to discuss it ofcourse. please use another thread for it tho, so stuff doesn't get mixed up with tvheadend posts.

Hi

I use pvr-testing for a long time now. Used to compile it myself.

Now i have a Zotac HD11 ion 2 nettop as client for a second room, I've installed your master build, on Ubuntu Maveric, and I have a really annoying problem ( never had this on my xbmc server before ).
I use VNSI vdr client.

I'd like to know if i'm alone with this problem.

Here is it:

- When i start a channel from the channel list, the stream is ok. Video is smooth, no stutter. I can see the fps as 25 or 50 fps ( depending of interlacing method choosen )
- If i Stop the channel, and open a new one from the list, so everything works smoothly too.
- But if I channel switch with + - ( page up / down ) while a channel is currently streamed, here starts the problem. Video/sound stutter every 2 seconds, and the framerate moove continiously from 22 to 50 fps.

Xbmc log here:
http://xmltv.free.fr/xbmc.log


On the logfile, first channel start around line 1540.

Then first channel switch around line 1738, with lot of discontinuuity packet:



I don't have any clue on this issue yet.

Regards.

please postbin the rest of the log too, from where you start playing the first stream.

edit:
sorry, totally overlooked that link you posted. that's what you get when you return home after a day's work ^^

Quote:sorry, totally overlooked that link you posted. that's what you get when you return home after a day's work ^^

Still better to return home as staying at work isn't it ?

Some more information on this. Tryed to set xbmc pvr not starting the video in fullscreen. While tuning channels from the right chan list, I don't have this problem. But this seems normal as it the same situation as stopping previous player, before opening the new channel.

The problem only occurs if video is in fullscreen while switching channel.

Other thing I've tested, using streammdev VTP native xxbmc implementation ( vtp://ip:3000 in video source ).
While in fullscreen , i can change channel without having the problem.

Couldn't test with streamdev xbmc-pvr client, it crash xbmc when opening a channel. Anyway it's another unrelated issue.

Cheers.

could you disable the syncing stuff in settings -> video and try again?

I think that in VNSI VDR implementation the problem is the same as in tvheadend. This is xbmc video player buffering issue. Because xbmc starts playback before it has enough content in the buffer. That is why I implementer Skip First I-frame functionality into tvheadend pvr client. Video player doesn't start playback until it gets the I-frame. I just tricked it to get more content into buffer.

but then this wouldn't make sense:

hotlobster Wrote:The problem only occurs if video is in fullscreen while switching channel.

I also found this issue at that time. Switching in full screen or from channel list is not the same. If you switch a channel in full screen then the player doesn't reinitialize all the demuxers and other stuff, but it reuses them if codecs are the same (It was a long time ago when I looked at that code, so maybe something is changed now).
But if you start channel change from channel list then the whole player is initialized from the beginning for every channel switch. You can see the buffer difference if you press key "o" to show the codec info. It is under named vq an aq. The problem with stuttering occurs when aq is around 0%(jumping between 0% and 1%).
This also affect the channel change time, which is a lot longer when you switch channel from channel list.

Exactly, Fullscreen or minimised don't have the same behavior while switching.

I've tryed enabling/disabling sync feature already, no change.
This really looks like a buffer issue.

Cool, thanks for the info :-)

So it seems like this buffering problem is present when using other addons too. We could put a buffer in between I suppose, but that'll slow down the zapping time a bit.