Kodi Community Forum

NICE!

proof accomplished - what a shame. The USB ports get flakey under high load ...

So when watching LiveTV simultaneously and using Deinterlacing, which causes high cpu load, that issue happens more often. An external powered hub does not help?

Edit: Try to debug usb. Pixelation should be less likely, when you turn of deinterlacing (though, you don't want that).
Edit2: You should see the pixelation also in vlc (when watching the channel on both machines in parallel)
Edit3: Play with the max cstates and try with 3 first
Edit4: Try a voltmeter on the power supply. I suspect, that we see some "savings" at the wrong parts :p

(2014-05-01, 13:36)fritsch Wrote: [ -> ]NICE!

proof accomplished - what a shame. The USB ports get flakey under high load ...

So when watching LiveTV simultaneously and using Deinterlacing, which causes high cpu load, that issue happens more often. An external powered hub does not help?

powered usb hub does not help. but your theory does not explain how it can work until feb 19 in openelec. And it also doesn't explain why it's working on some tv tuners in current nightly

Quote:Edit: Try to debug usb. Pixelation should be less likely, when you turn of deinterlacing (though, you don't want that).
Edit2: You should see the pixelation also in vlc (when watching the channel on both machines in parallel)
Edit3: Play with the max cstates and try with 3 first

1. Nope. not really. it's the same pixelation with/without deinterlacing
2. yes, pixelation is on tv and vlc
3. ?? can you explain this?




i guess yout theory is wrong, master fritsch

Nope, it's not. Whenever the nuc needs to do something else ontop of doing the recording, you get pixelation.

You can try the following: watch a channel from VLC and while watching, do that on the nuc machine:
Press ctl c from time to time and start again. Every start of that command should put out the NUC from a lower powerstate, and stopping back in. Keep watching with vlc all the time.

Can you introduce those errors, when doing so?

I think the older release had some different kernel with a different driver module for that device. Which driver is it again?

Edit: if that load is not enough, start another one on a different terminal. If you are really unlucky, you can even provoke it by just navigating through xbmc

I have a "hp server N40l" running openelec with tvheadend as backend. I dont us it to watch things i'ts only a server for my htpc: Intel nuc i3 and Rpi both of them has the same pixel issue on Gotham builds. If i back down Rpi to OE 3.2.3 i dont have the problem. Don't know if this info helps?

Not really. RPI does not use dvdplayer at all - your issue sounds like a tvheadend issue.

(2014-05-01, 13:54)fritsch Wrote: [ -> ]I think the older release had some different kernel with a different driver module for that device. Which driver is it again?

For the nanostick 290e, it's a cxd280r tuner and em28xx USB controller, but I don't think anything much changed in these modules between 3.13.3 and 3.13.5. The USB/XHCI commits seem more likely to me.

[EDIT: does anyone know a way to switch the USB ports to EHCI in the NUC bios, maybe a pre-0025 release? I cannot find an option in 0025.]

(2014-05-01, 13:54)fritsch Wrote: [ -> ]Nope, it's not. Whenever the nuc needs to do something else ontop of doing the recording, you get pixelation.

Indeed that seems to be the case. External powered USB hub does not help for this. The following works here for reproducing the issue:

1) Start recording of a channel (I took HD channel) from Tvheadend web UI
2) Start watching another HD channel using XBMC live TV functionality
-- At this point there are 0 errors even if I keep waiting for a few minutes --
3) Open the EPG on top of the live TV channel (EPG is overlaid on top of the picture)
-- At this point I start to get continuity counter errors approx once per minute AND they do happen for both the recorded channel and the live TV channel at exactly the same time. Naturally the picture gets pixelated every time there's such an error. I was watching Yle TV2 and recording Yle Fem and got the following:


4) Hide the EPG and return to full screen live TV and there are no more error and no pixelation. In general it's not too bad, but I'm still not too happy with it. Especially since I can't use 2 tuners simultanously without the xHCI host dying.

EDIT: I don't seem to get any of these errors if I choose Bob instead of Yadif for deinterlacing (not that it matters that much on a 1080i content). When I have De-interlace (yadif) chosen the CPU does not seem to go anywhere near 100% though. The codec info screen shows me CPU for 4 cores (dual core, 2 threads I guess) and at max one CPU seems to peak around 70% while mainly they hover around 10-20%.

