Kodi Community Forum

Full Version: Intel NUC - Haswell (4th Generation CPU)
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
in the second log for sure.

the pixelation appers at irregular interval, but very often.


Quote:I think that the bulk mode

i used the bulk mode. Does not help
does:

usb_xfer_mode with 0 and with 1 make a difference?

To be honest, I see absolutely nothing in there. I think we need to bisect on a ubuntu version from mainline kernel. So - finding a working mainline version would be highly useful.
in ubuntu i tried 3.14.2, 3.12 and 3.13.

are you sure that this is a kernel issue and not xbmc/ffmpeg/gpu-driver related?
(2014-05-02, 11:25)Nafi Wrote: [ -> ]in ubuntu i tried 3.14.2, 3.12 and 3.13.

are you sure that this is a kernel issue and not xbmc/ffmpeg/gpu-driver related?

Why it would affect tvheadend recordings then? They should be independent of all the things you mention... I'll take the logs with debugging enabled on both OE daily builds and try in about an hour and let's see.

I think for those of us who use tvheadend it's a good idea to enable debug for tvheadend and then look at the syslog (run journalctl --no-pager -b -0) if tvheadend has reported continuity counter errors. That's a clear indication that the error is present and it will be easy to pinpoint the moments from the log.

I think the tvheadend debugging is actually enabled if XBMC debug log is enabled. This is from ~/.xbmc/addons/service.multimedia.tvheadend/bin/tvheadend.start:

Code:
if [ "$DEBUG" = "yes" ]; then
  TVHEADEND_ARG="-C -s -u root -g video -c $ADDON_HOME"
else
  TVHEADEND_ARG="-C -u root -g video -c $ADDON_HOME"
fi

I've always used both -s and -d flags for debugging, but maybe -s is actually enough.
Guys try to keep this to a single issue.

The issue is that for some reason Live TV over USB has screen corruption since around Feburary 15th.

Multiple people are reporting this on OpenELEC so its important that we test it out on Ubuntu as well. It should be easy enough to test different kernels that way.
Ok, I'll stop confusing everyone with the issue regarding two tuners. Smile Perhaps this should in general be handled on a separate thread. Funnily enough, both tuners work simultaneously in r17733 and the xHCI host dies if I try to use both in r17811.

Anyway, test results here.

System: Intel NUC D34010WYK, 4G RAM, PCTV 290e tuner

r17733: No errors seen. Recorded one HD channel and watched another one. Switched on the EPG overlay and tried to goof around in the menus. Not a single error.
r17811: Continuity counter errors and pixelation after a couple of mins watching and recording the same channels while watching the EPG.

Logs here: http://trsqr.net/olli/r17733_logs/ http://trsqr.net/olli/r17811_logs/

If I enabled I2C debug for em28xx module the syslog was full and rotating in about a minute, so I left it out.
I have now installed Ubuntu trusty and tried out with different kernels. 3.13.4 kernel (http://kernel.ubuntu.com/~kernel-ppa/mai....4-trusty/ ) works ok, no continuity errors, no pixelation watching one HD channel and recording 2 others. 3.13.5 kernel does not. Results consistent with what was seen between the OE builds r17733 and r17811. I ran only about 10 minute tests, but these were enough to bring the differences between the two kernels.

Is there something I can do on the different Ubuntu kernels to debug this further?

Also two tuners work simultaneously with kernel 3.13.3 and 3.13.4 but do not work with 3.13.5 (xHCI host dies)
Hi,
Does NUC bitstream TrueHD and DTS-HD?
If so does it have requirments on operating system?
Thanks!
(2014-05-02, 15:11)trsqr Wrote: [ -> ]I have now installed Ubuntu trusty and tried out with different kernels. 3.13.4 kernel (http://kernel.ubuntu.com/~kernel-ppa/mai....4-trusty/ ) works ok, no continuity errors, no pixelation watching one HD channel and recording 2 others. 3.13.5 kernel does not. Results consistent with what was seen between the OE builds r17733 and r17811. I ran only about 10 minute tests, but these were enough to bring the differences between the two kernels.

Is there something I can do on the different Ubuntu kernels to debug this further?

Also two tuners work simultaneously with kernel 3.13.3 and 3.13.4 but do not work with 3.13.5 (xHCI host dies)

Excellent tsqr, you beat me to it, I am currently making a bootable USB drive with trusty and a few kernels which I will take home and plug into the NUC tonight, so I will be able to help down the road as this debugging process progresses. The next thing I would try is watching live TV with 3.13.5 and vlc (so no xbmc/tvheadend), to see if this is a fatal kernel regression or a less fatal kernel change which triggers an unwanted side effect in xbmc. My guess is that it won't work in vlc either .....
(2014-05-02, 15:24)somy Wrote: [ -> ]Hi,
Does NUC bitstream TrueHD and DTS-HD?
If so does it have requirments on operating system?
Thanks!

yes it does in Linux. In Windows it should work, too

Quote:3.13.4 kernel works ok,

so, kernel 3.13.0 does not, 3.13.4 does and 3.13.5 does not work.

that sounds strange
(2014-05-02, 15:31)Nafi Wrote: [ -> ]so, kernel 3.13.0 does not, 3.13.4 does and 3.13.5 does not work.

that sounds strange

Indeed. The 3.13.0 that trusty is shipped with did not work ok for me, but could it be that Ubuntu has customized that 3.13.0 whereas 3.13.4 and 3.13.5 from that site are less customized? Just speculation here. Also, another question is if the problem we see (I with PCTV 290e and you with PCTV 461e) is the same or not... But 3.13 does not have the driver for 461e, right?
at the moment i have pctv 460e

this is supported since Kernel 3.2
(2014-05-02, 15:48)trsqr Wrote: [ -> ]
(2014-05-02, 15:31)Nafi Wrote: [ -> ]so, kernel 3.13.0 does not, 3.13.4 does and 3.13.5 does not work.

that sounds strange

Indeed. The 3.13.0 that trusty is shipped with did not work ok for me, but could it be that Ubuntu has customized that 3.13.0 whereas 3.13.4 and 3.13.5 from that site are less customized?

I guess they might have backported supposed "bugfixes" into the mainstream supported kernel - but just speculation here too.
Ubuntu's 3.13.0 is not a .0 it's based upon whatever 3.13.x is stable currently, you can see that when looking at there git.

Okay, let's play guessing game: https://www.kernel.org/pub/linux/kernel/...Log-3.13.5
@trsqr: Thanks very much for your work. I think it's time to file that as regression bug with Sarah Sharp <sarah.a.sharp@Linux.intel.com> - as this should be done by someone that has the hardware, please try to find the correct upstream bugtracker. I am currently not sure if that's lkml directly or some other place.

So - we found a kernel bug, more precise a regression, introduced by changes / reverts in the usb subsystem.

Thanks everyone involved.

Edit: http://www.linux-usb.org/