"scan no data, failed" with 2 out of 3 tuners

[Yoshi]

I'm not sure if this is related to the USB 3.0 bug that is described in this bugzilla report https://bugzilla.kernel.org/show_bug.cgi?id=75521

I'm using the following setup:

• 2x MediaTV Pro III
• 1x Digital Home http://ecx.images-amazon.com/images/I/41QsVyeH1sL._SS400_.jpg
• 1x Startech USB 3.0 controller http://www.startech.com/Cards-Adapters/USB-3.0/Cards/2-Port-PCI-Express-SuperSpeed-USB-3-Card-Adapter~PEXUSB3S2
• 1x Startech USB 3.0 controller http://www.startech.com/Cards-Adapters/USB-3.0/Cards/2-port-PCI-Express-USB-3-Card~PEXUSB3S25
• Tvheadend 3.9.2656~g0d4f443
• CentOS 7
• Latest and greatest Sundtek drivers
• DVB-C on Ziggo

Because of the known USB 3.0 bug, I enter https://bugzilla.kernel.org/show_bug.cgi?id=75521#c28 this line before starting tvheadend and I do this for all three tuners.

After using tvheadend a while, the MediaTV Pro tuners stop working and tvheadend reports "scan no data, failed". The Digital Home tuner however keeps working. After a reboot of CentOS the whole setup works again for a while.

So now the question; is this behaviour to be expected, keeping the USB 3.0 bug in mind? Is there a logical explanation for the fact the Digital Home tuner keeps working?  

[Sundtek]

Hi, try to get an MCS9990 based USB 2.0 Controller if you want to use dedicated ports, each port will support up to 480 mbit

however a single USB port with 480 MBit would also be able to support 3 devices (when using a USB hub)

The drivers for those units are rock solid, only the USB 3.0 controller might be able to cause problems in that case.

[Yoshi]

I use CentOS on an esxi 5.5 server, and I've read that the MCS9990 controller isn't working properly with pass through.

The question remains, is there a logical explanation for the fact that only the MediaTV Pro III tuners are affected?

[Sundtek]

USB 2.0 devices are affected in general, there are dozens of reports of problems with USB 3.0 with various USB 2.0 streaming devices out there.
A TV tuner probably streams most data directly from the USB device (even compared with a USB Harddisk).
Also everything needs to happen within a certain latency (hickups are deadly for DVB streams).

There are some customers reporting that isochronous mode seems to work better than the default mode, you might give it a try:
/opt/bin/mediaclient --transfermode=iso -d /dev/dvb/adapter0/frontend0 (basically you need to do that for every adapter).

Regarding the pass through, USB 3.0 and USB 2.0 use the same mechanism to pass through the data to a virtual machine -- they both use USBDEVFS (just like our driver does).
That the MCS9990 does not support pass through should be a myth

Alternatively you might take the units connect it to a raspberry PI 2 and stream them via network.
http://support.sundtek.com/index.php/topic,179.0.html

[Yoshi]

Ok I'll try isochronous mode and will report back to you.

[Yoshi]

Same problem unfortunately. The Digital Home tuner is still going strong. Any other options?

I'd like to add that esxi 5.5 is very, very picky on the right USB controller. So the chance the MCS9990 works is close to zero. Especially after some research where people say this exact controller doesn't work with esxi 5.5

Still the question remains; why are the Pro tuners the only ones who have this problem? Is this something to be fixed within the driver?

[Sundtek]

Pro and Digital Home are exactly the same from datatransfer point of view.

You must be doing something else wrong if there's a difference.

You might try to pass the USB controller forward to the virtual machine directly instead of using a virtual USB controller which converts all the backend communication to USBDEVFS.
If you want to use multiple devices this is definitely a better choice (to forward the controller directly). This of course will require IOMMU support of your system (most systems should have that nowadays).

[Yoshi]

The complete controllers are forwarded to my tv server VM using PCI-passthrough, so that shouldn't be an issue...

Motherboard is Supermicro http://www.supermicro.com/products/motherboard/xeon/c202_c204/x9scm-f.cfm equipped with Intel Xeon E3-1230V2

Something else to try?

Just thinking, is there maybe a problem with two identical tuners on the same system? Maybe that messes up the driver?

[Sundtek]

The driver is tested over years with several devices, there's also no issue with it.

You are still using a USB 3.0 controller aren't you?

If you experience an issue with the tuners on it (with the USB 3.0 controller) we can only file a bugreport to the Linux Kernel Mailinglist. We've seen too many issues with USB 3.0 and various linux systems. Those controllers usually have very poor and unreliable Linux support.

USB 3.0 should have full USB 2.0 backward compatibility, however the Linux USB Controller driver still needs some work for that it seems..

Maybe your system still supports USB 2.0 (and allows some settings in the BIOS).

We have tested the Raspberry PI 2, it is able to transfer more than 20MB/sec via USB, you might try to connect the tuners to it and stream it via network into your VM (it's very easy)

/opt/bin/mediaclient --enablenetwork=on   (on the server)

/opt/bin/mediaclient --scan-network   (on the client, this will give you the IDs)
/opt/bin/mediaclient --mount IP.ADDRESS:DEVICEID     (on the client)

[Yoshi]

Yes I use two USB 3.0 controllers. One with Chipset ID Renesas / NEC - µPD720200, the other with Renesas / NEC - µPD720202

I'm trying with one Home and one Pro tuner now, let's see how that goes. Maybe filing a bug report is also an option if this turns out the same.

Thanks for your support so far!

[Yoshi]

Alright, same problem as you already thought. What info do you need to file a bug report?

[Sundtek]

https://bugzilla.kernel.org/

Maybe you can try to file the bugreport there?
(you can also link to this discussion here).

This information might be useful:

mount -t debugfs none /sys/kernel/debug
echo -n 'module xhci_hcd =p' > /sys/kernel/debug/dynamic_debug/control

and then triggering the stall.

[Yoshi]

Ok, but the log would be huge I think. There's no way to trigger the bug, it takes a few days sometimes. Would that be a problem?

[Sundtek]

Maybe you can just enable logging once the issue happens.

Once it fails it always fails until you reboot it?

Are you using the latest Linux Kernel driver with it, usb 3.0 is receiving patches regularly.