Tvheadend add-on on raspberry pi - not working
#31
(2013-02-17, 19:04)Neil Coggins Wrote: I have also observed something unexpected (and that I haven't seen reported previously)... When attempting to play a live HD channel, I get black screen as expected. Pressing enter brings up the playback / audio / video controls (again, as expected). However, the audio stream type is blank (i.e. no indication of MPEG-2 audio or similar), and audio streams is listed as "0.0" (instead of 2.0 or 5.1 as I would expect).

Does anyone else see this? I have been looking into whether the problem was a regression in the tvheadend plugin (see #166 here), but @opdenkamp believes the problem lies in omxplayer, and so that is where I intend to focus my efforts (for whatever they are worth).

Does anyone else experience the audio streams for live HD channels being misreported in this manner?

I have this also - going via Live TV -> channels -> pick any (SD Mpeg4) running on tvheadend 3.2.18~g40a8920-dirty, I have a 60-80% chance of getting a blank screen with audio missing as you mention.

Going via Videos -> LiveTV video source (htsp://....... configured as source) I have a 20-40% chance of hitting this.

Surely in the LiveTV(1st case) trying to switch channels the chance is 90-100% for a blank screen - so I'm now only using the Video source as a workaround.

Raspberry Pi type B, 128M VideoRAM, latest XBMC 12.0 (git unknown), HdHomeRun Dual DTV. It is becoming very annoying...
Reply
#32
(2013-02-28, 07:34)thagg1975 Wrote: It is becoming very annoying...
patches welcome
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.
Reply
#33
(2013-02-28, 13:04)opdenkamp Wrote:
(2013-02-28, 07:34)thagg1975 Wrote: It is becoming very annoying...
patches welcome

I certainly appreciate this is a volunteer project and as such any fixes/issues like this require someone to do them in their own time, without any remuneration. So with that in mind I would firstly like to tip my hat to all those involved who have provided this wonderful piece of software.

From my point of view I would just like to know if the problem has been identified? And if so, where does it lie? I had a version of Raspmc prior to the Frodo Final, which worked almost flawlessly with TVHeadend on my 512MB Pi. However since upgrading to Final it stopped working and seemed to revert to the same problems reported months ago.

So it seems at some point this was resolved, whether on purpose or by accident, therefore is there any way we can track down what changes have been made, or rolled back, to see where this 'fix' might have been lost?

This obviously requires the knowledge of where the issue resides - which brings me back to my first question...
Reply
#34
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...
Reply
#35
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.
Reply
#36
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.
Reply
#37
you're guessing too much. i manage the add-on and it is not caused by the add-on.
and you (and many others) already asked for this to be fixed here, but none of the devs seems interested in fixing it (me included, and i don't have time to look into pi specific issues anyway)

so again:
(2013-02-28, 13:04)opdenkamp Wrote:
(2013-02-28, 07:34)thagg1975 Wrote: It is becoming very annoying...
patches welcome
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.
Reply
#38
OK, then let's stop guessing.


There are currently two ways to "fix" this issue. One of them relies on a modified hts addon, the other works by circumventing the hts addon altogether.

Both are "dirty fixes" and might not have a 100% success rating, but they both improve things a great deal with very little effort. So, it should be simple for somebody who knows the code well to fix this permanently.


About the fixes:

The first one relies on a "hacked" hts plugin and is described here: http://forum.stmlabs.com/showthread.php?tid=4478&page=7

It apparently (did not try this one myself) removes most of the black screen issues, some problems remain though.

The second one works by adding TVH as a video source instead of LiveTV. It is described here http://forum.stmlabs.com/showthread.php?tid=4478&page=8

I tried this one myself and it works pretty nicely. You lose EPG and stuff of course, so this is really just a dirty workaround. The fact that it works pretty much perfectly though tells us that there is no basic problem with TVHeadend and XBMC on the Pi. I really hope somebody will grab this up and work it into a proper fix. If that doesn't happen we'll just have to make do with these workarounds...
Reply
#39
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.
Reply
#40
(2013-03-03, 15:15)adamsutton Wrote: 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.

Thank you Adam for taking the time to explain the situation. As disappointing as it is that this doesn't look like getting resolved, I totally understand the reasons, and it is good to know the 'state of play'. I wish I could help out but I fear this is all far beyond my skills!

Hopefully one day this will get some attention as aside from these issues XBMC on the Pi is a joy!
Reply
#41
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)
Reply
#42
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...
Reply
#43
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.
Reply
#44
see http://forum.xbmc.org/showthread.php?tid...pid1360272
Reply
#45
see my reply there Smile
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.
Reply

Logout Mark Read Team Forum Stats Members Help
Tvheadend add-on on raspberry pi - not working3