(2014-05-01, 17:02)fritsch Wrote: [ -> ]My DataMining based decissioner has some problems currently as of different infos I got through that thread.
Agreed! I have been getting the archived nightlies from here
xbmcnightlybuilds.com/category/openelec-generic/page/15/
and for me r17733-g6d3f2f3 (6d3f2f3d8d05832de9e6139feec6f810f4a896f6) works and r17811-gc4d1004 (c4d10046521e5387a308a59cecdc29108548fab3) does not work. I installed and tested both of these yesterday evening on the NUC. There's one build between those two that must have failed (only 27M). If anyone has any intermediate nightlies I would be happy to test.
Thanks much! Will forward to Seo and FernetMenta. Let's see.
(2014-05-01, 16:40)FernetMenta Wrote: [ -> ]do you run tvh or vdr on higher prio? If not can you try?
i just tested to renice vdr with -20.
This at least seems to affect the pixelation. There are much less artifacts in livetv, though it's still not perfect [atleast on ubuntu]
Quote:and for me r17733-g6d3f2f3 (6d3f2f3d8d05832de9e6139feec6f810f4a896f6) works and r17811-gc4d1004 (c4d10046521e5387a308a59cecdc29108548fab3) does not work. I installed and tested both of these yesterday evening on the NUC. There's one build between those two that must have failed (only 27M). If anyone has any intermediate nightlies I would be happy to test.
I'll copy back my openelec image soon and will test this aswell
make sure you are using the LATEST vdr-addon (4.1.6 atm)
make sure you disable usb3 in bios. this often causes troubles..
try booting with "usbcore.autosuspend=-1" (hint: /flash/extlinux.conf). this is unrelated but sometimes helps.
Quote:r17733-g6d3f2f3 (Commit:6d3f2f3) works and r17811-gc4d1004 (Commit:c4d1004) does not work
i can agree with this.
Quote:make sure you are using the LATEST vdr-addon (4.1.6 atm)
yes it is
Quote:make sure you disable usb3 in bios. this often causes troubles..
this is not possible on the NUC. But i installed an internal USB 2.0 Header adaptor for the tv tuner
Quote:try booting with "usbcore.autosuspend=-1" (hint: /flash/extlinux.conf). this is unrelated but sometimes helps.
thanks. i added this. But does not help.
(2014-05-01, 17:02)fritsch Wrote: [ -> ]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.
Yes, sir!
Will do that as soon as the wife is finished with her watching...
(2014-05-01, 17:11)ahgee2 Wrote: [ -> ]and for me r17733-g6d3f2f3 (6d3f2f3d8d05832de9e6139feec6f810f4a896f6) works and r17811-gc4d1004 (c4d10046521e5387a308a59cecdc29108548fab3) does not work.
Are the binary packages available somewhere, or is the only option to compile the whole OE distro? Did not see them under snapshots.openelec.tv anymore.
EDIT: Nevermind, Googled it.
(2014-05-01, 18:07)Nafi Wrote: [ -> ]this is not possible on the NUC. But i installed an internal USB 2.0 Header adaptor for the tv tuner
nafi, are you saying that you still get pixelation with the tuner on the NUC's USB2.0 bus? I was thinking of trying precisely this as a workaround, but if you are saying it doesn't work then you have spared me the effort of drilling a hole in my case and poking a header adaptor through!
yes. pixelation also with USB 2.0 port.
When you do an lsusb on the NUC it shows that you have 3 USB hubs:
Code:
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
However, no matter which port you will connect an USB 2.0 device (internal or external as confirmed by Nafi), it gets connected to bus 2. If you connect an USB 3.0 device in any of the front or rear ports of a Haswell NUC it get connected to bus 3.
As far as I have understood, all devices in bus 2 share the bandwidth of 480Mbit/s. That should not be a problem though, as any tuner should use approximately max 50 Mbit/s, in real life most likely less. However, when I saw the problem with 2 tuners that I have, I thought I could try to connect the other one to another bus. However, that just does not seem to be possible.
According to a post I saw at the Intel communities, it seems that the bus 1 is reserved for the PCIe devices (whatever that means).
I also tested 2 tuners in Windows 8 on the NUC. It seemed to work ok without crashing, though I couldn't tune the HD channels for some reason.
Let's fix the problem with exactly _one_ tuner first. I personally think, that this is a kernel regression (to be more exact: A side effect, a change that produces some race). So it's worth looking for changes to the USB subsystem and to the relevant driver. Therefore I'd need a kernel dmesg with the working version and with the non working version with the debugging options for both USB and the driver turned on.
I still don't get the point, that Ubuntu Users with "old kernel" - the one matching this old OE release keep having that problem, that fact makes me quite clueless. So let's gather the kernel debug logs first.
Edit: Those are module parameters for the em28xx module, all of them are worth a try.
Quote:parm: card:card type (array of int)
parm: usb_xfer_mode:USB transfer mode for frame data (-1 = auto, 0 = prefer isoc, 1 = prefer bulk) (int) <- looks interesting (try those also, plese)
parm: i2c_debug:i2c debug message level (1: normal debug, 2: show I2C transfers) (int) <- increase those
parm: core_debug:enable debug messages [core] (int) <- that one
parm: reg_debug:enable debug messages [URB reg] (int) <- that one
(2014-05-02, 09:39)fritsch Wrote: [ -> ]I personally think, that this is a kernel regression (to be more exact: A side effect, a change that produces some race). So it's worth looking for changes to the USB subsystem and to the relevant driver. Therefore I'd need a kernel dmesg with the working version and with the non working version with the debugging options for both USB and the driver turned on.
Thanks fritsch, I'll try these em28xx parameters when I get home this evening. Is it just the em28xx debugging you want enabled? I assume I do this from a .conf file under storage/.config/modprobe.d? For the "non-working" OE would you prefer the latest beta or the first one that broke (r17811)?
By the way, you will find more similar reports over on the Openelec thread
http://openelec.tv/news/22-releases/122-...7-released
where zag reports that OpenELEC-Generic.x86_64-devel-20140221232415-r17780-ge46e3ad was the last one to work. This is more recent than r17733 and uses kernel 3.13.4. I cannot find this build anywhere but it narrows the search and strongly suggests 3.13.4 -> 3.13.5 as the trigger, which makes sense given all the USB/XHCI changes reported here
https://www.kernel.org/pub/linux/kernel/...Log-3.13.5
Another thing I am happy to do is temporarily open port 22 on my router and forward it to the Openelec box, so you can experiment with it remotely. Would this be helpful?
(2014-05-01, 20:21)trsqr Wrote: [ -> ]According to a post I saw at the Intel communities, it seems that the bus 1 is reserved for the PCIe devices (whatever that means).
I believe that the Mini PCI-E spec includes USB connections to allow Mini PCI-E cards to either connect to a standard PCI-E bus, or to connect via USB instead. I believe the latter is sometimes used for 3G Cellular cards, and some WiFi cards?
So presumably if you used a Mini PCI-E DVB tuner card that connected using USB, it would connect to a different bus to the USB 3.0 sockets and the internal USB 2.0 header that appear to share the same bus?
(2014-05-02, 10:34)ahgee2 Wrote: [ -> ] (2014-05-02, 09:39)fritsch Wrote: [ -> ]I personally think, that this is a kernel regression (to be more exact: A side effect, a change that produces some race). So it's worth looking for changes to the USB subsystem and to the relevant driver. Therefore I'd need a kernel dmesg with the working version and with the non working version with the debugging options for both USB and the driver turned on.
Thanks fritsch, I'll try these em28xx parameters when I get home this evening. Is it just the em28xx debugging you want enabled? I assume I do this from a .conf file under storage/.config/modprobe.d? For the "non-working" OE would you prefer the latest beta or the first one that broke (r17811)?
By the way, you will find more similar reports over on the Openelec thread
http://openelec.tv/news/22-releases/122-...7-released
where zag reports that OpenELEC-Generic.x86_64-devel-20140221232415-r17780-ge46e3ad was the last one to work. This is more recent than r17733 and uses kernel 3.13.4. I cannot find this build anywhere but it narrows the search and strongly suggests 3.13.4 -> 3.13.5 as the trigger, which makes sense given all the USB/XHCI changes reported here
https://www.kernel.org/pub/linux/kernel/...Log-3.13.5
Another thing I am happy to do is temporarily open port 22 on my router and forward it to the Openelec box, so you can experiment with it remotely. Would this be helpful?
In fact it's quite hard to debug this on OpenELEC. As every step needs a recompile. If someone could do that on Ubuntu, e.g. find a working kernel (ubuntu mainline) and find the first non working one - this would be a lot easier. But yes, try with some of those parameters. 3 of them are only for logging anyway, I think that the bulk mode could do something useful.