| ↑back Search ←Prev date Next date→ Show only urls | (Click on time to select a line by its url) |
| Who | What | When |
|---|---|---|
| mchehab | void09: reading backlogs
the errors you may be seen could be due to USB througput with analog TV, you can't have more than one or two devices connected via USB digital TV has a higher limit, but I suspect that 9+ channels are too much for a single USB bus yeah, my patch forces old mode, but it still calls the Kernel... it just disables the part of tvheadend that handles the stats you can't sum the traffic USB limit is basically related to the max number of packets per second. If I'm not mistaken, the limit is 980 packets per second (the devices are USB2) the number of packets actually depends on the packet size, with is hardware-dependent If you need more than a certain number of devices, you'll need to ensure that the CPU has enough bandwidth, and you'll need to have more than one different USB bus almost all CPU boards have a single USB bus shared with several channels if the machine has empty PCI slots, you could try buying a PCI to USB board with multiple different USB buses on a quick browsing at the internet, I suspect that this one has 4 separated USB buses: https://www.amazon.com/StarTech-com-Express-SuperSpeed-Dedicated-Channels/dp/B00HJZEA2S If I understood well, with the patch, you're not noticing continuity errors anymore with up to 7 tuners, right? | [00:24] |
| .... (idle for 17mn) | ||
| void09 | mchehab: using a 16 port usb3.0 hub at the moment. i just had the bandwidth in mind, i had no idea about packet/s limit
mchehab: not using your tvheadend patch now, but it made no difference i think | [00:54] |
| mchehab | what do you mean? with the patch, did you have continuity errors? | [00:55] |
| void09 | there's too many variables, kernel patch, tv head end patch, new/old signal probe thingie, probe internal
interval* | [00:55] |
| mchehab | with my patch, new/old probe will behave exactly the same | [00:56] |
| void09 | yeah, the pastebin link i posted was with the tvh patch enabled.
and about the same behaviour with it not enabled | [00:56] |
| mchehab | yeah, but with too many tuners | [00:56] |
| void09 | yeah, since there were no errors with 1-2 tuners (as expected with the old probe mode), i tried more tuners
also as I said, i might have 2 devices that are a bit different from the rest | [00:57] |
| mchehab | ok, so one variable was isolated: the Kernel is OK | [00:58] |
| void09 | I tried for an hour to figure out which ones are they, but failed. | [00:58] |
| mchehab | it is tvheadend's logic that handles status that is broken somewhere | [00:58] |
| void09 | mchehab: how did you conclude the kernel is ok? | [00:59] |
| mchehab | well, my patch does 2 things:
1) it calls the Kernel's code that reads the stats 2) it disables the part of the tvheadend that handles the new API (v5.10 or upper) so, basically, calling the Kernel for v5.10 API or not makes no difference... but disabling the part of tvheadend with handles the status makes | [00:59] |
| void09 | well, we already knew that before, no?
nvm, it's a bit too complicated for me all I know is, I didn't see any changed behaviour, with or without patch | [01:01] |
| mchehab | we didn't know... the past tests showed that enabling the "new mode" at tvheadend caused trobules
we know now that the problems are at tvheadend code, not at the Kernel code | [01:04] |
| void09 | yes.. and your patch forces "old mode", which we already knew it worked? | [01:04] |
| mchehab | no, it forces new mode at the Kernel side | [01:05] |
| void09 | ohhhh | [01:05] |
| mchehab | This is the call for the Kernel's new mode
ioctl(lfe->lfe_fe_fd, FE_GET_PROPERTY, &dtv_prop); | [01:05] |
| void09 | alright
i will try to test an usb controller asap, to see if there lies the problem with 7+ tuners | [01:06] |
| mchehab | well, remove the Kernel patch...
with that many printks, it might be interfering at bandwidth bbl | [01:07] |
| void09 | ok, reinstalled kernel, original module in place, rebooting and testing again | [01:10] |
| nope, not having the kernel patch does not improve anything | [01:22] | |
| ................ (idle for 1h19mn) | ||
| mchehab | ok | [02:41] |
| ................................................................................................................... (idle for 9h30mn) | ||
| void09: could you try this patch for tvheadend? https://pastebin.com/6QxXKcpx
it simplifies the logic with collect stats with the new API just use the standard polling time and the new API | [12:11] | |
| ........... (idle for 51mn) | ||
| void09 | omg how did you come up with that. never having used tvheadend | [13:03] |
| mchehab | it took a while to understand the tvheadend code, but that part is not that complex
what I'm not sure is if are there any part of tvheadend that would use the stats to re-tune I was unable to find such code (despiste the field description that implies that such code exists)... but if are there any code that would, for example, try to re-tune if BER is higher than a certain value, this should be removed, as it would just cause more discontinuity without any real benefit btw, the patch was applied against the upstream version of tvheadend at the git tree I ended by creating an account for me at the tvheadend BZ and posted a comment with the patch there at bug #5625 | [13:10] |
| void09 | yeah, i only used git/head so far. will try soon. | [13:20] |
| mchehab | also, to be fair, I once installed tvheadend on a RPi in order to understand a bug that appeared on Kernel 4.9. That's the first time I looked at tvheadend's code, though | [13:20] |
| void09 | oh btw about the usb bottleneck issue, do you think it would help if i split some of them between usb2 and 3 on the motherboard?
would usb2 vs 3 ports use different.. buses? | [13:22] |
| .... (idle for 15mn) | ||
| mchehab | maybe
lsusb helps to identify that it should show you what bus each device is connected try to distribute them along the existing buses please notice that some buses are internal If you do something like: $ lsusb|grep -v Linux|sort you'll see what device is connected to each bus and with this: $ lsusb|grep Linux|sort you'll see the bus hubs | [13:37] |
| void09 | 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 Bus 004 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub | [13:41] |
| mchehab | so, the MB has 4 buses
plugging a device to the different USB ports will allow you to identify what bus is associated to each port | [13:43] |
| void09 | these are only the internal ones, right? the tuners are all in a 16port/4hub external hub | [13:44] |
| mchehab | they'll appear there, all at the same bus
$ lsusb|grep -v Linux|sort (-v will make it exclude the hub) if you see things like: Bus 001 Device 004: ID 8087:0a2b Intel Corp. or Bus 003 Device 002: ID 2109:2812 VIA Labs, Inc. VL812 Hub Bus 003 Device 003: ID 2109:2812 VIA Labs, Inc. VL812 Hub those are internal devices | [13:44] |
| void09 | i removed 4 tuners out of the total of 12, now I got 8 hanftek devices when doing lsusb, but still getting 10 "Bus 004 Device 006: ID 0bda:0411 Realtek Semiconductor Corp. "
10 realteks. does that mean the realtek entries are not related to the tv tuners ? should have been at most 8 if i removed 4 tuners | [13:45] |
| mchehab | (in this case, the VL812 is the hub on my USB-3 7-port hub
well, a physical device may expose more than one virtual device | [13:46] |
| void09 | 8 tuners, 10 device.s. does not add up. 6x1+2x2.. actually it does
but then i should have vad 14 realteks total when all were plugged in have had* | [13:48] |
| mchehab | when devices are disconnected, they should disappear from the list (except on Kernel bugs) | [13:50] |
| void09 | i also rebooted | [13:50] |
| mchehab | ah, if, for whatever reason, the Kernel is not able to an USB device, it won't show up
not able to -> not able to talk with | [13:51] |
| void09 | https://pastebin.com/2PVhYQuZ
this is the current list, with 8 tuners connected | [13:55] |
| mchehab | This is what matters:
drivers/media/usb/dvb-usb-v2/rtl28xxu.c: { DVB_USB_DEVICE(USB_VID_HANFTEK, 0x0131, | [13:58] |
| void09 | 0bda:0411 Realtek Semiconductor Corp. - but what are these then? | [13:59] |
| mchehab | perhaps some USB hub that it is internal to the device
https://linux-hardware.org/index.php?id=usb:0bda-0411 I *suspect* that those devices are part of your USB 3.0 hub | [13:59] |
| void09 | yep. this is lsusb with nothing connected:
Bus 003 Device 002: ID 8087:8001 Intel Corp. Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 001 Device 002: ID 8087:8009 Intel Corp. Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub yep, those 10 realteks are "hubs". not sure why 10 though | [14:07] |
| ....... (idle for 34mn) | ||
| ok, tested with some tuners plugged directly in the motherboard, which are different buses (usb2). you were right.. i could tune 8 without errors now
https://imgur.com/a/M3xFeVd :) | [14:42] | |
| *** | ChanServ sets mode: +o mchehab` | [14:55] |
| void09 | so max 6 tuners per usb bus.. interesting
but maybe not all buses are the same, maybe a more modern mobo could have handled it better this is haswell generation, 2012 I think | [15:00] |
| I wonder if this is the reason I only got 250MB/s from a raid array on USB | [15:06] | |
| ............. (idle for 1h3mn) | ||
| mchehab: tried your last patch now.. getting this when patching https://pastebin.com/5T3eNxve | [16:09] | |
| mchehab | nice setup | [16:11] |
| as I said, the limit is the number of packets per second
the USB bus has a limited number | [16:23] | |
| void09 | yep, glad that is behind. can tune 11/12 tuners now, out of ports. will add a front panel usb bracket, and i think i can get to 12 without buying another hub or usb card
can you take a look at that patch ? | [16:28] |
| mchehab | weird... perhaps you have some patches applied to the top of the git tree
or you're using a different branch ah... my patch was already applied upstream at tvheadend commit c8794d3aeaff7e99b30aa368e10dbea0f4a227c1 Author: Jaroslav Kysela <perex@perex.cz> Date: Sun Oct 6 16:53:55 2019 +0200 linuxdvb: do not mix DVBv3/v5 stats, it causes trouble to drivers, fixes #5625 so, if you re-build against latest tvheadend upstream changeset, you should have it applied already | [16:30] |
| ............................... (idle for 2h31mn) | ||
| void09 | what :o so soon?
they merged your patch the same day ? | [19:04] |
| mchehab | it seem so
it seems so :-) | [19:05] |
| void09 | that was a lot of code to check if it's proper ;o | [19:15] |
| ............ (idle for 58mn) | ||
| mchehab: compiled latest commit.. set tuner to new mode, 1000ms probe (default). tuned to a channel and..55 errors in 10 minutes
yep, just like before. not fixed :( | [20:13] | |
| mchehab | stats are working fine? | [20:17] |
| void09 | yeah, the new stats. old stats are still broken (0-1% signal bar) | [20:18] |
| mchehab | old stats are broken by design...
that's why they were replaced by new stats logic the major problem is that there's no defined scale for measurements | [20:20] |
| void09 | 2019-10-06 23:19:36.361 tbl-eit: eit: 434MHz in Digi: invalid checksum (len 527, errors 4)
2019-10-06 23:19:36.361 tbl-pass: pass-eit: -: invalid checksum (len 527, errors 4) also getting these.. nothing in dmesg | [20:21] |
| mchehab | each driver reports using its own way, and, as there's no scale, they're all right | [20:21] |
| void09 | but aren't they opensource drivers?
why didn't the driver devs meet and establish a standard | [20:22] |
| mchehab | because there was no standard for scale... each developer did its own way
the fix was to redesign the API and add scale info and migrate drivers to it deprecating the old broken API btw, you said you got 55 errors on 10 mins - e. g. one error per ~10.9 seconds... sounds a little beter than before as you said you got one error on every 8 seconds beter -> better | [20:23] |
| void09 | 2019-10-06 23:24:52.303 linuxdvb: Unable to provide BER value.
2019-10-06 23:24:52.303 linuxdvb: Unable to provide SNR value. 2019-10-06 23:24:52.303 linuxdvb: Unable to provide UNC value. also just saw these in tvh log | [20:28] |
| mchehab | with old or new API? | [20:28] |
| void09 | oh wait, some tuners are stuck on the old setting still
probably the old one, yeah, forgot. did not restart as there's an important recording going on | [20:29] |
| mchehab | with old API, that's right: you won't get those stats, as this driver doesn't provide them
as it doesn't implement the old API at all | [20:30] |
| void09 | well i am grateful we have a driver at least, and working, even with soem workaround | [20:30] |
| mchehab | well, let's try to get rid of the workarounds
I strongly suspecting that somethere tvheadend is checking the stats and doing something based on them, but I was unable to find where | [20:30] |
| void09 | cable guys coming tomorrow to replace cable, now it's 2 cables stiched | [20:31] |
| mchehab | I - I'm | [20:31] |
| void09 | and if that does not get rid of errors completely, i will tinfoil the tuners
I think the weak link is that amplifier though. Couldn't find anyting between $25, the price i payed for it, and hundreds of euros, for professional ones | [20:32] |
| mchehab | yeah, blinding them will help... just be sure to give some space for them to do heat dissipation
ah, when you finish recording the event, could you please try tvheadend with just one tuner, new API mode? | [20:33] |
| void09 | one tuner connected physically ,or just one tuner enabled, or just one tuner tuned? | [20:37] |
| mchehab | maybe the problems you're facing are due to a high latency, because of the number of tuners you're using | [20:37] |
| void09 | nah, i could tune 11 of them at once, after i distributed them more evenly on the usb buses, with almost no errors
when i am finished with this, iwant to make a video wall with 100 stations at once :D | [20:37] |
| mchehab | with such number of tuners, I would apply a patch like this: https://pastebin.com/TRmKiSYa
what happens is that, if tvheadend doesn't receive any data from a tuner after some time, it re-tunes it the timeout is currently hardcoded hmm... funny... tvheadend doesn't call DMX_SET_BUFFER_SIZE it is using the default Kernel buffer size with may or may not work properly on libdvbv5, we set it to ioctl(dmxfd, DMX_SET_BUFFER_SIZE, 4096 * 8 * 188); that could be a good reason why you're having discontinuity issues ideally, tvheadend should have a default, but allow changing it via a parameter | [20:39] |
| void09 | willing to test anything you propose | [20:47] |
| mchehab | https://pastebin.com/1fqftuRx
ops let me try compiling it first there's one small error there | [20:51] |
| void09 | and about the error rate improvement you mentioned, it's not an exact science. have 32 errors now in 2 minutes | [20:52] |
| mchehab | https://pastebin.com/8TzBSDyC | [20:54] |
| void09 | and would a retune be so "light" on the signal ? i mean the sound hardly ever gets interrupted, i just get a slight pause and frame glitch
on the stream i mean | [20:54] |
| mchehab | well, trying to tune the same channel probably will just reset the stream, discarding existing buffers
(that depends at the chipset) I don't have cxd2841er specs, so, I dunno for sure what it will do I wouldn't expect it losing mrore than a few frames | [20:55] |
| void09 | oh ok, makes sense | [20:56] |
| mchehab | yet, it would print a warning at the logs | [20:56] |
| void09 | ok, will try to compile the patch now, seems teh important recording was a bad epg entry | [20:56] |
| mchehab | tvhwarn(LS_LINUXDVB, "%s - poll TIMEOUT", name);
btw, IMHO, there's a problem with the polling logic there... it starts waiting just 600ms for the stream to start... some frontends may take up to 2 seconds to start returning buffers to userspace | [20:56] |
| void09 | hm maybe that's why I sometimes get errors right when starting a stream ?
2-3 error counts and then no errors after that | [20:58] |
| mchehab | cold be | [21:08] |
| void09 | compiled the patch and installed.. do you think only the tvheadend binary would be affected by your last patch ?
i removed it before installing the package, just to make sure as I am not too familiar with how pacman works when reinstalling packages | [21:11] |
| mchehab | I've no idea... don't usually use pacman here | [21:14] |
| void09 | ok, running the latest patch (i think). same behaviour
only thing i get in dmesg is this : https://pastebin.com/vcw6VU5s but i got these before too | [21:15] |
| majortom_ | with arch/aur, if you update a previously compiled package source, and remove the previous pkg.xz, if you run makepkg -e it will leave source as is, only compiling what was just changes in the source, watching what compiles usually is a good clue.. | [21:18] |
| void09 | majortom_: i removed all the source first, before building it
I was just wondering what happens when i do pacman -U package.xz | [21:19] |
| majortom_ | yeah, it will reinstall everything in the package over the existing files..
open the .xz with an archive manager and you'll see all of the files / paths in there... I like to use makepkg -e, that way I I can edit the src and don't have to wait forever to recompile something again to test... probly not so bad for tvheadend, but compile the entire kernel a few times and that will save you tons of time testing changes... | [21:20] |
| void09 | oh, i didn't realise it can be used in this way
Do not extract source files (use existing $srcdir/ dir) | [21:23] |
| majortom_ | exactly... | [21:24] |
| void09 | yes but how does it know what files changed vs what was compiled? | [21:24] |
| majortom_ | same as any other gcc development environment
just give it a whirl sometime and u'll see how much time it can save just testing, etc.. some packages you might need to use pacman --force -U package.xz the first time to force it to override the pacman db i think though... to install a test kernel pakcage over the one supported in pacman for instance... after doing tha tthe first time, I can install any further changes with just pacman -U packxage.xz i forget what the error message was if I didn't --force... one of thois edo it once and forget about things. | [21:24] |
| void09 | right, good to know, thanks
mchehab: so what now ? it's not fixed. sigh set the time to 8s and there are much less errors, but not eliminated. | [21:30] |
| .............. (idle for 1h5mn) | ||
| mchehab | I'll try to take a look on it tomorrow | [22:36] |
| void09 | maybe just send some pointers to the tvheadend guys , after all, it's not your domain | [22:41] |
| ↑back Search ←Prev date Next date→ Show only urls | (Click on time to select a line by its url) |