Posts: 48
Joined: Sep 2012
Reputation:
0
It is true that an older version worked. Also, the TVHeadend plugin on Android works fine as far as I can tell, so it is not a problem with ARM processors in general.
I think it was a specific XBMC version that worked. I also remember reading that it was a Pi-Firmware issue. That doesn't really seem likely though, if it started working with a certain XBMC version...
Posts: 2,274
Joined: Feb 2009
Reputation:
30
opdenkamp
Retired Team-Kodi Member
Posts: 2,274
one or more of the following reasons: pi firmware, tvh possibly not starting each mpeg stream with an i-frame, and omxplayer starting players directly when it should keep them paused and spamming setspeed in the debug log because of that.
opdenkamp / dushmaniac
xbmc-pvr [Eden-PVR builds] [now included in mainline XBMC, so no more source link here :)]
personal website: [link]
Found a problem with PVR? Report it on Trac, under "PVR - core components". Please attach the full debug log.
If you like my work, please consider donating to me and/or Team XBMC.
Posts: 48
Joined: Sep 2012
Reputation:
0
Hi opdenkamp,
I see the problem in XBMC itself. Since an older nightly worked flawlessly there must have been a change in how XBMC handles the Plugin. So I guess the TVHeadend Plugin has to be adapted somehow, Unfortunately I lack the skills and knowledge to do anything about it.
Who creates the Plugin? Where can we ask for this to be fixed?
Thanks.
Posts: 286
Joined: Jan 2012
Reputation:
16
You're going to have to accept, unfortunately, that no one currently has the time or inclination to make this work. So unless someone steps forward its not going to happen at the moment. We've long known there are problems, with PVR+OMX (at least when coupled with pvr.hts). But no one has ever managed to fully understand the issue.
I did quite a bit of digging and I did manage to make some progress at fixing some of the buffer startup issues, though gimli did a better job and I do have a patch from him. However the problem I have is as much as I'd love to use my rpi to watch TV (which I kinda can) it's just too unreliable.
Recently a patch was applied to possibly fix DTS playback, unfortunately that has completely trashed my ability watch recorded (from TVH) HDTV, which I could previously do.
I've look at trying a few things and from what I can see yes, using the htsp:// demuxer directly is slightly better (certainly circumventing the pvr caching does seem to be quicker and more reliable) however this is only for SDTV and does not always work. Note: I've also tried putting the i-frame waiting code back into pvr.hts (though I agree with opdenkamp on the point this is not where it should be handled, though I disagree that it shoudl be the servers job, that's asking for trouble, though it might "try" and help).
But I still occasionally see problems with both methods, so its far from foolproof.
For me HDTV simply doesn't work in any way shape or form these days (even recorded content, as per above) my guess is there is a problem with H264 processing, but I'm speculating on areas of the code I'm unfamiliar.
Basically for me there is currently just too many unknowns with rpi, I'm not inclined to look into it as for me the platform is just not reliable enough and I don't have time (or knowledge) to fix anything. And I think you'll find the same goes for most of the devs that might have some hope of fixing this.
I hate admitting defeat, and the last thing I want to see is users switching from TVH, but at this point in time it's fair to say that xbmc+pvr.hts+rpi = broken.
Adam
P.S.
In response to other comments about this/that works and this can't be a generic ARM/rpi issue, this is indeed completely true. There is at least one other TVH client (pidvbip) that is a dedicated STB/TVH client on pi. And this has no such issues, so yes this is a problem with XBMC core/omxplayer (I don't believe pvr.hts is, or should be, to blame) but there are still too many unknowns.
Posts: 4
Joined: Mar 2013
Reputation:
0
2013-03-04, 10:58
(This post was last modified: 2013-03-04, 15:24 by HarryL.)
Well i use TVH on my i386 soekris(500MHZ/RAM) box, and RPI to view en content(HTSP/zeroconf))... and i have no problem with SD/HD.. the only thing is that recorded content seem to be slower now to start through PVR-addon, via mounted NFS it is faster,
liveTV is a lot faster through PVR-addon, but there is 1/10 chance of a channel actually starts..
but i remember a few month ago where recorded content did work better though PVR-addon then NFS.. but hey it works, and i currently don't use the PVR-addon.
i use HDhomerun Dual Tuner.. anyone know how compile the new LIBHDHOMERUN on a headless server?(debian)
Posts: 4
Joined: Dec 2011
Reputation:
0
Hi,
I have found something, I do not know if it could help someone who have the skills.
In LIVE TV with contextual menu when you select AUDIO SETTING, switch AUDIO OUTPUT from HDMI to another mode until you can watch your channel. It works fine and kickly
I do not know why, but I think the problem is around AUDIO OUTPUT mode.
I have to unabled subtitle and select STRETCH 16/9 in VIEW MODE to watch TV like with the tv tuner.
I hope my contribution will help...
Posts: 2
Joined: Mar 2013
Reputation:
0
2013-03-07, 23:15
(This post was last modified: 2013-03-07, 23:32 by dahorne.)
I have just read through this thread with great interest. I have also been experimenting with the RPi hoping that I can come up with an elegant, low-power solution to home media centre that would allow me to decommission that power hungry dual-core P4 Wiin7 Media Center box with its whirring fans and massive DVB-S2 cards. And improve the WAF (wife acceptance factor) rating at the same time. My setup is 2 x model B RPis. One running TVheadend 3.5.22 on latest Raspbian with a WinTV-Duet twin DVB-T USB dongle through powered USB hub. The other running latest release XBMC on RaspBMC.
Streaming live TV from TVheadend works fine to various Linux (Ubuntu) laptops and Win7 and Win XP laptops running XBMC Frodo. Entirely reliable for multiple simultaneous streams, recording etc, the TVHeadend RPi is totally stable. Likewise no problem if I run TVheadend on one of the laptops and stream eleswhere.
Recorded TV playback is fine, but I have consistent liveTV "black screen" on the XBMC RPi (irrespective of where I am running TVHeadend). The only time this worked briefly was on some final RC2 updates (end of December I think), but returned back to the old problem as soon as I updated to RC3 and has stayed the same ever since - I have tried each nightly as it comes along but no change. I have 100% successful results using HTSP://tvheadend IP:9982 direct access to the muxes but as others have remarked, it is a "dirty" fix.
I am convinced that this is an OMXplayer/HTSP issue. Not TVHeadend or RPi firmware.
I just want to thank Adam and Gimli for the tremendous effort. It is now so...... close to a fully usable solution. Plus my wife - who can't see - uses her speaking iPhone to control it all through the official XBMC iOS app - brilliant!
The last time I did any Unix software was 20 yrs ago, I fear I am of no help in fixing this. I will just keep my fingers crossed that eventually someone will figure out exactly where the problem lies.
If I can help with testing, logs etc, I would be very happy to do so.