Tvheadend

I believe it's related to issue #2391

I have this exact issue as you descripe, but only on versions after 1743. Im using hdhomerun with xbmc and kodi.

/Rasmus

Rasmus Lundsgaard wrote:

I believe it's related to issue #2391

I have this exact issue as you descripe, but only on versions after 1743. Im using hdhomerun with xbmc and kodi.

/Rasmus

I don't know if it is related to bad tune, VLC streaming and recording are ok.

I got exactly the same issue here after updating to Tvheadend 3.9.2043~g0b2e072~trusty today. Don´t remember exactly what version I had before but it was about 1 week old and did not have pixelation.

J W wrote:

I got exactly the same issue here after updating to Tvheadend 3.9.2043~g0b2e072~trusty today. Don´t remember exactly what version I had before but it was about 1 week old and did not have pixelation.

Version 3.9.1992 also presents the same problem.

It only occurs in kodi, if I use other software to watch Live TV, like VLC, it's works ok.

Bruno Bastos wrote:

J W wrote:

I got exactly the same issue here after updating to Tvheadend 3.9.2043~g0b2e072~trusty today. Don´t remember exactly what version I had before but it was about 1 week old and did not have pixelation.

Version 3.9.1992 also presents the same problem.

It only occurs in kodi, if I use other software to watch Live TV, like VLC, it's works ok.

It also occurs in XBMC 13.2, which is the mediaplayer I use.

J W wrote:

Bruno Bastos wrote:

J W wrote:

I got exactly the same issue here after updating to Tvheadend 3.9.2043~g0b2e072~trusty today. Don´t remember exactly what version I had before but it was about 1 week old and did not have pixelation.

Version 3.9.1992 also presents the same problem.

It only occurs in kodi, if I use other software to watch Live TV, like VLC, it's works ok.

It also occurs in XBMC 13.2, which is the mediaplayer I use.

XBMC 13.2 also presents the problem.

I have tried 1900 (and newer) but didn't go further back. I have no issue on 1743

Rasmus Lundsgaard wrote:

I have tried 1900 (and newer) but didn't go further back. I have no issue on 1743

Do you know where I can find the 1743 build for ubuntu trusty? I'd like to test if my problem will be resolved with this build too.

Not as such... I compile from the git on my arm box But I can help you with compiling yourself if it is...

Rasmus Lundsgaard wrote:

Not as such... I compile from the git on my arm box But I can help you with compiling yourself if it is...

It would be nice

I'm already compiling my builds just don't know how to compile a later one.

If you already use Autobuild.sh script to make deb packages, you just need to checkout an earlier version of your local git. I'm no expert on git, but this is how I did. First it's a goot idea to make a new local branch:

git checkout -b older

For 1743 it's:
git checkout a510248efc719a7052e7b36d27a9550f3826933e

now when you do autobuild.sh it should make the 1743.

./Autobuild.sh
dpkg-buildpackage: source package tvheadend
dpkg-buildpackage: source version 3.9.1743~ga510248
dpkg-buildpackage: source changed by Andreas Öman <[email protected]>

To go back to newest you switch to master branch by git checkout master, and back again if needed with git checkout older

Which HD channels are affected (from satellite) ?

Jaroslav Kysela wrote:

Which HD channels are affected (from satellite) ?

In my case it's HD channels from cabel (yousee in Denmark).

Jaroslav Kysela wrote:

Which HD channels are affected (from satellite) ?

In my case is a dvb-c provider in Brazil.

In my case is a Brazilian dvb-c provider.

Rasmus Lundsgaard wrote:

If you already use Autobuild.sh script to make deb packages, you just need to checkout an earlier version of your local git. I'm no expert on git, but this is how I did. First it's a goot idea to make a new local branch:

git checkout -b older

For 1743 it's:
git checkout a510248efc719a7052e7b36d27a9550f3826933e

now when you do autobuild.sh it should make the 1743.

./Autobuild.sh
dpkg-buildpackage: source package tvheadend
dpkg-buildpackage: source version 3.9.1743~ga510248
dpkg-buildpackage: source changed by Andreas Öman <[email protected]>