There was also a bit suspicious "leaking memory" message in my log file which might be VAAPI related (or maybe not, it's just that earlier messages from that process are VAAPI related). That's at 15:10:31: http://sprunge.us/GLKF

Regarding my other problem with 2 tuners: Has anyone tried 2 USB tuners on the NUC simultaneously and can confirm that it works ok?

By the way, I noticed that if I plug in an USB 2.0 device on any of the ports, it gets plugged into bus 2 (when checking with lsusb). An USB 3.0 device gets plugged into bus 3. So far I haven't found any way to get the 2 tuners on different buses.

Can you check the pid 751 next time? It seems to be a running script - not vaapi related.
And also supply the xbmc.log when that happens.

Edit: Does adding: processor.max_cstate=3 to /etc/default/grub or syslinux pendant improve anything? Remember(!) to remove that line again as this stops a lot of powersaving.
Edit2: That message is a samba bug (which seo just fixes) - not related.

(2014-05-01, 13:54)fritsch Wrote: [ -> ]Nope, it's not. Whenever the nuc needs to do something else ontop of doing the recording, you get pixelation.

You can try the following: watch a channel from VLC and while watching, do that on the nuc machine:

Code:

dd if=/dev/zero of=/dev/null

Press ctl c from time to time and start again. Every start of that command should put out the NUC from a lower powerstate, and stopping back in. Keep watching with vlc all the time.

Can you introduce those errors, when doing so?

I think the older release had some different kernel with a different driver module for that device. Which driver is it again?

Edit: if that load is not enough, start another one on a different terminal. If you are really unlucky, you can even provoke it by just navigating through xbmc

ok, just had to compile the streamdev plugin on my ubuntu nuc.

I just opened 4 ssh sessions and navigated through xbmc menu. NO WAY to reproduce the pixelation in the VLC Stream with this method. But when i play your test sample from servustv, i get the pixelation in the vlc stream but in a very moderate way. Not as heavy as when watching the save channel in vlc and on the nuc itself


my tuner is a pctv 460e with dvb-fe-tda10071.fw firmware and em28xx comtroller. the controller seems to be the same in all pctv tuners. maybe this is the problem
Link to lsmod: http://pastebin.com/Q3DNZE8h

Quote:Edit: Does adding: processor.max_cstate=3 to /etc/default/grub or syslinux pendant improve anything? Remember(!) to remove that line again as this stops a lot of powersaving.

no. does not change anything. i tried max_cstate= 3,2,1,0

Anyone tried to reproduce this with vdr backend?

(2014-05-01, 15:35)-DDD- Wrote: [ -> ]Anyone tried to reproduce this with vdr backend?

Yep, happens with VDR as well when I open the EPG.

---

(2014-05-01, 14:59)Nafi Wrote: [ -> ]my tuner is a pctv 460e with dvb-fe-tda10071.fw firmware and em28xx comtroller. the controller seems to be the same in all pctv tuners. maybe this is the problem
Link to lsmod: http://pastebin.com/Q3DNZE8h

When you do get pixelation, do you see on the Status tab of the Tvheadend web UI that the errors keep growing? If you enable debugging, do you see the contivity counter errors in the syslog (or tvheadend debug log if you configured that)? I had to modify the tvheadend.start script to start tvheadend with the debug parameters I wanted...

do you run tvh or vdr on higher prio? If not can you try?

(2014-05-01, 13:36)fritsch Wrote: [ -> ]proof accomplished - what a shame. The USB ports get flakey under high load ...

But they don't get flaky under high load in every Openelec Gotham alpha up to and including 19 February, which suggests a software regression of some sort somewhere. I cannot help thinking that the best clue we have is a working Openelec and then a broken Openelec, with a limited number of commits between them. If one of the experts thinks bisection debugging is the way to go, I am happy to help build (but will need some quick instructions to get started). Would it be easy/feasible to build the current Openelec nightly but with the 3.13.3 kernel?

Okay - get me the very latest revision (hash id) that works and also the very first one, that stops working, please.

We use git for OE development, so we can easily find out what this is causing. What makes me afraid is, that it's the same problem in Ubuntu.

Additionally, I want three (in numbers 3) of you - that verify: Yes, everything is working perfectly with xy build (that you installed _today_ on the NUC) and it stopped working with za build. My DataMining based decissioner has some problems currently as of different infos I got through that thread.