Tvheadend add-on on raspberry pi - not working
#16
broadcom & gimli, no and no
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
#17
Please refer to my issue on github and add information about this problem and your config:

https://github.com/raspberrypi/firmware/issues/137


Reply
#18
This is almost certainly NOT a bug in the firmware though broadcom have been involved. It looks more like a simple state machine/AV controller bug in OMXplayer. I'm currently doing a bit of digging myself.

Adam
Reply
#19
well the more I look at it, the less sure I get Smile
Reply
#20
I talked to gimli, he said that he didn't found a solution for this problem, maybe you too together could figure it out?
Reply
#21
adamsutton: doesn't sound good! is it something we should push with the XBMC team working on the RPi port instead or is there a workaround you can put in TVH?
Reply
#22
@spylex gimli is the xbmc team working on rpi. He's thus far been unable to find a complete solution, though we may have some minor progress. But nothing concrete yet.

Adam
Reply
#23
Just got my RPi, running TVH 3.2.18 on my unRAID server, i assume even the latest Raspmc won't show me TV unless i use the workarounds mentioned in the previous pages. Thanks for the prompt response adamsutton Smile
Reply
#24
I have my Pi streaming using Tvheadend on Mpeg2 streams (SD not HD). With the option choices described below it works first time. By that I mean I can enter live TV and select a channel, if I try to change the channel I see only a black screen and I need to reboot. I'm not sure which option or combination of options is responsible. When I have time I'll iterate through and find out. The aspect ratio problem remains.

I know people already have this working first time. But until I made these changes I was unable to stream any TV. Ie I saw a black screen on the first channel selection. Some might find this post helpful if they're in the same position. Entering the HTSP stream as a source workaround didn't work for me either.

System: Openelec 2.99.1 on 256MB Pi Model B streaming from Tvheadend 3.2.18~g40a8920~precise.

Menu options (import all data and set up what should be correctly then go and change the options after):

Synchronize channel groups with backends OFF
Imports channel groups from the backend OFF
Always use the channel order from the backend(s) OFF
Use backend channels numbers (only works with 1 enabled PVR add-on) OFF

Do not store the EPG in the database ON
Reply
#25
I tried using the htsp:// method in sources.xml and I still get channels displaying in 4:3. However if I set up a http:// link directly to a channel as a strm file there is no problem. This leads me to think that it's not necessarily a problem with the TVHeadend addon but with the XBMC implementation of HTSP in the way it calls OMXPlayer.
It seems a lot of people are having the same issue - these forum threads are getting a lot of views. I've added my logs to the ticket on trac:
trac.xbmc.org/ticket/13783#comment:7
I hope the devs show this bug some love soon.
Reply
#26
With the newest build from this site:
http://openelec.thestateofme.com/r13143.img.zip

Live-TV is working for me (ok the channel switching takes more time then on the atv2, but it is ok).

Even HD-Channels are working.

The only thing which is not working is the aspect ratio issue.

Could it be possible that the width and height is mixed up? On 16:9 HD channels i get a width of 720 pixel and on 4:3 channels the picture has the aspect ratio 3:3. Maybe i'm wrong but this is what i see.

[EDIT]
OK the private german hd channels aren't working for, everything else looks good.
[/EDIT]
Reply
#27
@gimli did you have any luck with this since 12.0 final came out? Smile
Reply
#28
Using raspbmc installation, streaming from tvheadend 3.2.18 (running on a separate i5 debian box on my LAN) has not worked since I upgraded from RC2 to RC3. Using 12.0 it still doesn't work.

More specifically, I'm streaming DVB-S2 (FreeSat, plus some other stuff, ahem) from tvheadend to my 2 pi units (1x512MB, 1x256MB, both with MPEG-2 and VC-1 licenses installed correctly). Under RC2, I had problems with some SD channels on the pi, but all HD channels worked flawlessly. Since upgrading, I cannot watch -any- channels.

The same channels (both SD and HD) work perfectly on a number of other XBMC systems (Android phone/tablet, laptop, etc), which are running a mix of RC2, RC3 and 12.0 final, so I -think- we can rule out an XBMC-wide problem. Moreover, recordings from any channel work perfectly on the pi, so it isn't power-related or performance-related or memory-related (playing an HD recording from tvheadend uses about 30MB of memory according to the screen output when logging is enabled).

What I see happening with live TV on the pi, however, is the available memory (shown when logging is enabled) dropping continually until it reaches about 17MB (starting from 400MB, dropping 5-10MB every 2 seconds) and then XBMC restarts (presumably because it fails to allocate additional memory and crashes / exits).

There is nothing in "xbmc.log" to indicate that XBMC failed to allocate memory, however. In fact, there is nothing -at-all- in the log from 30s after starting the stream until it crashes / exits - here's the last few entries from the log:

12:21:55 T:2765268032 DEBUG: audio stream stalled. start buffering
12:21:55 T:2765268032 DEBUG: COMXPlayer::SetCaching - caching state 2
12:21:55 T:2765268032 DEBUG: OMXClock::OMXSetSpeed 0 buffering 0
12:21:55 T:2765268032 DEBUG: COMXPlayer::HandleMessages - player started 2
12:21:55 T:2732586048 DEBUG: COMXPlayerAudio - CDVDMsg:TongueLAYER_SETSPEED
12:21:55 T:3038486528 DEBUG: Previous line repeats 6 times.
12:21:55 T:3038486528 DEBUG: ------ Window Deinit (DialogSeekBar.xml) ------
12:21:55 T:3038486528 DEBUG: ------ Window Init (DialogSeekBar.xml) ------
12:21:55 T:2765268032 DEBUG: COMXPlayer::HandleMessages - player started 1
12:21:55 T:2732586048 DEBUG: COMXPlayerAudio - CDVDMsg:TongueLAYER_SETSPEED
12:21:56 T:2765268032 DEBUG: Previous line repeats 100 times.
12:21:56 T:2765268032 DEBUG: set caching from pvr to done. audio (1) = 11. video (1) = 9
12:21:56 T:2732586048 DEBUG: COMXPlayerAudio - CDVDMsg:TongueLAYER_SETSPEED
12:21:56 T:2765268032 DEBUG: Previous line repeats 3 times.
12:21:56 T:2765268032 DEBUG: COMXPlayer::SetCaching - caching state 0
12:21:56 T:2765268032 DEBUG: OMXClock::OMXSetSpeed 1 buffering 0
12:21:56 T:2732586048 DEBUG: COMXPlayerAudio - CDVDMsg:TongueLAYER_SETSPEED
12:21:56 T:2732586048 INFO: COMXPlayerAudio - Switching to normal playback
12:21:56 T:3038486528 DEBUG: ------ Window Deinit (DialogSeekBar.xml) ------
12:22:24 T:2883265600 DEBUG: Thread Jobworker 2883265600 terminating (autodelete)
12:22:24 T:2774910016 DEBUG: Thread Jobworker 2774910016 terminating (autodelete)

and it crashed / exited (due to lack of memory) some 3 minutes after this last entry.

It would appear that omxplayer isn't being initialised / told to start playing the stream properly. What I'm not clear on is why there is a difference between live TV and recorded TV. (I record in TS format, so in theory the recording and the live stream should be identical to XBMC, shouldn't they?)

[EDIT]
I've now tried OpenElec (r13238 and a custom build by rbej) - I've got SD channels -almost- working (oddly only some of the channels can be used to start playback, but once it works, all SD channels can be switched to), but no HD channels will play.
[/EDIT]
Reply
#29
@Neil i have also tested openELEC now with similar results as yourself.
Reply
#30
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?
Reply

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