To go back to newest you switch to master branch by git checkout master, and back again if needed with git checkout older

Thank you Ramus,

I've built the 1743 version but unfortunately in my case the problem persists.

It's seems that my problem is on tvh pvr addon.

Hello

I have artifacts with 2043 package from h264 streams (hungarian DVB-T) SD and HD too, but with 1879 package they are gone. With VLC the picture is perfect with both package.

I got it on Dutch DVB-C provider Ziggo on the "National Geographic Channel HD" which is using H264-encoding; same with "Discovery Channel HD".

However, I do not have it on "Fox HD" which is also H264-encoded.

They also all on different muxes, I can not find anything in my setup which points to a single cause of failure based on QAM, Mux, encoding or encryption or anything...

OK, all DVB-C - a bit difficult to test.. Could you try to remove / comment the line 'hs->hs_merge_meta_compomentidx = -1;' in src/htsp_server.c line 2982 (in latest) ?

Jaroslav Kysela wrote:

OK, all DVB-C - a bit difficult to test.. Could you try to remove / comment the line 'hs->hs_merge_meta_compomentidx = -1;' in src/htsp_server.c line 2982 (in latest) ?

Sure! I'll test and report you back.

Thank you.

TS: NET DIGITAL RJ/465/Globo HD: AC3 @ #275 Continuity counter error (total 1)

These errors mean that the received stream is not correct.

Jaroslav Kysela wrote:

[...]

These errors mean that the received stream is not correct.

Streaming direct from TVH web inf to VLC ok. If I stop tvh and use VDR as backend this same channel are also ok.
If is it a problem with stream received, shouldn't VLC/Recordings and VDR be affected too?

So, you don't see these continuity errors for HTTP streaming and DVR ? If not, then two reasons might be possibel:

1) memory is somewhat malformed (bad writes from some parts of tvh)
2) HTSP server code blocks too much the incoming packet queue and some data are dropped

Do errors depend on the input bandwidth ?

Jaroslav Kysela wrote:

So, you don't see these continuity errors for HTTP streaming and DVR ? If not, then two reasons might be possibel:

1) memory is somewhat malformed (bad writes from some parts of tvh)
2) HTSP server code blocks too much the incoming packet queue and some data are dropped

Do errors depend on the input bandwidth ?

Yes, I don't see any continuity errors from http streaming and dvr. They are working fine, the problem only happens in Kodi live TV.

I don't know if the errors depend of input bandwith but Globo HD (problematic channel) is showing 17000 ~ 180000 kb/s of input bandwidth while TLC HD (ok channel) is showing only 8000 ~ 12000 kb/s.

Jaroslav Kysela wrote:

So, you don't see these continuity errors for HTTP streaming and DVR ? If not, then two reasons might be possibel:

1) memory is somewhat malformed (bad writes from some parts of tvh)
2) HTSP server code blocks too much the incoming packet queue and some data are dropped

Do errors depend on the input bandwidth ?

AFAIK there is not a significant difference in bitrate for "faulty" channels and "good" ones. My problematic channel is roughly 10 Mbit/sec and that is roughly the same bitrate as a good channel.

Did a rollback to HTS 3.9.1743~ga510248 and no problems - András reports 1879 works too, I will test that one too to locate the introduced bug closer.

Don't know if it helps, but if you like, I can take a record and upload it somewhere else.

