•   
  • 1
  • 7
  • 8
  • 9(current)
  • 10
  • 11
  • 30
  •   
Live TV doesn't work on Openelec [tvheadend server]
As far as I understand the issue, there is no buffering method in XBMC when omxplayer is used. Omxplayer wants the stream to be started with a keyframe, which probably isn't the case most of the time. So, XBMC should either wait for a keyframe before starting Omxplayer, or Omxplayer should ignore all data until a keyframe is received.
Either way, a nice and decent buffering system when using Omxplayer should be very nice.
Reply
I don't think that is an good idea. As far as i know all developers working on xbmc in their free time. So if you don't pay for the product you cannot demand (or blackmail) these people to fix your problem.

I would try to fix this, but i am definitly not skilled enough to make any changes (also gimli, memphiz and opdenkamp gave it already a shot).

However in my opinion this issue will get fixed as soon as a (xbmc) developer has enough motivation to dig into it.

I think we should be grateful that xbmc generally runs this smooth on the rbp. And so long my atv2 don't get replaced by rbps Wink.

greetz

regnets
Reply
Star 
I finally found a solution for the problems with playing Live-TV from Tvheadend on Raspberry Pi.

The two main problems are:

- The I-Frame issue. Omxplayer needs an I-Frame first. This was already discussed and there were special pvr.hts add-on versions trying to fix this issue.

- The other problem is with HD LiveTV on a lot of channels. Tvheadend submits height=1088 in the subsciptionStart message. Omxplayer seems to have problems, it needs height=1080 to start the stream correctly.

What I've done to solve this problems:
I wrote a Python Tvheadend proxy which is used between XBMC/Pi and Tvheadend. The proxy drops the first frames until an I-Frame arrives and corrects the height from 1088 to 1080. The benefits of this solution:
- This workaround can be used until Tvheadend or pvr.hts add-on or Omxplayer are corrected.
- You don't need a special version of OpenELEC, Tvheadend etc. Just use your current installation.
- The solution doesn't affect other clients (PC/Laptops etc.) as you only pass your Pi(s) through the proxy

You can download TvhPiProxy here: https://github.com/polini/TvhPiProxy

TvhPiProxy has beta status. My Python-knowledge is very limited, so the script could be optimized perhaps. But it works. I had 100% success rate with the proxy up to now.
Reply
You, my friend, are a genius!! Works like a charm!! Finally I can reliably watch live TV on my Raspberry Pi. Awesome!
Reply
Thanks, it sort of works. Using the proxy channels always show picture.

The first channel is still always with wrong AR.
And for some reason picture is cropped from left and right. But it was like this before.
It does not matter if I have 16:9 or 4:3 picture, I have always black bars (left and right) and cropped picture on my 1280x1024 screen.

I have SD channels with h264 encoding.

The problem is only with live TV. Everything else works.
Reply
Thanks first,
i works most of the time but sometimes not but its quit ok its work 100% better then bevor.
One behavor is a little bit ugly old films are most in 4:3 wenn i now say xbmc should make 16:9 the picture are strecht but after zapping the the picture is in 4:3
This hehavor is on sd channels i dont have hd channels

lg
Reply
I will have a look at the aspect ratio problem. I configured XBMC to stretch the video, so I didn't noticed this problem.

Please start a recording on the channels with false aspect ratio and post the output of Tvheadend system log (web interface at the bottom):

...
Mär 09 12:02:21 dvr: # type lang resolution aspect ratio sample rate channels
Mär 09 12:02:21 dvr: 1 H264 1280x720 16:9
...
Reply
@xoox
Looking good...!
I just noticed that this 'Error: too many file descriptors in select()' is repeating on my server where i started ./tvhpiproxy.py
Don't know when and why it started...?

Thanx for your work!!
Reply
you should be fixing the actual issue instead of a nasty work around like this, which will lead to other issues.
putting a sleep() in the add-on when opening a stream before reading the first packet will work just as well i bet.
and i doubt that 1088 height is the problem here, since tvh has always sent that if your provider sends streams like that.

the problem needs to be picked up in omxplayer instead.
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
A "real" fix would be better, however, since none of the devs seem willing to look at the problem I think it's great that this gets a better workaround.
Also, why do you think this is a problem with omxplayer? I'm honestly curious since all the fixes I've seen so gar seem to involve either modifying or circumventing the TVH plugin, so I would assume that the fault lies with the plugin, not OMX...
Reply
(2013-03-09, 13:50)opdenkamp Wrote: you should be fixing the actual issue instead of a nasty work around like this, which will lead to other issues.
putting a sleep() in the add-on when opening a stream before reading the first packet will work just as well i bet.
and i doubt that 1088 height is the problem here, since tvh has always sent that if your provider sends streams like that.

