2013-03-03, 15:15
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.
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.