I have tried 1800 (works) and 1900 (doesn't work), will narrow it further at some point...

Rasmus Lundsgaard wrote:

I have tried 1800 (works) and 1900 (doesn't work), will narrow it further at some point...

Do you mind to tell how can I find the commit hash for an older build? I don't want to bore you every time I need to compile an older version

Just type 'git describe' to see which "number of changes" are you on.. The you may go backward using 'HEAD~20' where 20 is number of changes to remove...

But I suggest to look to 'git bisect' - it will do some these things automatically (to find the failing commit)...

Rasmus Lundsgaard wrote:

I have tried 1800 (works) and 1900 (doesn't work), will narrow it further at some point...

HTS Tvheadend 3.9.1879~g94ff39d works fine too. So I cut your work in half

Jaroslav Kysela wrote:

Which HD channels are affected (from satellite) ?

In my case i have artifacts not only in HD but also in SD.

I've been facing some artifacts for quite sometime, but never tried to stream to VLC, neither tried to record.
I've done it yesterday.... and i have the same thing as reported.
- Stream it to VLC.... perfect
- Record using Stream profile "pass" (.ts file) ..... perfect
- Record using Stream profile "matroska" (mkv file) .... and the artifacts are there in the recording.

I've tried different players in my laptop, (not in XBMC)like bs.player, vlc, and media player for viewing the recorded files and the results are as stated above
Using XBMC for viewing the recorded channels is exactly the same thing.... ts file plays ok, but mkv file plays with the artifacts.

I don't know about you guys, but i'm using Hispasat Sattelite, "meo" and "zon" providers
The artifacts only shows in the bottom of the image... more or less 3 to 5 cm.

J Elz wrote:

Rasmus Lundsgaard wrote:

I have tried 1800 (works) and 1900 (doesn't work), will narrow it further at some point...

HTS Tvheadend 3.9.1879~g94ff39d works fine too. So I cut your work in half

1884 doesn't work, so now we know its somwhere between 1879 and 1887

Rasmus Lundsgaard wrote:

J Elz wrote:

Rasmus Lundsgaard wrote:

I have tried 1800 (works) and 1900 (doesn't work), will narrow it further at some point...

HTS Tvheadend 3.9.1879~g94ff39d works fine too. So I cut your work in half

1884 doesn't work, so now we know its somwhere between 1879 and 1887

sorry 1884 of course. (why can't we edit old post or at least delete?)

Rasmus Lundsgaard wrote:

J Elz wrote:

Rasmus Lundsgaard wrote:

I have tried 1800 (works) and 1900 (doesn't work), will narrow it further at some point...

HTS Tvheadend 3.9.1879~g94ff39d works fine too. So I cut your work in half

1884 doesn't work, so now we know its somwhere between 1879 and 1887

Sorry guys, but for me none of the builds suggested have worked. I've tested with 3.9.1743, 3.9.1800, 3.9.1879 and 3.9.1881.

With the 3.9.1743 build it get worse, with VLC and XBMC show the same artifacts/pixelation.

I'll try to make a video of the problem.

Here is the video: http://youtu.be/c22KacnJIKY

The video shows the problem with xbmc playback and the same channel working fine over http streaming.

Bruno Bastos wrote:

Here is the video: http://youtu.be/c22KacnJIKY

The video shows the problem with xbmc playback and the same channel working fine over http streaming.

Yeah it seems your problem is actually a lot different then mine. The image I see in your XBMC looks nothing like mine: My XBMC just shows some pixelation, yours is completely distorted.. What happens if you turn off Hardware-Acceleration in XBMC ?

J Elz wrote:

Bruno Bastos wrote:

Here is the video: http://youtu.be/c22KacnJIKY

The video shows the problem with xbmc playback and the same channel working fine over http streaming.

Yeah it seems your problem is actually a lot different then mine. The image I see in your XBMC looks nothing like mine: My XBMC just shows some pixelation, yours is completely distorted.. What happens if you turn off Hardware-Acceleration in XBMC ?

I agree, this is also nothing like what I see. Mine is some pixelation and then some horizontal lines where it gets a bit more greyish in between.

/Rasmus

J Elz wrote:

Bruno Bastos wrote:

Here is the video: http://youtu.be/c22KacnJIKY

The video shows the problem with xbmc playback and the same channel working fine over http streaming.

Yeah it seems your problem is actually a lot different then mine. The image I see in your XBMC looks nothing like mine: My XBMC just shows some pixelation, yours is completely distorted.. What happens if you turn off Hardware-Acceleration in XBMC ?

I've tried all different acceleration modes, no difference.

What could be a hint is that in build 3.9.1743 VLC was also presenting the same problem, some changes made after 3.9.1743 have fixed the http streaming.

HTTP streaming was fixed between 3.9.1743 and 3.9.1800.

Maybe looking at the fix in http streaming could help fixing the XBMC problem.

Hello guys, I've been testing a lot of builds trying to find one to fix my problems but with no success.

I've tested the follow builds:

tvheadend_3.9.1743~ga510248
tvheadend_3.9.1744~g29d5c75
tvheadend_3.9.1745~g2012dc8
tvheadend_3.9.1746~gffa68ce
tvheadend_3.9.1747~g2481881
tvheadend_3.9.1748~g811191c
tvheadend_3.9.1749~g0b69b2d
tvheadend_3.9.1750~g9d0c46d
tvheadend_3.9.1751~g3860305
tvheadend_3.9.1753~g7753a6f
tvheadend_3.9.1771~g3ba4597
tvheadend_3.9.1785~g49ebb3c
tvheadend_3.9.1799~g97b593c
tvheadend_3.9.1800~gddeb002
tvheadend_3.9.1804~g45d00a3
tvheadend_3.9.1805~g14a7de8
tvheadend_3.9.1814~gd6f66e7
tvheadend_3.9.1820~ga78a83c
tvheadend_3.9.1838~gb1e1097
tvheadend_3.9.1850~gf70e601
tvheadend_3.9.1851~g2637ee0
tvheadend_3.9.1865~gb72ad69
tvheadend_3.9.1868~gf5d700e
tvheadend_3.9.1869~g40d0ac4
tvheadend_3.9.1879~g94ff39d
tvheadend_3.9.1881~g4a6d5ca
tvheadend_3.9.1900~g9305694
tvheadend_3.9.2064~g3cc291c
tvheadend_3.9.2066~ge0f8ee4

None of them have worked, the 3.9.1800 seems to work better, it has less image's distortion. As last resource, I've tested 3.4 version but the distortion/artifacts/pixelation still there.

Really don't know what to do, these channels are the most watched in home.
If there is anything I can do to help some developer to debug the problem please let me know, I'll be glad to help.

Thank you!

It seems like J Elz and I are having another issue than you, should we start a new issue thread?

Bruno Bastos wrote:

Here is the video: http://youtu.be/c22KacnJIKY

The video shows the problem with xbmc playback and the same channel working fine over http streaming.

My problem is also nothing like yours....
Mine is something like Rasmus Lundsgaard said, pixelization, but mine is in the bottom of the screen 3 to 5 cm.

Bruno Bastos wrote:

Here is the video: http://youtu.be/c22KacnJIKY

The video shows the problem with xbmc playback and the same channel working fine over http streaming.

My problem is also nothing like yours....
Mine is something like Rasmus Lundsgaard said, pixelization, but mine is in the bottom of the screen 3 to 5 cm.
And only with one transponder.... 12476/Horizontal/Meo Provider/Hispasat

Rasmus Lundsgaard wrote:

It seems like J Elz and I are having another issue than you, should we start a new issue thread?

I think it's better, it may help developer to identify the problem. Thank you so much for the help

I have now made a new issue thread for our issue #2480 and have also found that the exact introduction of the bug to be in rev. 1882

/Rasmus

Bruno Bastos wrote:

Rasmus Lundsgaard wrote:

It seems like J Elz and I are having another issue than you, should we start a new issue thread?

I think it's better, it may help developer to identify the problem. Thank you so much for the help

@Jaroslav Kysela

Is there any thing I can do to try to help you to identify the problem?

I tried the last build (2168) but the problem still there and it is happening in others channels, including SD channels.

Could you give me 60 seconds of .TS stream for one service (the play link in the service grid, assuming that your default stream profile is 'pass').. Use wget to save the contents to a file and upload it here...

Sorry for the delay @Jaroslav Kysela. I'll test and let you know.

Thank you!

@Jaroslav Kysela

Thank you so much for your help and work! The channels are working great now!

Thanks!