the problem needs to be picked up in omxplayer instead.

Seems a bit rude, calling xoox's workaround "a nasty work around". No dev has found the time to fix "the actual issue" and maybe xoox doesn't have the time or experience to do so either, so I think we should be grateful he's offered us a workaround in the meantime.
Reply
(2013-03-09, 00:55)xoox Wrote: I finally found a solution for the problems with playing Live-TV from Tvheadend on Raspberry Pi.

The two main problems are:

- The I-Frame issue. Omxplayer needs an I-Frame first. This was already discussed and there were special pvr.hts add-on versions trying to fix this issue.

- The other problem is with HD LiveTV on a lot of channels. Tvheadend submits height=1088 in the subsciptionStart message. Omxplayer seems to have problems, it needs height=1080 to start the stream correctly.

What I've done to solve this problems:
I wrote a Python Tvheadend proxy which is used between XBMC/Pi and Tvheadend. The proxy drops the first frames until an I-Frame arrives and corrects the height from 1088 to 1080. The benefits of this solution:
- This workaround can be used until Tvheadend or pvr.hts add-on or Omxplayer are corrected.
- You don't need a special version of OpenELEC, Tvheadend etc. Just use your current installation.
- The solution doesn't affect other clients (PC/Laptops etc.) as you only pass your Pi(s) through the proxy

You can download TvhPiProxy here: https://github.com/polini/TvhPiProxy

TvhPiProxy has beta status. My Python-knowledge is very limited, so the script could be optimized perhaps. But it works. I had 100% success rate with the proxy up to now.

Thanks xoox.

Could you explain a bit more how to use this please? If I ssh into my Raspbmc box, ./ seems to point to my home/pi directory, so I copied and pasted your script into tvhpiproxy.py (I couldn't find a way to download it that didn't just give me an .htm document but perhaps that's because I'm using Opera) and copied it to there with WinSCP, changed the permissions to allow it execute and then run it but how do I have it autorun on boot?

EDIT: Hmm, doesn't seem to work for me on Raspbmc. I just get "No hardware present" when trying to start a channel and I don't have any EPG data either. I see it "Importing EPG data from client" when it starts but it's very quick and I know that it takes about 7mins for Mediaportal to retrieve the OTA EPG data on Freeview, so maybe it just needs to do this (in the background) and it will appear later. I'll have a play with OpenElec anyway.
Reply
Try this:

Git clone https://github.com/polini/TvhPiProxy and the execute the file as recommended above with ./
Don't forget to change the port for your addon.
Reply
All,

You need to forgive @opdenkamp he's probably particularly grumpy from his recent lack of sleep!

I tried this myself and I must admit for the first time in a very long time I was able to view HD live TV. (Note: I simply hacked pvr.hts to change 1088 to 1080). Interestingly this is not the first time this has been suggested as a fix for a hardware H264 decoder. Though it's the first time in this context.

Now we can hack these things in to pvr.hts to overcome the problems, but really this is clearly (as has already been made pretty clear) a problem in XBMC omxplayer. 1088 is a commonly used broadcast height. Also the lack of an i-frame at the start of the stream, while I can mod TVH to ensure this its still a bad idea to rely on this in the player, just in case. Most other players/decoders already cope with this just fine.

I must add those this was far from a complete solution, I still didn't get playback every time, but I'll revisit some other investigations I undertook some months ago to try and improve the omxplayer pvr buffering.

This does look like a step in the right direction though and at least might help the relevant people focus on the problem.

Adam
Reply
(2013-03-09, 16:54)CommanderROR Wrote: Try this:

Git clone https://github.com/polini/TvhPiProxy and the execute the file as recommended above with ./
Don't forget to change the port for your addon.

I've got it on the Pi, I just need to know how to autostart it so that I don't have to SSH in and run it manually everytime?
Reply
  •   
  • 1
  • 7
  • 8
  • 9(current)
  • 10
  • 11
  • 30
  •   
 
Thread Rating:
  • 5 Vote(s) - 4.6 Average



Logout Mark Read Team Forum Stats Members Help
Live TV doesn't work on Openelec [tvheadend server]4.65