* Re: dvb usb issues since kernel 4.9 [not found] ` <trinity-1fa14556-8596-44b1-95cb-b8919d94d2d4-1515251056328@3c-app-gmx-bs15> @ 2018-01-06 19:54 ` Mauro Carvalho Chehab 2018-01-06 21:07 ` Aw: " Josef Griebichler ` (2 more replies) 0 siblings, 3 replies; 47+ messages in thread From: Mauro Carvalho Chehab @ 2018-01-06 19:54 UTC (permalink / raw) To: Josef Griebichler, Greg Kroah-Hartman, Alan Stern, linux-usb Cc: Eric Dumazet, Rik van Riel, Paolo Abeni, Hannes Frederic Sowa, Jesper Dangaard Brouer, linux-kernel, netdev, Jonathan Corbet, LMML, Peter Zijlstra, David Miller, torvalds Hi Josef, Em Sat, 6 Jan 2018 16:04:16 +0100 "Josef Griebichler" <griebichler.josef@gmx.at> escreveu: > Hi, > > the causing commit has been identified. > After reverting commit https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=4cd13c21b207e80ddb1144c576500098f2d5f882 > its working again. Just replying to me won't magically fix this. The ones that were involved on this patch should also be c/c, plus USB people. Just added them. > Please have a look into the thread https://forum.libreelec.tv/thread/4235-dvb-issue-since-le-switched-to-kernel-4-9-x/?pageNo=13 > here are several users aknowledging the revert solves their issues with usb dvb cards. I read the entire (long) thread there. In order to make easier for the others, from what I understand, the problem happens on both x86 and arm, although almost all comments there are mentioning tests with raspbian Kernel (with uses a different USB host driver than the upstream one). It happens when watching digital TV DVB-C channels, with usually means a sustained bit rate of 11 MBps to 54 MBps. The reports mention the dvbsky, with uses USB URB bulk transfers. On every several minutes (5 to 10 mins), the stream suffer "glitches" caused by frame losses. The part of the thread that contains the bisect is at: https://forum.libreelec.tv/thread/4235-dvb-issue-since-le-switched-to-kernel-4-9-x/?postID=75965#post75965 It indirectly mentions another comment on the thread with points to: https://github.com/raspberrypi/linux/issues/2134 There, it says that this fix part of the issues: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=34f41c0316ed52b0b44542491d89278efdaa70e4 but it affects URB packet losses on a lesser extend. The main issue is really the logic changes a the core softirq logic. Using Kernel 4.14.10 on a Raspberry Pi 3 with 4cd13c2 commit reverted fixed the issue. Joseph, is the above right? Anything else to mention? Does the same issue affect also on x86 with vanilla Kernel 4.14.10? - It seems that the original patch were designed to solve some IRQ issues with network cards with causes data losses on high traffic. However, it is also causing bad effects on sustained high bandwidth demands required by DVB cards, at least on some USB host drivers. Alan/Greg/Eric/David: Any ideas about how to fix it without causing regressions to network? Regards, Mauro > Gesendet: Sonntag, 17. Dezember 2017 um 14:27 Uhr > Von: "Mauro Carvalho Chehab" <mchehab@s-opensource.com> > An: "Sean Young" <sean@mess.org> > Cc: "Josef Griebichler" <griebichler.josef@gmx.at>, lcaumont2@gmail.com, gregkh@linuxfoundation.org, linux-media@vger.kernel.org, linux-usb@vger.kernel.org > Betreff: Re: dvb usb issues since kernel 4.9 > Em Sun, 17 Dec 2017 12:06:37 +0000 > Sean Young <sean@mess.org> escreveu: > > > Hi Josef, > > Em Sun, 17 Dec 2017 11:19:38 +0100 > "Josef Griebichler" <griebichler.josef@gmx.at> escreveu: > > > > Hello Mr. Caumont, > > > > > > since switch to kernel 4.9 there are several users which have issues with their usb dvb cards. > > > Some get artifacts when watching livetv, I'm getting discontinuity errors in tvheadend when recording. > > > I'm using latest test build of LibreElec with kernel 4.14.6 but the issues are still there. > > > There's an librelec forum thread for this topic > > > https://forum.libreelec.tv/thread/4235-dvb-issue-since-le-switched-to-kernel-4-9-x/ > > > and also an open kernel bug > > > https://bugzilla.kernel.org/show_bug.cgi?id=197835[https://bugzilla.kernel.org/show_bug.cgi?id=197835] > > > > > > This is my dmesg http://sprunge.us/WRIE[http://sprunge.us/WRIE] > > > and tvh service log http://sprunge.us/bEiE[http://sprunge.us/bEiE] > > > > > > I saw in kernel changelog that you made an improvement/change for dvb und usb (commit 9a11204d2b26324636ff54f8d28095ed5dd17e91) > > > > > > Is there anything that can be done to improve our situation or are we forced to stay with kernel 4.8? > > > > > > Thanks for support! > > > > > > Josef > > > > Between kernel v4.8 and v4.9 there are many changes, and it is unlikely that > > commit 9a11204d2b26324636ff54f8d28095ed5dd17e91 is responsible for this. > > Let me add linux-media@vger.kernel.org and linux-usb@vger.kernel.org ML. > > Josef, Please be sure that your e-mailer won't be sending e-mails with > HTML tags on it, otherwise the ML server will automatically drop. > > > What would be really helpful is if you could find out which commit did > > cause a regression. This can be done by bisecting the kernel. There are > > various guides to this: > > > > https://wiki.ubuntu.com/Kernel/KernelBisection[https://wiki.ubuntu.com/Kernel/KernelBisection] > > or > > https://wiki.archlinux.org/index.php/Bisecting_bugs[https://wiki.archlinux.org/index.php/Bisecting_bugs] > > > > Once the commit has been identified we can work together to narrow it down > > to the exact change, and then work together on a fix. > > Yeah, we need more data in order to start tracking it. I suspect, > however, that a simple git bisect may not work in this case, due to the > USB changes that forbids DMA on stack that was added to Kernel 4.9, if > the card Josef is using was affected by such change. > > Probably, he'll need to disable CONFIG_VMAP_STACK in the middle > of bisect (e. g. when the patch that implements it is added), > or to cherry-pick any needed DMA fixup patch on the top of Kernel > 4.8 before starting bisect. > > It is also worth mentioning what's the USB host controller that > are used, and what's the media driver, as this could be an issue > there. > > That's said, from the bug report, it seems that this is > happening on RPi3. Could you please test it also on a PC? That > will help to identify if the bug is at RPi's host driver or > on media drivers. > > With regards to RPi3, there are actually two different drivers > for it: one used on Raspbian Kernel, and another one upstream. > They're completely different ones. > > What driver are you using? > > Thanks, > Mauro Thanks, Mauro ^ permalink raw reply [flat|nested] 47+ messages in thread
* Aw: Re: dvb usb issues since kernel 4.9 2018-01-06 19:54 ` dvb usb issues since kernel 4.9 Mauro Carvalho Chehab @ 2018-01-06 21:07 ` Josef Griebichler 2018-01-06 21:44 ` Alan Stern 2018-01-07 21:23 ` Linus Torvalds 2 siblings, 0 replies; 47+ messages in thread From: Josef Griebichler @ 2018-01-06 21:07 UTC (permalink / raw) To: Mauro Carvalho Chehab Cc: Greg Kroah-Hartman, Alan Stern, linux-usb, Eric Dumazet, Rik van Riel, Paolo Abeni, Hannes Frederic Sowa, Jesper Dangaard Brouer, linux-kernel, netdev, Jonathan Corbet, LMML, Peter Zijlstra, David Miller, torvalds Hi, thanks for adding the people involved! Yes arm and x86 are affected. Bisecting was not done by me on a x86_64 machine on mainline kernel and not raspbian kernel (https://forum.libreelec.tv/thread/4235-dvb-issue-since-le-switched-to-kernel-4-9-x/?postID=75965#post75965). In the mentioned post you also find the bisect log. I'm using a dvb-s/s2 usb tv card (technotrend s2-4600 with firmware dvb-fe-ds3103.fw, components M88DS3103, M88TS2022), so not only dvb-c is affected. Yes kernel 4.14.10 with revert of the mentioned commit works as before on kernel 4.8 with rpi3. I hope this is of some help. Regards, Josef Hi Josef, Em Sat, 6 Jan 2018 16:04:16 +0100 "Josef Griebichler" <griebichler.josef@gmx.at> escreveu: > Hi, > > the causing commit has been identified. > After reverting commit https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=4cd13c21b207e80ddb1144c576500098f2d5f882 > its working again. Just replying to me won't magically fix this. The ones that were involved on this patch should also be c/c, plus USB people. Just added them. > Please have a look into the thread https://forum.libreelec.tv/thread/4235-dvb-issue-since-le-switched-to-kernel-4-9-x/?pageNo=13[https://forum.libreelec.tv/thread/4235-dvb-issue-since-le-switched-to-kernel-4-9-x/?pageNo=13] > here are several users aknowledging the revert solves their issues with usb dvb cards. I read the entire (long) thread there. In order to make easier for the others, from what I understand, the problem happens on both x86 and arm, although almost all comments there are mentioning tests with raspbian Kernel (with uses a different USB host driver than the upstream one). It happens when watching digital TV DVB-C channels, with usually means a sustained bit rate of 11 MBps to 54 MBps. The reports mention the dvbsky, with uses USB URB bulk transfers. On every several minutes (5 to 10 mins), the stream suffer "glitches" caused by frame losses. The part of the thread that contains the bisect is at: https://forum.libreelec.tv/thread/4235-dvb-issue-since-le-switched-to-kernel-4-9-x/?postID=75965#post75965[https://forum.libreelec.tv/thread/4235-dvb-issue-since-le-switched-to-kernel-4-9-x/?postID=75965#post75965] It indirectly mentions another comment on the thread with points to: https://github.com/raspberrypi/linux/issues/2134[https://github.com/raspberrypi/linux/issues/2134] There, it says that this fix part of the issues: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=34f41c0316ed52b0b44542491d89278efdaa70e4[https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=34f41c0316ed52b0b44542491d89278efdaa70e4] but it affects URB packet losses on a lesser extend. The main issue is really the logic changes a the core softirq logic. Using Kernel 4.14.10 on a Raspberry Pi 3 with 4cd13c2 commit reverted fixed the issue. Joseph, is the above right? Anything else to mention? Does the same issue affect also on x86 with vanilla Kernel 4.14.10? - It seems that the original patch were designed to solve some IRQ issues with network cards with causes data losses on high traffic. However, it is also causing bad effects on sustained high bandwidth demands required by DVB cards, at least on some USB host drivers. Alan/Greg/Eric/David: Any ideas about how to fix it without causing regressions to network? Regards, Mauro > Gesendet: Sonntag, 17. Dezember 2017 um 14:27 Uhr > Von: "Mauro Carvalho Chehab" <mchehab@s-opensource.com> > An: "Sean Young" <sean@mess.org> > Cc: "Josef Griebichler" <griebichler.josef@gmx.at>, lcaumont2@gmail.com, gregkh@linuxfoundation.org, linux-media@vger.kernel.org, linux-usb@vger.kernel.org > Betreff: Re: dvb usb issues since kernel 4.9 > Em Sun, 17 Dec 2017 12:06:37 +0000 > Sean Young <sean@mess.org> escreveu: > > > Hi Josef, > > Em Sun, 17 Dec 2017 11:19:38 +0100 > "Josef Griebichler" <griebichler.josef@gmx.at> escreveu: > > > > Hello Mr. Caumont, > > > > > > since switch to kernel 4.9 there are several users which have issues with their usb dvb cards. > > > Some get artifacts when watching livetv, I'm getting discontinuity errors in tvheadend when recording. > > > I'm using latest test build of LibreElec with kernel 4.14.6 but the issues are still there. > > > There's an librelec forum thread for this topic > > > https://forum.libreelec.tv/thread/4235-dvb-issue-since-le-switched-to-kernel-4-9-x/[https://forum.libreelec.tv/thread/4235-dvb-issue-since-le-switched-to-kernel-4-9-x/] > > > and also an open kernel bug > > > https://bugzilla.kernel.org/show_bug.cgi?id=197835[https://bugzilla.kernel.org/show_bug.cgi?id=197835][https://bugzilla.kernel.org/show_bug.cgi?id=197835[https://bugzilla.kernel.org/show_bug.cgi?id=197835]] > > > > > > This is my dmesg http://sprunge.us/WRIE[http://sprunge.us/WRIE][http://sprunge.us/WRIE[http://sprunge.us/WRIE]] > > > and tvh service log http://sprunge.us/bEiE[http://sprunge.us/bEiE][http://sprunge.us/bEiE[http://sprunge.us/bEiE]] > > > > > > I saw in kernel changelog that you made an improvement/change for dvb und usb (commit 9a11204d2b26324636ff54f8d28095ed5dd17e91) > > > > > > Is there anything that can be done to improve our situation or are we forced to stay with kernel 4.8? > > > > > > Thanks for support! > > > > > > Josef > > > > Between kernel v4.8 and v4.9 there are many changes, and it is unlikely that > > commit 9a11204d2b26324636ff54f8d28095ed5dd17e91 is responsible for this. > > Let me add linux-media@vger.kernel.org and linux-usb@vger.kernel.org ML. > > Josef, Please be sure that your e-mailer won't be sending e-mails with > HTML tags on it, otherwise the ML server will automatically drop. > > > What would be really helpful is if you could find out which commit did > > cause a regression. This can be done by bisecting the kernel. There are > > various guides to this: > > > > https://wiki.ubuntu.com/Kernel/KernelBisection[https://wiki.ubuntu.com/Kernel/KernelBisection][https://wiki.ubuntu.com/Kernel/KernelBisection[https://wiki.ubuntu.com/Kernel/KernelBisection]] > > or > > https://wiki.archlinux.org/index.php/Bisecting_bugs[https://wiki.archlinux.org/index.php/Bisecting_bugs][https://wiki.archlinux.org/index.php/Bisecting_bugs[https://wiki.archlinux.org/index.php/Bisecting_bugs]] > > > > Once the commit has been identified we can work together to narrow it down > > to the exact change, and then work together on a fix. > > Yeah, we need more data in order to start tracking it. I suspect, > however, that a simple git bisect may not work in this case, due to the > USB changes that forbids DMA on stack that was added to Kernel 4.9, if > the card Josef is using was affected by such change. > > Probably, he'll need to disable CONFIG_VMAP_STACK in the middle > of bisect (e. g. when the patch that implements it is added), > or to cherry-pick any needed DMA fixup patch on the top of Kernel > 4.8 before starting bisect. > > It is also worth mentioning what's the USB host controller that > are used, and what's the media driver, as this could be an issue > there. > > That's said, from the bug report, it seems that this is > happening on RPi3. Could you please test it also on a PC? That > will help to identify if the bug is at RPi's host driver or > on media drivers. > > With regards to RPi3, there are actually two different drivers > for it: one used on Raspbian Kernel, and another one upstream. > They're completely different ones. > > What driver are you using? > > Thanks, > Mauro Thanks, Mauro ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: dvb usb issues since kernel 4.9 2018-01-06 19:54 ` dvb usb issues since kernel 4.9 Mauro Carvalho Chehab 2018-01-06 21:07 ` Aw: " Josef Griebichler @ 2018-01-06 21:44 ` Alan Stern 2018-01-07 11:03 ` Mauro Carvalho Chehab 2018-01-07 21:23 ` Linus Torvalds 2 siblings, 1 reply; 47+ messages in thread From: Alan Stern @ 2018-01-06 21:44 UTC (permalink / raw) To: Mauro Carvalho Chehab Cc: Josef Griebichler, Greg Kroah-Hartman, linux-usb, Eric Dumazet, Rik van Riel, Paolo Abeni, Hannes Frederic Sowa, Jesper Dangaard Brouer, linux-kernel, netdev, Jonathan Corbet, LMML, Peter Zijlstra, David Miller, torvalds On Sat, 6 Jan 2018, Mauro Carvalho Chehab wrote: > Hi Josef, > > Em Sat, 6 Jan 2018 16:04:16 +0100 > "Josef Griebichler" <griebichler.josef@gmx.at> escreveu: > > > Hi, > > > > the causing commit has been identified. > > After reverting commit https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=4cd13c21b207e80ddb1144c576500098f2d5f882 > > its working again. > > Just replying to me won't magically fix this. The ones that were involved on > this patch should also be c/c, plus USB people. Just added them. > > > Please have a look into the thread https://forum.libreelec.tv/thread/4235-dvb-issue-since-le-switched-to-kernel-4-9-x/?pageNo=13 > > here are several users aknowledging the revert solves their issues with usb dvb cards. > > I read the entire (long) thread there. In order to make easier for the > others, from what I understand, the problem happens on both x86 and arm, > although almost all comments there are mentioning tests with raspbian > Kernel (with uses a different USB host driver than the upstream one). > > It happens when watching digital TV DVB-C channels, with usually means > a sustained bit rate of 11 MBps to 54 MBps. > > The reports mention the dvbsky, with uses USB URB bulk transfers. > On every several minutes (5 to 10 mins), the stream suffer "glitches" > caused by frame losses. > > The part of the thread that contains the bisect is at: > https://forum.libreelec.tv/thread/4235-dvb-issue-since-le-switched-to-kernel-4-9-x/?postID=75965#post75965 > > It indirectly mentions another comment on the thread with points > to: > https://github.com/raspberrypi/linux/issues/2134 > > There, it says that this fix part of the issues: > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=34f41c0316ed52b0b44542491d89278efdaa70e4 > > but it affects URB packet losses on a lesser extend. > > The main issue is really the logic changes a the core softirq logic. > > Using Kernel 4.14.10 on a Raspberry Pi 3 with 4cd13c2 commit reverted > fixed the issue. > > Joseph, is the above right? Anything else to mention? Does the > same issue affect also on x86 with vanilla Kernel 4.14.10? > > - > > It seems that the original patch were designed to solve some IRQ issues > with network cards with causes data losses on high traffic. However, > it is also causing bad effects on sustained high bandwidth demands > required by DVB cards, at least on some USB host drivers. > > Alan/Greg/Eric/David: > > Any ideas about how to fix it without causing regressions to > network? It would be good to know what hardware was involved on the x86 system and to have some timing data. Can we see the output from lsusb and usbmon, running on a vanilla kernel that gets plenty of video glitches? Overall, this may be a very difficult problem to solve. The 4cd13c21b207 commit was intended to improve throughput at the cost of increased latency. But then what do you do when the latency becomes too high for the video subsystem to handle? Alan Stern ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: dvb usb issues since kernel 4.9 2018-01-06 21:44 ` Alan Stern @ 2018-01-07 11:03 ` Mauro Carvalho Chehab 2018-01-07 15:41 ` Alan Stern 0 siblings, 1 reply; 47+ messages in thread From: Mauro Carvalho Chehab @ 2018-01-07 11:03 UTC (permalink / raw) To: Alan Stern Cc: Josef Griebichler, Greg Kroah-Hartman, linux-usb, Eric Dumazet, Rik van Riel, Paolo Abeni, Hannes Frederic Sowa, Jesper Dangaard Brouer, linux-kernel, netdev, Jonathan Corbet, LMML, Peter Zijlstra, David Miller, torvalds Em Sat, 6 Jan 2018 16:44:20 -0500 (EST) Alan Stern <stern@rowland.harvard.edu> escreveu: > On Sat, 6 Jan 2018, Mauro Carvalho Chehab wrote: > > > Hi Josef, > > > > Em Sat, 6 Jan 2018 16:04:16 +0100 > > "Josef Griebichler" <griebichler.josef@gmx.at> escreveu: > > > > > Hi, > > > > > > the causing commit has been identified. > > > After reverting commit https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=4cd13c21b207e80ddb1144c576500098f2d5f882 > > > its working again. > > > > Just replying to me won't magically fix this. The ones that were involved on > > this patch should also be c/c, plus USB people. Just added them. > > > > > Please have a look into the thread https://forum.libreelec.tv/thread/4235-dvb-issue-since-le-switched-to-kernel-4-9-x/?pageNo=13 > > > here are several users aknowledging the revert solves their issues with usb dvb cards. > > > > I read the entire (long) thread there. In order to make easier for the > > others, from what I understand, the problem happens on both x86 and arm, > > although almost all comments there are mentioning tests with raspbian > > Kernel (with uses a different USB host driver than the upstream one). > > > > It happens when watching digital TV DVB-C channels, with usually means > > a sustained bit rate of 11 MBps to 54 MBps. > > > > The reports mention the dvbsky, with uses USB URB bulk transfers. > > On every several minutes (5 to 10 mins), the stream suffer "glitches" > > caused by frame losses. > > > > The part of the thread that contains the bisect is at: > > https://forum.libreelec.tv/thread/4235-dvb-issue-since-le-switched-to-kernel-4-9-x/?postID=75965#post75965 > > > > It indirectly mentions another comment on the thread with points > > to: > > https://github.com/raspberrypi/linux/issues/2134 > > > > There, it says that this fix part of the issues: > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=34f41c0316ed52b0b44542491d89278efdaa70e4 > > > > but it affects URB packet losses on a lesser extend. > > > > The main issue is really the logic changes a the core softirq logic. > > > > Using Kernel 4.14.10 on a Raspberry Pi 3 with 4cd13c2 commit reverted > > fixed the issue. > > > > Joseph, is the above right? Anything else to mention? Does the > > same issue affect also on x86 with vanilla Kernel 4.14.10? > > > > - > > > > It seems that the original patch were designed to solve some IRQ issues > > with network cards with causes data losses on high traffic. However, > > it is also causing bad effects on sustained high bandwidth demands > > required by DVB cards, at least on some USB host drivers. > > > > Alan/Greg/Eric/David: > > > > Any ideas about how to fix it without causing regressions to > > network? > > It would be good to know what hardware was involved on the x86 system > and to have some timing data. Can we see the output from lsusb and > usbmon, running on a vanilla kernel that gets plenty of video glitches? >From Josef's report, and from the BZ, the affected hardware seems to be based on Montage Technology M88DS3103/M88TS2022 chipset. The driver it uses is at drivers/media/usb/dvb-usb-v2/dvbsky.c, with shares a USB implementation that is used by a lot more drivers. The URB handling code is at: drivers/media/usb/dvb-usb-v2/usb_urb.c This particular driver allocates 8 buffers with 4096 bytes each for bulk transfers, using transfer_flags = URB_NO_TRANSFER_DMA_MAP. This become a popular USB hardware nowadays. I have one S960c myself, so I can send you the lsusb from it. You should notice, however, that a DVB-C/DVB-S2 channel can easily provide very high sustained bit rates. Here, on my DVB-S2 provider, a typical transponder produces 58 Mpps of payload after removing URB headers. A 10 minutes record with the entire data (with typically contains 5-10 channels) can easily go above 4 GB, just to reproduce 1-2 glitches. So, I'm not sure if a usbmon dump would be useful. I'm enclosing the lsusb from a S960C device, with is based on those Montage chipsets: Bus 002 Device 007: ID 0572:960c Conexant Systems (Rockwell), Inc. DVBSky S960C DVB-S2 tuner Couldn't open device, some information will be missing Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 64 idVendor 0x0572 Conexant Systems (Rockwell), Inc. idProduct 0x960c DVBSky S960C DVB-S2 tuner bcdDevice 0.00 iManufacturer 1 iProduct 2 iSerial 3 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 219 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 4 bmAttributes 0x80 (Bus Powered) MaxPower 500mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 3 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 1 bInterfaceProtocol 1 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x01 EP 1 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 1 bNumEndpoints 3 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 1 bInterfaceProtocol 1 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 3 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x01 EP 1 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes 1 Transfer Type Isochronous Synch Type None Usage Type Data wMaxPacketSize 0x13f2 3x 1010 bytes bInterval 1 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 2 bNumEndpoints 3 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 1 bInterfaceProtocol 1 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 3 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x01 EP 1 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes 1 Transfer Type Isochronous Synch Type None Usage Type Data wMaxPacketSize 0x12d6 3x 726 bytes bInterval 1 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 3 bNumEndpoints 3 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 1 bInterfaceProtocol 1 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 3 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x01 EP 1 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes 1 Transfer Type Isochronous Synch Type None Usage Type Data wMaxPacketSize 0x12ae 3x 686 bytes bInterval 1 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 4 bNumEndpoints 3 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 1 bInterfaceProtocol 1 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 3 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x01 EP 1 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes 1 Transfer Type Isochronous Synch Type None Usage Type Data wMaxPacketSize 0x03ca 1x 970 bytes bInterval 1 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 5 bNumEndpoints 3 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 1 bInterfaceProtocol 1 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 3 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x01 EP 1 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes 1 Transfer Type Isochronous Synch Type None Usage Type Data wMaxPacketSize 0x02ac 1x 684 bytes bInterval 1 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 6 bNumEndpoints 3 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 1 bInterfaceProtocol 1 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 3 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x01 EP 1 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes 1 Transfer Type Isochronous Synch Type None Usage Type Data wMaxPacketSize 0x03ac 1x 940 bytes bInterval 1 > Overall, this may be a very difficult problem to solve. The > 4cd13c21b207 commit was intended to improve throughput at the cost of > increased latency. But then what do you do when the latency becomes > too high for the video subsystem to handle? Latency can't be too high, otherwise frames will be dropped. Even if the Kernel itself doesn't drop, if the delay goes higher than a certain threshold, userspace will need to drop, as it should be presenting audio and video on real time. Yet, typically, userspace will delay it by one or two seconds, with would mean 1500-3500 buffers, with I suspect it is a lot more than the hardware limits. So I suspect that the hardware starves free buffers a way before userspace, as media hardware don't have unlimited buffers inside them, as they assume that the Kernel/userspace will be fast enough to sustain bit rates up to 66 Mbps of payload. Perhaps media drivers could pass some quirk similar to URB_ISO_ASAP, in order to revert the kernel logic to prioritize latency instead of throughput. Thanks, Mauro ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: dvb usb issues since kernel 4.9 2018-01-07 11:03 ` Mauro Carvalho Chehab @ 2018-01-07 15:41 ` Alan Stern 2018-01-07 17:01 ` Aw: " Josef Griebichler 2018-01-08 9:43 ` Mauro Carvalho Chehab 0 siblings, 2 replies; 47+ messages in thread From: Alan Stern @ 2018-01-07 15:41 UTC (permalink / raw) To: Mauro Carvalho Chehab Cc: Josef Griebichler, Greg Kroah-Hartman, linux-usb, Eric Dumazet, Rik van Riel, Paolo Abeni, Hannes Frederic Sowa, Jesper Dangaard Brouer, linux-kernel, netdev, Jonathan Corbet, LMML, Peter Zijlstra, David Miller, torvalds On Sun, 7 Jan 2018, Mauro Carvalho Chehab wrote: > > > It seems that the original patch were designed to solve some IRQ issues > > > with network cards with causes data losses on high traffic. However, > > > it is also causing bad effects on sustained high bandwidth demands > > > required by DVB cards, at least on some USB host drivers. > > > > > > Alan/Greg/Eric/David: > > > > > > Any ideas about how to fix it without causing regressions to > > > network? > > > > It would be good to know what hardware was involved on the x86 system > > and to have some timing data. Can we see the output from lsusb and > > usbmon, running on a vanilla kernel that gets plenty of video glitches? > > From Josef's report, and from the BZ, the affected hardware seems > to be based on Montage Technology M88DS3103/M88TS2022 chipset. What type of USB host controller does the x86_64 system use? EHCI or xHCI? > The driver it uses is at drivers/media/usb/dvb-usb-v2/dvbsky.c, > with shares a USB implementation that is used by a lot more drivers. > The URB handling code is at: > > drivers/media/usb/dvb-usb-v2/usb_urb.c > > This particular driver allocates 8 buffers with 4096 bytes each > for bulk transfers, using transfer_flags = URB_NO_TRANSFER_DMA_MAP. > > This become a popular USB hardware nowadays. I have one S960c > myself, so I can send you the lsusb from it. You should notice, however, > that a DVB-C/DVB-S2 channel can easily provide very high sustained bit > rates. Here, on my DVB-S2 provider, a typical transponder produces 58 Mpps > of payload after removing URB headers. You mentioned earlier that the driver uses bulk transfers. In USB-2.0, the maximum possible payload data transfer rate using bulk transfers is 53248 bytes/ms, which is 53.248 MB/s (i.e., lower than 58 MB/s). And even this is possible only if almost nothing else is using the bus at the same time. > A 10 minutes record with the > entire data (with typically contains 5-10 channels) can easily go > above 4 GB, just to reproduce 1-2 glitches. So, I'm not sure if > a usbmon dump would be useful. It might not be helpful at all. However, I'm not interested in the payload data (which would be unintelligible to me anyway) but rather the timing of URB submissions and completions. A usbmon trace which didn't keep much of the payload data would only require on the order of 50 MB per minute -- and Josef said that glitches usually would show up within a minute or so. > I'm enclosing the lsusb from a S960C device, with is based on those > Montage chipsets: What I wanted to see was the output from "lsusb" on the affected system, not the output from "lsusb -v -s B:D" on your system. > > Overall, this may be a very difficult problem to solve. The > > 4cd13c21b207 commit was intended to improve throughput at the cost of > > increased latency. But then what do you do when the latency becomes > > too high for the video subsystem to handle? > > Latency can't be too high, otherwise frames will be dropped. Yes, that's the whole point. > Even if the Kernel itself doesn't drop, if the delay goes higher > than a certain threshold, userspace will need to drop, as it > should be presenting audio and video on real time. Yet, typically, > userspace will delay it by one or two seconds, with would mean > 1500-3500 buffers, with I suspect it is a lot more than the hardware > limits. So I suspect that the hardware starves free buffers a way > before userspace, as media hardware don't have unlimited buffers > inside them, as they assume that the Kernel/userspace will be fast > enough to sustain bit rates up to 66 Mbps of payload. The timing information would tell us how large the latency is. In any case, you might be able to attack the problem simply by using more than 8 buffers. With just eight 4096-byte buffers, the total pipeline capacity is only about 0.62 ms (at the maximum possible transfer rate). Increasing the number of buffers to 65 would give a capacity of 5 ms, which is probably a lot better suited for situations where completions are handled by the ksoftirqd thread. > Perhaps media drivers could pass some quirk similar to URB_ISO_ASAP, > in order to revert the kernel logic to prioritize latency instead of > throughput. It can't be done without pervasive changes to the USB subsystem, which I would greatly prefer to avoid. Besides, this wouldn't really solve the problem. Decreasing the latency for one device will cause it to be increased for others. Alan Stern ^ permalink raw reply [flat|nested] 47+ messages in thread
* Aw: Re: dvb usb issues since kernel 4.9 2018-01-07 15:41 ` Alan Stern @ 2018-01-07 17:01 ` Josef Griebichler 2018-01-08 9:43 ` Mauro Carvalho Chehab 1 sibling, 0 replies; 47+ messages in thread From: Josef Griebichler @ 2018-01-07 17:01 UTC (permalink / raw) To: Alan Stern Cc: Mauro Carvalho Chehab, Greg Kroah-Hartman, linux-usb, Eric Dumazet, Rik van Riel, Paolo Abeni, Hannes Frederic Sowa, Jesper Dangaard Brouer, linux-kernel, netdev, Jonathan Corbet, LMML, Peter Zijlstra, David Miller, torvalds [-- Attachment #1: Type: text/plain, Size: 5676 bytes --] Hi, here I provide lsusb from my affected hardware (technotrend s2-4600). http://ix.io/DLY With this hardware I had errors when recording with tvheadend. Livetv was ok, only channel switching made some problems sometimes. Please see attached tvheadend service logs. I also provide dmesg (libreelec on rpi3 with kernel 4.14.10 with revert of the mentioned commit). http://ix.io/DM2 Regards Josef Gesendet: Sonntag, 07. Januar 2018 um 16:41 Uhr Von: "Alan Stern" <stern@rowland.harvard.edu> An: "Mauro Carvalho Chehab" <mchehab@s-opensource.com> Cc: "Josef Griebichler" <griebichler.josef@gmx.at>, "Greg Kroah-Hartman" <gregkh@linuxfoundation.org>, linux-usb@vger.kernel.org, "Eric Dumazet" <edumazet@google.com>, "Rik van Riel" <riel@redhat.com>, "Paolo Abeni" <pabeni@redhat.com>, "Hannes Frederic Sowa" <hannes@redhat.com>, "Jesper Dangaard Brouer" <jbrouer@redhat.com>, linux-kernel <linux-kernel@vger.kernel.org>, netdev <netdev@vger.kernel.org>, "Jonathan Corbet" <corbet@lwn.net>, LMML <linux-media@vger.kernel.org>, "Peter Zijlstra" <peterz@infradead.org>, "David Miller" <davem@davemloft.net>, torvalds@linux-foundation.org Betreff: Re: dvb usb issues since kernel 4.9 On Sun, 7 Jan 2018, Mauro Carvalho Chehab wrote: > > > It seems that the original patch were designed to solve some IRQ issues > > > with network cards with causes data losses on high traffic. However, > > > it is also causing bad effects on sustained high bandwidth demands > > > required by DVB cards, at least on some USB host drivers. > > > > > > Alan/Greg/Eric/David: > > > > > > Any ideas about how to fix it without causing regressions to > > > network? > > > > It would be good to know what hardware was involved on the x86 system > > and to have some timing data. Can we see the output from lsusb and > > usbmon, running on a vanilla kernel that gets plenty of video glitches? > > From Josef's report, and from the BZ, the affected hardware seems > to be based on Montage Technology M88DS3103/M88TS2022 chipset. What type of USB host controller does the x86_64 system use? EHCI or xHCI? > The driver it uses is at drivers/media/usb/dvb-usb-v2/dvbsky.c, > with shares a USB implementation that is used by a lot more drivers. > The URB handling code is at: > > drivers/media/usb/dvb-usb-v2/usb_urb.c > > This particular driver allocates 8 buffers with 4096 bytes each > for bulk transfers, using transfer_flags = URB_NO_TRANSFER_DMA_MAP. > > This become a popular USB hardware nowadays. I have one S960c > myself, so I can send you the lsusb from it. You should notice, however, > that a DVB-C/DVB-S2 channel can easily provide very high sustained bit > rates. Here, on my DVB-S2 provider, a typical transponder produces 58 Mpps > of payload after removing URB headers. You mentioned earlier that the driver uses bulk transfers. In USB-2.0, the maximum possible payload data transfer rate using bulk transfers is 53248 bytes/ms, which is 53.248 MB/s (i.e., lower than 58 MB/s). And even this is possible only if almost nothing else is using the bus at the same time. > A 10 minutes record with the > entire data (with typically contains 5-10 channels) can easily go > above 4 GB, just to reproduce 1-2 glitches. So, I'm not sure if > a usbmon dump would be useful. It might not be helpful at all. However, I'm not interested in the payload data (which would be unintelligible to me anyway) but rather the timing of URB submissions and completions. A usbmon trace which didn't keep much of the payload data would only require on the order of 50 MB per minute -- and Josef said that glitches usually would show up within a minute or so. > I'm enclosing the lsusb from a S960C device, with is based on those > Montage chipsets: What I wanted to see was the output from "lsusb" on the affected system, not the output from "lsusb -v -s B:D" on your system. > > Overall, this may be a very difficult problem to solve. The > > 4cd13c21b207 commit was intended to improve throughput at the cost of > > increased latency. But then what do you do when the latency becomes > > too high for the video subsystem to handle? > > Latency can't be too high, otherwise frames will be dropped. Yes, that's the whole point. > Even if the Kernel itself doesn't drop, if the delay goes higher > than a certain threshold, userspace will need to drop, as it > should be presenting audio and video on real time. Yet, typically, > userspace will delay it by one or two seconds, with would mean > 1500-3500 buffers, with I suspect it is a lot more than the hardware > limits. So I suspect that the hardware starves free buffers a way > before userspace, as media hardware don't have unlimited buffers > inside them, as they assume that the Kernel/userspace will be fast > enough to sustain bit rates up to 66 Mbps of payload. The timing information would tell us how large the latency is. In any case, you might be able to attack the problem simply by using more than 8 buffers. With just eight 4096-byte buffers, the total pipeline capacity is only about 0.62 ms (at the maximum possible transfer rate). Increasing the number of buffers to 65 would give a capacity of 5 ms, which is probably a lot better suited for situations where completions are handled by the ksoftirqd thread. > Perhaps media drivers could pass some quirk similar to URB_ISO_ASAP, > in order to revert the kernel logic to prioritize latency instead of > throughput. It can't be done without pervasive changes to the USB subsystem, which I would greatly prefer to avoid. Besides, this wouldn't really solve the problem. Decreasing the latency for one device will cause it to be increased for others. Alan Stern [-- Attachment #2: service.log --] [-- Type: application/octet-stream, Size: 43862 bytes --] 2017-01-16 16:30:22.749 [ INFO] main: Log started 2017-01-16 16:30:22.756 [ INFO] http: Starting HTTP server 0.0.0.0:9981 2017-01-16 16:30:22.756 [ INFO] htsp: Starting HTSP server 0.0.0.0:9982 2017-01-16 16:30:22.757 [ ERROR] satips: use --satip_bindaddr parameter to select the local IP for SAT>IP 2017-01-16 16:30:22.757 [ ERROR] satips: using Google lookup (might block the task until timeout) 2017-01-16 16:30:22.797 [ INFO] config: loaded 2017-01-16 16:30:22.801 [ INFO] config: scanfile (re)initialization with path <none> 2017-01-16 16:30:24.211 [ INFO] scanfile: DVB-S - loaded 1 regions with 112 networks 2017-01-16 16:30:24.211 [ INFO] scanfile: DVB-T - loaded 43 regions with 1106 networks 2017-01-16 16:30:24.211 [ INFO] scanfile: DVB-C - loaded 17 regions with 56 networks 2017-01-16 16:30:24.211 [ INFO] scanfile: ATSC-T - loaded 2 regions with 9 networks 2017-01-16 16:30:24.211 [ INFO] scanfile: ATSC-C - loaded 1 regions with 5 networks 2017-01-16 16:30:24.211 [ INFO] scanfile: ISDB-T - loaded 2 regions with 1297 networks 2017-01-16 16:30:24.817 [ INFO] linuxdvb: adapter added /dev/dvb/adapter0 2017-01-16 16:30:24.925 [ INFO] dvr: Creating new configuration '' 2017-01-16 16:30:24.925 [ INFO] dvr: Creating new configuration '' 2017-01-16 16:30:24.925 [ ERROR] dvr: Unable to create second default config, removing 2017-01-16 16:30:24.932 [ INFO] capmt: Oscam active 2017-01-16 16:30:24.932 [ INFO] descrambler: adding CAID 2600 as constant crypto-word (BISS) 2017-01-16 16:30:24.932 [ INFO] epggrab: module eit created 2017-01-16 16:30:24.932 [ INFO] epggrab: module uk_freesat created 2017-01-16 16:30:24.932 [ ERROR] capmt: Oscam: Cannot connect to 127.0.0.1:9000 (Connection refused); Do you have OSCam running? 2017-01-16 16:30:24.932 [ INFO] capmt: Oscam: Automatic reconnection attempt in in 60 seconds 2017-01-16 16:30:24.932 [ INFO] epggrab: module uk_freeview created 2017-01-16 16:30:24.933 [ INFO] epggrab: module viasat_baltic created 2017-01-16 16:30:24.933 [ INFO] epggrab: module Bulsatcom_39E created 2017-01-16 16:30:24.933 [ INFO] epggrab: module psip created 2017-01-16 16:30:24.948 [ INFO] epggrab: module opentv-ausat created 2017-01-16 16:30:24.948 [ INFO] epggrab: module opentv-skyuk created 2017-01-16 16:30:24.949 [ INFO] epggrab: module opentv-skyit created 2017-01-16 16:30:24.951 [ INFO] epggrab: module opentv-skynz created 2017-01-16 16:30:24.952 [ INFO] epggrab: module pyepg created 2017-01-16 16:30:24.952 [ INFO] epggrab: module xmltv created 2017-01-16 16:30:24.957 [ INFO] spawn: Executing "/storage/.kodi/addons/service.tvheadend42/bin/tv_grab_file" 2017-01-16 16:30:24.963 [ INFO] epggrab: module /storage/.kodi/addons/service.tvheadend42/bin/tv_grab_file created 2017-01-16 16:30:25.074 [ INFO] epgdb: gzip format detected, inflating (ratio 17.3% deflated size 2995068) 2017-01-16 16:30:25.308 [ INFO] epgdb: parsing 17344211 bytes 2017-01-16 16:30:26.471 [ INFO] epgdb: loaded v2 2017-01-16 16:30:26.471 [ INFO] epgdb: config 1 2017-01-16 16:30:26.471 [ INFO] epgdb: brands 0 2017-01-16 16:30:26.471 [ INFO] epgdb: seasons 0 2017-01-16 16:30:26.471 [ INFO] epgdb: episodes 24310 2017-01-16 16:30:26.471 [ INFO] epgdb: broadcasts 22479 2017-01-16 16:30:26.526 [ NOTICE] START: HTS Tvheadend version 4.1.2401 ~ LibreELEC Tvh-addon v8.1.108-#0110-milhouse-v4.1-2413-g489ba95 started, running as PID:419 UID:0 GID:39, CWD:/ CNF:/storage/.kodi/userdata/addon_data/service.tvheadend42 2017-01-16 16:30:26.530 [ INFO] mpegts: 10773.25H in Astra 19,2 - tuning on TechnoTrend S2-4600 2017-01-16 16:30:26.567 [ INFO] subscription: 0001: "epggrab" subscribing to mux "10773.25H", weight: 4, adapter: "TechnoTrend S2-4600", network: "Astra 19,2", service: "Raw PID Subscription" 2017-01-16 16:30:28.262 [ INFO] htsp: Got connection from 127.0.0.1 2017-01-16 16:30:28.265 [ INFO] htsp: 127.0.0.1: Welcomed client software: Kodi Media Center (HTSPv25) 2017-01-16 16:30:28.273 [ INFO] htsp: 127.0.0.1 [ Kodi Media Center ]: Identified as user '' 2017-01-16 16:30:37.216 [ INFO] subscription: 0001: "epggrab" unsubscribing 2017-01-16 16:30:38.120 [ INFO] mpegts: 10891.25H in Astra 19,2 - tuning on TechnoTrend S2-4600 2017-01-16 16:30:38.139 [ INFO] subscription: 0003: "epggrab" subscribing to mux "10891.25H", weight: 4, adapter: "TechnoTrend S2-4600", network: "Astra 19,2", service: "Raw PID Subscription" 2017-01-16 16:31:06.560 [ INFO] subscription: 0003: "epggrab" unsubscribing 2017-01-16 16:31:07.546 [ INFO] mpegts: 10920.75H in Astra 19,2 - tuning on TechnoTrend S2-4600 2017-01-16 16:31:07.565 [ INFO] subscription: 0005: "epggrab" subscribing to mux "10920.75H", weight: 4, adapter: "TechnoTrend S2-4600", network: "Astra 19,2", service: "Raw PID Subscription" 2017-01-16 16:31:17.990 [ INFO] subscription: 0005: "epggrab" unsubscribing 2017-01-16 16:31:18.956 [ INFO] mpegts: 11052.75H in Astra 19,2 - tuning on TechnoTrend S2-4600 2017-01-16 16:31:18.975 [ INFO] subscription: 0007: "epggrab" subscribing to mux "11052.75H", weight: 4, adapter: "TechnoTrend S2-4600", network: "Astra 19,2", service: "Raw PID Subscription" 2017-01-16 16:31:24.903 [ INFO] capmt: Oscam: mode 5 connected to 127.0.0.1:9000 (single) 2017-01-16 16:31:24.904 [ INFO] capmt: Oscam: Connected to server 'OSCam v1.20-unstable_svn, build r (armv7ve-libreelec-linux-gnueabi)' (protocol version 2) 2017-01-16 16:31:45.461 [ INFO] subscription: 0007: "epggrab" unsubscribing 2017-01-16 16:31:46.405 [ INFO] mpegts: 11243.75H in Astra 19,2 - tuning on TechnoTrend S2-4600 2017-01-16 16:31:46.423 [ INFO] subscription: 0009: "epggrab" subscribing to mux "11243.75H", weight: 4, adapter: "TechnoTrend S2-4600", network: "Astra 19,2", service: "Raw PID Subscription" 2017-01-16 16:32:14.211 [ INFO] subscription: 0009: "epggrab" unsubscribing 2017-01-16 16:32:14.745 [ INFO] mpegts: 11302.75H in Astra 19,2 - tuning on TechnoTrend S2-4600 2017-01-16 16:32:14.765 [ INFO] capmt: Oscam: Starting CAPMT server for service "ORF1 HD" on adapter 0 2017-01-16 16:32:14.766 [ INFO] subscription: 000B: "127.0.0.1 [ | Kodi Media Center ]" subscribing on channel "ORF1 HD", weight: 150, adapter: "TechnoTrend S2-4600", network: "Astra 19,2", mux: "11302.75H", provider: "ORF", service: "ORF1 HD", profile="htsp", hostname="127.0.0.1", username="127.0.0.1", client="Kodi Media Center" 2017-01-16 16:32:15.486 [WARNING] tbl-eit: eit: 11302.75H in Astra 19,2: invalid checksum (len 1846, errors 1) 2017-01-16 16:32:15.561 [WARNING] tbl-base: pmt: 11302.75H in Astra 19,2: invalid checksum (len 164, errors 1) 2017-01-16 16:32:16.894 [WARNING] TS: Astra 19,2/11302.75H/ORF1 HD Transport error indicator (total 1) 2017-01-16 16:32:17.329 [ ERROR] descrambler: cannot decode packets for service "ORF1 HD" 2017-01-16 16:32:20.488 [WARNING] tbl-base: nit: 11302.75H in Astra 19,2: invalid checksum (len 1023, errors 1) 2017-01-16 16:32:21.038 [WARNING] tbl-base: pat: 11302.75H in Astra 19,2: invalid checksum (len 36, errors 1) 2017-01-16 16:32:22.888 [ INFO] subscription: 000B: "127.0.0.1 [ | Kodi Media Center ]" unsubscribing from "ORF1 HD", hostname="127.0.0.1", username="127.0.0.1", client="Kodi Media Center" 2017-01-16 16:32:23.848 [ INFO] mpegts: 11302.75H in Astra 19,2 - tuning on TechnoTrend S2-4600 2017-01-16 16:32:23.866 [ INFO] subscription: 000D: "epggrab" subscribing to mux "11302.75H", weight: 4, adapter: "TechnoTrend S2-4600", network: "Astra 19,2", service: "Raw PID Subscription" 2017-01-16 16:32:24.628 [ INFO] mpegts: 11273.25H in Astra 19,2 - tuning on TechnoTrend S2-4600 2017-01-16 16:32:24.632 [ INFO] subscription: 000D: "epggrab" unsubscribing 2017-01-16 16:32:24.651 [ INFO] capmt: Oscam: Starting CAPMT server for service "ORF SPORT+ HD" on adapter 0 2017-01-16 16:32:24.651 [ INFO] subscription: 000F: "127.0.0.1 [ | Kodi Media Center ]" subscribing on channel "ORF SPORT+ HD", weight: 150, adapter: "TechnoTrend S2-4600", network: "Astra 19,2", mux: "11273.25H", provider: "ORF", service: "ORF SPORT+ HD", profile="htsp", hostname="127.0.0.1", username="127.0.0.1", client="Kodi Media Center" 2017-01-16 16:39:44.768 [ INFO] subscription: 000F: "127.0.0.1 [ | Kodi Media Center ]" unsubscribing from "ORF SPORT+ HD", hostname="127.0.0.1", username="127.0.0.1", client="Kodi Media Center" 2017-01-16 16:39:50.867 [ INFO] mpegts: 12051V in Astra 19,2 - tuning on TechnoTrend S2-4600 2017-01-16 16:39:50.927 [ INFO] capmt: Oscam: Starting CAPMT server for service "PULS 4 Austria" on adapter 0 2017-01-16 16:39:50.927 [ INFO] subscription: 0018: "127.0.0.1 [ | Kodi Media Center ]" subscribing on channel "PULS 4 Austria", weight: 150, adapter: "TechnoTrend S2-4600", network: "Astra 19,2", mux: "12051V", provider: "ProSiebenSat.1", service: "PULS 4 Austria", profile="htsp", hostname="127.0.0.1", username="127.0.0.1", client="Kodi Media Center" 2017-01-16 16:39:51.905 [WARNING] TS: Astra 19,2/12051V/PULS 4 Austria: TELETEXT @ #39 Continuity counter error (total 1) 2017-01-16 16:53:35.037 [ INFO] subscription: 0018: "127.0.0.1 [ | Kodi Media Center ]" unsubscribing from "PULS 4 Austria", hostname="127.0.0.1", username="127.0.0.1", client="Kodi Media Center" 2017-01-16 16:53:35.041 [ INFO] mpegts: 11273.25H in Astra 19,2 - tuning on TechnoTrend S2-4600 2017-01-16 16:53:35.064 [ INFO] capmt: Oscam: Starting CAPMT server for service "ORF SPORT+ HD" on adapter 0 2017-01-16 16:53:35.064 [ INFO] subscription: 0026: "127.0.0.1 [ | Kodi Media Center ]" subscribing on channel "ORF SPORT+ HD", weight: 150, adapter: "TechnoTrend S2-4600", network: "Astra 19,2", mux: "11273.25H", provider: "ORF", service: "ORF SPORT+ HD", profile="htsp", hostname="127.0.0.1", username="127.0.0.1", client="Kodi Media Center" 2017-01-16 16:53:52.671 [ INFO] subscription: 0026: "127.0.0.1 [ | Kodi Media Center ]" unsubscribing from "ORF SPORT+ HD", hostname="127.0.0.1", username="127.0.0.1", client="Kodi Media Center" 2017-01-16 16:53:53.637 [ INFO] mpegts: 11302.75H in Astra 19,2 - tuning on TechnoTrend S2-4600 2017-01-16 16:53:53.656 [ INFO] subscription: 0027: "epggrab" subscribing to mux "11302.75H", weight: 4, adapter: "TechnoTrend S2-4600", network: "Astra 19,2", service: "Raw PID Subscription" 2017-01-16 16:54:09.382 [ INFO] dvr: entry adcf886064fc4846648169c93f3223d6 "Film um 4: Verlobung auf Umwegen" on "PULS 4 Austria" starting at 2017-01-16 15:54:20, scheduled for recording by "127.0.0.1" 2017-01-16 16:54:09.382 [ INFO] dvr: "Film um 4: Verlobung auf Umwegen" on "PULS 4 Austria" recorder starting 2017-01-16 16:54:09.383 [ INFO] mpegts: 12051V in Astra 19,2 - tuning on TechnoTrend S2-4600 2017-01-16 16:54:09.385 [ INFO] subscription: 0027: "epggrab" unsubscribing 2017-01-16 16:54:09.426 [ INFO] capmt: Oscam: Starting CAPMT server for service "PULS 4 Austria" on adapter 0 2017-01-16 16:54:09.427 [ INFO] subscription: 0029: "DVR: Film um 4: Verlobung auf Umwegen" subscribing on channel "PULS 4 Austria", weight: 300, adapter: "TechnoTrend S2-4600", network: "Astra 19,2", mux: "12051V", provider: "ProSiebenSat.1", service: "PULS 4 Austria", profile="pass" 2017-01-16 16:54:10.278 [ INFO] dvr: /storage/recordings/Film um 4_ Verlobung auf Umwegen.ts from adapter: "TechnoTrend S2-4600", network: "Astra 19,2", mux: "12051V", provider: "ProSiebenSat.1", service: "PULS 4 Austria" 2017-01-16 16:54:10.278 [ INFO] dvr: # type lang resolution aspect ratio sample rate channels 2017-01-16 16:54:10.278 [ INFO] dvr: 1 TELETEXT 2017-01-16 16:54:10.278 [ INFO] dvr: 2 MPEG2VIDEO 720x576 ? 2017-01-16 16:54:10.278 [ INFO] dvr: 3 MPEG2AUDIO ger ? ? 2017-01-16 16:54:10.278 [ INFO] dvr: 4 CA 2017-01-16 16:54:10.278 [ INFO] dvr: 5 CA 2017-01-16 16:54:10.278 [ INFO] dvr: 6 CA 2017-01-16 16:54:10.278 [ INFO] dvr: 7 CA 2017-01-16 16:54:10.278 [ INFO] dvr: 8 CA 2017-01-16 16:54:10.278 [ INFO] dvr: 9 CA 2017-01-16 16:54:10.278 [ INFO] dvr: 10 CA 2017-01-16 16:54:46.512 [ INFO] htsp: Got connection from 127.0.0.1 2017-01-16 16:54:46.512 [ INFO] htsp: 127.0.0.1: Welcomed client software: Kodi Media Center (HTSPv25) 2017-01-16 16:54:46.514 [ INFO] htsp: 127.0.0.1 [ Kodi Media Center ]: Identified as user '' 2017-01-16 16:54:47.611 [ INFO] htsp: 127.0.0.1 [ | Kodi Media Center ]: Disconnected 2017-01-16 16:54:50.514 [ INFO] htsp: 127.0.0.1 [ | Kodi Media Center ]: Disconnected 2017-01-16 16:55:04.516 [ INFO] htsp: Got connection from 127.0.0.1 2017-01-16 16:55:04.516 [ INFO] htsp: 127.0.0.1: Welcomed client software: Kodi Media Center (HTSPv25) 2017-01-16 16:55:04.518 [ INFO] htsp: 127.0.0.1 [ Kodi Media Center ]: Identified as user '' 2017-01-16 17:30:22.000 [ INFO] epgdb: snapshot start 2017-01-16 17:30:22.727 [ INFO] epgdb: queued to save (size 16168596) 2017-01-16 17:30:22.727 [ INFO] epgdb: brands 0 2017-01-16 17:30:22.727 [ INFO] epgdb: seasons 0 2017-01-16 17:30:22.727 [ INFO] epgdb: save start 2017-01-16 17:30:22.727 [ INFO] epgdb: episodes 22996 2017-01-16 17:30:22.727 [ INFO] epgdb: broadcasts 22996 2017-01-16 17:30:23.848 [ INFO] epgdb: stored (size 2737648) 2017-01-16 17:37:39.388 [WARNING] TS: Astra 19,2/12051V/PULS 4 Austria: MPEG2VIDEO @ #1791 Continuity counter error (total 1) 2017-01-16 17:37:39.388 [WARNING] TS: Astra 19,2/12051V/PULS 4 Austria: TELETEXT @ #39 Continuity counter error (total 1) 2017-01-16 17:37:39.388 [WARNING] TS: Astra 19,2/12051V/PULS 4 Austria: MPEG2AUDIO @ #1792 Continuity counter error (total 1) 2017-01-16 17:50:53.141 [ INFO] subscription: 0029: "DVR: Film um 4: Verlobung auf Umwegen" unsubscribing from "PULS 4 Austria" 2017-01-16 17:50:53.144 [ INFO] dvr: "Film um 4: Verlobung auf Umwegen" on "PULS 4 Austria": End of program: Completed OK 2017-01-16 17:51:56.769 [ INFO] mpegts: 11302.75H in Astra 19,2 - tuning on TechnoTrend S2-4600 2017-01-16 17:51:56.808 [ INFO] subscription: 0061: "epggrab" subscribing to mux "11302.75H", weight: 4, adapter: "TechnoTrend S2-4600", network: "Astra 19,2", service: "Raw PID Subscription" 2017-01-16 17:52:24.271 [ INFO] subscription: 0061: "epggrab" unsubscribing 2017-01-16 17:52:25.263 [ INFO] mpegts: 11361.75H in Astra 19,2 - tuning on TechnoTrend S2-4600 2017-01-16 17:52:25.282 [ INFO] subscription: 0063: "epggrab" subscribing to mux "11361.75H", weight: 4, adapter: "TechnoTrend S2-4600", network: "Astra 19,2", service: "Raw PID Subscription" 2017-01-16 17:52:34.727 [ INFO] subscription: 0063: "epggrab" unsubscribing 2017-01-16 17:52:35.694 [ INFO] mpegts: 11420.75H in Astra 19,2 - tuning on TechnoTrend S2-4600 2017-01-16 17:52:35.713 [ INFO] subscription: 0065: "epggrab" subscribing to mux "11420.75H", weight: 4, adapter: "TechnoTrend S2-4600", network: "Astra 19,2", service: "Raw PID Subscription" 2017-01-16 17:52:46.306 [ INFO] subscription: 0065: "epggrab" unsubscribing 2017-01-16 17:52:47.304 [ INFO] mpegts: 11493.75H in Astra 19,2 - tuning on TechnoTrend S2-4600 2017-01-16 17:52:47.324 [ INFO] subscription: 0067: "epggrab" subscribing to mux "11493.75H", weight: 4, adapter: "TechnoTrend S2-4600", network: "Astra 19,2", service: "Raw PID Subscription" 2017-01-16 17:53:14.281 [ INFO] subscription: 0067: "epggrab" unsubscribing 2017-01-16 17:53:15.228 [ INFO] mpegts: 11582.25H in Astra 19,2 - tuning on TechnoTrend S2-4600 2017-01-16 17:53:15.246 [ INFO] subscription: 0069: "epggrab" subscribing to mux "11582.25H", weight: 4, adapter: "TechnoTrend S2-4600", network: "Astra 19,2", service: "Raw PID Subscription" 2017-01-16 17:53:43.071 [ INFO] subscription: 0069: "epggrab" unsubscribing 2017-01-16 17:53:44.052 [ INFO] mpegts: 11670.75H in Astra 19,2 - tuning on TechnoTrend S2-4600 2017-01-16 17:53:44.071 [ INFO] subscription: 006B: "epggrab" subscribing to mux "11670.75H", weight: 4, adapter: "TechnoTrend S2-4600", network: "Astra 19,2", service: "Raw PID Subscription" 2017-01-16 17:53:54.805 [ INFO] subscription: 006B: "epggrab" unsubscribing 2017-01-16 17:53:55.762 [ INFO] mpegts: 12148.5H in Astra 19,2 - tuning on TechnoTrend S2-4600 2017-01-16 17:53:55.803 [ INFO] subscription: 006D: "epggrab" subscribing to mux "12148.5H", weight: 4, adapter: "TechnoTrend S2-4600", network: "Astra 19,2", service: "Raw PID Subscription" 2017-01-16 17:54:06.298 [ INFO] subscription: 006D: "epggrab" unsubscribing 2017-01-16 17:54:07.272 [ INFO] mpegts: 12187.5H in Astra 19,2 - tuning on TechnoTrend S2-4600 2017-01-16 17:54:07.313 [ INFO] subscription: 006F: "epggrab" subscribing to mux "12187.5H", weight: 4, adapter: "TechnoTrend S2-4600", network: "Astra 19,2", service: "Raw PID Subscription" 2017-01-16 17:54:23.361 [ INFO] subscription: 006F: "epggrab" unsubscribing 2017-01-16 17:54:24.315 [ INFO] mpegts: 12226.5H in Astra 19,2 - tuning on TechnoTrend S2-4600 2017-01-16 17:54:24.355 [ INFO] subscription: 0071: "epggrab" subscribing to mux "12226.5H", weight: 4, adapter: "TechnoTrend S2-4600", network: "Astra 19,2", service: "Raw PID Subscription" 2017-01-16 17:54:38.315 [ INFO] subscription: 0071: "epggrab" unsubscribing 2017-01-16 17:54:39.301 [ INFO] mpegts: 12265.5H in Astra 19,2 - tuning on TechnoTrend S2-4600 2017-01-16 17:54:39.342 [ INFO] subscription: 0073: "epggrab" subscribing to mux "12265.5H", weight: 4, adapter: "TechnoTrend S2-4600", network: "Astra 19,2", service: "Raw PID Subscription" 2017-01-16 17:55:07.105 [ INFO] subscription: 0073: "epggrab" unsubscribing 2017-01-16 17:55:08.103 [ INFO] mpegts: 12304.5H in Astra 19,2 - tuning on TechnoTrend S2-4600 2017-01-16 17:55:08.144 [ INFO] subscription: 0075: "epggrab" subscribing to mux "12304.5H", weight: 4, adapter: "TechnoTrend S2-4600", network: "Astra 19,2", service: "Raw PID Subscription" 2017-01-16 17:55:18.490 [ INFO] subscription: 0075: "epggrab" unsubscribing 2017-01-16 17:55:19.436 [ INFO] mpegts: 12421.5H in Astra 19,2 - tuning on TechnoTrend S2-4600 2017-01-16 17:55:19.477 [ INFO] subscription: 0077: "epggrab" subscribing to mux "12421.5H", weight: 4, adapter: "TechnoTrend S2-4600", network: "Astra 19,2", service: "Raw PID Subscription" 2017-01-16 17:55:47.325 [ INFO] subscription: 0077: "epggrab" unsubscribing 2017-01-16 17:55:48.262 [ INFO] mpegts: 12460.5H in Astra 19,2 - tuning on TechnoTrend S2-4600 2017-01-16 17:55:48.303 [ INFO] subscription: 0079: "epggrab" subscribing to mux "12460.5H", weight: 4, adapter: "TechnoTrend S2-4600", network: "Astra 19,2", service: "Raw PID Subscription" 2017-01-16 17:55:58.805 [ INFO] subscription: 0079: "epggrab" unsubscribing 2017-01-16 17:55:59.772 [ INFO] mpegts: 12662.75H in Astra 19,2 - tuning on TechnoTrend S2-4600 2017-01-16 17:55:59.812 [ INFO] subscription: 007B: "epggrab" subscribing to mux "12662.75H", weight: 4, adapter: "TechnoTrend S2-4600", network: "Astra 19,2", service: "Raw PID Subscription" 2017-01-16 17:56:00.851 [WARNING] tbl-eit: eit: 12662.75H in Astra 19,2: invalid checksum (len 1183, errors 1) 2017-01-16 17:56:10.776 [WARNING] tbl-eit: eit: 12662.75H in Astra 19,2: invalid checksum (len 152, errors 59) 2017-01-16 17:56:15.992 [WARNING] tbl-base: pat: 12662.75H in Astra 19,2: invalid checksum (len 3, errors 1) 2017-01-16 17:56:21.293 [WARNING] tbl-eit: eit: 12662.75H in Astra 19,2: invalid checksum (len 55, errors 114) 2017-01-16 17:56:24.970 [WARNING] tbl-base: nit: 12662.75H in Astra 19,2: invalid checksum (len 1012, errors 1) 2017-01-16 17:56:26.503 [WARNING] tbl-base: pat: 12662.75H in Astra 19,2: invalid checksum (len 124, errors 2) 2017-01-16 17:56:31.701 [WARNING] tbl-eit: eit: 12662.75H in Astra 19,2: invalid checksum (len 160, errors 155) 2017-01-16 17:56:34.359 [WARNING] tbl-base: cat: 12662.75H in Astra 19,2: invalid checksum (len 48, errors 1) 2017-01-16 17:56:41.731 [WARNING] tbl-eit: eit: 12662.75H in Astra 19,2: invalid checksum (len 289, errors 201) 2017-01-16 17:56:41.732 [WARNING] tbl-base: pat: 12662.75H in Astra 19,2: invalid checksum (len 3, errors 4) 2017-01-16 17:56:52.226 [WARNING] tbl-eit: eit: 12662.75H in Astra 19,2: invalid checksum (len 58, errors 242) 2017-01-16 17:56:52.721 [WARNING] tbl-base: pat: 12662.75H in Astra 19,2: invalid checksum (len 124, errors 6) 2017-01-16 17:57:02.694 [WARNING] tbl-eit: eit: 12662.75H in Astra 19,2: invalid checksum (len 3702, errors 300) 2017-01-16 17:57:04.843 [WARNING] tbl-base: nit: 12662.75H in Astra 19,2: invalid checksum (len 111, errors 2) 2017-01-16 17:57:05.924 [WARNING] tbl-base: cat: 12662.75H in Astra 19,2: invalid checksum (len 48, errors 2) 2017-01-16 17:57:12.636 [WARNING] tbl-eit: eit: 12662.75H in Astra 19,2: invalid checksum (len 111, errors 341) 2017-01-16 17:57:16.780 [WARNING] tbl-base: pat: 12662.75H in Astra 19,2: invalid checksum (len 124, errors 9) 2017-01-16 17:57:23.122 [WARNING] tbl-eit: eit: 12662.75H in Astra 19,2: invalid checksum (len 2973, errors 389) 2017-01-16 17:57:27.347 [WARNING] tbl-base: pat: 12662.75H in Astra 19,2: invalid checksum (len 124, errors 11) 2017-01-16 17:57:33.127 [WARNING] tbl-eit: eit: 12662.75H in Astra 19,2: invalid checksum (len 731, errors 449) 2017-01-16 17:57:43.647 [WARNING] tbl-eit: eit: 12662.75H in Astra 19,2: invalid checksum (len 245, errors 499) 2017-01-16 17:57:46.727 [WARNING] tbl-base: nit: 12662.75H in Astra 19,2: invalid checksum (len 1023, errors 3) 2017-01-16 17:57:49.367 [WARNING] tbl-base: bat: 12662.75H in Astra 19,2: invalid checksum (len 60, errors 1) 2017-01-16 17:57:49.368 [WARNING] tbl-base: sdt: 12662.75H in Astra 19,2: invalid checksum (len 60, errors 1) 2017-01-16 17:57:54.030 [WARNING] tbl-eit: eit: 12662.75H in Astra 19,2: invalid checksum (len 1083, errors 545) 2017-01-16 17:57:54.030 [WARNING] tbl-base: pat: 12662.75H in Astra 19,2: invalid checksum (len 124, errors 13) 2017-01-16 17:58:03.979 [WARNING] tbl-eit: eit: 12662.75H in Astra 19,2: invalid checksum (len 1049, errors 596) 2017-01-16 17:58:05.083 [WARNING] tbl-base: pat: 12662.75H in Astra 19,2: invalid checksum (len 124, errors 16) 2017-01-16 17:58:12.388 [WARNING] tbl-base: nit: 12662.75H in Astra 19,2: invalid checksum (len 1023, errors 4) 2017-01-16 17:58:14.068 [WARNING] tbl-eit: eit: 12662.75H in Astra 19,2: invalid checksum (len 3008, errors 641) 2017-01-16 17:58:16.217 [WARNING] tbl-base: pat: 12662.75H in Astra 19,2: invalid checksum (len 3, errors 20) 2017-01-16 17:58:24.515 [WARNING] tbl-eit: eit: 12662.75H in Astra 19,2: invalid checksum (len 3299, errors 686) 2017-01-16 17:58:29.670 [WARNING] tbl-base: nit: 12662.75H in Astra 19,2: invalid checksum (len 1023, errors 5) 2017-01-16 17:58:34.962 [WARNING] tbl-eit: eit: 12662.75H in Astra 19,2: invalid checksum (len 308, errors 738) 2017-01-16 17:58:40.153 [WARNING] tbl-base: cat: 12662.75H in Astra 19,2: invalid checksum (len 48, errors 3) 2017-01-16 17:58:40.711 [WARNING] tbl-base: pat: 12662.75H in Astra 19,2: invalid checksum (len 124, errors 22) 2017-01-16 17:58:44.917 [WARNING] tbl-eit: eit: 12662.75H in Astra 19,2: invalid checksum (len 4030, errors 789) 2017-01-16 17:58:47.017 [WARNING] tbl-base: nit: 12662.75H in Astra 19,2: invalid checksum (len 1023, errors 6) 2017-01-16 17:58:51.150 [WARNING] tbl-base: cat: 12662.75H in Astra 19,2: invalid checksum (len 27, errors 4) 2017-01-16 17:58:55.422 [WARNING] tbl-eit: eit: 12662.75H in Astra 19,2: invalid checksum (len 2341, errors 838) 2017-01-16 17:58:57.528 [WARNING] tbl-base: pat: 12662.75H in Astra 19,2: invalid checksum (len 3, errors 23) 2017-01-16 17:59:02.212 [WARNING] tbl-base: cat: 12662.75H in Astra 19,2: invalid checksum (len 3, errors 5) 2017-01-16 17:59:05.822 [WARNING] tbl-eit: eit: 12662.75H in Astra 19,2: invalid checksum (len 815, errors 885) 2017-01-16 17:59:13.197 [WARNING] tbl-base: nit: 12662.75H in Astra 19,2: invalid checksum (len 1023, errors 8) 2017-01-16 17:59:15.938 [WARNING] tbl-eit: eit: 12662.75H in Astra 19,2: invalid checksum (len 3342, errors 929) 2017-01-16 17:59:16.340 [WARNING] tbl-base: pat: 12662.75H in Astra 19,2: invalid checksum (len 124, errors 27) 2017-01-16 17:59:26.348 [WARNING] tbl-eit: eit: 12662.75H in Astra 19,2: invalid checksum (len 1907, errors 980) 2017-01-16 17:59:26.850 [WARNING] tbl-base: nit: 12662.75H in Astra 19,2: invalid checksum (len 1012, errors 9) 2017-01-16 17:59:29.538 [WARNING] tbl-base: pat: 12662.75H in Astra 19,2: invalid checksum (len 124, errors 29) 2017-01-16 17:59:34.149 [WARNING] tbl-base: cat: 12662.75H in Astra 19,2: invalid checksum (len 17, errors 6) 2017-01-16 17:59:36.888 [WARNING] tbl-eit: eit: 12662.75H in Astra 19,2: invalid checksum (len 1928, errors 1036) 2017-01-16 17:59:42.160 [WARNING] tbl-base: pat: 12662.75H in Astra 19,2: invalid checksum (len 124, errors 32) 2017-01-16 17:59:47.368 [WARNING] tbl-eit: eit: 12662.75H in Astra 19,2: invalid checksum (len 58, errors 1086) 2017-01-16 17:59:49.456 [WARNING] tbl-base: nit: 12662.75H in Astra 19,2: invalid checksum (len 111, errors 11) 2017-01-16 17:59:54.079 [WARNING] tbl-base: pat: 12662.75H in Astra 19,2: invalid checksum (len 124, errors 34) 2017-01-16 17:59:58.285 [WARNING] tbl-eit: eit: 12662.75H in Astra 19,2: invalid checksum (len 252, errors 1145) 2017-01-16 18:00:04.590 [WARNING] tbl-base: pat: 12662.75H in Astra 19,2: invalid checksum (len 124, errors 37) 2017-01-16 18:00:08.785 [WARNING] tbl-eit: eit: 12662.75H in Astra 19,2: invalid checksum (len 1733, errors 1190) 2017-01-16 18:00:15.103 [WARNING] tbl-base: cat: 12662.75H in Astra 19,2: invalid checksum (len 48, errors 8) 2017-01-16 18:00:18.784 [WARNING] tbl-eit: eit: 12662.75H in Astra 19,2: invalid checksum (len 994, errors 1226) 2017-01-16 18:00:22.410 [WARNING] tbl-base: pat: 12662.75H in Astra 19,2: invalid checksum (len 124, errors 38) 2017-01-16 18:00:27.713 [WARNING] tbl-base: nit: 12662.75H in Astra 19,2: invalid checksum (len 1012, errors 12) 2017-01-16 18:00:28.711 [WARNING] tbl-eit: eit: 12662.75H in Astra 19,2: invalid checksum (len 2309, errors 1281) 2017-01-16 18:00:39.156 [WARNING] tbl-eit: eit: 12662.75H in Astra 19,2: invalid checksum (len 620, errors 1332) 2017-01-16 18:00:45.026 [WARNING] tbl-base: nit: 12662.75H in Astra 19,2: invalid checksum (len 1012, errors 13) 2017-01-16 18:00:49.243 [WARNING] tbl-eit: eit: 12662.75H in Astra 19,2: invalid checksum (len 1083, errors 1378) 2017-01-16 18:00:52.798 [WARNING] tbl-base: pat: 12662.75H in Astra 19,2: invalid checksum (len 124, errors 39) 2017-01-16 18:00:59.671 [WARNING] tbl-eit: eit: 12662.75H in Astra 19,2: invalid checksum (len 2977, errors 1433) 2017-01-16 18:01:02.239 [WARNING] tbl-base: cat: 12662.75H in Astra 19,2: invalid checksum (len 48, errors 9) 2017-01-16 18:01:09.648 [WARNING] tbl-eit: eit: 12662.75H in Astra 19,2: invalid checksum (len 2031, errors 1485) 2017-01-16 18:01:10.210 [WARNING] tbl-base: pat: 12662.75H in Astra 19,2: invalid checksum (len 124, errors 43) 2017-01-16 18:01:13.309 [WARNING] tbl-base: cat: 12662.75H in Astra 19,2: invalid checksum (len 48, errors 11) 2017-01-16 18:01:14.801 [WARNING] tbl-base: nit: 12662.75H in Astra 19,2: invalid checksum (len 1023, errors 14) 2017-01-16 18:01:19.675 [WARNING] tbl-eit: eit: 12662.75H in Astra 19,2: invalid checksum (len 505, errors 1534) 2017-01-16 18:01:21.140 [WARNING] tbl-base: pat: 12662.75H in Astra 19,2: invalid checksum (len 124, errors 46) 2017-01-16 18:01:29.066 [WARNING] tbl-base: cat: 12662.75H in Astra 19,2: invalid checksum (len 48, errors 12) 2017-01-16 18:01:30.159 [WARNING] tbl-eit: eit: 12662.75H in Astra 19,2: invalid checksum (len 2263, errors 1590) 2017-01-16 18:01:32.286 [WARNING] tbl-base: nit: 12662.75H in Astra 19,2: invalid checksum (len 1023, errors 16) 2017-01-16 18:01:40.544 [WARNING] tbl-eit: eit: 12662.75H in Astra 19,2: invalid checksum (len 940, errors 1649) 2017-01-16 18:01:50.479 [WARNING] tbl-eit: eit: 12662.75H in Astra 19,2: invalid checksum (len 3186, errors 1692) 2017-01-16 18:01:52.155 [WARNING] tbl-base: pat: 12662.75H in Astra 19,2: invalid checksum (len 124, errors 48) 2017-01-16 18:02:00.990 [WARNING] tbl-eit: eit: 12662.75H in Astra 19,2: invalid checksum (len 268, errors 1741) 2017-01-16 18:02:02.574 [WARNING] tbl-base: pat: 12662.75H in Astra 19,2: invalid checksum (len 3, errors 51) 2017-01-16 18:02:11.498 [WARNING] tbl-eit: eit: 12662.75H in Astra 19,2: invalid checksum (len 553, errors 1789) 2017-01-16 18:02:12.500 [WARNING] tbl-base: pat: 12662.75H in Astra 19,2: invalid checksum (len 124, errors 53) 2017-01-16 18:02:15.702 [WARNING] tbl-base: cat: 12662.75H in Astra 19,2: invalid checksum (len 48, errors 14) 2017-01-16 18:02:21.913 [WARNING] tbl-eit: eit: 12662.75H in Astra 19,2: invalid checksum (len 399, errors 1844) 2017-01-16 18:02:26.671 [WARNING] tbl-base: pat: 12662.75H in Astra 19,2: invalid checksum (len 124, errors 56) 2017-01-16 18:02:32.023 [WARNING] tbl-eit: eit: 12662.75H in Astra 19,2: invalid checksum (len 1735, errors 1878) 2017-01-16 18:02:32.975 [WARNING] tbl-base: nit: 12662.75H in Astra 19,2: invalid checksum (len 1023, errors 18) 2017-01-16 18:02:40.390 [WARNING] tbl-base: pat: 12662.75H in Astra 19,2: invalid checksum (len 74, errors 57) 2017-01-16 18:02:42.390 [WARNING] tbl-eit: eit: 12662.75H in Astra 19,2: invalid checksum (len 136, errors 1937) 2017-01-16 18:02:46.630 [WARNING] tbl-base: cat: 12662.75H in Astra 19,2: invalid checksum (len 48, errors 15) 2017-01-16 18:02:52.339 [WARNING] tbl-eit: eit: 12662.75H in Astra 19,2: invalid checksum (len 656, errors 1989) 2017-01-16 18:02:55.002 [WARNING] tbl-base: nit: 12662.75H in Astra 19,2: invalid checksum (len 1012, errors 19) 2017-01-16 18:03:02.427 [WARNING] tbl-eit: eit: 12662.75H in Astra 19,2: invalid checksum (len 218, errors 2042) 2017-01-16 18:03:02.818 [WARNING] tbl-base: pat: 12662.75H in Astra 19,2: invalid checksum (len 124, errors 60) 2017-01-16 18:03:12.871 [WARNING] tbl-base: nit: 12662.75H in Astra 19,2: invalid checksum (len 1012, errors 20) 2017-01-16 18:03:12.871 [WARNING] tbl-eit: eit: 12662.75H in Astra 19,2: invalid checksum (len 262, errors 2094) 2017-01-16 18:03:20.224 [WARNING] tbl-base: pat: 12662.75H in Astra 19,2: invalid checksum (len 170, errors 61) 2017-01-16 18:03:23.356 [WARNING] tbl-eit: eit: 12662.75H in Astra 19,2: invalid checksum (len 280, errors 2133) 2017-01-16 18:03:24.864 [WARNING] tbl-base: nit: 12662.75H in Astra 19,2: invalid checksum (len 1023, errors 21) 2017-01-16 18:03:30.676 [WARNING] tbl-base: pat: 12662.75H in Astra 19,2: invalid checksum (len 124, errors 63) 2017-01-16 18:03:33.761 [WARNING] tbl-eit: eit: 12662.75H in Astra 19,2: invalid checksum (len 238, errors 2190) 2017-01-16 18:03:43.780 [WARNING] tbl-eit: eit: 12662.75H in Astra 19,2: invalid checksum (len 1761, errors 2252) 2017-01-16 18:03:47.467 [WARNING] tbl-base: nit: 12662.75H in Astra 19,2: invalid checksum (len 1012, errors 22) 2017-01-16 18:03:50.685 [WARNING] tbl-base: cat: 12662.75H in Astra 19,2: invalid checksum (len 48, errors 17) 2017-01-16 18:03:54.188 [WARNING] tbl-eit: eit: 12662.75H in Astra 19,2: invalid checksum (len 262, errors 2310) 2017-01-16 18:04:01.596 [WARNING] tbl-base: cat: 12662.75H in Astra 19,2: invalid checksum (len 48, errors 18) 2017-01-16 18:04:04.288 [WARNING] tbl-eit: eit: 12662.75H in Astra 19,2: invalid checksum (len 58, errors 2357) 2017-01-16 18:04:13.679 [WARNING] tbl-base: pat: 12662.75H in Astra 19,2: invalid checksum (len 55, errors 67) 2017-01-16 18:04:14.704 [WARNING] tbl-eit: eit: 12662.75H in Astra 19,2: invalid checksum (len 354, errors 2410) 2017-01-16 18:04:16.743 [WARNING] tbl-base: cat: 12662.75H in Astra 19,2: invalid checksum (len 48, errors 20) 2017-01-16 18:04:24.619 [WARNING] tbl-eit: eit: 12662.75H in Astra 19,2: invalid checksum (len 2244, errors 2460) 2017-01-16 18:04:25.719 [WARNING] tbl-base: nit: 12662.75H in Astra 19,2: invalid checksum (len 1023, errors 24) 2017-01-16 18:04:27.331 [WARNING] tbl-base: pat: 12662.75H in Astra 19,2: invalid checksum (len 124, errors 69) 2017-01-16 18:04:34.678 [WARNING] tbl-eit: eit: 12662.75H in Astra 19,2: invalid checksum (len 2877, errors 2519) 2017-01-16 18:04:38.768 [WARNING] tbl-base: pat: 12662.75H in Astra 19,2: invalid checksum (len 124, errors 71) 2017-01-16 18:04:40.897 [WARNING] tbl-base: cat: 12662.75H in Astra 19,2: invalid checksum (len 48, errors 21) 2017-01-16 18:04:45.118 [WARNING] tbl-eit: eit: 12662.75H in Astra 19,2: invalid checksum (len 2966, errors 2579) 2017-01-16 18:04:54.593 [WARNING] tbl-base: pat: 12662.75H in Astra 19,2: invalid checksum (len 20, errors 74) 2017-01-16 18:04:55.045 [WARNING] tbl-eit: eit: 12662.75H in Astra 19,2: invalid checksum (len 113, errors 2623) 2017-01-16 18:05:01.351 [WARNING] tbl-base: cat: 12662.75H in Astra 19,2: invalid checksum (len 48, errors 22) 2017-01-16 18:05:06.127 [WARNING] tbl-eit: eit: 12662.75H in Astra 19,2: invalid checksum (len 521, errors 2681) 2017-01-16 18:05:08.202 [WARNING] tbl-base: pat: 12662.75H in Astra 19,2: invalid checksum (len 74, errors 77) 2017-01-16 18:05:14.524 [WARNING] tbl-base: cat: 12662.75H in Astra 19,2: invalid checksum (len 3, errors 23) 2017-01-16 18:05:16.062 [WARNING] tbl-eit: eit: 12662.75H in Astra 19,2: invalid checksum (len 1185, errors 2723) 2017-01-16 18:05:26.467 [WARNING] tbl-eit: eit: 12662.75H in Astra 19,2: invalid checksum (len 3361, errors 2761) 2017-01-16 18:05:33.359 [WARNING] tbl-base: pat: 12662.75H in Astra 19,2: invalid checksum (len 157, errors 78) 2017-01-16 18:05:34.874 [WARNING] tbl-base: nit: 12662.75H in Astra 19,2: invalid checksum (len 1023, errors 25) 2017-01-16 18:05:36.572 [WARNING] tbl-eit: eit: 12662.75H in Astra 19,2: invalid checksum (len 57, errors 2808) 2017-01-16 18:05:46.989 [WARNING] tbl-eit: eit: 12662.75H in Astra 19,2: invalid checksum (len 1600, errors 2862) 2017-01-16 18:05:49.591 [WARNING] tbl-base: pat: 12662.75H in Astra 19,2: invalid checksum (len 124, errors 81) 2017-01-16 18:05:52.255 [WARNING] tbl-base: nit: 12662.75H in Astra 19,2: invalid checksum (len 1023, errors 27) 2017-01-16 18:05:57.455 [WARNING] tbl-eit: eit: 12662.75H in Astra 19,2: invalid checksum (len 656, errors 2920) 2017-01-16 18:06:07.405 [WARNING] tbl-eit: eit: 12662.75H in Astra 19,2: invalid checksum (len 292, errors 2980) 2017-01-16 18:06:09.772 [WARNING] epggrab: EIT: DVB Grabber - data completion timeout for 12662.75H in Astra 19,2 2017-01-16 18:06:09.772 [ INFO] subscription: 007B: "epggrab" unsubscribing 2017-01-16 18:06:10.773 [ INFO] mpegts: 10773.25H in Astra 19,2 - tuning on TechnoTrend S2-4600 2017-01-16 18:06:10.791 [ INFO] subscription: 0080: "epggrab" subscribing to mux "10773.25H", weight: 4, adapter: "TechnoTrend S2-4600", network: "Astra 19,2", service: "Raw PID Subscription" 2017-01-16 18:06:23.523 [WARNING] linuxdvb: TechnoTrend S2-4600 - retune 2017-01-16 18:06:34.432 [ INFO] subscription: 0080: "epggrab" unsubscribing 2017-01-16 18:06:35.424 [ INFO] mpegts: 10891.25H in Astra 19,2 - tuning on TechnoTrend S2-4600 2017-01-16 18:06:35.444 [ INFO] subscription: 0082: "epggrab" subscribing to mux "10891.25H", weight: 4, adapter: "TechnoTrend S2-4600", network: "Astra 19,2", service: "Raw PID Subscription" 2017-01-16 18:07:03.680 [ INFO] subscription: 0082: "epggrab" unsubscribing 2017-01-16 18:07:04.651 [ INFO] mpegts: 10920.75H in Astra 19,2 - tuning on TechnoTrend S2-4600 2017-01-16 18:07:04.671 [ INFO] subscription: 0084: "epggrab" subscribing to mux "10920.75H", weight: 4, adapter: "TechnoTrend S2-4600", network: "Astra 19,2", service: "Raw PID Subscription" 2017-01-16 18:07:05.262 [WARNING] tbl-eit: eit: 10920.75H in Astra 19,2: invalid checksum (len 673, errors 1) 2017-01-16 18:07:15.409 [ INFO] subscription: 0084: "epggrab" unsubscribing 2017-01-16 18:07:16.362 [ INFO] mpegts: 11052.75H in Astra 19,2 - tuning on TechnoTrend S2-4600 2017-01-16 18:07:16.381 [ INFO] subscription: 0086: "epggrab" subscribing to mux "11052.75H", weight: 4, adapter: "TechnoTrend S2-4600", network: "Astra 19,2", service: "Raw PID Subscription" 2017-01-16 18:07:43.602 [ INFO] subscription: 0086: "epggrab" unsubscribing 2017-01-16 18:07:44.591 [ INFO] mpegts: 11243.75H in Astra 19,2 - tuning on TechnoTrend S2-4600 2017-01-16 18:07:44.611 [ INFO] subscription: 0088: "epggrab" subscribing to mux "11243.75H", weight: 4, adapter: "TechnoTrend S2-4600", network: "Astra 19,2", service: "Raw PID Subscription" 2017-01-16 18:08:11.120 [ INFO] subscription: 0088: "epggrab" unsubscribing 2017-01-16 18:08:12.117 [ INFO] mpegts: 11273.25H in Astra 19,2 - tuning on TechnoTrend S2-4600 2017-01-16 18:08:12.136 [ INFO] subscription: 008A: "epggrab" subscribing to mux "11273.25H", weight: 4, adapter: "TechnoTrend S2-4600", network: "Astra 19,2", service: "Raw PID Subscription" 2017-01-16 18:08:47.327 [ INFO] subscription: 008A: "epggrab" unsubscribing 2017-01-16 18:08:48.248 [ INFO] mpegts: 11302.75H in Astra 19,2 - tuning on TechnoTrend S2-4600 2017-01-16 18:08:48.267 [ INFO] subscription: 008C: "epggrab" subscribing to mux "11302.75H", weight: 4, adapter: "TechnoTrend S2-4600", network: "Astra 19,2", service: "Raw PID Subscription" 2017-01-16 18:09:39.604 [ INFO] subscription: 008C: "epggrab" unsubscribing 2017-01-16 18:09:40.595 [ INFO] mpegts: 11361.75H in Astra 19,2 - tuning on TechnoTrend S2-4600 2017-01-16 18:09:40.614 [ INFO] subscription: 008E: "epggrab" subscribing to mux "11361.75H", weight: 4, adapter: "TechnoTrend S2-4600", network: "Astra 19,2", service: "Raw PID Subscription" 2017-01-16 18:09:54.536 [ INFO] subscription: 008E: "epggrab" unsubscribing 2017-01-16 18:09:55.528 [ INFO] mpegts: 11420.75H in Astra 19,2 - tuning on TechnoTrend S2-4600 2017-01-16 18:09:55.547 [ INFO] subscription: 0090: "epggrab" subscribing to mux "11420.75H", weight: 4, adapter: "TechnoTrend S2-4600", network: "Astra 19,2", service: "Raw PID Subscription" 2017-01-16 18:10:05.974 [ INFO] subscription: 0090: "epggrab" unsubscribing 2017-01-16 18:10:06.960 [ INFO] mpegts: 11493.75H in Astra 19,2 - tuning on TechnoTrend S2-4600 2017-01-16 18:10:06.979 [ INFO] subscription: 0092: "epggrab" subscribing to mux "11493.75H", weight: 4, adapter: "TechnoTrend S2-4600", network: "Astra 19,2", service: "Raw PID Subscription" 2017-01-16 18:10:33.687 [ INFO] subscription: 0092: "epggrab" unsubscribing 2017-01-16 18:10:34.641 [ INFO] mpegts: 11582.25H in Astra 19,2 - tuning on TechnoTrend S2-4600 2017-01-16 18:10:34.660 [ INFO] subscription: 0094: "epggrab" subscribing to mux "11582.25H", weight: 4, adapter: "TechnoTrend S2-4600", network: "Astra 19,2", service: "Raw PID Subscription" 2017-01-16 18:11:02.300 [ INFO] subscription: 0094: "epggrab" unsubscribing 2017-01-16 18:11:03.267 [ INFO] mpegts: 11670.75H in Astra 19,2 - tuning on TechnoTrend S2-4600 2017-01-16 18:11:03.287 [ INFO] subscription: 0096: "epggrab" subscribing to mux "11670.75H", weight: 4, adapter: "TechnoTrend S2-4600", network: "Astra 19,2", service: "Raw PID Subscription" 2017-01-16 18:11:13.923 [ INFO] subscription: 0096: "epggrab" unsubscribing 2017-01-16 18:11:14.876 [ INFO] mpegts: 12148.5H in Astra 19,2 - tuning on TechnoTrend S2-4600 2017-01-16 18:11:14.917 [ INFO] subscription: 0098: "epggrab" subscribing to mux "12148.5H", weight: 4, adapter: "TechnoTrend S2-4600", network: "Astra 19,2", service: "Raw PID Subscription" 2017-01-16 18:11:25.315 [ INFO] subscription: 0098: "epggrab" unsubscribing 2017-01-16 18:11:26.285 [ INFO] mpegts: 12187.5H in Astra 19,2 - tuning on TechnoTrend S2-4600 2017-01-16 18:11:26.326 [ INFO] subscription: 009A: "epggrab" subscribing to mux "12187.5H", weight: 4, adapter: "TechnoTrend S2-4600", network: "Astra 19,2", service: "Raw PID Subscription" 2017-01-16 18:11:42.468 [ INFO] subscription: 009A: "epggrab" unsubscribing 2017-01-16 18:11:43.399 [ INFO] mpegts: 12226.5H in Astra 19,2 - tuning on TechnoTrend S2-4600 2017-01-16 18:11:43.440 [ INFO] subscription: 009C: "epggrab" subscribing to mux "12226.5H", weight: 4, adapter: "TechnoTrend S2-4600", network: "Astra 19,2", service: "Raw PID Subscription" 2017-01-16 18:11:57.227 [ INFO] subscription: 009C: "epggrab" unsubscribing 2017-01-16 18:11:58.211 [ INFO] mpegts: 12265.5H in Astra 19,2 - tuning on TechnoTrend S2-4600 2017-01-16 18:11:58.252 [ INFO] subscription: 009E: "epggrab" subscribing to mux "12265.5H", weight: 4, adapter: "TechnoTrend S2-4600", network: "Astra 19,2", service: "Raw PID Subscription" 2017-01-16 18:12:25.877 [ INFO] subscription: 009E: "epggrab" unsubscribing 2017-01-16 18:12:26.837 [ INFO] mpegts: 12304.5H in Astra 19,2 - tuning on TechnoTrend S2-4600 2017-01-16 18:12:26.879 [ INFO] subscription: 00A0: "epggrab" subscribing to mux "12304.5H", weight: 4, adapter: "TechnoTrend S2-4600", network: "Astra 19,2", service: "Raw PID Subscription" 2017-01-16 18:12:37.421 [ INFO] subscription: 00A0: "epggrab" unsubscribing 2017-01-16 18:12:38.348 [ INFO] mpegts: 12421.5H in Astra 19,2 - tuning on TechnoTrend S2-4600 2017-01-16 18:12:38.390 [ INFO] subscription: 00A2: "epggrab" subscribing to mux "12421.5H", weight: 4, adapter: "TechnoTrend S2-4600", network: "Astra 19,2", service: "Raw PID Subscription" 2017-01-16 18:12:38.885 [WARNING] tbl-eit: eit: 12421.5H in Astra 19,2: invalid checksum (len 371, errors 1) 2017-01-16 18:13:08.101 [ INFO] subscription: 00A2: "epggrab" unsubscribing 2017-01-16 18:13:09.075 [ INFO] mpegts: 12460.5H in Astra 19,2 - tuning on TechnoTrend S2-4600 2017-01-16 18:13:09.116 [ INFO] subscription: 00A4: "epggrab" subscribing to mux "12460.5H", weight: 4, adapter: "TechnoTrend S2-4600", network: "Astra 19,2", service: "Raw PID Subscription" 2017-01-16 18:13:19.488 [ INFO] subscription: 00A4: "epggrab" unsubscribing 2017-01-16 18:13:20.486 [ INFO] mpegts: 12692.25H in Astra 19,2 - tuning on TechnoTrend S2-4600 2017-01-16 18:13:20.526 [ INFO] subscription: 00A6: "epggrab" subscribing to mux "12692.25H", weight: 4, adapter: "TechnoTrend S2-4600", network: "Astra 19,2", service: "Raw PID Subscription" 2017-01-16 18:13:52.921 [ INFO] subscription: 00A6: "epggrab" unsubscribing 2017-01-16 18:13:53.918 [ INFO] mpegts: 11347V in Astra 19,2 - tuning on TechnoTrend S2-4600 2017-01-16 18:13:53.937 [ INFO] subscription: 00A8: "epggrab" subscribing to mux "11347V", weight: 4, adapter: "TechnoTrend S2-4600", network: "Astra 19,2", service: "Raw PID Subscription" 2017-01-16 18:14:03.088 [ INFO] subscription: 00A8: "epggrab" unsubscribing 2017-01-16 18:14:04.026 [ INFO] mpegts: 12051V in Astra 19,2 - tuning on TechnoTrend S2-4600 2017-01-16 18:14:04.068 [ INFO] subscription: 00AA: "epggrab" subscribing to mux "12051V", weight: 4, adapter: "TechnoTrend S2-4600", network: "Astra 19,2", service: "Raw PID Subscription" 2017-01-16 18:14:14.613 [ INFO] subscription: 00AA: "epggrab" unsubscribing 2017-01-16 18:14:15.536 [ INFO] mpegts: 12480V in Astra 19,2 - tuning on TechnoTrend S2-4600 2017-01-16 18:14:15.576 [ INFO] subscription: 00AC: "epggrab" subscribing to mux "12480V", weight: 4, adapter: "TechnoTrend S2-4600", network: "Astra 19,2", service: "Raw PID Subscription" 2017-01-16 18:14:26.080 [ INFO] subscription: 00AC: "epggrab" unsubscribing [-- Attachment #3: service0.log --] [-- Type: application/octet-stream, Size: 73102 bytes --] 2017-01-15 08:23:58.096 [ INFO] main: Log started 2017-01-15 08:23:58.103 [ INFO] http: Starting HTTP server 0.0.0.0:9981 2017-01-15 08:23:58.104 [ INFO] htsp: Starting HTSP server 0.0.0.0:9982 2017-01-15 08:23:58.104 [ ERROR] satips: use --satip_bindaddr parameter to select the local IP for SAT>IP 2017-01-15 08:23:58.104 [ ERROR] satips: using Google lookup (might block the task until timeout) 2017-01-15 08:23:58.143 [ INFO] config: loaded 2017-01-15 08:23:58.147 [ INFO] config: scanfile (re)initialization with path <none> 2017-01-15 08:23:59.570 [ INFO] scanfile: DVB-S - loaded 1 regions with 112 networks 2017-01-15 08:23:59.570 [ INFO] scanfile: DVB-T - loaded 43 regions with 1106 networks 2017-01-15 08:23:59.570 [ INFO] scanfile: DVB-C - loaded 17 regions with 56 networks 2017-01-15 08:23:59.571 [ INFO] scanfile: ATSC-T - loaded 2 regions with 9 networks 2017-01-15 08:23:59.571 [ INFO] scanfile: ATSC-C - loaded 1 regions with 5 networks 2017-01-15 08:23:59.571 [ INFO] scanfile: ISDB-T - loaded 2 regions with 1297 networks 2017-01-15 08:24:00.160 [ INFO] linuxdvb: adapter added /dev/dvb/adapter0 2017-01-15 08:24:00.242 [ INFO] dvr: Creating new configuration '' 2017-01-15 08:24:00.242 [ INFO] dvr: Creating new configuration '' 2017-01-15 08:24:00.242 [ ERROR] dvr: Unable to create second default config, removing 2017-01-15 08:24:00.248 [ INFO] capmt: Oscam active 2017-01-15 08:24:00.248 [ INFO] descrambler: adding CAID 2600 as constant crypto-word (BISS) 2017-01-15 08:24:00.248 [ INFO] epggrab: module eit created 2017-01-15 08:24:00.248 [ INFO] epggrab: module uk_freesat created 2017-01-15 08:24:00.248 [ INFO] epggrab: module uk_freeview created 2017-01-15 08:24:00.248 [ INFO] epggrab: module viasat_baltic created 2017-01-15 08:24:00.249 [ INFO] epggrab: module Bulsatcom_39E created 2017-01-15 08:24:00.249 [ INFO] epggrab: module psip created 2017-01-15 08:24:00.249 [ ERROR] capmt: Oscam: Cannot connect to 127.0.0.1:9000 (Connection refused); Do you have OSCam running? 2017-01-15 08:24:00.249 [ INFO] capmt: Oscam: Automatic reconnection attempt in in 60 seconds 2017-01-15 08:24:00.262 [ INFO] epggrab: module opentv-ausat created 2017-01-15 08:24:00.262 [ INFO] epggrab: module opentv-skyuk created 2017-01-15 08:24:00.262 [ INFO] epggrab: module opentv-skyit created 2017-01-15 08:24:00.264 [ INFO] epggrab: module opentv-skynz created 2017-01-15 08:24:00.265 [ INFO] epggrab: module pyepg created 2017-01-15 08:24:00.265 [ INFO] epggrab: module xmltv created 2017-01-15 08:24:00.270 [ INFO] spawn: Executing "/storage/.kodi/addons/service.tvheadend42/bin/tv_grab_file" 2017-01-15 08:24:00.275 [ INFO] epggrab: module /storage/.kodi/addons/service.tvheadend42/bin/tv_grab_file created 2017-01-15 08:24:00.412 [ INFO] epgdb: gzip format detected, inflating (ratio 17.4% deflated size 3031228) 2017-01-15 08:24:00.635 [ INFO] epgdb: parsing 17432913 bytes 2017-01-15 08:24:01.774 [ INFO] epgdb: loaded v2 2017-01-15 08:24:01.774 [ INFO] epgdb: config 1 2017-01-15 08:24:01.774 [ INFO] epgdb: brands 0 2017-01-15 08:24:01.774 [ INFO] epgdb: seasons 0 2017-01-15 08:24:01.774 [ INFO] epgdb: episodes 24363 2017-01-15 08:24:01.774 [ INFO] epgdb: broadcasts 23301 2017-01-15 08:24:01.809 [ NOTICE] START: HTS Tvheadend version 4.1.2401 ~ LibreELEC Tvh-addon v8.1.108-#0110-milhouse-v4.1-2413-g489ba95 started, running as PID:418 UID:0 GID:39, CWD:/ CNF:/storage/.kodi/userdata/addon_data/service.tvheadend42 2017-01-15 08:24:01.814 [ INFO] mpegts: 10773.25H in Astra 19,2 - tuning on TechnoTrend S2-4600 2017-01-15 08:24:01.852 [ INFO] subscription: 0001: "epggrab" subscribing to mux "10773.25H", weight: 4, adapter: "TechnoTrend S2-4600", network: "Astra 19,2", service: "Raw PID Subscription" 2017-01-15 08:24:03.723 [ INFO] htsp: Got connection from 127.0.0.1 2017-01-15 08:24:03.725 [ INFO] htsp: 127.0.0.1: Welcomed client software: Kodi Media Center (HTSPv25) 2017-01-15 08:24:03.728 [ INFO] htsp: 127.0.0.1 [ Kodi Media Center ]: Identified as user '' 2017-01-15 08:24:12.542 [ INFO] subscription: 0001: "epggrab" unsubscribing 2017-01-15 08:24:13.460 [ INFO] mpegts: 10891.25H in Astra 19,2 - tuning on TechnoTrend S2-4600 2017-01-15 08:24:13.479 [ INFO] subscription: 0003: "epggrab" subscribing to mux "10891.25H", weight: 4, adapter: "TechnoTrend S2-4600", network: "Astra 19,2", service: "Raw PID Subscription" 2017-01-15 08:24:14.157 [WARNING] tbl-eit: eit: 10891.25H in Astra 19,2: invalid checksum (len 3328, errors 1) 2017-01-15 08:24:14.271 [WARNING] tbl-base: pat: 10891.25H in Astra 19,2: invalid checksum (len 40, errors 1) 2017-01-15 08:24:22.565 [WARNING] tbl-base: nit: 10891.25H in Astra 19,2: invalid checksum (len 1012, errors 1) 2017-01-15 08:24:24.112 [WARNING] tbl-eit: eit: 10891.25H in Astra 19,2: invalid checksum (len 2723, errors 207) 2017-01-15 08:24:25.276 [WARNING] tbl-base: bat: 10891.25H in Astra 19,2: invalid checksum (len 407, errors 1) 2017-01-15 08:24:25.276 [WARNING] tbl-base: sdt: 10891.25H in Astra 19,2: invalid checksum (len 407, errors 1) 2017-01-15 08:24:25.982 [WARNING] tbl-base: pat: 10891.25H in Astra 19,2: invalid checksum (len 40, errors 3) 2017-01-15 08:24:34.091 [WARNING] tbl-eit: eit: 10891.25H in Astra 19,2: invalid checksum (len 2234, errors 405) 2017-01-15 08:24:39.377 [WARNING] tbl-base: pat: 10891.25H in Astra 19,2: invalid checksum (len 40, errors 6) 2017-01-15 08:24:39.930 [WARNING] tbl-base: nit: 10891.25H in Astra 19,2: invalid checksum (len 1012, errors 3) 2017-01-15 08:24:40.507 [WARNING] tbl-base: bat: 10891.25H in Astra 19,2: invalid checksum (len 984, errors 9) 2017-01-15 08:24:40.507 [WARNING] tbl-base: sdt: 10891.25H in Astra 19,2: invalid checksum (len 984, errors 9) 2017-01-15 08:24:41.270 [WARNING] tbl-base: cat: 10891.25H in Astra 19,2: invalid checksum (len 12, errors 1) 2017-01-15 08:24:44.139 [WARNING] tbl-eit: eit: 10891.25H in Astra 19,2: invalid checksum (len 3766, errors 624) 2017-01-15 08:24:51.495 [WARNING] tbl-base: nit: 10891.25H in Astra 19,2: invalid checksum (len 1023, errors 4) 2017-01-15 08:24:51.949 [WARNING] tbl-base: pat: 10891.25H in Astra 19,2: invalid checksum (len 40, errors 8) 2017-01-15 08:24:54.197 [WARNING] tbl-eit: eit: 10891.25H in Astra 19,2: invalid checksum (len 3474, errors 832) 2017-01-15 08:24:58.974 [WARNING] tbl-base: bat: 10891.25H in Astra 19,2: invalid checksum (len 173, errors 11) 2017-01-15 08:24:58.974 [WARNING] tbl-base: sdt: 10891.25H in Astra 19,2: invalid checksum (len 173, errors 11) 2017-01-15 08:25:00.250 [ INFO] capmt: Oscam: mode 5 connected to 127.0.0.1:9000 (single) 2017-01-15 08:25:00.251 [ INFO] capmt: Oscam: Connected to server 'OSCam v1.20-unstable_svn, build r (armv7ve-libreelec-linux-gnueabi)' (protocol version 2) 2017-01-15 08:25:02.079 [WARNING] tbl-base: pat: 10891.25H in Astra 19,2: invalid checksum (len 40, errors 12) 2017-01-15 08:25:03.307 [WARNING] tbl-base: cat: 10891.25H in Astra 19,2: invalid checksum (len 12, errors 2) 2017-01-15 08:25:04.295 [WARNING] tbl-eit: eit: 10891.25H in Astra 19,2: invalid checksum (len 757, errors 1047) 2017-01-15 08:25:13.391 [WARNING] tbl-base: pat: 10891.25H in Astra 19,2: invalid checksum (len 40, errors 16) 2017-01-15 08:25:14.235 [WARNING] tbl-eit: eit: 10891.25H in Astra 19,2: invalid checksum (len 548, errors 1254) 2017-01-15 08:25:14.586 [WARNING] tbl-base: nit: 10891.25H in Astra 19,2: invalid checksum (len 1012, errors 6) 2017-01-15 08:25:15.907 [WARNING] tbl-base: bat: 10891.25H in Astra 19,2: invalid checksum (len 108, errors 13) 2017-01-15 08:25:15.907 [WARNING] tbl-base: sdt: 10891.25H in Astra 19,2: invalid checksum (len 108, errors 13) 2017-01-15 08:25:22.438 [WARNING] tbl-base: cat: 10891.25H in Astra 19,2: invalid checksum (len 12, errors 3) 2017-01-15 08:25:24.316 [WARNING] tbl-eit: eit: 10891.25H in Astra 19,2: invalid checksum (len 3979, errors 1469) 2017-01-15 08:25:24.316 [WARNING] tbl-base: pat: 10891.25H in Astra 19,2: invalid checksum (len 40, errors 17) 2017-01-15 08:25:27.421 [WARNING] tbl-base: nit: 10891.25H in Astra 19,2: invalid checksum (len 111, errors 8) 2017-01-15 08:25:28.659 [WARNING] tbl-base: bat: 10891.25H in Astra 19,2: invalid checksum (len 185, errors 17) 2017-01-15 08:25:28.659 [WARNING] tbl-base: sdt: 10891.25H in Astra 19,2: invalid checksum (len 185, errors 17) 2017-01-15 08:25:34.280 [WARNING] tbl-eit: eit: 10891.25H in Astra 19,2: invalid checksum (len 1386, errors 1679) 2017-01-15 08:25:36.937 [WARNING] tbl-base: pat: 10891.25H in Astra 19,2: invalid checksum (len 40, errors 26) 2017-01-15 08:25:38.192 [WARNING] tbl-base: cat: 10891.25H in Astra 19,2: invalid checksum (len 12, errors 4) 2017-01-15 08:25:44.132 [WARNING] tbl-base: bat: 10891.25H in Astra 19,2: invalid checksum (len 185, errors 18) 2017-01-15 08:25:44.132 [WARNING] tbl-base: sdt: 10891.25H in Astra 19,2: invalid checksum (len 185, errors 18) 2017-01-15 08:25:44.252 [WARNING] tbl-eit: eit: 10891.25H in Astra 19,2: invalid checksum (len 76, errors 1867) 2017-01-15 08:25:51.515 [WARNING] tbl-base: pat: 10891.25H in Astra 19,2: invalid checksum (len 40, errors 27) 2017-01-15 08:25:52.168 [WARNING] tbl-base: nit: 10891.25H in Astra 19,2: invalid checksum (len 1023, errors 9) 2017-01-15 08:25:54.302 [WARNING] tbl-eit: eit: 10891.25H in Astra 19,2: invalid checksum (len 1839, errors 2068) 2017-01-15 08:25:58.487 [WARNING] tbl-base: bat: 10891.25H in Astra 19,2: invalid checksum (len 984, errors 20) 2017-01-15 08:25:58.487 [WARNING] tbl-base: sdt: 10891.25H in Astra 19,2: invalid checksum (len 984, errors 20) 2017-01-15 08:26:02.709 [WARNING] tbl-base: pat: 10891.25H in Astra 19,2: invalid checksum (len 40, errors 30) 2017-01-15 08:26:04.281 [WARNING] tbl-eit: eit: 10891.25H in Astra 19,2: invalid checksum (len 1227, errors 2273) 2017-01-15 08:26:05.380 [WARNING] tbl-base: cat: 10891.25H in Astra 19,2: invalid checksum (len 12, errors 5) 2017-01-15 08:26:13.055 [WARNING] tbl-base: bat: 10891.25H in Astra 19,2: invalid checksum (len 265, errors 23) 2017-01-15 08:26:13.055 [WARNING] tbl-base: sdt: 10891.25H in Astra 19,2: invalid checksum (len 265, errors 23) 2017-01-15 08:26:13.858 [WARNING] tbl-base: pat: 10891.25H in Astra 19,2: invalid checksum (len 40, errors 34) 2017-01-15 08:26:14.330 [WARNING] tbl-eit: eit: 10891.25H in Astra 19,2: invalid checksum (len 639, errors 2465) 2017-01-15 08:26:24.334 [WARNING] tbl-eit: eit: 10891.25H in Astra 19,2: invalid checksum (len 3848, errors 2661) 2017-01-15 08:26:26.090 [WARNING] tbl-base: bat: 10891.25H in Astra 19,2: invalid checksum (len 217, errors 26) 2017-01-15 08:26:26.090 [WARNING] tbl-base: sdt: 10891.25H in Astra 19,2: invalid checksum (len 217, errors 26) 2017-01-15 08:26:29.285 [WARNING] tbl-base: pat: 10891.25H in Astra 19,2: invalid checksum (len 40, errors 37) 2017-01-15 08:26:34.365 [WARNING] tbl-eit: eit: 10891.25H in Astra 19,2: invalid checksum (len 842, errors 2859) 2017-01-15 08:26:41.325 [WARNING] tbl-base: nit: 10891.25H in Astra 19,2: invalid checksum (len 1012, errors 10) 2017-01-15 08:26:44.304 [WARNING] tbl-eit: eit: 10891.25H in Astra 19,2: invalid checksum (len 1644, errors 3039) 2017-01-15 08:26:46.408 [WARNING] tbl-base: pat: 10891.25H in Astra 19,2: invalid checksum (len 40, errors 41) 2017-01-15 08:26:46.633 [WARNING] tbl-base: bat: 10891.25H in Astra 19,2: invalid checksum (len 185, errors 31) 2017-01-15 08:26:46.633 [WARNING] tbl-base: sdt: 10891.25H in Astra 19,2: invalid checksum (len 185, errors 31) 2017-01-15 08:26:54.517 [WARNING] tbl-eit: eit: 10891.25H in Astra 19,2: invalid checksum (len 477, errors 3240) 2017-01-15 08:26:56.618 [WARNING] tbl-base: pat: 10891.25H in Astra 19,2: invalid checksum (len 40, errors 44) 2017-01-15 08:26:58.036 [WARNING] tbl-base: bat: 10891.25H in Astra 19,2: invalid checksum (len 1006, errors 34) 2017-01-15 08:26:58.036 [WARNING] tbl-base: sdt: 10891.25H in Astra 19,2: invalid checksum (len 1006, errors 34) 2017-01-15 08:27:04.335 [WARNING] tbl-base: cat: 10891.25H in Astra 19,2: invalid checksum (len 12, errors 6) 2017-01-15 08:27:04.562 [WARNING] tbl-eit: eit: 10891.25H in Astra 19,2: invalid checksum (len 740, errors 3432) 2017-01-15 08:27:09.000 [WARNING] tbl-base: bat: 10891.25H in Astra 19,2: invalid checksum (len 173, errors 38) 2017-01-15 08:27:09.000 [WARNING] tbl-base: sdt: 10891.25H in Astra 19,2: invalid checksum (len 173, errors 38) 2017-01-15 08:27:11.155 [WARNING] tbl-base: pat: 10891.25H in Astra 19,2: invalid checksum (len 40, errors 48) 2017-01-15 08:27:14.563 [WARNING] tbl-eit: eit: 10891.25H in Astra 19,2: invalid checksum (len 843, errors 3627) 2017-01-15 08:27:24.609 [WARNING] tbl-eit: eit: 10891.25H in Astra 19,2: invalid checksum (len 702, errors 3820) 2017-01-15 08:27:24.941 [WARNING] tbl-base: bat: 10891.25H in Astra 19,2: invalid checksum (len 185, errors 43) 2017-01-15 08:27:24.941 [WARNING] tbl-base: sdt: 10891.25H in Astra 19,2: invalid checksum (len 185, errors 43) 2017-01-15 08:27:26.359 [WARNING] tbl-base: pat: 10891.25H in Astra 19,2: invalid checksum (len 40, errors 51) 2017-01-15 08:27:26.467 [WARNING] tbl-base: cat: 10891.25H in Astra 19,2: invalid checksum (len 12, errors 7) 2017-01-15 08:27:27.148 [WARNING] tbl-base: nit: 10891.25H in Astra 19,2: invalid checksum (len 1023, errors 12) 2017-01-15 08:27:34.575 [WARNING] tbl-eit: eit: 10891.25H in Astra 19,2: invalid checksum (len 795, errors 4025) 2017-01-15 08:27:35.574 [WARNING] tbl-base: bat: 10891.25H in Astra 19,2: invalid checksum (len 185, errors 47) 2017-01-15 08:27:35.574 [WARNING] tbl-base: sdt: 10891.25H in Astra 19,2: invalid checksum (len 185, errors 47) 2017-01-15 08:27:37.686 [WARNING] tbl-base: pat: 10891.25H in Astra 19,2: invalid checksum (len 40, errors 52) 2017-01-15 08:27:42.077 [WARNING] tbl-base: nit: 10891.25H in Astra 19,2: invalid checksum (len 1012, errors 13) 2017-01-15 08:27:44.621 [WARNING] tbl-eit: eit: 10891.25H in Astra 19,2: invalid checksum (len 1342, errors 4231) 2017-01-15 08:27:47.278 [WARNING] tbl-base: bat: 10891.25H in Astra 19,2: invalid checksum (len 185, errors 50) 2017-01-15 08:27:47.278 [WARNING] tbl-base: sdt: 10891.25H in Astra 19,2: invalid checksum (len 185, errors 50) 2017-01-15 08:27:49.952 [WARNING] tbl-base: pat: 10891.25H in Astra 19,2: invalid checksum (len 40, errors 55) 2017-01-15 08:27:54.570 [WARNING] tbl-eit: eit: 10891.25H in Astra 19,2: invalid checksum (len 643, errors 4432) 2017-01-15 08:27:59.891 [WARNING] tbl-base: bat: 10891.25H in Astra 19,2: invalid checksum (len 984, errors 53) 2017-01-15 08:27:59.891 [WARNING] tbl-base: sdt: 10891.25H in Astra 19,2: invalid checksum (len 984, errors 53) 2017-01-15 08:28:02.557 [WARNING] tbl-base: pat: 10891.25H in Astra 19,2: invalid checksum (len 40, errors 58) 2017-01-15 08:28:04.659 [WARNING] tbl-eit: eit: 10891.25H in Astra 19,2: invalid checksum (len 2620, errors 4637) 2017-01-15 08:28:07.641 [WARNING] tbl-base: cat: 10891.25H in Astra 19,2: invalid checksum (len 12, errors 8) 2017-01-15 08:28:10.621 [WARNING] tbl-base: bat: 10891.25H in Astra 19,2: invalid checksum (len 407, errors 57) 2017-01-15 08:28:10.621 [WARNING] tbl-base: sdt: 10891.25H in Astra 19,2: invalid checksum (len 407, errors 57) 2017-01-15 08:28:13.500 [WARNING] tbl-base: pat: 10891.25H in Astra 19,2: invalid checksum (len 40, errors 64) 2017-01-15 08:28:14.592 [WARNING] tbl-eit: eit: 10891.25H in Astra 19,2: invalid checksum (len 460, errors 4818) 2017-01-15 08:28:22.133 [WARNING] tbl-base: bat: 10891.25H in Astra 19,2: invalid checksum (len 112, errors 61) 2017-01-15 08:28:22.133 [WARNING] tbl-base: sdt: 10891.25H in Astra 19,2: invalid checksum (len 112, errors 61) 2017-01-15 08:28:23.409 [WARNING] tbl-base: cat: 10891.25H in Astra 19,2: invalid checksum (len 12, errors 10) 2017-01-15 08:28:24.702 [WARNING] tbl-eit: eit: 10891.25H in Astra 19,2: invalid checksum (len 1021, errors 5016) 2017-01-15 08:28:25.457 [WARNING] tbl-base: nit: 10891.25H in Astra 19,2: invalid checksum (len 1012, errors 15) 2017-01-15 08:28:34.869 [WARNING] tbl-eit: eit: 10891.25H in Astra 19,2: invalid checksum (len 643, errors 5234) 2017-01-15 08:28:35.215 [WARNING] tbl-base: pat: 10891.25H in Astra 19,2: invalid checksum (len 40, errors 66) 2017-01-15 08:28:37.506 [WARNING] tbl-base: bat: 10891.25H in Astra 19,2: invalid checksum (len 185, errors 65) 2017-01-15 08:28:37.506 [WARNING] tbl-base: sdt: 10891.25H in Astra 19,2: invalid checksum (len 185, errors 65) 2017-01-15 08:28:42.514 [WARNING] tbl-base: cat: 10891.25H in Astra 19,2: invalid checksum (len 12, errors 11) 2017-01-15 08:28:44.949 [WARNING] tbl-eit: eit: 10891.25H in Astra 19,2: invalid checksum (len 278, errors 5436) 2017-01-15 08:28:48.589 [WARNING] tbl-base: pat: 10891.25H in Astra 19,2: invalid checksum (len 40, errors 70) 2017-01-15 08:28:51.448 [WARNING] tbl-base: nit: 10891.25H in Astra 19,2: invalid checksum (len 1012, errors 18) 2017-01-15 08:28:51.902 [WARNING] tbl-base: bat: 10891.25H in Astra 19,2: invalid checksum (len 984, errors 68) 2017-01-15 08:28:51.902 [WARNING] tbl-base: sdt: 10891.25H in Astra 19,2: invalid checksum (len 984, errors 68) 2017-01-15 08:28:54.983 [WARNING] tbl-eit: eit: 10891.25H in Astra 19,2: invalid checksum (len 1114, errors 5666) 2017-01-15 08:28:59.520 [WARNING] tbl-base: pat: 10891.25H in Astra 19,2: invalid checksum (len 40, errors 74) 2017-01-15 08:29:02.215 [WARNING] tbl-base: bat: 10891.25H in Astra 19,2: invalid checksum (len 185, errors 72) 2017-01-15 08:29:02.215 [WARNING] tbl-base: sdt: 10891.25H in Astra 19,2: invalid checksum (len 185, errors 72) 2017-01-15 08:29:04.938 [WARNING] tbl-eit: eit: 10891.25H in Astra 19,2: invalid checksum (len 959, errors 5858) 2017-01-15 08:29:09.607 [WARNING] tbl-base: pat: 10891.25H in Astra 19,2: invalid checksum (len 40, errors 76) 2017-01-15 08:29:10.814 [WARNING] tbl-base: cat: 10891.25H in Astra 19,2: invalid checksum (len 12, errors 12) 2017-01-15 08:29:13.919 [WARNING] tbl-base: bat: 10891.25H in Astra 19,2: invalid checksum (len 185, errors 75) 2017-01-15 08:29:13.919 [WARNING] tbl-base: sdt: 10891.25H in Astra 19,2: invalid checksum (len 185, errors 75) 2017-01-15 08:29:15.044 [WARNING] tbl-eit: eit: 10891.25H in Astra 19,2: invalid checksum (len 3042, errors 6067) 2017-01-15 08:29:17.456 [WARNING] tbl-base: nit: 10891.25H in Astra 19,2: invalid checksum (len 1012, errors 20) 2017-01-15 08:29:20.715 [WARNING] tbl-base: pat: 10891.25H in Astra 19,2: invalid checksum (len 40, errors 77) 2017-01-15 08:29:25.097 [WARNING] tbl-eit: eit: 10891.25H in Astra 19,2: invalid checksum (len 1592, errors 6283) 2017-01-15 08:29:29.404 [WARNING] tbl-base: bat: 10891.25H in Astra 19,2: invalid checksum (len 102, errors 77) 2017-01-15 08:29:29.405 [WARNING] tbl-base: sdt: 10891.25H in Astra 19,2: invalid checksum (len 102, errors 77) 2017-01-15 08:29:33.071 [WARNING] tbl-base: pat: 10891.25H in Astra 19,2: invalid checksum (len 40, errors 80) 2017-01-15 08:29:34.845 [WARNING] tbl-base: nit: 10891.25H in Astra 19,2: invalid checksum (len 1012, errors 21) 2017-01-15 08:29:35.067 [WARNING] tbl-eit: eit: 10891.25H in Astra 19,2: invalid checksum (len 3474, errors 6503) 2017-01-15 08:29:41.688 [WARNING] tbl-base: bat: 10891.25H in Astra 19,2: invalid checksum (len 988, errors 80) 2017-01-15 08:29:41.690 [WARNING] tbl-base: sdt: 10891.25H in Astra 19,2: invalid checksum (len 988, errors 80) 2017-01-15 08:29:44.777 [WARNING] tbl-base: pat: 10891.25H in Astra 19,2: invalid checksum (len 40, errors 84) 2017-01-15 08:29:45.120 [WARNING] tbl-eit: eit: 10891.25H in Astra 19,2: invalid checksum (len 924, errors 6727) 2017-01-15 08:29:52.552 [WARNING] tbl-base: bat: 10891.25H in Astra 19,2: invalid checksum (len 984, errors 85) 2017-01-15 08:29:52.552 [WARNING] tbl-base: sdt: 10891.25H in Astra 19,2: invalid checksum (len 984, errors 85) 2017-01-15 08:29:55.094 [WARNING] tbl-eit: eit: 10891.25H in Astra 19,2: invalid checksum (len 643, errors 6965) 2017-01-15 08:29:55.881 [WARNING] tbl-base: pat: 10891.25H in Astra 19,2: invalid checksum (len 40, errors 86) 2017-01-15 08:30:03.717 [WARNING] tbl-base: nit: 10891.25H in Astra 19,2: invalid checksum (len 1023, errors 23) 2017-01-15 08:30:05.167 [WARNING] tbl-eit: eit: 10891.25H in Astra 19,2: invalid checksum (len 868, errors 7195) 2017-01-15 08:30:09.792 [WARNING] tbl-base: bat: 10891.25H in Astra 19,2: invalid checksum (len 984, errors 88) 2017-01-15 08:30:09.792 [WARNING] tbl-base: sdt: 10891.25H in Astra 19,2: invalid checksum (len 984, errors 88) 2017-01-15 08:30:10.475 [WARNING] tbl-base: pat: 10891.25H in Astra 19,2: invalid checksum (len 40, errors 93) 2017-01-15 08:30:15.179 [WARNING] tbl-eit: eit: 10891.25H in Astra 19,2: invalid checksum (len 475, errors 7428) 2017-01-15 08:30:18.201 [WARNING] tbl-base: nit: 10891.25H in Astra 19,2: invalid checksum (len 1012, errors 24) 2017-01-15 08:30:20.233 [WARNING] tbl-base: bat: 10891.25H in Astra 19,2: invalid checksum (len 185, errors 90) 2017-01-15 08:30:20.235 [WARNING] tbl-base: sdt: 10891.25H in Astra 19,2: invalid checksum (len 185, errors 90) 2017-01-15 08:30:24.215 [WARNING] tbl-base: pat: 10891.25H in Astra 19,2: invalid checksum (len 40, errors 95) 2017-01-15 08:30:25.177 [WARNING] tbl-eit: eit: 10891.25H in Astra 19,2: invalid checksum (len 834, errors 7645) 2017-01-15 08:30:30.737 [WARNING] tbl-base: cat: 10891.25H in Astra 19,2: invalid checksum (len 12, errors 13) 2017-01-15 08:30:31.925 [WARNING] tbl-base: bat: 10891.25H in Astra 19,2: invalid checksum (len 185, errors 94) 2017-01-15 08:30:31.926 [WARNING] tbl-base: sdt: 10891.25H in Astra 19,2: invalid checksum (len 185, errors 94) 2017-01-15 08:30:34.371 [WARNING] tbl-base: pat: 10891.25H in Astra 19,2: invalid checksum (len 17, errors 98) 2017-01-15 08:30:35.139 [WARNING] tbl-eit: eit: 10891.25H in Astra 19,2: invalid checksum (len 1227, errors 7858) 2017-01-15 08:30:41.339 [WARNING] tbl-base: nit: 10891.25H in Astra 19,2: invalid checksum (len 496, errors 25) 2017-01-15 08:30:43.328 [WARNING] tbl-base: bat: 10891.25H in Astra 19,2: invalid checksum (len 1006, errors 97) 2017-01-15 08:30:43.330 [WARNING] tbl-base: sdt: 10891.25H in Astra 19,2: invalid checksum (len 1006, errors 97) 2017-01-15 08:30:45.229 [WARNING] tbl-eit: eit: 10891.25H in Astra 19,2: invalid checksum (len 2773, errors 8040) 2017-01-15 08:30:50.956 [WARNING] tbl-base: cat: 10891.25H in Astra 19,2: invalid checksum (len 12, errors 15) 2017-01-15 08:30:53.175 [WARNING] tbl-base: pat: 10891.25H in Astra 19,2: invalid checksum (len 40, errors 101) 2017-01-15 08:30:55.277 [WARNING] tbl-eit: eit: 10891.25H in Astra 19,2: invalid checksum (len 667, errors 8277) 2017-01-15 08:30:56.519 [WARNING] tbl-base: bat: 10891.25H in Astra 19,2: invalid checksum (len 73, errors 102) 2017-01-15 08:30:56.520 [WARNING] tbl-base: sdt: 10891.25H in Astra 19,2: invalid checksum (len 73, errors 102) 2017-01-15 08:30:58.725 [WARNING] tbl-base: nit: 10891.25H in Astra 19,2: invalid checksum (len 496, errors 28) 2017-01-15 08:31:05.260 [WARNING] tbl-eit: eit: 10891.25H in Astra 19,2: invalid checksum (len 82, errors 8521) 2017-01-15 08:31:06.568 [WARNING] tbl-base: pat: 10891.25H in Astra 19,2: invalid checksum (len 40, errors 104) 2017-01-15 08:31:09.415 [WARNING] tbl-base: bat: 10891.25H in Astra 19,2: invalid checksum (len 1006, errors 105) 2017-01-15 08:31:09.417 [WARNING] tbl-base: sdt: 10891.25H in Astra 19,2: invalid checksum (len 1006, errors 105) 2017-01-15 08:31:13.108 [WARNING] tbl-base: nit: 10891.25H in Astra 19,2: invalid checksum (len 1023, errors 29) 2017-01-15 08:31:15.300 [WARNING] tbl-eit: eit: 10891.25H in Astra 19,2: invalid checksum (len 657, errors 8751) 2017-01-15 08:31:22.617 [WARNING] tbl-base: pat: 10891.25H in Astra 19,2: invalid checksum (len 40, errors 106) 2017-01-15 08:31:24.174 [WARNING] tbl-base: bat: 10891.25H in Astra 19,2: invalid checksum (len 112, errors 109) 2017-01-15 08:31:24.174 [WARNING] tbl-base: sdt: 10891.25H in Astra 19,2: invalid checksum (len 112, errors 109) 2017-01-15 08:31:24.499 [WARNING] tbl-base: cat: 10891.25H in Astra 19,2: invalid checksum (len 12, errors 16) 2017-01-15 08:31:24.724 [WARNING] tbl-base: nit: 10891.25H in Astra 19,2: invalid checksum (len 496, errors 30) 2017-01-15 08:31:25.266 [WARNING] tbl-eit: eit: 10891.25H in Astra 19,2: invalid checksum (len 2298, errors 8948) 2017-01-15 08:31:35.337 [WARNING] tbl-eit: eit: 10891.25H in Astra 19,2: invalid checksum (len 747, errors 9188) 2017-01-15 08:31:35.447 [WARNING] tbl-base: pat: 10891.25H in Astra 19,2: invalid checksum (len 40, errors 110) 2017-01-15 08:31:41.415 [WARNING] tbl-base: bat: 10891.25H in Astra 19,2: invalid checksum (len 112, errors 112) 2017-01-15 08:31:41.415 [WARNING] tbl-base: sdt: 10891.25H in Astra 19,2: invalid checksum (len 112, errors 112) 2017-01-15 08:31:44.983 [WARNING] tbl-base: nit: 10891.25H in Astra 19,2: invalid checksum (len 1012, errors 33) 2017-01-15 08:31:45.282 [WARNING] tbl-eit: eit: 10891.25H in Astra 19,2: invalid checksum (len 896, errors 9422) 2017-01-15 08:31:46.636 [WARNING] tbl-base: pat: 10891.25H in Astra 19,2: invalid checksum (len 40, errors 115) 2017-01-15 08:31:51.711 [WARNING] tbl-base: bat: 10891.25H in Astra 19,2: invalid checksum (len 988, errors 115) 2017-01-15 08:31:51.713 [WARNING] tbl-base: sdt: 10891.25H in Astra 19,2: invalid checksum (len 988, errors 115) 2017-01-15 08:31:53.039 [WARNING] tbl-base: cat: 10891.25H in Astra 19,2: invalid checksum (len 12, errors 17) 2017-01-15 08:31:55.383 [WARNING] tbl-eit: eit: 10891.25H in Astra 19,2: invalid checksum (len 834, errors 9644) 2017-01-15 08:31:56.484 [WARNING] tbl-base: nit: 10891.25H in Astra 19,2: invalid checksum (len 1023, errors 34) 2017-01-15 08:31:58.851 [WARNING] tbl-base: pat: 10891.25H in Astra 19,2: invalid checksum (len 40, errors 119) 2017-01-15 08:32:02.557 [WARNING] tbl-base: bat: 10891.25H in Astra 19,2: invalid checksum (len 984, errors 120) 2017-01-15 08:32:02.557 [WARNING] tbl-base: sdt: 10891.25H in Astra 19,2: invalid checksum (len 984, errors 120) 2017-01-15 08:32:05.308 [WARNING] tbl-eit: eit: 10891.25H in Astra 19,2: invalid checksum (len 787, errors 9899) 2017-01-15 08:32:05.647 [WARNING] tbl-base: cat: 10891.25H in Astra 19,2: invalid checksum (len 12, errors 18) 2017-01-15 08:32:09.208 [WARNING] tbl-base: pat: 10891.25H in Astra 19,2: invalid checksum (len 74, errors 122) 2017-01-15 08:32:13.303 [WARNING] tbl-base: bat: 10891.25H in Astra 19,2: invalid checksum (len 407, errors 125) 2017-01-15 08:32:13.303 [WARNING] tbl-base: sdt: 10891.25H in Astra 19,2: invalid checksum (len 407, errors 125) 2017-01-15 08:32:15.419 [WARNING] tbl-eit: eit: 10891.25H in Astra 19,2: invalid checksum (len 643, errors 10121) 2017-01-15 08:32:16.709 [WARNING] tbl-base: nit: 10891.25H in Astra 19,2: invalid checksum (len 496, errors 36) 2017-01-15 08:32:23.471 [WARNING] tbl-base: bat: 10891.25H in Astra 19,2: invalid checksum (len 104, errors 127) 2017-01-15 08:32:23.473 [WARNING] tbl-base: sdt: 10891.25H in Astra 19,2: invalid checksum (len 104, errors 127) 2017-01-15 08:32:25.416 [WARNING] tbl-eit: eit: 10891.25H in Astra 19,2: invalid checksum (len 955, errors 10344) 2017-01-15 08:32:26.458 [WARNING] tbl-base: pat: 10891.25H in Astra 19,2: invalid checksum (len 40, errors 125) 2017-01-15 08:32:35.073 [WARNING] tbl-base: bat: 10891.25H in Astra 19,2: invalid checksum (len 185, errors 131) 2017-01-15 08:32:35.073 [WARNING] tbl-base: sdt: 10891.25H in Astra 19,2: invalid checksum (len 185, errors 131) 2017-01-15 08:32:35.524 [WARNING] tbl-eit: eit: 10891.25H in Astra 19,2: invalid checksum (len 829, errors 10555) 2017-01-15 08:32:37.309 [WARNING] tbl-base: pat: 10891.25H in Astra 19,2: invalid checksum (len 40, errors 129) 2017-01-15 08:32:39.189 [WARNING] tbl-base: cat: 10891.25H in Astra 19,2: invalid checksum (len 12, errors 20) 2017-01-15 08:32:45.609 [WARNING] tbl-eit: eit: 10891.25H in Astra 19,2: invalid checksum (len 1542, errors 10776) 2017-01-15 08:32:45.722 [WARNING] tbl-base: nit: 10891.25H in Astra 19,2: invalid checksum (len 1012, errors 39) 2017-01-15 08:32:45.835 [WARNING] tbl-base: bat: 10891.25H in Astra 19,2: invalid checksum (len 984, errors 133) 2017-01-15 08:32:45.837 [WARNING] tbl-base: sdt: 10891.25H in Astra 19,2: invalid checksum (len 984, errors 133) 2017-01-15 08:32:48.479 [WARNING] tbl-base: pat: 10891.25H in Astra 19,2: invalid checksum (len 40, errors 134) 2017-01-15 08:32:55.556 [WARNING] tbl-eit: eit: 10891.25H in Astra 19,2: invalid checksum (len 892, errors 11012) 2017-01-15 08:32:58.758 [WARNING] tbl-base: pat: 10891.25H in Astra 19,2: invalid checksum (len 40, errors 139) 2017-01-15 08:32:59.104 [WARNING] tbl-base: bat: 10891.25H in Astra 19,2: invalid checksum (len 90, errors 134) 2017-01-15 08:32:59.104 [WARNING] tbl-base: sdt: 10891.25H in Astra 19,2: invalid checksum (len 90, errors 134) 2017-01-15 08:33:05.641 [WARNING] tbl-eit: eit: 10891.25H in Astra 19,2: invalid checksum (len 834, errors 11215) 2017-01-15 08:33:05.873 [WARNING] tbl-base: nit: 10891.25H in Astra 19,2: invalid checksum (len 1023, errors 41) 2017-01-15 08:33:09.648 [WARNING] tbl-base: bat: 10891.25H in Astra 19,2: invalid checksum (len 988, errors 138) 2017-01-15 08:33:09.649 [WARNING] tbl-base: sdt: 10891.25H in Astra 19,2: invalid checksum (len 988, errors 138) 2017-01-15 08:33:09.878 [WARNING] tbl-base: pat: 10891.25H in Astra 19,2: invalid checksum (len 40, errors 141) 2017-01-15 08:33:14.037 [WARNING] tbl-base: cat: 10891.25H in Astra 19,2: invalid checksum (len 12, errors 22) 2017-01-15 08:33:15.582 [WARNING] tbl-eit: eit: 10891.25H in Astra 19,2: invalid checksum (len 834, errors 11392) 2017-01-15 08:33:17.492 [WARNING] tbl-base: nit: 10891.25H in Astra 19,2: invalid checksum (len 496, errors 44) 2017-01-15 08:33:21.241 [WARNING] tbl-base: bat: 10891.25H in Astra 19,2: invalid checksum (len 108, errors 142) 2017-01-15 08:33:21.243 [WARNING] tbl-base: sdt: 10891.25H in Astra 19,2: invalid checksum (len 108, errors 142) 2017-01-15 08:33:22.576 [WARNING] tbl-base: pat: 10891.25H in Astra 19,2: invalid checksum (len 40, errors 144) 2017-01-15 08:33:25.649 [WARNING] tbl-eit: eit: 10891.25H in Astra 19,2: invalid checksum (len 474, errors 11631) 2017-01-15 08:33:33.388 [WARNING] tbl-base: pat: 10891.25H in Astra 19,2: invalid checksum (len 40, errors 145) 2017-01-15 08:33:33.964 [WARNING] tbl-base: bat: 10891.25H in Astra 19,2: invalid checksum (len 185, errors 145) 2017-01-15 08:33:33.965 [WARNING] tbl-base: sdt: 10891.25H in Astra 19,2: invalid checksum (len 185, errors 145) 2017-01-15 08:33:35.600 [WARNING] tbl-eit: eit: 10891.25H in Astra 19,2: invalid checksum (len 937, errors 11841) 2017-01-15 08:33:37.702 [WARNING] tbl-base: nit: 10891.25H in Astra 19,2: invalid checksum (len 1012, errors 45) 2017-01-15 08:33:43.472 [WARNING] tbl-base: pat: 10891.25H in Astra 19,2: invalid checksum (len 40, errors 146) 2017-01-15 08:33:45.596 [WARNING] tbl-eit: eit: 10891.25H in Astra 19,2: invalid checksum (len 41, errors 12044) 2017-01-15 08:33:47.313 [WARNING] tbl-base: bat: 10891.25H in Astra 19,2: invalid checksum (len 108, errors 146) 2017-01-15 08:33:47.313 [WARNING] tbl-base: sdt: 10891.25H in Astra 19,2: invalid checksum (len 108, errors 146) 2017-01-15 08:33:54.653 [WARNING] tbl-base: nit: 10891.25H in Astra 19,2: invalid checksum (len 1012, errors 46) 2017-01-15 08:33:55.630 [WARNING] tbl-eit: eit: 10891.25H in Astra 19,2: invalid checksum (len 842, errors 12257) 2017-01-15 08:33:58.504 [WARNING] tbl-base: bat: 10891.25H in Astra 19,2: invalid checksum (len 73, errors 148) 2017-01-15 08:33:58.506 [WARNING] tbl-base: sdt: 10891.25H in Astra 19,2: invalid checksum (len 73, errors 148) 2017-01-15 08:34:00.292 [WARNING] tbl-base: pat: 10891.25H in Astra 19,2: invalid checksum (len 40, errors 149) 2017-01-15 08:34:05.633 [WARNING] tbl-eit: eit: 10891.25H in Astra 19,2: invalid checksum (len 1101, errors 12478) 2017-01-15 08:34:06.611 [WARNING] tbl-base: nit: 10891.25H in Astra 19,2: invalid checksum (len 1023, errors 48) 2017-01-15 08:34:12.802 [WARNING] tbl-base: pat: 10891.25H in Astra 19,2: invalid checksum (len 40, errors 154) 2017-01-15 08:34:13.648 [WARNING] tbl-base: bat: 10891.25H in Astra 19,2: invalid checksum (len 173, errors 151) 2017-01-15 08:34:13.648 [WARNING] tbl-base: sdt: 10891.25H in Astra 19,2: invalid checksum (len 173, errors 151) 2017-01-15 08:34:15.648 [WARNING] tbl-eit: eit: 10891.25H in Astra 19,2: invalid checksum (len 1481, errors 12713) 2017-01-15 08:34:23.461 [WARNING] epggrab: EIT: DVB Grabber - data completion timeout for 10891.25H in Astra 19,2 2017-01-15 08:34:23.461 [ INFO] subscription: 0003: "epggrab" unsubscribing 2017-01-15 08:34:24.462 [ INFO] mpegts: 10920.75H in Astra 19,2 - tuning on TechnoTrend S2-4600 2017-01-15 08:34:24.480 [ INFO] subscription: 0005: "epggrab" subscribing to mux "10920.75H", weight: 4, adapter: "TechnoTrend S2-4600", network: "Astra 19,2", service: "Raw PID Subscription" 2017-01-15 08:34:34.857 [ INFO] subscription: 0005: "epggrab" unsubscribing 2017-01-15 08:34:35.824 [ INFO] mpegts: 11052.75H in Astra 19,2 - tuning on TechnoTrend S2-4600 2017-01-15 08:34:35.843 [ INFO] subscription: 0007: "epggrab" subscribing to mux "11052.75H", weight: 4, adapter: "TechnoTrend S2-4600", network: "Astra 19,2", service: "Raw PID Subscription" 2017-01-15 08:35:03.451 [ INFO] subscription: 0007: "epggrab" unsubscribing 2017-01-15 08:35:04.449 [ INFO] mpegts: 11243.75H in Astra 19,2 - tuning on TechnoTrend S2-4600 2017-01-15 08:35:04.468 [ INFO] subscription: 0009: "epggrab" subscribing to mux "11243.75H", weight: 4, adapter: "TechnoTrend S2-4600", network: "Astra 19,2", service: "Raw PID Subscription" 2017-01-15 08:35:38.778 [ INFO] subscription: 0009: "epggrab" unsubscribing 2017-01-15 08:35:39.680 [ INFO] mpegts: 11273.25H in Astra 19,2 - tuning on TechnoTrend S2-4600 2017-01-15 08:35:39.700 [ INFO] subscription: 000B: "epggrab" subscribing to mux "11273.25H", weight: 4, adapter: "TechnoTrend S2-4600", network: "Astra 19,2", service: "Raw PID Subscription" 2017-01-15 08:36:31.524 [ INFO] subscription: 000B: "epggrab" unsubscribing 2017-01-15 08:36:32.522 [ INFO] mpegts: 11302.75H in Astra 19,2 - tuning on TechnoTrend S2-4600 2017-01-15 08:36:32.541 [ INFO] subscription: 000D: "epggrab" subscribing to mux "11302.75H", weight: 4, adapter: "TechnoTrend S2-4600", network: "Astra 19,2", service: "Raw PID Subscription" 2017-01-15 08:37:05.050 [ INFO] subscription: 000D: "epggrab" unsubscribing 2017-01-15 08:37:06.049 [ INFO] mpegts: 11361.75H in Astra 19,2 - tuning on TechnoTrend S2-4600 2017-01-15 08:37:06.068 [ INFO] subscription: 000F: "epggrab" subscribing to mux "11361.75H", weight: 4, adapter: "TechnoTrend S2-4600", network: "Astra 19,2", service: "Raw PID Subscription" 2017-01-15 08:37:15.764 [ INFO] subscription: 000F: "epggrab" unsubscribing 2017-01-15 08:37:16.759 [ INFO] mpegts: 11420.75H in Astra 19,2 - tuning on TechnoTrend S2-4600 2017-01-15 08:37:16.777 [ INFO] subscription: 0011: "epggrab" subscribing to mux "11420.75H", weight: 4, adapter: "TechnoTrend S2-4600", network: "Astra 19,2", service: "Raw PID Subscription" 2017-01-15 08:37:27.584 [ INFO] subscription: 0011: "epggrab" unsubscribing 2017-01-15 08:37:28.571 [ INFO] mpegts: 11493.75H in Astra 19,2 - tuning on TechnoTrend S2-4600 2017-01-15 08:37:28.589 [ INFO] subscription: 0013: "epggrab" subscribing to mux "11493.75H", weight: 4, adapter: "TechnoTrend S2-4600", network: "Astra 19,2", service: "Raw PID Subscription" 2017-01-15 08:37:55.328 [ INFO] subscription: 0013: "epggrab" unsubscribing 2017-01-15 08:37:56.294 [ INFO] mpegts: 11582.25H in Astra 19,2 - tuning on TechnoTrend S2-4600 2017-01-15 08:37:56.312 [ INFO] subscription: 0015: "epggrab" subscribing to mux "11582.25H", weight: 4, adapter: "TechnoTrend S2-4600", network: "Astra 19,2", service: "Raw PID Subscription" 2017-01-15 08:38:23.718 [ INFO] subscription: 0015: "epggrab" unsubscribing 2017-01-15 08:38:24.718 [ INFO] mpegts: 11670.75H in Astra 19,2 - tuning on TechnoTrend S2-4600 2017-01-15 08:38:24.736 [ INFO] subscription: 0017: "epggrab" subscribing to mux "11670.75H", weight: 4, adapter: "TechnoTrend S2-4600", network: "Astra 19,2", service: "Raw PID Subscription" 2017-01-15 08:38:35.478 [ INFO] subscription: 0017: "epggrab" unsubscribing 2017-01-15 08:38:36.426 [ INFO] mpegts: 12148.5H in Astra 19,2 - tuning on TechnoTrend S2-4600 2017-01-15 08:38:36.467 [ INFO] subscription: 0019: "epggrab" subscribing to mux "12148.5H", weight: 4, adapter: "TechnoTrend S2-4600", network: "Astra 19,2", service: "Raw PID Subscription" 2017-01-15 08:38:46.841 [ INFO] subscription: 0019: "epggrab" unsubscribing 2017-01-15 08:38:47.837 [ INFO] mpegts: 12187.5H in Astra 19,2 - tuning on TechnoTrend S2-4600 2017-01-15 08:38:47.878 [ INFO] subscription: 001B: "epggrab" subscribing to mux "12187.5H", weight: 4, adapter: "TechnoTrend S2-4600", network: "Astra 19,2", service: "Raw PID Subscription" 2017-01-15 08:39:04.116 [ INFO] subscription: 001B: "epggrab" unsubscribing 2017-01-15 08:39:05.052 [ INFO] mpegts: 12226.5H in Astra 19,2 - tuning on TechnoTrend S2-4600 2017-01-15 08:39:05.092 [ INFO] subscription: 001D: "epggrab" subscribing to mux "12226.5H", weight: 4, adapter: "TechnoTrend S2-4600", network: "Astra 19,2", service: "Raw PID Subscription" 2017-01-15 08:39:27.988 [ INFO] subscription: 001D: "epggrab" unsubscribing 2017-01-15 08:39:28.972 [ INFO] mpegts: 12265.5H in Astra 19,2 - tuning on TechnoTrend S2-4600 2017-01-15 08:39:29.013 [ INFO] subscription: 001F: "epggrab" subscribing to mux "12265.5H", weight: 4, adapter: "TechnoTrend S2-4600", network: "Astra 19,2", service: "Raw PID Subscription" 2017-01-15 08:39:58.309 [ INFO] subscription: 001F: "epggrab" unsubscribing 2017-01-15 08:39:59.296 [ INFO] mpegts: 12304.5H in Astra 19,2 - tuning on TechnoTrend S2-4600 2017-01-15 08:39:59.337 [ INFO] subscription: 0021: "epggrab" subscribing to mux "12304.5H", weight: 4, adapter: "TechnoTrend S2-4600", network: "Astra 19,2", service: "Raw PID Subscription" 2017-01-15 08:40:09.786 [ INFO] subscription: 0021: "epggrab" unsubscribing 2017-01-15 08:40:10.705 [ INFO] mpegts: 12421.5H in Astra 19,2 - tuning on TechnoTrend S2-4600 2017-01-15 08:40:10.746 [ INFO] subscription: 0023: "epggrab" subscribing to mux "12421.5H", weight: 4, adapter: "TechnoTrend S2-4600", network: "Astra 19,2", service: "Raw PID Subscription" 2017-01-15 08:40:39.664 [ INFO] subscription: 0023: "epggrab" unsubscribing 2017-01-15 08:40:40.628 [ INFO] mpegts: 12460.5H in Astra 19,2 - tuning on TechnoTrend S2-4600 2017-01-15 08:40:40.670 [ INFO] subscription: 0025: "epggrab" subscribing to mux "12460.5H", weight: 4, adapter: "TechnoTrend S2-4600", network: "Astra 19,2", service: "Raw PID Subscription" 2017-01-15 08:40:51.091 [ INFO] subscription: 0025: "epggrab" unsubscribing 2017-01-15 08:40:52.037 [ INFO] mpegts: 12662.75H in Astra 19,2 - tuning on TechnoTrend S2-4600 2017-01-15 08:40:52.078 [ INFO] subscription: 0027: "epggrab" subscribing to mux "12662.75H", weight: 4, adapter: "TechnoTrend S2-4600", network: "Astra 19,2", service: "Raw PID Subscription" 2017-01-15 08:41:31.374 [ INFO] subscription: 0027: "epggrab" unsubscribing 2017-01-15 08:41:32.372 [ INFO] mpegts: 12692.25H in Astra 19,2 - tuning on TechnoTrend S2-4600 2017-01-15 08:41:32.413 [ INFO] subscription: 0029: "epggrab" subscribing to mux "12692.25H", weight: 4, adapter: "TechnoTrend S2-4600", network: "Astra 19,2", service: "Raw PID Subscription" 2017-01-15 08:42:08.401 [ INFO] subscription: 0029: "epggrab" unsubscribing 2017-01-15 08:42:09.402 [ INFO] mpegts: 11347V in Astra 19,2 - tuning on TechnoTrend S2-4600 2017-01-15 08:42:09.421 [ INFO] subscription: 002B: "epggrab" subscribing to mux "11347V", weight: 4, adapter: "TechnoTrend S2-4600", network: "Astra 19,2", service: "Raw PID Subscription" 2017-01-15 08:42:18.439 [ INFO] subscription: 002B: "epggrab" unsubscribing 2017-01-15 08:42:19.409 [ INFO] mpegts: 12051V in Astra 19,2 - tuning on TechnoTrend S2-4600 2017-01-15 08:42:19.449 [ INFO] subscription: 002D: "epggrab" subscribing to mux "12051V", weight: 4, adapter: "TechnoTrend S2-4600", network: "Astra 19,2", service: "Raw PID Subscription" 2017-01-15 08:42:29.959 [ INFO] subscription: 002D: "epggrab" unsubscribing 2017-01-15 08:42:30.919 [ INFO] mpegts: 12480V in Astra 19,2 - tuning on TechnoTrend S2-4600 2017-01-15 08:42:30.960 [ INFO] subscription: 002F: "epggrab" subscribing to mux "12480V", weight: 4, adapter: "TechnoTrend S2-4600", network: "Astra 19,2", service: "Raw PID Subscription" 2017-01-15 08:42:41.761 [ INFO] subscription: 002F: "epggrab" unsubscribing 2017-01-15 09:07:20.855 [ INFO] mpegts: 11302.75H in Astra 19,2 - tuning on TechnoTrend S2-4600 2017-01-15 09:07:20.896 [ INFO] capmt: Oscam: Starting CAPMT server for service "ORF1 HD" on adapter 0 2017-01-15 09:07:20.896 [ INFO] subscription: 0030: "127.0.0.1 [ | Kodi Media Center ]" subscribing on channel "ORF1 HD", weight: 150, adapter: "TechnoTrend S2-4600", network: "Astra 19,2", mux: "11302.75H", provider: "ORF", service: "ORF1 HD", profile="htsp", hostname="127.0.0.1", username="127.0.0.1", client="Kodi Media Center" 2017-01-15 09:07:22.158 [WARNING] TS: Astra 19,2/11302.75H/ORF1 HD: H264 @ #1920 Continuity counter error (total 1) 2017-01-15 09:07:22.158 [WARNING] TS: Astra 19,2/11302.75H/ORF1 HD: AC3 @ #1922 Continuity counter error (total 1) 2017-01-15 09:23:58.000 [ INFO] epgdb: snapshot start 2017-01-15 09:23:58.756 [ INFO] epgdb: queued to save (size 17851777) 2017-01-15 09:23:58.756 [ INFO] epgdb: brands 0 2017-01-15 09:23:58.756 [ INFO] epgdb: seasons 0 2017-01-15 09:23:58.756 [ INFO] epgdb: episodes 24907 2017-01-15 09:23:58.756 [ INFO] epgdb: broadcasts 24907 2017-01-15 09:23:58.756 [ INFO] epgdb: save start 2017-01-15 09:24:00.048 [ INFO] epgdb: stored (size 3105382) 2017-01-15 09:24:46.915 [ INFO] subscription: 0030: "127.0.0.1 [ | Kodi Media Center ]" unsubscribing from "ORF1 HD", hostname="127.0.0.1", username="127.0.0.1", client="Kodi Media Center" 2017-01-15 09:24:46.921 [ INFO] mpegts: 12051V in Astra 19,2 - tuning on TechnoTrend S2-4600 2017-01-15 09:24:46.962 [ INFO] subscription: 0031: "127.0.0.1 [ | Kodi Media Center ]" subscribing on channel "ProSieben Austria", weight: 150, adapter: "TechnoTrend S2-4600", network: "Astra 19,2", mux: "12051V", provider: "ProSiebenSat.1", service: "ProSieben Austria", profile="htsp", hostname="127.0.0.1", username="127.0.0.1", client="Kodi Media Center" 2017-01-15 09:33:43.985 [ INFO] subscription: 0031: "127.0.0.1 [ | Kodi Media Center ]" unsubscribing from "ProSieben Austria", hostname="127.0.0.1", username="127.0.0.1", client="Kodi Media Center" 2017-01-15 09:33:43.989 [ INFO] mpegts: 11302.75H in Astra 19,2 - tuning on TechnoTrend S2-4600 2017-01-15 09:33:44.008 [ INFO] capmt: Oscam: Starting CAPMT server for service "ORF1 HD" on adapter 0 2017-01-15 09:33:44.009 [ INFO] subscription: 0032: "127.0.0.1 [ | Kodi Media Center ]" subscribing on channel "ORF1 HD", weight: 150, adapter: "TechnoTrend S2-4600", network: "Astra 19,2", mux: "11302.75H", provider: "ORF", service: "ORF1 HD", profile="htsp", hostname="127.0.0.1", username="127.0.0.1", client="Kodi Media Center" 2017-01-15 10:11:12.297 [ INFO] subscription: 0032: "127.0.0.1 [ | Kodi Media Center ]" unsubscribing from "ORF1 HD", hostname="127.0.0.1", username="127.0.0.1", client="Kodi Media Center" 2017-01-15 10:11:12.301 [ INFO] mpegts: 12051V in Astra 19,2 - tuning on TechnoTrend S2-4600 2017-01-15 10:11:12.344 [ INFO] subscription: 0033: "127.0.0.1 [ | Kodi Media Center ]" subscribing on channel "ProSieben Austria", weight: 150, adapter: "TechnoTrend S2-4600", network: "Astra 19,2", mux: "12051V", provider: "ProSiebenSat.1", service: "ProSieben Austria", profile="htsp", hostname="127.0.0.1", username="127.0.0.1", client="Kodi Media Center" 2017-01-15 10:23:58.000 [ INFO] epgdb: snapshot start 2017-01-15 10:23:58.768 [ INFO] epgdb: queued to save (size 17837665) 2017-01-15 10:23:58.768 [ INFO] epgdb: brands 0 2017-01-15 10:23:58.768 [ INFO] epgdb: seasons 0 2017-01-15 10:23:58.768 [ INFO] epgdb: episodes 24896 2017-01-15 10:23:58.768 [ INFO] epgdb: broadcasts 24896 2017-01-15 10:23:58.768 [ INFO] epgdb: save start 2017-01-15 10:24:00.097 [ INFO] epgdb: stored (size 3101591) 2017-01-15 10:25:27.612 [ INFO] subscription: 0033: "127.0.0.1 [ | Kodi Media Center ]" unsubscribing from "ProSieben Austria", hostname="127.0.0.1", username="127.0.0.1", client="Kodi Media Center" 2017-01-15 10:25:27.616 [ INFO] mpegts: 11302.75H in Astra 19,2 - tuning on TechnoTrend S2-4600 2017-01-15 10:25:27.635 [ INFO] capmt: Oscam: Starting CAPMT server for service "ORF1 HD" on adapter 0 2017-01-15 10:25:27.635 [ INFO] subscription: 0034: "127.0.0.1 [ | Kodi Media Center ]" subscribing on channel "ORF1 HD", weight: 150, adapter: "TechnoTrend S2-4600", network: "Astra 19,2", mux: "11302.75H", provider: "ORF", service: "ORF1 HD", profile="htsp", hostname="127.0.0.1", username="127.0.0.1", client="Kodi Media Center" 2017-01-15 10:57:29.712 [ INFO] subscription: 0034: "127.0.0.1 [ | Kodi Media Center ]" unsubscribing from "ORF1 HD", hostname="127.0.0.1", username="127.0.0.1", client="Kodi Media Center" 2017-01-15 11:23:58.000 [ INFO] epgdb: snapshot start 2017-01-15 11:23:58.746 [ INFO] epgdb: queued to save (size 17836400) 2017-01-15 11:23:58.746 [ INFO] epgdb: brands 0 2017-01-15 11:23:58.746 [ INFO] epgdb: seasons 0 2017-01-15 11:23:58.746 [ INFO] epgdb: episodes 24894 2017-01-15 11:23:58.746 [ INFO] epgdb: save start 2017-01-15 11:23:58.746 [ INFO] epgdb: broadcasts 24894 2017-01-15 11:23:59.918 [ INFO] epgdb: stored (size 3101247) 2017-01-15 12:23:58.000 [ INFO] epgdb: snapshot start 2017-01-15 12:23:58.710 [ INFO] epgdb: queued to save (size 17836400) 2017-01-15 12:23:58.710 [ INFO] epgdb: brands 0 2017-01-15 12:23:58.710 [ INFO] epgdb: seasons 0 2017-01-15 12:23:58.710 [ INFO] epgdb: episodes 24894 2017-01-15 12:23:58.710 [ INFO] epgdb: broadcasts 24894 2017-01-15 12:23:58.710 [ INFO] epgdb: save start 2017-01-15 12:23:59.880 [ INFO] epgdb: stored (size 3101247) 2017-01-15 13:23:58.000 [ INFO] epgdb: snapshot start 2017-01-15 13:23:58.737 [ INFO] epgdb: queued to save (size 17836400) 2017-01-15 13:23:58.737 [ INFO] epgdb: brands 0 2017-01-15 13:23:58.737 [ INFO] epgdb: seasons 0 2017-01-15 13:23:58.737 [ INFO] epgdb: episodes 24894 2017-01-15 13:23:58.737 [ INFO] epgdb: broadcasts 24894 2017-01-15 13:23:58.737 [ INFO] epgdb: save start 2017-01-15 13:23:59.903 [ INFO] epgdb: stored (size 3101247) 2017-01-15 14:23:58.000 [ INFO] epgdb: snapshot start 2017-01-15 14:23:58.750 [ INFO] epgdb: queued to save (size 17836400) 2017-01-15 14:23:58.750 [ INFO] epgdb: brands 0 2017-01-15 14:23:58.750 [ INFO] epgdb: seasons 0 2017-01-15 14:23:58.750 [ INFO] epgdb: episodes 24894 2017-01-15 14:23:58.750 [ INFO] epgdb: broadcasts 24894 2017-01-15 14:23:58.750 [ INFO] epgdb: save start 2017-01-15 14:23:59.912 [ INFO] epgdb: stored (size 3101247) 2017-01-15 15:23:58.000 [ INFO] epgdb: snapshot start 2017-01-15 15:23:58.728 [ INFO] epgdb: queued to save (size 17836400) 2017-01-15 15:23:58.728 [ INFO] epgdb: brands 0 2017-01-15 15:23:58.728 [ INFO] epgdb: seasons 0 2017-01-15 15:23:58.728 [ INFO] epgdb: episodes 24894 2017-01-15 15:23:58.728 [ INFO] epgdb: save start 2017-01-15 15:23:58.728 [ INFO] epgdb: broadcasts 24894 2017-01-15 15:23:59.902 [ INFO] epgdb: stored (size 3101247) 2017-01-15 16:23:58.000 [ INFO] epgdb: snapshot start 2017-01-15 16:23:58.709 [ INFO] epgdb: queued to save (size 17836400) 2017-01-15 16:23:58.709 [ INFO] epgdb: brands 0 2017-01-15 16:23:58.709 [ INFO] epgdb: seasons 0 2017-01-15 16:23:58.709 [ INFO] epgdb: episodes 24894 2017-01-15 16:23:58.709 [ INFO] epgdb: broadcasts 24894 2017-01-15 16:23:58.709 [ INFO] epgdb: save start 2017-01-15 16:23:59.917 [ INFO] epgdb: stored (size 3101247) 2017-01-15 17:23:58.000 [ INFO] epgdb: snapshot start 2017-01-15 17:23:58.719 [ INFO] epgdb: queued to save (size 17836400) 2017-01-15 17:23:58.719 [ INFO] epgdb: brands 0 2017-01-15 17:23:58.719 [ INFO] epgdb: seasons 0 2017-01-15 17:23:58.719 [ INFO] epgdb: episodes 24894 2017-01-15 17:23:58.719 [ INFO] epgdb: broadcasts 24894 2017-01-15 17:23:58.719 [ INFO] epgdb: save start 2017-01-15 17:23:59.888 [ INFO] epgdb: stored (size 3101247) 2017-01-15 18:04:00.955 [ INFO] mpegts: 10773.25H in Astra 19,2 - tuning on TechnoTrend S2-4600 2017-01-15 18:04:00.993 [ INFO] subscription: 0035: "epggrab" subscribing to mux "10773.25H", weight: 4, adapter: "TechnoTrend S2-4600", network: "Astra 19,2", service: "Raw PID Subscription" 2017-01-15 18:04:01.248 [WARNING] linuxdvb: Unable to provide UNC value. 2017-01-15 18:04:11.868 [ INFO] subscription: 0035: "epggrab" unsubscribing 2017-01-15 18:04:12.864 [ INFO] mpegts: 10891.25H in Astra 19,2 - tuning on TechnoTrend S2-4600 2017-01-15 18:04:12.883 [ INFO] subscription: 0037: "epggrab" subscribing to mux "10891.25H", weight: 4, adapter: "TechnoTrend S2-4600", network: "Astra 19,2", service: "Raw PID Subscription" 2017-01-15 18:04:40.989 [ INFO] subscription: 0037: "epggrab" unsubscribing 2017-01-15 18:04:41.987 [ INFO] mpegts: 10920.75H in Astra 19,2 - tuning on TechnoTrend S2-4600 2017-01-15 18:04:42.006 [ INFO] subscription: 0039: "epggrab" subscribing to mux "10920.75H", weight: 4, adapter: "TechnoTrend S2-4600", network: "Astra 19,2", service: "Raw PID Subscription" 2017-01-15 18:04:52.475 [ INFO] subscription: 0039: "epggrab" unsubscribing 2017-01-15 18:04:53.396 [ INFO] mpegts: 11052.75H in Astra 19,2 - tuning on TechnoTrend S2-4600 2017-01-15 18:04:53.415 [ INFO] subscription: 003B: "epggrab" subscribing to mux "11052.75H", weight: 4, adapter: "TechnoTrend S2-4600", network: "Astra 19,2", service: "Raw PID Subscription" 2017-01-15 18:05:20.716 [ INFO] subscription: 003B: "epggrab" unsubscribing 2017-01-15 18:05:21.717 [ INFO] mpegts: 11243.75H in Astra 19,2 - tuning on TechnoTrend S2-4600 2017-01-15 18:05:21.736 [ INFO] subscription: 003D: "epggrab" subscribing to mux "11243.75H", weight: 4, adapter: "TechnoTrend S2-4600", network: "Astra 19,2", service: "Raw PID Subscription" 2017-01-15 18:05:48.848 [ INFO] subscription: 003D: "epggrab" unsubscribing 2017-01-15 18:05:49.842 [ INFO] mpegts: 11273.25H in Astra 19,2 - tuning on TechnoTrend S2-4600 2017-01-15 18:05:49.861 [ INFO] subscription: 003F: "epggrab" subscribing to mux "11273.25H", weight: 4, adapter: "TechnoTrend S2-4600", network: "Astra 19,2", service: "Raw PID Subscription" 2017-01-15 18:06:31.358 [ INFO] subscription: 003F: "epggrab" unsubscribing 2017-01-15 18:06:32.302 [ INFO] mpegts: 11302.75H in Astra 19,2 - tuning on TechnoTrend S2-4600 2017-01-15 18:06:32.321 [ INFO] subscription: 0041: "epggrab" subscribing to mux "11302.75H", weight: 4, adapter: "TechnoTrend S2-4600", network: "Astra 19,2", service: "Raw PID Subscription" 2017-01-15 18:07:00.586 [ INFO] subscription: 0041: "epggrab" unsubscribing 2017-01-15 18:07:01.501 [ INFO] mpegts: 11361.75H in Astra 19,2 - tuning on TechnoTrend S2-4600 2017-01-15 18:07:01.519 [ INFO] subscription: 0043: "epggrab" subscribing to mux "11361.75H", weight: 4, adapter: "TechnoTrend S2-4600", network: "Astra 19,2", service: "Raw PID Subscription" 2017-01-15 18:07:10.610 [ INFO] subscription: 0043: "epggrab" unsubscribing 2017-01-15 18:07:11.608 [ INFO] mpegts: 11420.75H in Astra 19,2 - tuning on TechnoTrend S2-4600 2017-01-15 18:07:11.627 [ INFO] subscription: 0045: "epggrab" subscribing to mux "11420.75H", weight: 4, adapter: "TechnoTrend S2-4600", network: "Astra 19,2", service: "Raw PID Subscription" 2017-01-15 18:07:22.206 [ INFO] subscription: 0045: "epggrab" unsubscribing 2017-01-15 18:07:23.119 [ INFO] mpegts: 11493.75H in Astra 19,2 - tuning on TechnoTrend S2-4600 2017-01-15 18:07:23.137 [ INFO] subscription: 0047: "epggrab" subscribing to mux "11493.75H", weight: 4, adapter: "TechnoTrend S2-4600", network: "Astra 19,2", service: "Raw PID Subscription" 2017-01-15 18:07:50.014 [ INFO] subscription: 0047: "epggrab" unsubscribing 2017-01-15 18:07:50.941 [ INFO] mpegts: 11582.25H in Astra 19,2 - tuning on TechnoTrend S2-4600 2017-01-15 18:07:50.959 [ INFO] subscription: 0049: "epggrab" subscribing to mux "11582.25H", weight: 4, adapter: "TechnoTrend S2-4600", network: "Astra 19,2", service: "Raw PID Subscription" 2017-01-15 18:08:18.672 [ INFO] subscription: 0049: "epggrab" unsubscribing 2017-01-15 18:08:19.666 [ INFO] mpegts: 11670.75H in Astra 19,2 - tuning on TechnoTrend S2-4600 2017-01-15 18:08:19.684 [ INFO] subscription: 004B: "epggrab" subscribing to mux "11670.75H", weight: 4, adapter: "TechnoTrend S2-4600", network: "Astra 19,2", service: "Raw PID Subscription" 2017-01-15 18:08:30.292 [ INFO] subscription: 004B: "epggrab" unsubscribing 2017-01-15 18:08:31.276 [ INFO] mpegts: 12148.5H in Astra 19,2 - tuning on TechnoTrend S2-4600 2017-01-15 18:08:31.317 [ INFO] subscription: 004D: "epggrab" subscribing to mux "12148.5H", weight: 4, adapter: "TechnoTrend S2-4600", network: "Astra 19,2", service: "Raw PID Subscription" 2017-01-15 18:08:41.782 [ INFO] subscription: 004D: "epggrab" unsubscribing 2017-01-15 18:08:42.686 [ INFO] mpegts: 12187.5H in Astra 19,2 - tuning on TechnoTrend S2-4600 2017-01-15 18:08:42.726 [ INFO] subscription: 004F: "epggrab" subscribing to mux "12187.5H", weight: 4, adapter: "TechnoTrend S2-4600", network: "Astra 19,2", service: "Raw PID Subscription" 2017-01-15 18:08:58.967 [ INFO] subscription: 004F: "epggrab" unsubscribing 2017-01-15 18:08:59.901 [ INFO] mpegts: 12226.5H in Astra 19,2 - tuning on TechnoTrend S2-4600 2017-01-15 18:08:59.942 [ INFO] subscription: 0051: "epggrab" subscribing to mux "12226.5H", weight: 4, adapter: "TechnoTrend S2-4600", network: "Astra 19,2", service: "Raw PID Subscription" 2017-01-15 18:09:13.925 [ INFO] subscription: 0051: "epggrab" unsubscribing 2017-01-15 18:09:14.914 [ INFO] mpegts: 12265.5H in Astra 19,2 - tuning on TechnoTrend S2-4600 2017-01-15 18:09:14.955 [ INFO] subscription: 0053: "epggrab" subscribing to mux "12265.5H", weight: 4, adapter: "TechnoTrend S2-4600", network: "Astra 19,2", service: "Raw PID Subscription" 2017-01-15 18:09:43.096 [ INFO] subscription: 0053: "epggrab" unsubscribing 2017-01-15 18:09:44.038 [ INFO] mpegts: 12304.5H in Astra 19,2 - tuning on TechnoTrend S2-4600 2017-01-15 18:09:44.079 [ INFO] subscription: 0055: "epggrab" subscribing to mux "12304.5H", weight: 4, adapter: "TechnoTrend S2-4600", network: "Astra 19,2", service: "Raw PID Subscription" 2017-01-15 18:09:54.561 [ INFO] subscription: 0055: "epggrab" unsubscribing 2017-01-15 18:09:55.546 [ INFO] mpegts: 12421.5H in Astra 19,2 - tuning on TechnoTrend S2-4600 2017-01-15 18:09:55.587 [ INFO] subscription: 0057: "epggrab" subscribing to mux "12421.5H", weight: 4, adapter: "TechnoTrend S2-4600", network: "Astra 19,2", service: "Raw PID Subscription" 2017-01-15 18:10:23.918 [ INFO] subscription: 0057: "epggrab" unsubscribing 2017-01-15 18:10:24.870 [ INFO] mpegts: 12460.5H in Astra 19,2 - tuning on TechnoTrend S2-4600 2017-01-15 18:10:24.910 [ INFO] subscription: 0059: "epggrab" subscribing to mux "12460.5H", weight: 4, adapter: "TechnoTrend S2-4600", network: "Astra 19,2", service: "Raw PID Subscription" 2017-01-15 18:10:35.308 [ INFO] subscription: 0059: "epggrab" unsubscribing 2017-01-15 18:10:36.279 [ INFO] mpegts: 12662.75H in Astra 19,2 - tuning on TechnoTrend S2-4600 2017-01-15 18:10:36.320 [ INFO] subscription: 005B: "epggrab" subscribing to mux "12662.75H", weight: 4, adapter: "TechnoTrend S2-4600", network: "Astra 19,2", service: "Raw PID Subscription" 2017-01-15 18:11:11.252 [ INFO] subscription: 005B: "epggrab" unsubscribing 2017-01-15 18:11:12.207 [ INFO] mpegts: 12692.25H in Astra 19,2 - tuning on TechnoTrend S2-4600 2017-01-15 18:11:12.248 [ INFO] subscription: 005D: "epggrab" subscribing to mux "12692.25H", weight: 4, adapter: "TechnoTrend S2-4600", network: "Astra 19,2", service: "Raw PID Subscription" 2017-01-15 18:11:44.334 [ INFO] subscription: 005D: "epggrab" unsubscribing 2017-01-15 18:11:45.334 [ INFO] mpegts: 11347V in Astra 19,2 - tuning on TechnoTrend S2-4600 2017-01-15 18:11:45.352 [ INFO] subscription: 005F: "epggrab" subscribing to mux "11347V", weight: 4, adapter: "TechnoTrend S2-4600", network: "Astra 19,2", service: "Raw PID Subscription" 2017-01-15 18:11:54.324 [ INFO] subscription: 005F: "epggrab" unsubscribing 2017-01-15 18:11:55.241 [ INFO] mpegts: 12051V in Astra 19,2 - tuning on TechnoTrend S2-4600 2017-01-15 18:11:55.281 [ INFO] subscription: 0061: "epggrab" subscribing to mux "12051V", weight: 4, adapter: "TechnoTrend S2-4600", network: "Astra 19,2", service: "Raw PID Subscription" 2017-01-15 18:12:05.788 [ INFO] subscription: 0061: "epggrab" unsubscribing 2017-01-15 18:12:06.750 [ INFO] mpegts: 12480V in Astra 19,2 - tuning on TechnoTrend S2-4600 2017-01-15 18:12:06.790 [ INFO] subscription: 0063: "epggrab" subscribing to mux "12480V", weight: 4, adapter: "TechnoTrend S2-4600", network: "Astra 19,2", service: "Raw PID Subscription" 2017-01-15 18:12:17.219 [ INFO] subscription: 0063: "epggrab" unsubscribing 2017-01-15 18:23:58.000 [ INFO] epgdb: snapshot start 2017-01-15 18:23:58.741 [ INFO] epgdb: queued to save (size 17409698) 2017-01-15 18:23:58.741 [ INFO] epgdb: brands 0 2017-01-15 18:23:58.741 [ INFO] epgdb: seasons 0 2017-01-15 18:23:58.741 [ INFO] epgdb: episodes 24383 2017-01-15 18:23:58.741 [ INFO] epgdb: broadcasts 24383 2017-01-15 18:23:58.741 [ INFO] epgdb: save start 2017-01-15 18:23:59.869 [ INFO] epgdb: stored (size 3008292) 2017-01-15 19:23:58.000 [ INFO] epgdb: snapshot start 2017-01-15 19:23:58.717 [ INFO] epgdb: queued to save (size 17406449) 2017-01-15 19:23:58.717 [ INFO] epgdb: brands 0 2017-01-15 19:23:58.717 [ INFO] epgdb: seasons 0 2017-01-15 19:23:58.717 [ INFO] epgdb: episodes 24380 2017-01-15 19:23:58.717 [ INFO] epgdb: broadcasts 24380 2017-01-15 19:23:58.717 [ INFO] epgdb: save start 2017-01-15 19:23:59.841 [ INFO] epgdb: stored (size 3007451) 2017-01-15 20:23:58.000 [ INFO] epgdb: snapshot start 2017-01-15 20:23:58.765 [ INFO] epgdb: queued to save (size 17403477) 2017-01-15 20:23:58.765 [ INFO] epgdb: brands 0 2017-01-15 20:23:58.765 [ INFO] epgdb: save start 2017-01-15 20:23:58.765 [ INFO] epgdb: seasons 0 2017-01-15 20:23:58.765 [ INFO] epgdb: episodes 24377 2017-01-15 20:23:58.765 [ INFO] epgdb: broadcasts 24377 2017-01-15 20:23:59.914 [ INFO] epgdb: stored (size 3007254) 2017-01-15 21:10:21.857 [ INFO] mpegts: 11243.75H in Astra 19,2 - tuning on TechnoTrend S2-4600 2017-01-15 21:10:21.895 [ INFO] capmt: Oscam: Starting CAPMT server for service "ATV HD" on adapter 0 2017-01-15 21:10:21.896 [ INFO] subscription: 0064: "127.0.0.1 [ | Kodi Media Center ]" subscribing on channel "ATV HD", weight: 150, adapter: "TechnoTrend S2-4600", network: "Astra 19,2", mux: "11243.75H", provider: "ATV", service: "ATV HD", profile="htsp", hostname="127.0.0.1", username="127.0.0.1", client="Kodi Media Center" 2017-01-15 21:10:22.154 [WARNING] linuxdvb: Unable to provide UNC value. 2017-01-15 21:10:23.037 [WARNING] tsfix: The timediff for TELETEXT is big (3898119747), using current dts 2017-01-15 21:10:23.037 [ ERROR] tsfix: transport stream TELETEXT, DTS discontinuity. DTS = 0, last = 4691811245 2017-01-15 21:23:58.000 [ INFO] epgdb: snapshot start 2017-01-15 21:23:58.763 [ INFO] epgdb: queued to save (size 17388858) 2017-01-15 21:23:58.763 [ INFO] epgdb: brands 0 2017-01-15 21:23:58.763 [ INFO] epgdb: seasons 0 2017-01-15 21:23:58.763 [ INFO] epgdb: episodes 24357 2017-01-15 21:23:58.763 [ INFO] epgdb: broadcasts 24357 2017-01-15 21:23:58.763 [ INFO] epgdb: save start 2017-01-15 21:24:00.056 [ INFO] epgdb: stored (size 3004635) 2017-01-15 21:56:25.436 [ INFO] htsp: Got connection from 10.0.0.13 2017-01-15 21:56:25.450 [ INFO] htsp: 10.0.0.13: Identified as user '' (unverified) 2017-01-15 21:56:25.450 [ INFO] htsp: 10.0.0.13 [ ]: Welcomed client software: org.tvheadend.tvhclient (HTSPv23) 2017-01-15 21:56:25.467 [ INFO] htsp: 10.0.0.13 [ | org.tvheadend.tvhclient ]: Identified as user '' 2017-01-15 21:56:43.748 [ INFO] dvr: entry 4e667f1a036625199387909817d865c5 "Stephen King's A Good Marriage" on "ATV HD" starting at 2017-01-15 22:21:06, scheduled for recording by "10.0.0.13" 2017-01-15 21:57:31.109 [ INFO] htsp: 10.0.0.13 [ | org.tvheadend.tvhclient ]: Disconnected 2017-01-15 22:21:06.001 [ INFO] dvr: "Stephen King's A Good Marriage" on "ATV HD" recorder starting 2017-01-15 22:21:06.001 [ INFO] subscription: 0065: "DVR: Stephen King's A Good Marriage" subscribing on channel "ATV HD", weight: 300, adapter: "TechnoTrend S2-4600", network: "Astra 19,2", mux: "11243.75H", provider: "ATV", service: "ATV HD", profile="pass" 2017-01-15 22:21:37.893 [ INFO] dvr: /storage/recordings/Stephen King's A Good Marriage.ts from adapter: "TechnoTrend S2-4600", network: "Astra 19,2", mux: "11243.75H", provider: "ATV", service: "ATV HD" 2017-01-15 22:21:37.893 [ INFO] dvr: # type lang resolution aspect ratio sample rate channels 2017-01-15 22:21:37.893 [ INFO] dvr: 1 H264 1920x1080 ? 2017-01-15 22:21:37.893 [ INFO] dvr: 2 MPEG2AUDIO ger ? ? 2017-01-15 22:21:37.893 [ INFO] dvr: 3 TELETEXT 2017-01-15 22:21:37.893 [ INFO] dvr: 4 CA 2017-01-15 22:21:37.893 [ INFO] dvr: 5 CA 2017-01-15 22:21:37.893 [ INFO] dvr: 6 CA 2017-01-15 22:21:37.893 [ INFO] dvr: 7 CA 2017-01-15 22:21:37.893 [ INFO] dvr: 8 CA 2017-01-15 22:21:37.893 [ INFO] dvr: 9 CA 2017-01-15 22:21:37.893 [ INFO] dvr: 10 CA 2017-01-15 22:22:08.033 [ INFO] subscription: 0064: "127.0.0.1 [ | Kodi Media Center ]" unsubscribing from "ATV HD", hostname="127.0.0.1", username="127.0.0.1", client="Kodi Media Center" 2017-01-15 22:23:58.000 [ INFO] epgdb: snapshot start 2017-01-15 22:23:58.709 [ INFO] epgdb: queued to save (size 17381305) 2017-01-15 22:23:58.709 [ INFO] epgdb: brands 0 2017-01-15 22:23:58.709 [ INFO] epgdb: seasons 0 2017-01-15 22:23:58.709 [ INFO] epgdb: episodes 24349 2017-01-15 22:23:58.709 [ INFO] epgdb: broadcasts 24349 2017-01-15 22:23:58.709 [ INFO] epgdb: save start 2017-01-15 22:23:59.853 [ INFO] epgdb: stored (size 3003474) 2017-01-15 22:50:20.942 [WARNING] TS: Astra 19,2/11243.75H/ATV HD: H264 @ #2280 Continuity counter error (total 1) 2017-01-15 22:50:20.942 [WARNING] TS: Astra 19,2/11243.75H/ATV HD: TELETEXT @ #2285 Continuity counter error (total 1) 2017-01-15 23:11:40.331 [WARNING] TS: Astra 19,2/11243.75H/ATV HD: H264 @ #2280 Continuity counter error (total 2) 2017-01-15 23:11:40.352 [WARNING] TS: Astra 19,2/11243.75H/ATV HD: TELETEXT @ #2285 Continuity counter error (total 2) 2017-01-15 23:23:58.000 [ INFO] epgdb: snapshot start 2017-01-15 23:23:58.715 [ INFO] epgdb: queued to save (size 17378404) 2017-01-15 23:23:58.715 [ INFO] epgdb: brands 0 2017-01-15 23:23:58.715 [ INFO] epgdb: seasons 0 2017-01-15 23:23:58.715 [ INFO] epgdb: episodes 24346 2017-01-15 23:23:58.715 [ INFO] epgdb: broadcasts 24346 2017-01-15 23:23:58.715 [ INFO] epgdb: save start 2017-01-15 23:23:59.947 [ INFO] epgdb: stored (size 3002777) 2017-01-15 23:33:35.723 [WARNING] TS: Astra 19,2/11243.75H/ATV HD: H264 @ #2280 Continuity counter error (total 3) 2017-01-16 00:17:39.787 [WARNING] TS: Astra 19,2/11243.75H/ATV HD: H264 @ #2280 Continuity counter error (total 4) 2017-01-16 00:23:58.000 [ INFO] epgdb: snapshot start 2017-01-16 00:23:58.720 [ INFO] epgdb: queued to save (size 17373220) 2017-01-16 00:23:58.720 [ INFO] epgdb: brands 0 2017-01-16 00:23:58.720 [ INFO] epgdb: seasons 0 2017-01-16 00:23:58.720 [ INFO] epgdb: episodes 24340 2017-01-16 00:23:58.720 [ INFO] epgdb: save start 2017-01-16 00:23:58.720 [ INFO] epgdb: broadcasts 24340 2017-01-16 00:23:59.880 [ INFO] epgdb: stored (size 3002107) 2017-01-16 00:26:16.955 [ INFO] subscription: 0065: "DVR: Stephen King's A Good Marriage" unsubscribing from "ATV HD" 2017-01-16 00:26:16.958 [ INFO] dvr: "Stephen King's A Good Marriage" on "ATV HD": End of program: Completed OK 2017-01-16 01:23:58.000 [ INFO] epgdb: snapshot start 2017-01-16 01:23:58.713 [ INFO] epgdb: queued to save (size 17368986) 2017-01-16 01:23:58.713 [ INFO] epgdb: brands 0 2017-01-16 01:23:58.713 [ INFO] epgdb: seasons 0 2017-01-16 01:23:58.713 [ INFO] epgdb: episodes 24335 2017-01-16 01:23:58.713 [ INFO] epgdb: broadcasts 24335 2017-01-16 01:23:58.713 [ INFO] epgdb: save start 2017-01-16 01:23:59.843 [ INFO] epgdb: stored (size 3001477) 2017-01-16 02:23:58.000 [ INFO] epgdb: snapshot start 2017-01-16 02:23:58.734 [ INFO] epgdb: queued to save (size 17367726) 2017-01-16 02:23:58.734 [ INFO] epgdb: brands 0 2017-01-16 02:23:58.734 [ INFO] epgdb: seasons 0 2017-01-16 02:23:58.734 [ INFO] epgdb: save start 2017-01-16 02:23:58.734 [ INFO] epgdb: episodes 24334 2017-01-16 02:23:58.734 [ INFO] epgdb: broadcasts 24334 2017-01-16 02:23:59.882 [ INFO] epgdb: stored (size 3001009) 2017-01-16 03:23:58.000 [ INFO] epgdb: snapshot start 2017-01-16 03:23:58.743 [ INFO] epgdb: queued to save (size 17365589) 2017-01-16 03:23:58.743 [ INFO] epgdb: brands 0 2017-01-16 03:23:58.743 [ INFO] epgdb: seasons 0 2017-01-16 03:23:58.743 [ INFO] epgdb: episodes 24332 2017-01-16 03:23:58.743 [ INFO] epgdb: broadcasts 24332 2017-01-16 03:23:58.743 [ INFO] epgdb: save start 2017-01-16 03:23:59.875 [ INFO] epgdb: stored (size 3000575) 2017-01-16 04:23:58.000 [ INFO] epgdb: snapshot start 2017-01-16 04:23:58.743 [ INFO] epgdb: queued to save (size 17362490) 2017-01-16 04:23:58.743 [ INFO] epgdb: brands 0 2017-01-16 04:23:58.743 [ INFO] epgdb: seasons 0 2017-01-16 04:23:58.743 [ INFO] epgdb: episodes 24329 2017-01-16 04:23:58.743 [ INFO] epgdb: broadcasts 24329 2017-01-16 04:23:58.743 [ INFO] epgdb: save start 2017-01-16 04:23:59.889 [ INFO] epgdb: stored (size 2999748) 2017-01-16 05:23:58.000 [ INFO] epgdb: snapshot start 2017-01-16 05:23:58.748 [ INFO] epgdb: queued to save (size 17360759) 2017-01-16 05:23:58.748 [ INFO] epgdb: brands 0 2017-01-16 05:23:58.748 [ INFO] epgdb: seasons 0 2017-01-16 05:23:58.748 [ INFO] epgdb: episodes 24327 2017-01-16 05:23:58.748 [ INFO] epgdb: broadcasts 24327 2017-01-16 05:23:58.748 [ INFO] epgdb: save start 2017-01-16 05:23:59.874 [ INFO] epgdb: stored (size 2999301) 2017-01-16 06:23:58.000 [ INFO] epgdb: snapshot start 2017-01-16 06:23:58.714 [ INFO] epgdb: queued to save (size 17358592) 2017-01-16 06:23:58.714 [ INFO] epgdb: brands 0 2017-01-16 06:23:58.714 [ INFO] epgdb: seasons 0 2017-01-16 06:23:58.714 [ INFO] epgdb: episodes 24325 2017-01-16 06:23:58.714 [ INFO] epgdb: broadcasts 24325 2017-01-16 06:23:58.714 [ INFO] epgdb: save start 2017-01-16 06:23:59.840 [ INFO] epgdb: stored (size 2998468) 2017-01-16 07:23:58.000 [ INFO] epgdb: snapshot start 2017-01-16 07:23:58.705 [ INFO] epgdb: queued to save (size 17357312) 2017-01-16 07:23:58.705 [ INFO] epgdb: brands 0 2017-01-16 07:23:58.705 [ INFO] epgdb: seasons 0 2017-01-16 07:23:58.705 [ INFO] epgdb: episodes 24324 2017-01-16 07:23:58.705 [ INFO] epgdb: broadcasts 24324 2017-01-16 07:23:58.705 [ INFO] epgdb: save start 2017-01-16 07:23:59.827 [ INFO] epgdb: stored (size 2997948) 2017-01-16 08:23:58.000 [ INFO] epgdb: snapshot start 2017-01-16 08:23:58.727 [ INFO] epgdb: queued to save (size 17356250) 2017-01-16 08:23:58.727 [ INFO] epgdb: brands 0 2017-01-16 08:23:58.727 [ INFO] epgdb: seasons 0 2017-01-16 08:23:58.727 [ INFO] epgdb: episodes 24323 2017-01-16 08:23:58.727 [ INFO] epgdb: save start 2017-01-16 08:23:58.727 [ INFO] epgdb: broadcasts 24323 2017-01-16 08:23:59.848 [ INFO] epgdb: stored (size 2997674) 2017-01-16 09:23:58.000 [ INFO] epgdb: snapshot start 2017-01-16 09:23:58.713 [ INFO] epgdb: queued to save (size 17354840) 2017-01-16 09:23:58.713 [ INFO] epgdb: brands 0 2017-01-16 09:23:58.713 [ INFO] epgdb: seasons 0 2017-01-16 09:23:58.713 [ INFO] epgdb: episodes 24321 2017-01-16 09:23:58.713 [ INFO] epgdb: broadcasts 24321 2017-01-16 09:23:58.713 [ INFO] epgdb: save start 2017-01-16 09:23:59.888 [ INFO] epgdb: stored (size 2997454) 2017-01-16 10:23:58.000 [ INFO] epgdb: snapshot start 2017-01-16 10:23:58.729 [ INFO] epgdb: queued to save (size 17352050) 2017-01-16 10:23:58.729 [ INFO] epgdb: save start 2017-01-16 10:23:58.730 [ INFO] epgdb: brands 0 2017-01-16 10:23:58.730 [ INFO] epgdb: seasons 0 2017-01-16 10:23:58.730 [ INFO] epgdb: episodes 24318 2017-01-16 10:23:58.730 [ INFO] epgdb: broadcasts 24318 2017-01-16 10:23:59.872 [ INFO] epgdb: stored (size 2996515) 2017-01-16 11:23:58.000 [ INFO] epgdb: snapshot start 2017-01-16 11:23:58.709 [ INFO] epgdb: queued to save (size 17350198) 2017-01-16 11:23:58.709 [ INFO] epgdb: brands 0 2017-01-16 11:23:58.709 [ INFO] epgdb: seasons 0 2017-01-16 11:23:58.709 [ INFO] epgdb: episodes 24316 2017-01-16 11:23:58.709 [ INFO] epgdb: broadcasts 24316 2017-01-16 11:23:58.709 [ INFO] epgdb: save start 2017-01-16 11:23:59.847 [ INFO] epgdb: stored (size 2996300) 2017-01-16 12:23:58.000 [ INFO] epgdb: snapshot start 2017-01-16 12:23:58.719 [ INFO] epgdb: queued to save (size 17349443) 2017-01-16 12:23:58.719 [ INFO] epgdb: brands 0 2017-01-16 12:23:58.719 [ INFO] epgdb: seasons 0 2017-01-16 12:23:58.719 [ INFO] epgdb: episodes 24315 2017-01-16 12:23:58.719 [ INFO] epgdb: broadcasts 24315 2017-01-16 12:23:58.719 [ INFO] epgdb: save start 2017-01-16 12:23:59.851 [ INFO] epgdb: stored (size 2996177) 2017-01-16 13:23:58.000 [ INFO] epgdb: snapshot start 2017-01-16 13:23:58.714 [ INFO] epgdb: queued to save (size 17348193) 2017-01-16 13:23:58.714 [ INFO] epgdb: brands 0 2017-01-16 13:23:58.714 [ INFO] epgdb: seasons 0 2017-01-16 13:23:58.714 [ INFO] epgdb: episodes 24314 2017-01-16 13:23:58.714 [ INFO] epgdb: broadcasts 24314 2017-01-16 13:23:58.714 [ INFO] epgdb: save start 2017-01-16 13:23:59.847 [ INFO] epgdb: stored (size 2995738) 2017-01-16 14:23:58.000 [ INFO] epgdb: snapshot start 2017-01-16 14:23:58.734 [ INFO] epgdb: queued to save (size 17346918) 2017-01-16 14:23:58.734 [ INFO] epgdb: brands 0 2017-01-16 14:23:58.734 [ INFO] epgdb: seasons 0 2017-01-16 14:23:58.734 [ INFO] epgdb: episodes 24313 2017-01-16 14:23:58.734 [ INFO] epgdb: broadcasts 24313 2017-01-16 14:23:58.734 [ INFO] epgdb: save start 2017-01-16 14:23:59.866 [ INFO] epgdb: stored (size 2995233) 2017-01-16 15:23:58.000 [ INFO] epgdb: snapshot start 2017-01-16 15:23:58.713 [ INFO] epgdb: queued to save (size 17345287) 2017-01-16 15:23:58.713 [ INFO] epgdb: brands 0 2017-01-16 15:23:58.713 [ INFO] epgdb: save start 2017-01-16 15:23:58.713 [ INFO] epgdb: seasons 0 2017-01-16 15:23:58.713 [ INFO] epgdb: episodes 24311 2017-01-16 15:23:58.713 [ INFO] epgdb: broadcasts 24311 2017-01-16 15:23:59.849 [ INFO] epgdb: stored (size 2995132) 2017-01-16 16:23:58.000 [ INFO] epgdb: snapshot start 2017-01-16 16:23:58.742 [ INFO] epgdb: queued to save (size 17344211) 2017-01-16 16:23:58.742 [ INFO] epgdb: brands 0 2017-01-16 16:23:58.742 [ INFO] epgdb: seasons 0 2017-01-16 16:23:58.742 [ INFO] epgdb: episodes 24310 2017-01-16 16:23:58.742 [ INFO] epgdb: save start 2017-01-16 16:23:58.742 [ INFO] epgdb: broadcasts 24310 2017-01-16 16:23:59.875 [ INFO] epgdb: stored (size 2995068) ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: dvb usb issues since kernel 4.9 2018-01-07 15:41 ` Alan Stern 2018-01-07 17:01 ` Aw: " Josef Griebichler @ 2018-01-08 9:43 ` Mauro Carvalho Chehab 2018-01-08 16:10 ` Alan Stern 2018-01-08 16:26 ` Aw: " Josef Griebichler 1 sibling, 2 replies; 47+ messages in thread From: Mauro Carvalho Chehab @ 2018-01-08 9:43 UTC (permalink / raw) To: Alan Stern Cc: Josef Griebichler, Greg Kroah-Hartman, linux-usb, Eric Dumazet, Rik van Riel, Paolo Abeni, Hannes Frederic Sowa, Jesper Dangaard Brouer, linux-kernel, netdev, Jonathan Corbet, LMML, Peter Zijlstra, David Miller, torvalds Em Sun, 7 Jan 2018 10:41:37 -0500 (EST) Alan Stern <stern@rowland.harvard.edu> escreveu: > On Sun, 7 Jan 2018, Mauro Carvalho Chehab wrote: > > > > > It seems that the original patch were designed to solve some IRQ issues > > > > with network cards with causes data losses on high traffic. However, > > > > it is also causing bad effects on sustained high bandwidth demands > > > > required by DVB cards, at least on some USB host drivers. > > > > > > > > Alan/Greg/Eric/David: > > > > > > > > Any ideas about how to fix it without causing regressions to > > > > network? > > > > > > It would be good to know what hardware was involved on the x86 system > > > and to have some timing data. Can we see the output from lsusb and > > > usbmon, running on a vanilla kernel that gets plenty of video glitches? > > > > From Josef's report, and from the BZ, the affected hardware seems > > to be based on Montage Technology M88DS3103/M88TS2022 chipset. > > What type of USB host controller does the x86_64 system use? EHCI or > xHCI? I'll let Josef answer this. > > > The driver it uses is at drivers/media/usb/dvb-usb-v2/dvbsky.c, > > with shares a USB implementation that is used by a lot more drivers. > > The URB handling code is at: > > > > drivers/media/usb/dvb-usb-v2/usb_urb.c > > > > This particular driver allocates 8 buffers with 4096 bytes each > > for bulk transfers, using transfer_flags = URB_NO_TRANSFER_DMA_MAP. > > > > This become a popular USB hardware nowadays. I have one S960c > > myself, so I can send you the lsusb from it. You should notice, however, > > that a DVB-C/DVB-S2 channel can easily provide very high sustained bit > > rates. Here, on my DVB-S2 provider, a typical transponder produces 58 Mpps > > of payload after removing URB headers. > > You mentioned earlier that the driver uses bulk transfers. In USB-2.0, > the maximum possible payload data transfer rate using bulk transfers is > 53248 bytes/ms, which is 53.248 MB/s (i.e., lower than 58 MB/s). And > even this is possible only if almost nothing else is using the bus at > the same time. No, I said 58 Mbits/s (not bytes). On DVB-C and DVB-S2 specs, AFAIKT, there's no hard limit for the maximum payload data rate, although industry seems to limit it to be around 60 Mbits/s. On those standards, the maximal bit rate is defined by the modulation type and by the channel symbol rate. To give you a practical example, my DVB-S2 provider modulates each transponder with 8/PSK (3 bits/symbol), and define channels with a symbol rate of 30 Mbauds/s. So, it could, theoretically, transport a MPEG-TS stream up to 90 Mbits/s (minus headers and guard intervals). In practice, the streams there are transmitted with 58,026.5 Kbits/s. > > A 10 minutes record with the > > entire data (with typically contains 5-10 channels) can easily go > > above 4 GB, just to reproduce 1-2 glitches. So, I'm not sure if > > a usbmon dump would be useful. > > It might not be helpful at all. However, I'm not interested in the > payload data (which would be unintelligible to me anyway) but rather > the timing of URB submissions and completions. A usbmon trace which > didn't keep much of the payload data would only require on the order of > 50 MB per minute -- and Josef said that glitches usually would show up > within a minute or so. Yeah, this could help. Josef, You can get it with wireshark/tshark or tcpdump. See: https://technolinchpin.wordpress.com/2015/10/23/usb-bus-sniffers-for-linux-system/ https://wiki.wireshark.org/CaptureSetup/USB > > I'm enclosing the lsusb from a S960C device, with is based on those > > Montage chipsets: > > What I wanted to see was the output from "lsusb" on the affected > system, not the output from "lsusb -v -s B:D" on your system. > > > > Overall, this may be a very difficult problem to solve. The > > > 4cd13c21b207 commit was intended to improve throughput at the cost of > > > increased latency. But then what do you do when the latency becomes > > > too high for the video subsystem to handle? > > > > Latency can't be too high, otherwise frames will be dropped. > > Yes, that's the whole point. > > > Even if the Kernel itself doesn't drop, if the delay goes higher > > than a certain threshold, userspace will need to drop, as it > > should be presenting audio and video on real time. Yet, typically, > > userspace will delay it by one or two seconds, with would mean > > 1500-3500 buffers, with I suspect it is a lot more than the hardware > > limits. So I suspect that the hardware starves free buffers a way > > before userspace, as media hardware don't have unlimited buffers > > inside them, as they assume that the Kernel/userspace will be fast > > enough to sustain bit rates up to 66 Mbps of payload. > > The timing information would tell us how large the latency is. > > In any case, you might be able to attack the problem simply by using > more than 8 buffers. With just eight 4096-byte buffers, the total > pipeline capacity is only about 0.62 ms (at the maximum possible > transfer rate). Increasing the number of buffers to 65 would give a > capacity of 5 ms, which is probably a lot better suited for situations > where completions are handled by the ksoftirqd thread. Increasing it to 65 shouldn't be hard. Not sure, however, if the hardware will actually fill the 65 buffers, but it is worth to try. > > Perhaps media drivers could pass some quirk similar to URB_ISO_ASAP, > > in order to revert the kernel logic to prioritize latency instead of > > throughput. > > It can't be done without pervasive changes to the USB subsystem, which > I would greatly prefer to avoid. Besides, this wouldn't really solve > the problem. Decreasing the latency for one device will cause it to be > increased for others. If there is a TV streaming traffic at a USB bus, it means that the user wants to either watch and/or record a TV program. On such usecase scenario, a low latency is highly desired for the TV capture (and display, if the GPU is USB), even it means a higher latency for other traffic. Josef, Could you please try the following patch on Kernel 4.14.10 (without reverting any changesets), and see if it fixes the issue? media: dvbsky: Increase the number of buffers Right now, This driver expects a 0.62 ms delay with 8 buffers on an USB 2.0 high speed bus. Increase it to 65 buffers, in order to give more time for the top half of the USB transfer handler to complete its task. Suggested-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com> diff --git a/drivers/media/usb/dvb-usb-v2/dvbsky.c b/drivers/media/usb/dvb-usb-v2/dvbsky.c index 131b6c08e199..d3f5ffc54b25 100644 --- a/drivers/media/usb/dvb-usb-v2/dvbsky.c +++ b/drivers/media/usb/dvb-usb-v2/dvbsky.c @@ -740,7 +740,7 @@ static struct dvb_usb_device_properties dvbsky_s960_props = { .num_adapters = 1, .adapter = { { - .stream = DVB_USB_STREAM_BULK(0x82, 8, 4096), + .stream = DVB_USB_STREAM_BULK(0x82, 65, 4096), } } }; > Thanks, Mauro ^ permalink raw reply related [flat|nested] 47+ messages in thread
* Re: dvb usb issues since kernel 4.9 2018-01-08 9:43 ` Mauro Carvalho Chehab @ 2018-01-08 16:10 ` Alan Stern 2018-01-08 16:26 ` Aw: " Josef Griebichler 1 sibling, 0 replies; 47+ messages in thread From: Alan Stern @ 2018-01-08 16:10 UTC (permalink / raw) To: Mauro Carvalho Chehab Cc: Josef Griebichler, Greg Kroah-Hartman, linux-usb, Eric Dumazet, Rik van Riel, Paolo Abeni, Hannes Frederic Sowa, Jesper Dangaard Brouer, linux-kernel, netdev, Jonathan Corbet, LMML, Peter Zijlstra, David Miller, torvalds On Mon, 8 Jan 2018, Mauro Carvalho Chehab wrote: > Em Sun, 7 Jan 2018 10:41:37 -0500 (EST) > Alan Stern <stern@rowland.harvard.edu> escreveu: > > > On Sun, 7 Jan 2018, Mauro Carvalho Chehab wrote: > > > > > > > It seems that the original patch were designed to solve some IRQ issues > > > > > with network cards with causes data losses on high traffic. However, > > > > > it is also causing bad effects on sustained high bandwidth demands > > > > > required by DVB cards, at least on some USB host drivers. > > > > > > > > > > Alan/Greg/Eric/David: > > > > > > > > > > Any ideas about how to fix it without causing regressions to > > > > > network? > > > > > > > > It would be good to know what hardware was involved on the x86 system > > > > and to have some timing data. Can we see the output from lsusb and > > > > usbmon, running on a vanilla kernel that gets plenty of video glitches? > > > > > > From Josef's report, and from the BZ, the affected hardware seems > > > to be based on Montage Technology M88DS3103/M88TS2022 chipset. > > > > What type of USB host controller does the x86_64 system use? EHCI or > > xHCI? > > I'll let Josef answer this. > > > > > > The driver it uses is at drivers/media/usb/dvb-usb-v2/dvbsky.c, > > > with shares a USB implementation that is used by a lot more drivers. > > > The URB handling code is at: > > > > > > drivers/media/usb/dvb-usb-v2/usb_urb.c > > > > > > This particular driver allocates 8 buffers with 4096 bytes each > > > for bulk transfers, using transfer_flags = URB_NO_TRANSFER_DMA_MAP. > > > > > > This become a popular USB hardware nowadays. I have one S960c > > > myself, so I can send you the lsusb from it. You should notice, however, > > > that a DVB-C/DVB-S2 channel can easily provide very high sustained bit > > > rates. Here, on my DVB-S2 provider, a typical transponder produces 58 Mpps > > > of payload after removing URB headers. > > > > You mentioned earlier that the driver uses bulk transfers. In USB-2.0, > > the maximum possible payload data transfer rate using bulk transfers is > > 53248 bytes/ms, which is 53.248 MB/s (i.e., lower than 58 MB/s). And > > even this is possible only if almost nothing else is using the bus at > > the same time. > > No, I said 58 Mbits/s (not bytes). Well, what you actually _wrote_ was "58 Mpps of payload" (see above), and I couldn't tell how to interpret that. :-) 58 Mb/s is obviously almost 8 times less than the full USB bus bandwidth. > On DVB-C and DVB-S2 specs, AFAIKT, there's no hard limit for the maximum > payload data rate, although industry seems to limit it to be around > 60 Mbits/s. On those standards, the maximal bit rate is defined by the > modulation type and by the channel symbol rate. > > To give you a practical example, my DVB-S2 provider modulates each > transponder with 8/PSK (3 bits/symbol), and define channels with a > symbol rate of 30 Mbauds/s. So, it could, theoretically, transport > a MPEG-TS stream up to 90 Mbits/s (minus headers and guard intervals). > In practice, the streams there are transmitted with 58,026.5 Kbits/s. Okay. This is 58 Kb/ms or 7.25 KB/ms. So your scheme of eight 4-KB buffers gives a latency of 0.57 ms with a total capacity of 4.5 ms, which is a lot better than what I was thinking. > > In any case, you might be able to attack the problem simply by using > > more than 8 buffers. With just eight 4096-byte buffers, the total > > pipeline capacity is only about 0.62 ms (at the maximum possible > > transfer rate). Increasing the number of buffers to 65 would give a > > capacity of 5 ms, which is probably a lot better suited for situations > > where completions are handled by the ksoftirqd thread. > > Increasing it to 65 shouldn't be hard. Not sure, however, if the hardware > will actually fill the 65 buffers, but it is worth to try. Given the new information, 65 would be overkill. But going from 8 to 16 might help. > > > Perhaps media drivers could pass some quirk similar to URB_ISO_ASAP, > > > in order to revert the kernel logic to prioritize latency instead of > > > throughput. > > > > It can't be done without pervasive changes to the USB subsystem, which > > I would greatly prefer to avoid. Besides, this wouldn't really solve > > the problem. Decreasing the latency for one device will cause it to be > > increased for others. > > If there is a TV streaming traffic at a USB bus, it means that the > user wants to either watch and/or record a TV program. On such > usecase scenario, a low latency is highly desired for the TV capture > (and display, if the GPU is USB), even it means a higher latency for > other traffic. Not if the other traffic is also a TV capture. :-) It might make sense to classify softirq sources as "high priority" or "low priority", and only defer the "low priority" work to ksoftirqd. Alan Stern ^ permalink raw reply [flat|nested] 47+ messages in thread
* Aw: Re: dvb usb issues since kernel 4.9 2018-01-08 9:43 ` Mauro Carvalho Chehab 2018-01-08 16:10 ` Alan Stern @ 2018-01-08 16:26 ` Josef Griebichler 2018-01-08 16:31 ` Alan Stern 2018-01-08 21:31 ` Jesper Dangaard Brouer 1 sibling, 2 replies; 47+ messages in thread From: Josef Griebichler @ 2018-01-08 16:26 UTC (permalink / raw) To: Mauro Carvalho Chehab Cc: Alan Stern, Greg Kroah-Hartman, linux-usb, Eric Dumazet, Rik van Riel, Paolo Abeni, Hannes Frederic Sowa, Jesper Dangaard Brouer, linux-kernel, netdev, Jonathan Corbet, LMML, Peter Zijlstra, David Miller, torvalds Hi Maro, I tried your mentioned patch but unfortunately no real improvement for me. dmesg http://ix.io/DOg tvheadend service log http://ix.io/DOi Errors during recording are still there. Errors increase if there is additional tcp load on raspberry. Unfortunately there's no usbmon or tshark on libreelec so I can't provide further logs. Regards, Josef > On Sun, 7 Jan 2018, Mauro Carvalho Chehab wrote: > > > > > It seems that the original patch were designed to solve some IRQ issues > > > > with network cards with causes data losses on high traffic. However, > > > > it is also causing bad effects on sustained high bandwidth demands > > > > required by DVB cards, at least on some USB host drivers. > > > > > > > > Alan/Greg/Eric/David: > > > > > > > > Any ideas about how to fix it without causing regressions to > > > > network? > > > > > > It would be good to know what hardware was involved on the x86 system > > > and to have some timing data. Can we see the output from lsusb and > > > usbmon, running on a vanilla kernel that gets plenty of video glitches? > > > > From Josef's report, and from the BZ, the affected hardware seems > > to be based on Montage Technology M88DS3103/M88TS2022 chipset. > > What type of USB host controller does the x86_64 system use? EHCI or > xHCI? I'll let Josef answer this. > > > The driver it uses is at drivers/media/usb/dvb-usb-v2/dvbsky.c, > > with shares a USB implementation that is used by a lot more drivers. > > The URB handling code is at: > > > > drivers/media/usb/dvb-usb-v2/usb_urb.c > > > > This particular driver allocates 8 buffers with 4096 bytes each > > for bulk transfers, using transfer_flags = URB_NO_TRANSFER_DMA_MAP. > > > > This become a popular USB hardware nowadays. I have one S960c > > myself, so I can send you the lsusb from it. You should notice, however, > > that a DVB-C/DVB-S2 channel can easily provide very high sustained bit > > rates. Here, on my DVB-S2 provider, a typical transponder produces 58 Mpps > > of payload after removing URB headers. > > You mentioned earlier that the driver uses bulk transfers. In USB-2.0, > the maximum possible payload data transfer rate using bulk transfers is > 53248 bytes/ms, which is 53.248 MB/s (i.e., lower than 58 MB/s). And > even this is possible only if almost nothing else is using the bus at > the same time. No, I said 58 Mbits/s (not bytes). On DVB-C and DVB-S2 specs, AFAIKT, there's no hard limit for the maximum payload data rate, although industry seems to limit it to be around 60 Mbits/s. On those standards, the maximal bit rate is defined by the modulation type and by the channel symbol rate. To give you a practical example, my DVB-S2 provider modulates each transponder with 8/PSK (3 bits/symbol), and define channels with a symbol rate of 30 Mbauds/s. So, it could, theoretically, transport a MPEG-TS stream up to 90 Mbits/s (minus headers and guard intervals). In practice, the streams there are transmitted with 58,026.5 Kbits/s. > > A 10 minutes record with the > > entire data (with typically contains 5-10 channels) can easily go > > above 4 GB, just to reproduce 1-2 glitches. So, I'm not sure if > > a usbmon dump would be useful. > > It might not be helpful at all. However, I'm not interested in the > payload data (which would be unintelligible to me anyway) but rather > the timing of URB submissions and completions. A usbmon trace which > didn't keep much of the payload data would only require on the order of > 50 MB per minute -- and Josef said that glitches usually would show up > within a minute or so. Yeah, this could help. Josef, You can get it with wireshark/tshark or tcpdump. See: https://technolinchpin.wordpress.com/2015/10/23/usb-bus-sniffers-for-linux-system/ https://wiki.wireshark.org/CaptureSetup/USB > > I'm enclosing the lsusb from a S960C device, with is based on those > > Montage chipsets: > > What I wanted to see was the output from "lsusb" on the affected > system, not the output from "lsusb -v -s B:D" on your system. > > > > Overall, this may be a very difficult problem to solve. The > > > 4cd13c21b207 commit was intended to improve throughput at the cost of > > > increased latency. But then what do you do when the latency becomes > > > too high for the video subsystem to handle? > > > > Latency can't be too high, otherwise frames will be dropped. > > Yes, that's the whole point. > > > Even if the Kernel itself doesn't drop, if the delay goes higher > > than a certain threshold, userspace will need to drop, as it > > should be presenting audio and video on real time. Yet, typically, > > userspace will delay it by one or two seconds, with would mean > > 1500-3500 buffers, with I suspect it is a lot more than the hardware > > limits. So I suspect that the hardware starves free buffers a way > > before userspace, as media hardware don't have unlimited buffers > > inside them, as they assume that the Kernel/userspace will be fast > > enough to sustain bit rates up to 66 Mbps of payload. > > The timing information would tell us how large the latency is. > > In any case, you might be able to attack the problem simply by using > more than 8 buffers. With just eight 4096-byte buffers, the total > pipeline capacity is only about 0.62 ms (at the maximum possible > transfer rate). Increasing the number of buffers to 65 would give a > capacity of 5 ms, which is probably a lot better suited for situations > where completions are handled by the ksoftirqd thread. Increasing it to 65 shouldn't be hard. Not sure, however, if the hardware will actually fill the 65 buffers, but it is worth to try. > > Perhaps media drivers could pass some quirk similar to URB_ISO_ASAP, > > in order to revert the kernel logic to prioritize latency instead of > > throughput. > > It can't be done without pervasive changes to the USB subsystem, which > I would greatly prefer to avoid. Besides, this wouldn't really solve > the problem. Decreasing the latency for one device will cause it to be > increased for others. If there is a TV streaming traffic at a USB bus, it means that the user wants to either watch and/or record a TV program. On such usecase scenario, a low latency is highly desired for the TV capture (and display, if the GPU is USB), even it means a higher latency for other traffic. Josef, Could you please try the following patch on Kernel 4.14.10 (without reverting any changesets), and see if it fixes the issue? media: dvbsky: Increase the number of buffers Right now, This driver expects a 0.62 ms delay with 8 buffers on an USB 2.0 high speed bus. Increase it to 65 buffers, in order to give more time for the top half of the USB transfer handler to complete its task. Suggested-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com> diff --git a/drivers/media/usb/dvb-usb-v2/dvbsky.c b/drivers/media/usb/dvb-usb-v2/dvbsky.c index 131b6c08e199..d3f5ffc54b25 100644 --- a/drivers/media/usb/dvb-usb-v2/dvbsky.c +++ b/drivers/media/usb/dvb-usb-v2/dvbsky.c @@ -740,7 +740,7 @@ static struct dvb_usb_device_properties dvbsky_s960_props = { .num_adapters = 1, .adapter = { { - .stream = DVB_USB_STREAM_BULK(0x82, 8, 4096), + .stream = DVB_USB_STREAM_BULK(0x82, 65, 4096), } } }; > Thanks, Mauro ^ permalink raw reply related [flat|nested] 47+ messages in thread
* Re: Aw: Re: dvb usb issues since kernel 4.9 2018-01-08 16:26 ` Aw: " Josef Griebichler @ 2018-01-08 16:31 ` Alan Stern 2018-01-08 17:15 ` Aw: " Josef Griebichler 2018-01-08 21:31 ` Jesper Dangaard Brouer 1 sibling, 1 reply; 47+ messages in thread From: Alan Stern @ 2018-01-08 16:31 UTC (permalink / raw) To: Josef Griebichler Cc: Mauro Carvalho Chehab, Greg Kroah-Hartman, linux-usb, Eric Dumazet, Rik van Riel, Paolo Abeni, Hannes Frederic Sowa, Jesper Dangaard Brouer, linux-kernel, netdev, Jonathan Corbet, LMML, Peter Zijlstra, David Miller, torvalds On Mon, 8 Jan 2018, Josef Griebichler wrote: > Hi Maro, > > I tried your mentioned patch but unfortunately no real improvement for me. > dmesg http://ix.io/DOg > tvheadend service log http://ix.io/DOi > Errors during recording are still there. > Errors increase if there is additional tcp load on raspberry. > > Unfortunately there's no usbmon or tshark on libreelec so I can't provide further logs. Can you try running the same test on an x86_64 system? Alan Stern ^ permalink raw reply [flat|nested] 47+ messages in thread
* Aw: Re: Re: dvb usb issues since kernel 4.9 2018-01-08 16:31 ` Alan Stern @ 2018-01-08 17:15 ` Josef Griebichler 2018-01-08 17:35 ` Alan Stern 0 siblings, 1 reply; 47+ messages in thread From: Josef Griebichler @ 2018-01-08 17:15 UTC (permalink / raw) To: Alan Stern Cc: Mauro Carvalho Chehab, Greg Kroah-Hartman, linux-usb, Eric Dumazet, Rik van Riel, Paolo Abeni, Hannes Frederic Sowa, Jesper Dangaard Brouer, linux-kernel, netdev, Jonathan Corbet, LMML, Peter Zijlstra, David Miller, torvalds No I can't sorry. There's no sat connection near to my workstation. Gesendet: Montag, 08. Januar 2018 um 17:31 Uhr Von: "Alan Stern" <stern@rowland.harvard.edu> An: "Josef Griebichler" <griebichler.josef@gmx.at> Cc: "Mauro Carvalho Chehab" <mchehab@s-opensource.com>, "Greg Kroah-Hartman" <gregkh@linuxfoundation.org>, linux-usb@vger.kernel.org, "Eric Dumazet" <edumazet@google.com>, "Rik van Riel" <riel@redhat.com>, "Paolo Abeni" <pabeni@redhat.com>, "Hannes Frederic Sowa" <hannes@redhat.com>, "Jesper Dangaard Brouer" <jbrouer@redhat.com>, linux-kernel <linux-kernel@vger.kernel.org>, netdev <netdev@vger.kernel.org>, "Jonathan Corbet" <corbet@lwn.net>, LMML <linux-media@vger.kernel.org>, "Peter Zijlstra" <peterz@infradead.org>, "David Miller" <davem@davemloft.net>, torvalds@linux-foundation.org Betreff: Re: Aw: Re: dvb usb issues since kernel 4.9 On Mon, 8 Jan 2018, Josef Griebichler wrote: > Hi Maro, > > I tried your mentioned patch but unfortunately no real improvement for me. > dmesg http://ix.io/DOg > tvheadend service log http://ix.io/DOi[http://ix.io/DOi] > Errors during recording are still there. > Errors increase if there is additional tcp load on raspberry. > > Unfortunately there's no usbmon or tshark on libreelec so I can't provide further logs. Can you try running the same test on an x86_64 system? Alan Stern ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: Aw: Re: Re: dvb usb issues since kernel 4.9 2018-01-08 17:15 ` Aw: " Josef Griebichler @ 2018-01-08 17:35 ` Alan Stern 2018-01-08 20:40 ` Jesper Dangaard Brouer 0 siblings, 1 reply; 47+ messages in thread From: Alan Stern @ 2018-01-08 17:35 UTC (permalink / raw) To: Josef Griebichler Cc: Mauro Carvalho Chehab, Greg Kroah-Hartman, linux-usb, Eric Dumazet, Rik van Riel, Paolo Abeni, Hannes Frederic Sowa, Jesper Dangaard Brouer, linux-kernel, netdev, Jonathan Corbet, LMML, Peter Zijlstra, David Miller, torvalds On Mon, 8 Jan 2018, Josef Griebichler wrote: > No I can't sorry. There's no sat connection near to my workstation. Can we ask the person who made this post: https://forum.libreelec.tv/thread/4235-dvb-issue-since-le-switched-to-kernel-4-9-x/?postID=75965#post75965 to run the test? The post says that the testing was done on an x86_64 machine. > Gesendet: Montag, 08. Januar 2018 um 17:31 Uhr > Von: "Alan Stern" <stern@rowland.harvard.edu> > An: "Josef Griebichler" <griebichler.josef@gmx.at> > Cc: "Mauro Carvalho Chehab" <mchehab@s-opensource.com>, "Greg Kroah-Hartman" <gregkh@linuxfoundation.org>, linux-usb@vger.kernel.org, "Eric Dumazet" <edumazet@google.com>, "Rik van Riel" <riel@redhat.com>, "Paolo Abeni" <pabeni@redhat.com>, "Hannes Frederic Sowa" <hannes@redhat.com>, "Jesper Dangaard Brouer" <jbrouer@redhat.com>, linux-kernel <linux-kernel@vger.kernel.org>, netdev <netdev@vger.kernel.org>, "Jonathan Corbet" <corbet@lwn.net>, LMML <linux-media@vger.kernel.org>, "Peter Zijlstra" <peterz@infradead.org>, "David Miller" <davem@davemloft.net>, torvalds@linux-foundation.org > Betreff: Re: Aw: Re: dvb usb issues since kernel 4.9 > On Mon, 8 Jan 2018, Josef Griebichler wrote: > Hi Maro, > > I tried your mentioned patch but unfortunately no real improvement for me. > dmesg http://ix.io/DOg > tvheadend service log http://ix.io/DOi[http://ix.io/DOi] > Errors during recording are still there. > Errors increase if there is additional tcp load on raspberry. > > Unfortunately there's no usbmon or tshark on libreelec so I can't provide further logs. Can you try running the same test on an x86_64 system? Alan Stern It appears that you are using a non-standard kernel. The vanilla kernel does not include any "dwc_otg_hcd" driver. Alan Stern ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: Re: dvb usb issues since kernel 4.9 2018-01-08 17:35 ` Alan Stern @ 2018-01-08 20:40 ` Jesper Dangaard Brouer 0 siblings, 0 replies; 47+ messages in thread From: Jesper Dangaard Brouer @ 2018-01-08 20:40 UTC (permalink / raw) To: Alan Stern Cc: Josef Griebichler, Mauro Carvalho Chehab, Greg Kroah-Hartman, linux-usb, Eric Dumazet, Rik van Riel, Paolo Abeni, Hannes Frederic Sowa, linux-kernel, netdev, Jonathan Corbet, LMML, Peter Zijlstra, David Miller, torvalds On Mon, 8 Jan 2018 12:35:08 -0500 (EST) Alan Stern <stern@rowland.harvard.edu> wrote: > On Mon, 8 Jan 2018, Josef Griebichler wrote: > > > No I can't sorry. There's no sat connection near to my workstation. > > Can we ask the person who made this post: > https://forum.libreelec.tv/thread/4235-dvb-issue-since-le-switched-to-kernel-4-9-x/?postID=75965#post75965 > > to run the test? The post says that the testing was done on an x86_64 > machine. For >5 years ago I used to play a lot with IPTV multicast MPEG2-TS streams (I implemented the wireshark mp2ts drop detecting, and a out-of-tree netfilter kernel module to detect drops[1]). The web-site is dead, but archive.org have a copy[2]. Let me quote my own Lab-setup documentation[3]. You don't need a live IPTV MPEG2TS signal, you can simply generate your own using VLC: $ vlc ~/Videos/test_video.mkv -I rc --sout '#duplicate{dst=std{access=udp,mux=ts,dst=239.254.1.1:5500}}' Viewing your own signal: You can view your own generated signal, again, by using VLC. $ vlc udp/ts://@239.254.1.1:5500 I hope the vlc syntax is still valid. And remember to join the multicast channels, if you don't have an application requesting the stream, as desc in [4]. [1] https://github.com/netoptimizer/IPTV-Analyzer [2] http://web.archive.org/web/20150328200122/http://www.iptv-analyzer.org:80/wiki/index.php/Main_Page [3] http://web.archive.org/web/20150329095538/http://www.iptv-analyzer.org:80/wiki/index.php/Lab_Setup [4] http://web.archive.org/web/20150328234459/http://www.iptv-analyzer.org:80/wiki/index.php/Multicast_Signal_on_Linux -- Best regards, Jesper Dangaard Brouer MSc.CS, Principal Kernel Engineer at Red Hat LinkedIn: http://www.linkedin.com/in/brouer ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: dvb usb issues since kernel 4.9 2018-01-08 16:26 ` Aw: " Josef Griebichler 2018-01-08 16:31 ` Alan Stern @ 2018-01-08 21:31 ` Jesper Dangaard Brouer 2018-01-08 21:44 ` Peter Zijlstra 1 sibling, 1 reply; 47+ messages in thread From: Jesper Dangaard Brouer @ 2018-01-08 21:31 UTC (permalink / raw) To: Josef Griebichler Cc: Mauro Carvalho Chehab, Alan Stern, Greg Kroah-Hartman, linux-usb, Eric Dumazet, Rik van Riel, Paolo Abeni, Hannes Frederic Sowa, linux-kernel, netdev, Jonathan Corbet, LMML, Peter Zijlstra, David Miller, torvalds On Mon, 8 Jan 2018 17:26:10 +0100 "Josef Griebichler" <griebichler.josef@gmx.at> wrote: > I tried your mentioned patch but unfortunately no real improvement for me. > dmesg http://ix.io/DOg > tvheadend service log http://ix.io/DOi > > Errors during recording are still there. Are you _also_ recording the stream on the Raspberry Pi? It seems to me, that you are expecting too much from this small device. > Errors increase if there is additional tcp load on raspberry. I did expected the issue to get worse, when you load the Pi with network traffic, as now the softirq time-budget have to be shared between networking and USB/DVB. Thus, I guess you are running TCP and USB/mpeg2ts on the same CPU (why when you have 4 CPUs?...) If you expect/want to get stable performance out of such a small box, then you (or LibreELEC) need to tune the box for this usage. And it does not have to be that complicated. First step is to move IRQ handling for the NIC to another CPU and than the USB port handling the DVB signal (/proc/irq/*/smp_affinity_list). And then pin the userspace process (taskset) to another CPU than the one handling USB-softirq. > Unfortunately there's no usbmon or tshark on libreelec so I can't > provide further logs. Do you have perf or trace-cmd on the box? Maybe we could come up with some kernel functions to trace, to measure/show the latency spikes? -- Best regards, Jesper Dangaard Brouer MSc.CS, Principal Kernel Engineer at Red Hat LinkedIn: http://www.linkedin.com/in/brouer ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: dvb usb issues since kernel 4.9 2018-01-08 21:31 ` Jesper Dangaard Brouer @ 2018-01-08 21:44 ` Peter Zijlstra 2018-01-08 22:16 ` Jesper Dangaard Brouer 0 siblings, 1 reply; 47+ messages in thread From: Peter Zijlstra @ 2018-01-08 21:44 UTC (permalink / raw) To: Jesper Dangaard Brouer Cc: Josef Griebichler, Mauro Carvalho Chehab, Alan Stern, Greg Kroah-Hartman, linux-usb, Eric Dumazet, Rik van Riel, Paolo Abeni, Hannes Frederic Sowa, linux-kernel, netdev, Jonathan Corbet, LMML, David Miller, torvalds On Mon, Jan 08, 2018 at 10:31:09PM +0100, Jesper Dangaard Brouer wrote: > I did expected the issue to get worse, when you load the Pi with > network traffic, as now the softirq time-budget have to be shared > between networking and USB/DVB. Thus, I guess you are running TCP and > USB/mpeg2ts on the same CPU (why when you have 4 CPUs?...) Isn't networking also over USB on the Pi ? ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: dvb usb issues since kernel 4.9 2018-01-08 21:44 ` Peter Zijlstra @ 2018-01-08 22:16 ` Jesper Dangaard Brouer 2018-01-09 16:51 ` Aw: " Josef Griebichler 0 siblings, 1 reply; 47+ messages in thread From: Jesper Dangaard Brouer @ 2018-01-08 22:16 UTC (permalink / raw) To: Peter Zijlstra Cc: Josef Griebichler, Mauro Carvalho Chehab, Alan Stern, Greg Kroah-Hartman, linux-usb, Eric Dumazet, Rik van Riel, Paolo Abeni, Hannes Frederic Sowa, linux-kernel, netdev, Jonathan Corbet, LMML, David Miller, torvalds On Mon, 8 Jan 2018 22:44:27 +0100 Peter Zijlstra <peterz@infradead.org> wrote: > On Mon, Jan 08, 2018 at 10:31:09PM +0100, Jesper Dangaard Brouer wrote: > > I did expected the issue to get worse, when you load the Pi with > > network traffic, as now the softirq time-budget have to be shared > > between networking and USB/DVB. Thus, I guess you are running TCP and > > USB/mpeg2ts on the same CPU (why when you have 4 CPUs?...) > > Isn't networking also over USB on the Pi ? Darn, that is true. Looking at the dmesg output in http://ix.io/DOg: [ 0.405942] usbcore: registered new interface driver smsc95xx [ 5.821104] smsc95xx 1-1.1:1.0 eth0: link up, 100Mbps, full-duplex, lpa 0x45E1 I don't know enough about USB... is it possible to control which CPU handles the individual USB ports, or on some other level (than ports)? -- Best regards, Jesper Dangaard Brouer MSc.CS, Principal Kernel Engineer at Red Hat LinkedIn: http://www.linkedin.com/in/brouer ^ permalink raw reply [flat|nested] 47+ messages in thread
* Aw: Re: dvb usb issues since kernel 4.9 2018-01-08 22:16 ` Jesper Dangaard Brouer @ 2018-01-09 16:51 ` Josef Griebichler 2018-01-09 17:27 ` Eric Dumazet 0 siblings, 1 reply; 47+ messages in thread From: Josef Griebichler @ 2018-01-09 16:51 UTC (permalink / raw) To: Jesper Dangaard Brouer Cc: Peter Zijlstra, Mauro Carvalho Chehab, Alan Stern, Greg Kroah-Hartman, linux-usb, Eric Dumazet, Rik van Riel, Paolo Abeni, Hannes Frederic Sowa, linux-kernel, netdev, Jonathan Corbet, LMML, David Miller, torvalds Hi Linus, your patch works very good for me and others (please see https://forum.libreelec.tv/thread/4235-dvb-issue-since-le-switched-to-kernel-4-9-x/?postID=77006#post77006). No errors in recordings any more. The patch was also tested on x86_64 (Revo 3700) with positive effect. I agree with the forum poster, that there's still an issue when recording and watching livetv at same time. I also get audio dropouts and audio is out of sync. According to user smp kernel 4.9.73 with your patch on rpi and according to user jahutchi kernel 4.11.12 on x86_64 have no such issues. I don't know if this dropouts are related to this topic. If of any help I could provide perf output on raspberry with libreelec and tvheadend. Regards, Josef Gesendet: Montag, 08. Januar 2018 um 23:16 Uhr Von: "Jesper Dangaard Brouer" <jbrouer@redhat.com> An: "Peter Zijlstra" <peterz@infradead.org> Cc: "Josef Griebichler" <griebichler.josef@gmx.at>, "Mauro Carvalho Chehab" <mchehab@s-opensource.com>, "Alan Stern" <stern@rowland.harvard.edu>, "Greg Kroah-Hartman" <gregkh@linuxfoundation.org>, linux-usb@vger.kernel.org, "Eric Dumazet" <edumazet@google.com>, "Rik van Riel" <riel@redhat.com>, "Paolo Abeni" <pabeni@redhat.com>, "Hannes Frederic Sowa" <hannes@redhat.com>, linux-kernel <linux-kernel@vger.kernel.org>, netdev <netdev@vger.kernel.org>, "Jonathan Corbet" <corbet@lwn.net>, LMML <linux-media@vger.kernel.org>, "David Miller" <davem@davemloft.net>, torvalds@linux-foundation.org Betreff: Re: dvb usb issues since kernel 4.9 On Mon, 8 Jan 2018 22:44:27 +0100 Peter Zijlstra <peterz@infradead.org> wrote: > On Mon, Jan 08, 2018 at 10:31:09PM +0100, Jesper Dangaard Brouer wrote: > > I did expected the issue to get worse, when you load the Pi with > > network traffic, as now the softirq time-budget have to be shared > > between networking and USB/DVB. Thus, I guess you are running TCP and > > USB/mpeg2ts on the same CPU (why when you have 4 CPUs?...) > > Isn't networking also over USB on the Pi ? Darn, that is true. Looking at the dmesg output in http://ix.io/DOg: [ 0.405942] usbcore: registered new interface driver smsc95xx [ 5.821104] smsc95xx 1-1.1:1.0 eth0: link up, 100Mbps, full-duplex, lpa 0x45E1 I don't know enough about USB... is it possible to control which CPU handles the individual USB ports, or on some other level (than ports)? -- Best regards, Jesper Dangaard Brouer MSc.CS, Principal Kernel Engineer at Red Hat LinkedIn: http://www.linkedin.com/in/brouer[http://www.linkedin.com/in/brouer] ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: Re: dvb usb issues since kernel 4.9 2018-01-09 16:51 ` Aw: " Josef Griebichler @ 2018-01-09 17:27 ` Eric Dumazet 2018-01-09 17:48 ` Linus Torvalds 0 siblings, 1 reply; 47+ messages in thread From: Eric Dumazet @ 2018-01-09 17:27 UTC (permalink / raw) To: Josef Griebichler Cc: Jesper Dangaard Brouer, Peter Zijlstra, Mauro Carvalho Chehab, Alan Stern, Greg Kroah-Hartman, linux-usb, Rik van Riel, Paolo Abeni, Hannes Frederic Sowa, linux-kernel, netdev, Jonathan Corbet, LMML, David Miller, Linus Torvalds On Tue, Jan 9, 2018 at 8:51 AM, Josef Griebichler <griebichler.josef@gmx.at> wrote: > Hi Linus, > > your patch works very good for me and others (please see https://forum.libreelec.tv/thread/4235-dvb-issue-since-le-switched-to-kernel-4-9-x/?postID=77006#post77006). No errors in recordings any more. > The patch was also tested on x86_64 (Revo 3700) with positive effect. > I agree with the forum poster, that there's still an issue when recording and watching livetv at same time. I also get audio dropouts and audio is out of sync. > According to user smp kernel 4.9.73 with your patch on rpi and according to user jahutchi kernel 4.11.12 on x86_64 have no such issues. > I don't know if this dropouts are related to this topic. > > If of any help I could provide perf output on raspberry with libreelec and tvheadend. > Sorry to come late to the party. It seems problem comes from some piece of hardware/driver having some precise timing prereq, and opportunistic use of softirq/tasklet (instead maybe of hard irq handlers ) While it is true that softirq might do the job in most cases, we already have cases where this can be easily defeated, say if one cpu has suddenly to handle multiple sources of interrupts for various devices. NET_RX can easily lock the cpu for 10ms (on HZ=100 builds) So yes, commit 4cd13c21b207 ("softirq: Let ksoftirqd do its job") has shown up multiple times in various 'regressions' simply because it could surface the problem more often. But even if you revert it, you can still make the faulty driver/subsystem misbehave by adding more stress to the cpu handling the IRQ. Note that networking lacks fine control of its softirq processing. Some people found/complained that relying more on ksoftirqd was potentially adding tail latencies. Maybe the answer is to tune the kernel for small latencies at the price of small throughput (situation before the patch) 1) Revert the patch 2) get rid of ksoftirqd since it adds unexpected latencies. 3) Let applications that expect to have high throughput make sure to pin their threads on cpus that are not processing IRQ. (And make sure to not use irqbalance, and setup IRQ cpu affinities) ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: Re: dvb usb issues since kernel 4.9 2018-01-09 17:27 ` Eric Dumazet @ 2018-01-09 17:48 ` Linus Torvalds 2018-01-09 17:57 ` Eric Dumazet 2018-01-12 21:13 ` Mauro Carvalho Chehab 0 siblings, 2 replies; 47+ messages in thread From: Linus Torvalds @ 2018-01-09 17:48 UTC (permalink / raw) To: Eric Dumazet Cc: Josef Griebichler, Jesper Dangaard Brouer, Peter Zijlstra, Mauro Carvalho Chehab, Alan Stern, Greg Kroah-Hartman, USB list, Rik van Riel, Paolo Abeni, Hannes Frederic Sowa, linux-kernel, netdev, Jonathan Corbet, LMML, David Miller On Tue, Jan 9, 2018 at 9:27 AM, Eric Dumazet <edumazet@google.com> wrote: > > So yes, commit 4cd13c21b207 ("softirq: Let ksoftirqd do its job") has > shown up multiple times in various 'regressions' > simply because it could surface the problem more often. > But even if you revert it, you can still make the faulty > driver/subsystem misbehave by adding more stress to the cpu handling > the IRQ. ..but that's always true. People sometimes live on the edge - often by design (ie hardware has been designed/selected to be the crappiest possible that still work). That doesn't change anything. A patch that takes "bad things can happen" to "bad things DO happen" is a bad patch. > Maybe the answer is to tune the kernel for small latencies at the > price of small throughput (situation before the patch) Generally we always want to tune for latency. Throughput is "easy", but almost never interesting. Sure, people do batch jobs. And yes, people often _benchmark_ throughput, because it's easy to benchmark. It's much harder to benchmark latency, even when it's often much more important. A prime example is the SSD benchmarks in the last few years - they improved _dramatically_ when people noticed that the real problem was latency, not the idiotic maximum big-block bandwidth numbers that have almost zero impact on most people. Put another way: we already have a very strong implicit bias towards bandwidth just because it's easier to see and measure. That means that we generally should strive to have a explicit bias towards optimizing for latency when that choice comes up. Just to balance things out (and just to not take the easy way out: bandwidth can often be improved by adding more layers of buffering and bigger buffers, and that often ends up really hurting latency). > 1) Revert the patch Well, we can revert it only partially - limiting it to just networking for example. Just saying "act the way you used to for tasklets" already seems to have fixed the issue in DVB. > 2) get rid of ksoftirqd since it adds unexpected latencies. We can't get rid of it entirely, since the synchronous softirq code can cause problems too. It's why we have that "maximum of ten synchronous events" in __do_softirq(). And we don't *want* to get rid of it. We've _always_ had that small-scale "at some point we can't do it synchronously any more". That is a small-scale "don't have horrible latency for _other_ things" protection. So it's about latency too, it's just about protecting latency of the rest of the system. The problem with commit 4cd13c21b207 is that it turns the small-scale latency issues in softirq handling (they get larger latencies for lots of hardware interrupts or even from non-preemptible kernel code) into the _huge_ scale latency of scheduling, and does so in a racy way too. > 3) Let applications that expect to have high throughput make sure to > pin their threads on cpus that are not processing IRQ. > (And make sure to not use irqbalance, and setup IRQ cpu affinities) The only people that really deal in "thoughput only" tend to be the HPC people, and they already do things like this. (The other end of the spectrum is the realtime people that have extreme latency requirements, who do things like that for the reverse reason: keeping one or more CPU's reserved for the particular low-latency realtime job). Linus ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: Re: dvb usb issues since kernel 4.9 2018-01-09 17:48 ` Linus Torvalds @ 2018-01-09 17:57 ` Eric Dumazet 2018-01-09 18:58 ` Linus Torvalds 2018-01-12 21:13 ` Mauro Carvalho Chehab 1 sibling, 1 reply; 47+ messages in thread From: Eric Dumazet @ 2018-01-09 17:57 UTC (permalink / raw) To: Linus Torvalds Cc: Josef Griebichler, Jesper Dangaard Brouer, Peter Zijlstra, Mauro Carvalho Chehab, Alan Stern, Greg Kroah-Hartman, USB list, Rik van Riel, Paolo Abeni, Hannes Frederic Sowa, linux-kernel, netdev, Jonathan Corbet, LMML, David Miller On Tue, Jan 9, 2018 at 9:48 AM, Linus Torvalds <torvalds@linux-foundation.org> wrote: > On Tue, Jan 9, 2018 at 9:27 AM, Eric Dumazet <edumazet@google.com> wrote: >> >> So yes, commit 4cd13c21b207 ("softirq: Let ksoftirqd do its job") has >> shown up multiple times in various 'regressions' >> simply because it could surface the problem more often. >> But even if you revert it, you can still make the faulty >> driver/subsystem misbehave by adding more stress to the cpu handling >> the IRQ. > > ..but that's always true. People sometimes live on the edge - often by > design (ie hardware has been designed/selected to be the crappiest > possible that still work). > > That doesn't change anything. A patch that takes "bad things can > happen" to "bad things DO happen" is a bad patch. I was expecting that people could get a chance to fix the root cause, instead of trying to keep status quo. Strangely, it took 18 months for someone to complain enough and 'bisect to this commit' Your patch considers TASKLET_SOFTIRQ being a candidate for 'immediate handling', but TCP Small queues heavily use TASKLET, so as far as I am concerned a revert would have the same effect. ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: Re: dvb usb issues since kernel 4.9 2018-01-09 17:57 ` Eric Dumazet @ 2018-01-09 18:58 ` Linus Torvalds 2018-01-09 21:48 ` Eric Dumazet 2018-01-10 9:45 ` Jesper Dangaard Brouer 0 siblings, 2 replies; 47+ messages in thread From: Linus Torvalds @ 2018-01-09 18:58 UTC (permalink / raw) To: Eric Dumazet Cc: Josef Griebichler, Jesper Dangaard Brouer, Peter Zijlstra, Mauro Carvalho Chehab, Alan Stern, Greg Kroah-Hartman, USB list, Rik van Riel, Paolo Abeni, Hannes Frederic Sowa, linux-kernel, netdev, Jonathan Corbet, LMML, David Miller On Tue, Jan 9, 2018 at 9:57 AM, Eric Dumazet <edumazet@google.com> wrote: > > Your patch considers TASKLET_SOFTIRQ being a candidate for 'immediate > handling', but TCP Small queues heavily use TASKLET, > so as far as I am concerned a revert would have the same effect. Does it actually? TCP ends up dropping packets outside of the window etc, so flooding a machine with TCP packets and causing some further processing up the stack sounds very different from the basic packet flooding thing that happens with NET_RX_SOFTIRQ. Also, honestly, the kinds of people who really worry about flooding tend to have packet filtering in the receive path etc. So I really think "you can use up 90% of CPU time with a UDP packet flood from the same network" is very very very different - and honestly not at all as important - as "you want to be able to use a USB DVB receiver and watch/record TV". Because that whole "UDP packet flood from the same network" really is something you _fundamentally_ have other mitigations for. I bet that whole commit was introduced because of a benchmark test, rather than real life. No? In contrast, now people are complaining about real loads not working. Linus ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: Re: dvb usb issues since kernel 4.9 2018-01-09 18:58 ` Linus Torvalds @ 2018-01-09 21:48 ` Eric Dumazet 2018-01-10 9:45 ` Jesper Dangaard Brouer 1 sibling, 0 replies; 47+ messages in thread From: Eric Dumazet @ 2018-01-09 21:48 UTC (permalink / raw) To: Linus Torvalds Cc: Josef Griebichler, Jesper Dangaard Brouer, Peter Zijlstra, Mauro Carvalho Chehab, Alan Stern, Greg Kroah-Hartman, USB list, Rik van Riel, Paolo Abeni, Hannes Frederic Sowa, linux-kernel, netdev, Jonathan Corbet, LMML, David Miller On Tue, Jan 9, 2018 at 10:58 AM, Linus Torvalds <torvalds@linux-foundation.org> wrote: > On Tue, Jan 9, 2018 at 9:57 AM, Eric Dumazet <edumazet@google.com> wrote: >> >> Your patch considers TASKLET_SOFTIRQ being a candidate for 'immediate >> handling', but TCP Small queues heavily use TASKLET, >> so as far as I am concerned a revert would have the same effect. > > Does it actually? > > TCP ends up dropping packets outside of the window etc, so flooding a > machine with TCP packets and causing some further processing up the > stack sounds very different from the basic packet flooding thing that > happens with NET_RX_SOFTIRQ. > > Also, honestly, the kinds of people who really worry about flooding > tend to have packet filtering in the receive path etc. > > So I really think "you can use up 90% of CPU time with a UDP packet > flood from the same network" is very very very different - and > honestly not at all as important - as "you want to be able to use a > USB DVB receiver and watch/record TV". > > Because that whole "UDP packet flood from the same network" really is > something you _fundamentally_ have other mitigations for. > > I bet that whole commit was introduced because of a benchmark test, > rather than real life. No? > > In contrast, now people are complaining about real loads not working. > > Linus I said that a revert was fine, maybe I was not clear. Clearly we can not touch anything scheduler related without breaking someone workload/assumptions on how system behaved at some point. Your patch wont solve other workloads that might have been impacted by my patch, so in one year (or next week), we will have to cope with another device driver not using tasklet but still relying on immediate softirq processing. Apparently, we have to live with softirq model forever, or switch to RT kernels. Note that we have no mitigation for something that involve flood of valid packets that no firewall can drop (without dropping legitimate packets). The 'benchmark' here is not really the trigger, only a tool validating an idea/patch. ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: dvb usb issues since kernel 4.9 2018-01-09 18:58 ` Linus Torvalds 2018-01-09 21:48 ` Eric Dumazet @ 2018-01-10 9:45 ` Jesper Dangaard Brouer 1 sibling, 0 replies; 47+ messages in thread From: Jesper Dangaard Brouer @ 2018-01-10 9:45 UTC (permalink / raw) To: Linus Torvalds Cc: Eric Dumazet, Josef Griebichler, Peter Zijlstra, Mauro Carvalho Chehab, Alan Stern, Greg Kroah-Hartman, USB list, Rik van Riel, Paolo Abeni, Hannes Frederic Sowa, linux-kernel, netdev, Jonathan Corbet, LMML, David Miller, Marek Majkowski On Tue, 9 Jan 2018 10:58:30 -0800 Linus Torvalds <torvalds@linux-foundation.org> wrote: > So I really think "you can use up 90% of CPU time with a UDP packet > flood from the same network" is very very very different - and > honestly not at all as important - as "you want to be able to use a > USB DVB receiver and watch/record TV". > > Because that whole "UDP packet flood from the same network" really is > something you _fundamentally_ have other mitigations for. > > I bet that whole commit was introduced because of a benchmark test, > rather than real life. No? I believe this have happened in real-life. In the form of DNS servers not being able to recover after long outage, where DNS-TTL had timeout causing legitimate traffic to overload their DNS servers. The goodput answers/sec from their DNS servers were too low, when bringing them online again. (Based on talk over beer at NetDevConf from a guy claiming they ran DNS for AWS). The commit 4cd13c21b207 ("softirq: Let ksoftirqd do its job") tries to address a fundamental problem that the network stack have when interacting with softirq in overload situations. (Maybe we can come up with a better solution?) Before this commit, when application run on same CPU as softirq, the kernel have a bad "drop off cliff" behavior, when reaching above the saturation point. This is confirmed in CloudFlare blogpost[1], which used a kernel that predates this commit. From[1] section: "A note on NUMA performance" Quote:" 1. Run receiver on another CPU, but on the same NUMA node as the RX queue. The performance as we saw above is around 360kpps. 2. With receiver on exactly same CPU as the RX queue we can get up to ~430kpps. But it creates high variability. The performance drops down to zero if the NIC is overwhelmed with packets." The behavior problem here is "performance drops down to zero if the NIC is overwhelmed with packets". That is a bad way to handle overload. Not only when attacked, but also when bringing a service online after an outage. What essentially happens is that: 1. softirq NAPI enqueue 64 packets into socket. 2. application dequeue 1 packet and invoke local_bh_enable() 3. causing softirq to run in app-timeslice, again enq 64 packets 4. app only see goodput of 1/128 of packets That is essentially what Eric solved with his commit, avoiding (3) local_bh_enable() to invoke softirq if ksoftirqd is already running. Maybe we can come up with a better solution? (as I do agree this was a too big-hammer affecting other use-cases) [1] https://blog.cloudflare.com/how-to-receive-a-million-packets/ p.s. Regarding quote[1] point "1.", after Paolo Abeni optimized the UDP code, that statement is no longer true. It now (significantly) faster to run/pin your UDP application to another CPU than the RX-CPU. -- Best regards, Jesper Dangaard Brouer MSc.CS, Principal Kernel Engineer at Red Hat LinkedIn: http://www.linkedin.com/in/brouer ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: dvb usb issues since kernel 4.9 2018-01-09 17:48 ` Linus Torvalds 2018-01-09 17:57 ` Eric Dumazet @ 2018-01-12 21:13 ` Mauro Carvalho Chehab 2018-01-12 21:48 ` Eric Dumazet 1 sibling, 1 reply; 47+ messages in thread From: Mauro Carvalho Chehab @ 2018-01-12 21:13 UTC (permalink / raw) To: Linus Torvalds, Eric Dumazet Cc: Josef Griebichler, Jesper Dangaard Brouer, Peter Zijlstra, Alan Stern, Greg Kroah-Hartman, USB list, Rik van Riel, Paolo Abeni, Hannes Frederic Sowa, linux-kernel, netdev, Jonathan Corbet, LMML, David Miller, Arnd Bergmann Em Tue, 9 Jan 2018 09:48:47 -0800 Linus Torvalds <torvalds@linux-foundation.org> escreveu: > On Tue, Jan 9, 2018 at 9:27 AM, Eric Dumazet <edumazet@google.com> wrote: > > > > So yes, commit 4cd13c21b207 ("softirq: Let ksoftirqd do its job") has > > shown up multiple times in various 'regressions' > > simply because it could surface the problem more often. > > But even if you revert it, you can still make the faulty > > driver/subsystem misbehave by adding more stress to the cpu handling > > the IRQ. > > ..but that's always true. People sometimes live on the edge - often by > design (ie hardware has been designed/selected to be the crappiest > possible that still work). > > That doesn't change anything. A patch that takes "bad things can > happen" to "bad things DO happen" is a bad patch. > > > Maybe the answer is to tune the kernel for small latencies at the > > price of small throughput (situation before the patch) > > Generally we always want to tune for latency. Throughput is "easy", > but almost never interesting. > > Sure, people do batch jobs. And yes, people often _benchmark_ > throughput, because it's easy to benchmark. It's much harder to > benchmark latency, even when it's often much more important. > > A prime example is the SSD benchmarks in the last few years - they > improved _dramatically_ when people noticed that the real problem was > latency, not the idiotic maximum big-block bandwidth numbers that have > almost zero impact on most people. > > Put another way: we already have a very strong implicit bias towards > bandwidth just because it's easier to see and measure. > > That means that we generally should strive to have a explicit bias > towards optimizing for latency when that choice comes up. Just to > balance things out (and just to not take the easy way out: bandwidth > can often be improved by adding more layers of buffering and bigger > buffers, and that often ends up really hurting latency). > > > 1) Revert the patch > > Well, we can revert it only partially - limiting it to just networking > for example. > > Just saying "act the way you used to for tasklets" already seems to > have fixed the issue in DVB. > > > 2) get rid of ksoftirqd since it adds unexpected latencies. > > We can't get rid of it entirely, since the synchronous softirq code > can cause problems too. It's why we have that "maximum of ten > synchronous events" in __do_softirq(). > > And we don't *want* to get rid of it. > > We've _always_ had that small-scale "at some point we can't do it > synchronously any more". > > That is a small-scale "don't have horrible latency for _other_ things" > protection. So it's about latency too, it's just about protecting > latency of the rest of the system. > > The problem with commit 4cd13c21b207 is that it turns the small-scale > latency issues in softirq handling (they get larger latencies for lots > of hardware interrupts or even from non-preemptible kernel code) into > the _huge_ scale latency of scheduling, and does so in a racy way too. > > > 3) Let applications that expect to have high throughput make sure to > > pin their threads on cpus that are not processing IRQ. > > (And make sure to not use irqbalance, and setup IRQ cpu affinities) > > The only people that really deal in "thoughput only" tend to be the > HPC people, and they already do things like this. > > (The other end of the spectrum is the realtime people that have > extreme latency requirements, who do things like that for the reverse > reason: keeping one or more CPU's reserved for the particular > low-latency realtime job). Ok, it took me some time - and a faster microSD - in order to be sure that the data loss weren't due to bad storage performance, but I have now some test results. In summary, indeed the ksoftirq commit 4cd13c21b207 ("softirq: Let ksoftirqd do its job") is causing data losses. On my tests, it generate at least one continuity error on every 1-5 minutes. Either reverting it or applying Linus proposal of partially reverting it fixes the issues. Increasing the number of URBs doesn't seem to help. I'm enclosing the dirty details below. Linus/Eric, Now that I have an environment setup, I can test whatever other alternative that would fix the UDP packet flow attack while won't break the softirq handling code. Regards, Mauro --- All tests below were done on a Raspberry Pi3 with a SanDisk Extreme U3 microSD card with 32GB and a DVBSky S960C DVB-S2 tuner with an external power supply, connected to a TCP/IP network via Ethernet (with uses USB on RPi). It also have a serial cable connected to it. It was installed with LibreELEC 8.2.2, using tvheadend backend. I'm recording one MPEG-TS service/"channel" composed of one audio and one video stream, The total traffic collected by tvheadend was about 4 Mbits/s (audio+video+EPG tables). It is part of a 58 mbits/s MPEG Transport stream, with 23 TV service/"channels" on it. While handling this issue, I found one unrelated bug, fixed on this patch: https://git.linuxtv.org/mchehab/experimental.git/commit/?h=softirq_fixup&id=afb6c749c9da6e661335bc059f2b117421c09f77 This bug has no effect on DVB streaming. It only causes the signal strength to be reported wrongly on 32 bit Kernels. On all tests below I had this patch applied. Test 1 ====== Kernel (e. g. Raspbian Kernel), recording and watching the video at the same time on Kodi, plus one VLC client, on an interval of time of 5 minutes, it had 4 MPEG continuity errors on video (and one on audio): Jan 12 15:05:39 rpi3 tvheadend[285]: TS: DVB-S Network/12090H/TV Senado: H264 @ #1601 Continuity counter error (total 1) Jan 12 15:06:20 rpi3 tvheadend[285]: TS: DVB-S Network/12090H/TV Senado: H264 @ #1601 Continuity counter error (total 2) Jan 12 15:07:36 rpi3 tvheadend[285]: TS: DVB-S Network/12090H/TV Senado: H264 @ #1601 Continuity counter error (total 3) Jan 12 15:07:36 rpi3 tvheadend[285]: TS: DVB-S Network/12090H/TV Senado: MPEG2AUDIO @ #1602 Continuity counter error (total 1) Jan 12 15:10:28 rpi3 tvheadend[285]: TS: DVB-S Network/12090H/TV Senado: H264 @ #1601 Continuity counter error (total 4) With upstream Kernels, Kodi stops working (it depends on Raspbian video driver). So, I opened two VLC players, on separate machines, in order to also have 2 clients watching, plus the record task. That increased the network and USB traffic as well. All the next tests were on such scenario. Test 2 ====== With Kernel 4.14.12 vanilla with just one extra patch increasing the number of URB buffers from 8 to 16, it got 2 video errors on a 6 minutes interval: Jan 12 15:56:09 rpi3 tvheadend[222]: TS: DVB-S Network/12090H/TV Senado: H264 @ #1601 Continuity counter error (total 2) Jan 12 15:56:09 rpi3 tvheadend[222]: TS: DVB-S Network/12090H/TV Senado: MPEG2AUDIO @ #1602 Continuity counter error (total 1) Jan 12 16:03:05 rpi3 tvheadend[222]: TS: DVB-S Network/12090H/TV Senado: H264 @ #1601 Continuity counter error (total 3) Jan 12 16:03:05 rpi3 tvheadend[222]: TS: DVB-S Network/12090H/TV Senado: MPEG2AUDIO @ #1602 Continuity counter error (total 2) Test 3 ====== With upstream Kernel 4.14.12 + 16 buffers patch + commit 4cd13c21b207 reverted, I kept it running for about 15-30 mins. No continuity errors. Test 4 ====== With upstream Kernel 4.14.12 with the partial softirq revert made by Linus test patch[1], running for about 20 mins, it got just one continuity error: Jan 12 16:51:31 rpi3 tvheadend[237]: TS: DVB-S Network/12090H/TV Senado: H264 @ #1601 Continuity counter error (total 1) Jan 12 16:51:31 rpi3 tvheadend[237]: TS: DVB-S Network/12090H/TV Senado: MPEG2AUDIO @ #1602 Continuity counter error (total 1) [1] https://git.linuxtv.org/mchehab/experimental.git/commit/?h=softirq_fixup&id=7996c39af87d329f64e6b1b2af120d6ce11ede29 Test 5 ====== I then moved to Kernel 4.15-rc7. In this case, I had to add an extra patch, as the USB controller is currently broken upstream: https://git.linuxtv.org/mchehab/experimental.git/commit/?h=softirq_fixup&id=6bcc57ea8a84e9d5fed9f5ebf13d63fd28ef181c The .config file used to build the Kernel is at: https://pastebin.com/wpZghann With upstream Kernel 4.15-rc7 - with Linus patch applied[2], I kept the record + 2 VLC clients running for about one hour. It got just one continuity error: Jan 12 20:06:26 rpi3 tvheadend[226]: TS: DVB-S Network/12090H/TV Senado: H264 @ #1601 Continuity counter error (total 1) Jan 12 20:06:26 rpi3 tvheadend[226]: TS: DVB-S Network/12090H/TV Senado: MPEG2AUDIO @ #1602 Continuity counter error (total 1) [2] The test Kernel is this one: https://git.linuxtv.org/mchehab/experimental.git/log/?h=softirq_fixup It is hard to tell if this one continuity error is due to some Kernel issue, or if it is simply due to some PES packet with bad CRC that got discarded, but it seems a normal condition to me. Thanks, Mauro ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: dvb usb issues since kernel 4.9 2018-01-12 21:13 ` Mauro Carvalho Chehab @ 2018-01-12 21:48 ` Eric Dumazet 2018-01-13 9:09 ` Mauro Carvalho Chehab 0 siblings, 1 reply; 47+ messages in thread From: Eric Dumazet @ 2018-01-12 21:48 UTC (permalink / raw) To: Mauro Carvalho Chehab, Linus Torvalds, Eric Dumazet Cc: Josef Griebichler, Jesper Dangaard Brouer, Peter Zijlstra, Alan Stern, Greg Kroah-Hartman, USB list, Rik van Riel, Paolo Abeni, Hannes Frederic Sowa, linux-kernel, netdev, Jonathan Corbet, LMML, David Miller, Arnd Bergmann On Fri, 2018-01-12 at 19:13 -0200, Mauro Carvalho Chehab wrote: > > > The .config file used to build the Kernel is at: > https://pastebin.com/wpZghann > Hi Mauro Any chance you can try CONFIG_HZ_1000=y, CONFIG_HZ=1000 ? Thanks. ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: dvb usb issues since kernel 4.9 2018-01-12 21:48 ` Eric Dumazet @ 2018-01-13 9:09 ` Mauro Carvalho Chehab 2018-01-13 10:46 ` Mauro Carvalho Chehab 0 siblings, 1 reply; 47+ messages in thread From: Mauro Carvalho Chehab @ 2018-01-13 9:09 UTC (permalink / raw) To: Eric Dumazet Cc: Linus Torvalds, Eric Dumazet, Josef Griebichler, Jesper Dangaard Brouer, Peter Zijlstra, Alan Stern, Greg Kroah-Hartman, USB list, Rik van Riel, Paolo Abeni, Hannes Frederic Sowa, linux-kernel, netdev, Jonathan Corbet, LMML, David Miller, Arnd Bergmann Em Fri, 12 Jan 2018 13:48:46 -0800 Eric Dumazet <eric.dumazet@gmail.com> escreveu: > On Fri, 2018-01-12 at 19:13 -0200, Mauro Carvalho Chehab wrote: > > > > > > The .config file used to build the Kernel is at: > > https://pastebin.com/wpZghann > > > > Hi Mauro > > Any chance you can try CONFIG_HZ_1000=y, CONFIG_HZ=1000 ? I can do such test to satisfy your curiosity, but that doesn't sound the right fix. See, almost all TV and set top boxes(STB) run Linux nowadays and usually come with ARM cpus designed to "just do their job" (e. g. CPUs with low clocks). There, power consumption is a must. This bug very likely affect those devices, once migrated to Kernel 4.9+. Changing from NO_HZ to HZ=1000 on TV/STB will for sure have bad side effects on those types of devices, increasing power consumption. Not saying that this will be environmentally very bad, as the number of just TV unit sales is at the order of 230 million units per year[1]. [1] https://www.statista.com/statistics/461316/global-tv-unit-sales/ Thanks, Mauro ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: dvb usb issues since kernel 4.9 2018-01-13 9:09 ` Mauro Carvalho Chehab @ 2018-01-13 10:46 ` Mauro Carvalho Chehab 0 siblings, 0 replies; 47+ messages in thread From: Mauro Carvalho Chehab @ 2018-01-13 10:46 UTC (permalink / raw) To: Eric Dumazet Cc: Linus Torvalds, Eric Dumazet, Josef Griebichler, Jesper Dangaard Brouer, Peter Zijlstra, Alan Stern, Greg Kroah-Hartman, USB list, Rik van Riel, Paolo Abeni, Hannes Frederic Sowa, linux-kernel, netdev, Jonathan Corbet, LMML, David Miller, Arnd Bergmann Em Sat, 13 Jan 2018 07:09:20 -0200 Mauro Carvalho Chehab <mchehab@s-opensource.com> escreveu: > Em Fri, 12 Jan 2018 13:48:46 -0800 > Eric Dumazet <eric.dumazet@gmail.com> escreveu: > > > On Fri, 2018-01-12 at 19:13 -0200, Mauro Carvalho Chehab wrote: > > > > > > > > > The .config file used to build the Kernel is at: > > > https://pastebin.com/wpZghann > > > > > > > Hi Mauro > > > > Any chance you can try CONFIG_HZ_1000=y, CONFIG_HZ=1000 ? It actually made it a lot worse! without Linus patch (or reverting the softirq patch), on a 4 minutes of capture, it got all those errors: Jan 13 10:41:41 rpi3 tvheadend[226]: TS: DVB-S Network/12130H/NBR: H264 @ #1911 Continuity counter error (total 1) Jan 13 10:41:42 rpi3 tvheadend[226]: TS: DVB-S Network/12130H/NBR: MPEG2AUDIO @ #1912 Continuity counter error (total 1) Jan 13 10:42:14 rpi3 tvheadend[226]: TS: DVB-S Network/12130H/NBR: H264 @ #1911 Continuity counter error (total 3) Jan 13 10:42:47 rpi3 tvheadend[226]: TS: DVB-S Network/12130H/NBR: H264 @ #1911 Continuity counter error (total 4) Jan 13 10:42:58 rpi3 tvheadend[226]: TS: DVB-S Network/12130H/NBR: H264 @ #1911 Continuity counter error (total 5) Jan 13 10:42:58 rpi3 tvheadend[226]: TS: DVB-S Network/12130H/NBR: MPEG2AUDIO @ #1912 Continuity counter error (total 2) Jan 13 10:43:34 rpi3 tvheadend[226]: TS: DVB-S Network/12130H/NBR: H264 @ #1911 Continuity counter error (total 9) Jan 13 10:43:37 rpi3 tvheadend[226]: TS: DVB-S Network/12130H/NBR: MPEG2AUDIO @ #1912 Continuity counter error (total 5) Jan 13 10:44:00 rpi3 tvheadend[226]: TS: DVB-S Network/12130H/NBR: H264 @ #1911 Continuity counter error (total 12) Jan 13 10:44:29 rpi3 tvheadend[226]: TS: DVB-S Network/12130H/NBR: H264 @ #1911 Continuity counter error (total 13) Thanks, Mauro ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: dvb usb issues since kernel 4.9 2018-01-06 19:54 ` dvb usb issues since kernel 4.9 Mauro Carvalho Chehab 2018-01-06 21:07 ` Aw: " Josef Griebichler 2018-01-06 21:44 ` Alan Stern @ 2018-01-07 21:23 ` Linus Torvalds 2018-01-08 10:02 ` Mauro Carvalho Chehab 2018-01-08 17:55 ` Ingo Molnar 2 siblings, 2 replies; 47+ messages in thread From: Linus Torvalds @ 2018-01-07 21:23 UTC (permalink / raw) To: Mauro Carvalho Chehab, Ingo Molnar Cc: Josef Griebichler, Greg Kroah-Hartman, Alan Stern, USB list, Eric Dumazet, Rik van Riel, Paolo Abeni, Hannes Frederic Sowa, Jesper Dangaard Brouer, linux-kernel, netdev, Jonathan Corbet, LMML, Peter Zijlstra, David Miller On Sat, Jan 6, 2018 at 11:54 AM, Mauro Carvalho Chehab <mchehab@s-opensource.com> wrote: > > Em Sat, 6 Jan 2018 16:04:16 +0100 > "Josef Griebichler" <griebichler.josef@gmx.at> escreveu: >> >> the causing commit has been identified. >> After reverting commit https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=4cd13c21b207e80ddb1144c576500098f2d5f882 >> its working again. > > Just replying to me won't magically fix this. The ones that were involved on > this patch should also be c/c, plus USB people. Just added them. Actually, you seem to have added an odd subset of the people involved. For example, Ingo - who actually committed that patch - wasn't on the cc. I do think we need to simply revert that patch. It's very simple: it has been reported to lead to actual problems for people, and we don't fix one problem and then say "well, it fixed something else" when something breaks. When something breaks, we either unbreak it, or we revert the change that caused the breakage. It's really that simple. That's what "no regressions" means. We don't accept changes that cause regressions. This one did. Linus ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: dvb usb issues since kernel 4.9 2018-01-07 21:23 ` Linus Torvalds @ 2018-01-08 10:02 ` Mauro Carvalho Chehab 2018-01-08 11:59 ` Jesper Dangaard Brouer 2018-01-08 17:55 ` Ingo Molnar 1 sibling, 1 reply; 47+ messages in thread From: Mauro Carvalho Chehab @ 2018-01-08 10:02 UTC (permalink / raw) To: Linus Torvalds Cc: Ingo Molnar, Josef Griebichler, Greg Kroah-Hartman, Alan Stern, USB list, Eric Dumazet, Rik van Riel, Paolo Abeni, Hannes Frederic Sowa, Jesper Dangaard Brouer, linux-kernel, netdev, Jonathan Corbet, LMML, Peter Zijlstra, David Miller Hi Linus, Em Sun, 7 Jan 2018 13:23:39 -0800 Linus Torvalds <torvalds@linux-foundation.org> escreveu: > On Sat, Jan 6, 2018 at 11:54 AM, Mauro Carvalho Chehab > <mchehab@s-opensource.com> wrote: > > > > Em Sat, 6 Jan 2018 16:04:16 +0100 > > "Josef Griebichler" <griebichler.josef@gmx.at> escreveu: > >> > >> the causing commit has been identified. > >> After reverting commit https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=4cd13c21b207e80ddb1144c576500098f2d5f882 > >> its working again. > > > > Just replying to me won't magically fix this. The ones that were involved on > > this patch should also be c/c, plus USB people. Just added them. > > Actually, you seem to have added an odd subset of the people involved. > > For example, Ingo - who actually committed that patch - wasn't on the cc. Sorry, my fault. I forgot to add him to it. > I do think we need to simply revert that patch. It's very simple: it > has been reported to lead to actual problems for people, and we don't > fix one problem and then say "well, it fixed something else" when > something breaks. > > When something breaks, we either unbreak it, or we revert the change > that caused the breakage. > > It's really that simple. That's what "no regressions" means. We don't > accept changes that cause regressions. This one did. Yeah, we should either unbreak or revert it. In the specific case of media devices, Alan came with a proposal of increasing the number of buffers. This is an one line change, and increase a capture delay from 0.63 ms to 5 ms on this specific case (Digital TV) shouldn't make much harm. So, I guess it would worth trying it before reverting the patch. It is hard to foresee the consequences of the softirq changes for other devices, though. For example, we didn't have any reports about this issue affecting cameras, Most cameras use ISOC nowadays, but some only provide bulk transfers. We usually try to use the minimum number of buffers possible, as increasing latency on cameras can be very annoying, specially on videoconference applications. Thanks, Mauro ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: dvb usb issues since kernel 4.9 2018-01-08 10:02 ` Mauro Carvalho Chehab @ 2018-01-08 11:59 ` Jesper Dangaard Brouer 2018-01-08 12:53 ` Mauro Carvalho Chehab 0 siblings, 1 reply; 47+ messages in thread From: Jesper Dangaard Brouer @ 2018-01-08 11:59 UTC (permalink / raw) To: Mauro Carvalho Chehab Cc: Linus Torvalds, Ingo Molnar, Josef Griebichler, Greg Kroah-Hartman, Alan Stern, USB list, Eric Dumazet, Rik van Riel, Paolo Abeni, Hannes Frederic Sowa, linux-kernel, netdev, Jonathan Corbet, LMML, Peter Zijlstra, David Miller On Mon, 8 Jan 2018 08:02:00 -0200 Mauro Carvalho Chehab <mchehab@s-opensource.com> wrote: > Hi Linus, > > Em Sun, 7 Jan 2018 13:23:39 -0800 > Linus Torvalds <torvalds@linux-foundation.org> escreveu: > > > On Sat, Jan 6, 2018 at 11:54 AM, Mauro Carvalho Chehab > > <mchehab@s-opensource.com> wrote: > > > > > > Em Sat, 6 Jan 2018 16:04:16 +0100 > > > "Josef Griebichler" <griebichler.josef@gmx.at> escreveu: > > >> > > >> the causing commit has been identified. > > >> After reverting commit https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=4cd13c21b207e80ddb1144c576500098f2d5f882 > > >> its working again. > > > > > > Just replying to me won't magically fix this. The ones that were involved on > > > this patch should also be c/c, plus USB people. Just added them. > > > > Actually, you seem to have added an odd subset of the people involved. > > > > For example, Ingo - who actually committed that patch - wasn't on the cc. > > Sorry, my fault. I forgot to add him to it. > > > I do think we need to simply revert that patch. It's very simple: it > > has been reported to lead to actual problems for people, and we don't > > fix one problem and then say "well, it fixed something else" when > > something breaks. > > > > When something breaks, we either unbreak it, or we revert the change > > that caused the breakage. > > > > It's really that simple. That's what "no regressions" means. We don't > > accept changes that cause regressions. This one did. > > Yeah, we should either unbreak or revert it. In the specific case of > media devices, Alan came with a proposal of increasing the number of > buffers. This is an one line change, and increase a capture delay from > 0.63 ms to 5 ms on this specific case (Digital TV) shouldn't make much > harm. So, I guess it would worth trying it before reverting the patch. Let find the root-cause of this before reverting, as this will hurt the networking use-case. I want to see if the increase buffer will solve the issue (the current buffer of 0.63 ms seem too small). I would also like to see experiments with adjusting adjust the sched priority of the kthread's and/or the userspace prog. (e.g use command like 'sudo chrt --fifo -p 10 $(pgrep udp_sink)' ). Are we really sure that the regression is cause by 4cd13c21b207 ("softirq: Let ksoftirqd do its job"), the forum thread also report that the problem is almost gone after commit 34f41c0316ed ("timers: Fix overflow in get_next_timer_interrupt") https://git.kernel.org/torvalds/c/34f41c0316ed It makes me suspicious that this fix changes things... After this fix, I suspect that changing the sched priorities, will fix the remaining glitches. > It is hard to foresee the consequences of the softirq changes for other > devices, though. Yes, it is hard to foresee, I can only cover networking. For networking, if reverting this, we will (again) open the kernel for an easy DDoS vector with UDP packets. As mentioned in the commit desc, before you could easily cause softirq to take all the CPU time from the application, resulting in very low "good-put" in the UDP-app. (That's why it was so easy to DDoS DNS servers before...) With the softirqd patch in place, ksoftirqd is scheduled fairly between other applications running on the same CPU. But in some cases this is not what you want, so as the also commit mentions, the admin can now more easily tune process scheduling parameters if needed, to adjust for such use-cases (it was not really an admin choice before). > For example, we didn't have any reports about this issue affecting cameras, > Most cameras use ISOC nowadays, but some only provide bulk transfers. > We usually try to use the minimum number of buffers possible, as > increasing latency on cameras can be very annoying, specially on > videoconference applications. -- Best regards, Jesper Dangaard Brouer MSc.CS, Principal Kernel Engineer at Red Hat LinkedIn: http://www.linkedin.com/in/brouer ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: dvb usb issues since kernel 4.9 2018-01-08 11:59 ` Jesper Dangaard Brouer @ 2018-01-08 12:53 ` Mauro Carvalho Chehab 2018-01-08 16:25 ` Alan Stern 0 siblings, 1 reply; 47+ messages in thread From: Mauro Carvalho Chehab @ 2018-01-08 12:53 UTC (permalink / raw) To: Jesper Dangaard Brouer Cc: Linus Torvalds, Ingo Molnar, Josef Griebichler, Greg Kroah-Hartman, Alan Stern, USB list, Eric Dumazet, Rik van Riel, Paolo Abeni, Hannes Frederic Sowa, linux-kernel, netdev, Jonathan Corbet, LMML, Peter Zijlstra, David Miller Em Mon, 8 Jan 2018 12:59:10 +0100 Jesper Dangaard Brouer <jbrouer@redhat.com> escreveu: > On Mon, 8 Jan 2018 08:02:00 -0200 > Mauro Carvalho Chehab <mchehab@s-opensource.com> wrote: > > > Hi Linus, > > > > Em Sun, 7 Jan 2018 13:23:39 -0800 > > Linus Torvalds <torvalds@linux-foundation.org> escreveu: > > > > > On Sat, Jan 6, 2018 at 11:54 AM, Mauro Carvalho Chehab > > > <mchehab@s-opensource.com> wrote: > > > > > > > > Em Sat, 6 Jan 2018 16:04:16 +0100 > > > > "Josef Griebichler" <griebichler.josef@gmx.at> escreveu: > > > >> > > > >> the causing commit has been identified. > > > >> After reverting commit https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=4cd13c21b207e80ddb1144c576500098f2d5f882 > > > >> its working again. > > > > > > > > Just replying to me won't magically fix this. The ones that were involved on > > > > this patch should also be c/c, plus USB people. Just added them. > > > > > > Actually, you seem to have added an odd subset of the people involved. > > > > > > For example, Ingo - who actually committed that patch - wasn't on the cc. > > > > Sorry, my fault. I forgot to add him to it. > > > > > I do think we need to simply revert that patch. It's very simple: it > > > has been reported to lead to actual problems for people, and we don't > > > fix one problem and then say "well, it fixed something else" when > > > something breaks. > > > > > > When something breaks, we either unbreak it, or we revert the change > > > that caused the breakage. > > > > > > It's really that simple. That's what "no regressions" means. We don't > > > accept changes that cause regressions. This one did. > > > > Yeah, we should either unbreak or revert it. In the specific case of > > media devices, Alan came with a proposal of increasing the number of > > buffers. This is an one line change, and increase a capture delay from > > 0.63 ms to 5 ms on this specific case (Digital TV) shouldn't make much > > harm. So, I guess it would worth trying it before reverting the patch. > > Let find the root-cause of this before reverting, as this will hurt the > networking use-case. > > I want to see if the increase buffer will solve the issue (the current > buffer of 0.63 ms seem too small). For TV, high latency has mainly two practical consequences: 1) it increases the time to switch channels. MPEG-TS based transmissions usually takes some time to start showing the channel contents. Adding more buffers make it worse; 2) specially when watching sports, a higher latency means that you'll know that your favorite team made a score when your neighbors start celebrating... seeing the actual event only after them. So, the lower, the merrier, but I think that 5 ms would be acceptable. > I would also like to see experiments with adjusting adjust the sched > priority of the kthread's and/or the userspace prog. (e.g use command > like 'sudo chrt --fifo -p 10 $(pgrep udp_sink)' ). If this fixes the issue, we'll need to do something inside the Kernel to change the priority, as TV userspace apps should not run as root. Not sure where such change should be done (USB? media?). > Are we really sure that the regression is cause by 4cd13c21b207 > ("softirq: Let ksoftirqd do its job"), the forum thread also report > that the problem is almost gone after commit 34f41c0316ed ("timers: Fix > overflow in get_next_timer_interrupt") > https://git.kernel.org/torvalds/c/34f41c0316ed I'll see if I can mount a test scenario here in order to try reproduce the reported bug. I suspect that I won't be able to reproduce it on my "standard" i7core-based test machine, even with KPTI enabled. > It makes me suspicious that this fix changes things... > After this fix, I suspect that changing the sched priorities, will fix > the remaining glitches. > > > > It is hard to foresee the consequences of the softirq changes for other > > devices, though. > > Yes, it is hard to foresee, I can only cover networking. > > For networking, if reverting this, we will (again) open the kernel for > an easy DDoS vector with UDP packets. As mentioned in the commit desc, > before you could easily cause softirq to take all the CPU time from the > application, resulting in very low "good-put" in the UDP-app. (That's why > it was so easy to DDoS DNS servers before...) > > With the softirqd patch in place, ksoftirqd is scheduled fairly between > other applications running on the same CPU. But in some cases this is > not what you want, so as the also commit mentions, the admin can now > more easily tune process scheduling parameters if needed, to adjust for > such use-cases (it was not really an admin choice before). Can't the ksoftirq patch be modified to only apply to the networking IRQ handling? That sounds less risky of affecting unrelated subsystems[1]. [1] Actually, DVB drivers can also implement networking for satellite based Internet, but, in this case, the top half is implemented inside the DVB core, as the IP traffic should be filtered out of an MPEG-TS stream. Not sure if the UDP DDoS attack you're mentioning would affect DVB net, but I guess not. AFAIKT, there aren't many users using DVB net nowadays. I don't have any easy way to test DVB net here. Thanks, Mauro ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: dvb usb issues since kernel 4.9 2018-01-08 12:53 ` Mauro Carvalho Chehab @ 2018-01-08 16:25 ` Alan Stern 0 siblings, 0 replies; 47+ messages in thread From: Alan Stern @ 2018-01-08 16:25 UTC (permalink / raw) To: Mauro Carvalho Chehab Cc: Jesper Dangaard Brouer, Linus Torvalds, Ingo Molnar, Josef Griebichler, Greg Kroah-Hartman, USB list, Eric Dumazet, Rik van Riel, Paolo Abeni, Hannes Frederic Sowa, linux-kernel, netdev, Jonathan Corbet, LMML, Peter Zijlstra, David Miller On Mon, 8 Jan 2018, Mauro Carvalho Chehab wrote: > > Let find the root-cause of this before reverting, as this will hurt the > > networking use-case. > > > > I want to see if the increase buffer will solve the issue (the current > > buffer of 0.63 ms seem too small). > > For TV, high latency has mainly two practical consequences: > > 1) it increases the time to switch channels. MPEG-TS based transmissions > usually takes some time to start showing the channel contents. Adding > more buffers make it worse; > > 2) specially when watching sports, a higher latency means that you'll know > that your favorite team made a score when your neighbors start > celebrating... seeing the actual event only after them. > > So, the lower, the merrier, but I think that 5 ms would be acceptable. That value 65 for the number of buffers was calculated based on a misunderstanding of the actual bandwidth requirement. Still increasing the number of buffers shouldn't hurt, and it's worth trying. But there is another misunderstanding here which needs to be cleared up. Adding more buffers does _not_ increase latency; it increases capacity. Making each buffer larger _would_ increase latency, but that's not what I proposed. Going through this more explicitly... Suppose you receive 8 KB of data every ms, and suppose you have four 8-KB buffers. Then the latency is 1 ms, because that's how long you have to wait for the first buffer to be filled up after you submit an I/O request. (The driver does _not_ need to wait for all four buffers to be filled before it can start displaying the data in the first buffer.) The capacity would be 4 ms, because that's how much data your buffers can store. If you end up waiting longer than 4 ms before ksoftirqd gets around to processing any of the data, then some data will inevitably get lost. That's why the way to deal with the delays caused by deferring softirqs to ksoftirqd is to add more buffers (and not make the buffers larger than they already are). > > I would also like to see experiments with adjusting adjust the sched > > priority of the kthread's and/or the userspace prog. (e.g use command > > like 'sudo chrt --fifo -p 10 $(pgrep udp_sink)' ). > > If this fixes the issue, we'll need to do something inside the Kernel > to change the priority, as TV userspace apps should not run as root. Not > sure where such change should be done (USB? media?). It would be interesting to try this, but I agree that it's not likely to be a practical solution. Anyway, shouldn't ksoftirqd already be running with very high priority? > > Are we really sure that the regression is cause by 4cd13c21b207 > > ("softirq: Let ksoftirqd do its job"), the forum thread also report > > that the problem is almost gone after commit 34f41c0316ed ("timers: Fix > > overflow in get_next_timer_interrupt") > > https://git.kernel.org/torvalds/c/34f41c0316ed That is a good point. It's hard to see how the issues in the two commits could be related, but who knows? > I'll see if I can mount a test scenario here in order to try reproduce > the reported bug. I suspect that I won't be able to reproduce it on my > "standard" i7core-based test machine, even with KPTI enabled. If you're using the same sort of hardware as Josef, under similar circumstances, the buggy bahavior should be the same. If not, there must be something else going on that we're not aware of. > > It makes me suspicious that this fix changes things... > > After this fix, I suspect that changing the sched priorities, will fix > > the remaining glitches. > > > > > > > It is hard to foresee the consequences of the softirq changes for other > > > devices, though. > > > > Yes, it is hard to foresee, I can only cover networking. > > > > For networking, if reverting this, we will (again) open the kernel for > > an easy DDoS vector with UDP packets. As mentioned in the commit desc, > > before you could easily cause softirq to take all the CPU time from the > > application, resulting in very low "good-put" in the UDP-app. (That's why > > it was so easy to DDoS DNS servers before...) > > > > With the softirqd patch in place, ksoftirqd is scheduled fairly between > > other applications running on the same CPU. But in some cases this is > > not what you want, so as the also commit mentions, the admin can now > > more easily tune process scheduling parameters if needed, to adjust for > > such use-cases (it was not really an admin choice before). > > Can't the ksoftirq patch be modified to only apply to the networking > IRQ handling? That sounds less risky of affecting unrelated subsystems[1]. That might work. Or more generally, allow drivers to specify which softirq sources should be deferred to ksoftirqd and which should not. Alan Stern > [1] Actually, DVB drivers can also implement networking for satellite > based Internet, but, in this case, the top half is implemented inside > the DVB core, as the IP traffic should be filtered out of an MPEG-TS > stream. Not sure if the UDP DDoS attack you're mentioning would affect > DVB net, but I guess not. AFAIKT, there aren't many users using DVB net > nowadays. I don't have any easy way to test DVB net here. > > Thanks, > Mauro ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: dvb usb issues since kernel 4.9 2018-01-07 21:23 ` Linus Torvalds 2018-01-08 10:02 ` Mauro Carvalho Chehab @ 2018-01-08 17:55 ` Ingo Molnar 2018-01-08 18:32 ` Linus Torvalds 1 sibling, 1 reply; 47+ messages in thread From: Ingo Molnar @ 2018-01-08 17:55 UTC (permalink / raw) To: Linus Torvalds Cc: Mauro Carvalho Chehab, Josef Griebichler, Greg Kroah-Hartman, Alan Stern, USB list, Eric Dumazet, Rik van Riel, Paolo Abeni, Hannes Frederic Sowa, Jesper Dangaard Brouer, linux-kernel, netdev, Jonathan Corbet, LMML, Peter Zijlstra, David Miller * Linus Torvalds <torvalds@linux-foundation.org> wrote: > On Sat, Jan 6, 2018 at 11:54 AM, Mauro Carvalho Chehab > <mchehab@s-opensource.com> wrote: > > > > Em Sat, 6 Jan 2018 16:04:16 +0100 > > "Josef Griebichler" <griebichler.josef@gmx.at> escreveu: > >> > >> the causing commit has been identified. > >> After reverting commit https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=4cd13c21b207e80ddb1144c576500098f2d5f882 > >> its working again. > > > > Just replying to me won't magically fix this. The ones that were involved on > > this patch should also be c/c, plus USB people. Just added them. > > Actually, you seem to have added an odd subset of the people involved. > > For example, Ingo - who actually committed that patch - wasn't on the cc. > > I do think we need to simply revert that patch. It's very simple: it > has been reported to lead to actual problems for people, and we don't > fix one problem and then say "well, it fixed something else" when > something breaks. > > When something breaks, we either unbreak it, or we revert the change > that caused the breakage. > > It's really that simple. That's what "no regressions" means. We don't > accept changes that cause regressions. This one did. Yeah, absolutely - for the revert: Acked-by: Ingo Molnar <mingo@kernel.org> as I doubt we have enough time to root-case this properly. Thanks, Ingo ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: dvb usb issues since kernel 4.9 2018-01-08 17:55 ` Ingo Molnar @ 2018-01-08 18:32 ` Linus Torvalds 2018-01-08 19:15 ` Alan Stern 0 siblings, 1 reply; 47+ messages in thread From: Linus Torvalds @ 2018-01-08 18:32 UTC (permalink / raw) To: Ingo Molnar Cc: Mauro Carvalho Chehab, Josef Griebichler, Greg Kroah-Hartman, Alan Stern, USB list, Eric Dumazet, Rik van Riel, Paolo Abeni, Hannes Frederic Sowa, Jesper Dangaard Brouer, linux-kernel, netdev, Jonathan Corbet, LMML, Peter Zijlstra, David Miller On Mon, Jan 8, 2018 at 9:55 AM, Ingo Molnar <mingo@kernel.org> wrote: > > as I doubt we have enough time to root-case this properly. Well, it's not like this is a new issue, and we don't have to get it fixed for 4.15. It's been around since 4.9, it's not a "have to suddenly fix it this week" issue. I just think that people should plan on having to maybe revert it and mark the revert for stable. But if the USB or DVB layers can instead just make the packet queue a bit deeper and not react so badly to the latency of a single softirq, that would obviously be a good thing in general, and maybe fix this issue. So I'm not saying that the revert is inevitable either. But I have to say that that commit 4cd13c21b207 ("softirq: Let ksoftirqd do its job") was a pretty damn big hammer, and entirely ignored the "softirqs can have latency concerns" issue. So I do feel like the UDP packet storm thing might want a somewhat more directed fix than that huge hammer of trying to move softirqs aggressively into the softirq thread. This is not that different from threaded irqs. And while you can set the "thread every irq" flag, that would be largely insane to do by default and in general. So instead, people do it either for specific irqs (ie "request_threaded_irq()") or they have a way to opt out of it (IRQF_NO_THREAD). I _suspect_ that the softirq thing really just wants the same thing. Have the networking case maybe set the "prefer threaded" flag just for networking, if it's less latency-sensitive for softirq handling than In fact, even for networking, there are separate TX/RX softirqs, maybe networking would only set it for the RX case? Or maybe even trigger it only for cases where things queue up and it goes into a "polling mode" (like NAPI already does). Of course, I don't even know _which_ softirq it is that the DVB case has issues with. Maybe it's the same NET_RX case? But looking at that offending commit, I do note (for example), that we literally have things like tasklet[_hi]_schedule() that might have been explicitly expected to just run the tasklet at a fairly low latency (maybe instead of a workqueue exactly because it doesn't need to sleep and wants lower latency). So saying "just because softirqd is possibly already woken up, let's delay all those tasklets etc" does really seem very wrong to me. Can somebody tell which softirq it is that dvb/usb cares about? Linus ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: dvb usb issues since kernel 4.9 2018-01-08 18:32 ` Linus Torvalds @ 2018-01-08 19:15 ` Alan Stern 2018-01-08 19:51 ` Linus Torvalds 2018-01-26 14:17 ` Mauro Carvalho Chehab 0 siblings, 2 replies; 47+ messages in thread From: Alan Stern @ 2018-01-08 19:15 UTC (permalink / raw) To: Linus Torvalds Cc: Ingo Molnar, Mauro Carvalho Chehab, Josef Griebichler, Greg Kroah-Hartman, USB list, Eric Dumazet, Rik van Riel, Paolo Abeni, Hannes Frederic Sowa, Jesper Dangaard Brouer, linux-kernel, netdev, Jonathan Corbet, LMML, Peter Zijlstra, David Miller On Mon, 8 Jan 2018, Linus Torvalds wrote: > Can somebody tell which softirq it is that dvb/usb cares about? I don't know about the DVB part. The USB part is a little difficult to analyze, mostly because the bug reports I've seen are mostly from people running non-vanilla kernels. For example, Josef is using a Raspberry Pi 3B with a non-standard USB host controller driver: dwc_otg_hcd is built into raspbian in place of the normal dwc2_hsotg driver. Both dwc2_hsotg and ehci-hcd use the tasklets embedded in the giveback_urb_bh member of struct usb_hcd. See usb_hcd_giveback_urb() in drivers/usb/core/hcd.c; the calls are else if (high_prio_bh) tasklet_hi_schedule(&bh->bh); else tasklet_schedule(&bh->bh); As it turns out, high_prio_bh gets set for interrupt and isochronous URBs but not for bulk and control URBs. The DVB driver in question uses bulk transfers. xhci-hcd, on the other hand, does not use these tasklets (it doesn't set the HCD_BH bit in the hc_driver's .flags member). Alan Stern ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: dvb usb issues since kernel 4.9 2018-01-08 19:15 ` Alan Stern @ 2018-01-08 19:51 ` Linus Torvalds 2018-01-09 17:42 ` Mauro Carvalho Chehab 2018-07-17 11:54 ` Hanna Hawa 2018-01-26 14:17 ` Mauro Carvalho Chehab 1 sibling, 2 replies; 47+ messages in thread From: Linus Torvalds @ 2018-01-08 19:51 UTC (permalink / raw) To: Alan Stern Cc: Ingo Molnar, Mauro Carvalho Chehab, Josef Griebichler, Greg Kroah-Hartman, USB list, Eric Dumazet, Rik van Riel, Paolo Abeni, Hannes Frederic Sowa, Jesper Dangaard Brouer, linux-kernel, netdev, Jonathan Corbet, LMML, Peter Zijlstra, David Miller [-- Attachment #1: Type: text/plain, Size: 716 bytes --] On Mon, Jan 8, 2018 at 11:15 AM, Alan Stern <stern@rowland.harvard.edu> wrote: > > Both dwc2_hsotg and ehci-hcd use the tasklets embedded in the > giveback_urb_bh member of struct usb_hcd. See usb_hcd_giveback_urb() > in drivers/usb/core/hcd.c; the calls are > > else if (high_prio_bh) > tasklet_hi_schedule(&bh->bh); > else > tasklet_schedule(&bh->bh); > > As it turns out, high_prio_bh gets set for interrupt and isochronous > URBs but not for bulk and control URBs. The DVB driver in question > uses bulk transfers. Ok, so we could try out something like the appended? NOTE! I have not tested this at all. It LooksObvious(tm), but... Linus [-- Attachment #2: patch.diff --] [-- Type: text/plain, Size: 1342 bytes --] kernel/softirq.c | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/kernel/softirq.c b/kernel/softirq.c index 2f5e87f1bae2..97b080956fea 100644 --- a/kernel/softirq.c +++ b/kernel/softirq.c @@ -79,12 +79,16 @@ static void wakeup_softirqd(void) /* * If ksoftirqd is scheduled, we do not want to process pending softirqs - * right now. Let ksoftirqd handle this at its own rate, to get fairness. + * right now. Let ksoftirqd handle this at its own rate, to get fairness, + * unless we're doing some of the synchronous softirqs. */ -static bool ksoftirqd_running(void) +#define SOFTIRQ_NOW_MASK ((1 << HI_SOFTIRQ) | (1 << TASKLET_SOFTIRQ)) +static bool ksoftirqd_running(unsigned long pending) { struct task_struct *tsk = __this_cpu_read(ksoftirqd); + if (pending & SOFTIRQ_NOW_MASK) + return false; return tsk && (tsk->state == TASK_RUNNING); } @@ -325,7 +329,7 @@ asmlinkage __visible void do_softirq(void) pending = local_softirq_pending(); - if (pending && !ksoftirqd_running()) + if (pending && !ksoftirqd_running(pending)) do_softirq_own_stack(); local_irq_restore(flags); @@ -352,7 +356,7 @@ void irq_enter(void) static inline void invoke_softirq(void) { - if (ksoftirqd_running()) + if (ksoftirqd_running(local_softirq_pending())) return; if (!force_irqthreads) { ^ permalink raw reply related [flat|nested] 47+ messages in thread
* Re: dvb usb issues since kernel 4.9 2018-01-08 19:51 ` Linus Torvalds @ 2018-01-09 17:42 ` Mauro Carvalho Chehab 2018-01-09 17:55 ` Linus Torvalds 2018-01-09 21:26 ` Jesper Dangaard Brouer 2018-07-17 11:54 ` Hanna Hawa 1 sibling, 2 replies; 47+ messages in thread From: Mauro Carvalho Chehab @ 2018-01-09 17:42 UTC (permalink / raw) To: Linus Torvalds, Peter Zijlstra Cc: Alan Stern, Ingo Molnar, Josef Griebichler, Greg Kroah-Hartman, USB list, Eric Dumazet, Rik van Riel, Paolo Abeni, Hannes Frederic Sowa, Jesper Dangaard Brouer, linux-kernel, netdev, Jonathan Corbet, LMML, David Miller Em Mon, 8 Jan 2018 11:51:04 -0800 Linus Torvalds <torvalds@linux-foundation.org> escreveu: > On Mon, Jan 8, 2018 at 11:15 AM, Alan Stern <stern@rowland.harvard.edu> wrote: > > > > Both dwc2_hsotg and ehci-hcd use the tasklets embedded in the > > giveback_urb_bh member of struct usb_hcd. See usb_hcd_giveback_urb() > > in drivers/usb/core/hcd.c; the calls are > > > > else if (high_prio_bh) > > tasklet_hi_schedule(&bh->bh); > > else > > tasklet_schedule(&bh->bh); > > > > As it turns out, high_prio_bh gets set for interrupt and isochronous > > URBs but not for bulk and control URBs. The DVB driver in question > > uses bulk transfers. > > Ok, so we could try out something like the appended? > > NOTE! I have not tested this at all. It LooksObvious(tm), but... > > Linus > kernel/softirq.c | 12 ++++++++---- > 1 file changed, 8 insertions(+), 4 deletions(-) > > diff --git a/kernel/softirq.c b/kernel/softirq.c > index 2f5e87f1bae2..97b080956fea 100644 > --- a/kernel/softirq.c > +++ b/kernel/softirq.c > @@ -79,12 +79,16 @@ static void wakeup_softirqd(void) > > /* > * If ksoftirqd is scheduled, we do not want to process pending softirqs > - * right now. Let ksoftirqd handle this at its own rate, to get fairness. > + * right now. Let ksoftirqd handle this at its own rate, to get fairness, > + * unless we're doing some of the synchronous softirqs. > */ > -static bool ksoftirqd_running(void) > +#define SOFTIRQ_NOW_MASK ((1 << HI_SOFTIRQ) | (1 << TASKLET_SOFTIRQ)) > +static bool ksoftirqd_running(unsigned long pending) > { > struct task_struct *tsk = __this_cpu_read(ksoftirqd); > > + if (pending & SOFTIRQ_NOW_MASK) > + return false; > return tsk && (tsk->state == TASK_RUNNING); > } > > @@ -325,7 +329,7 @@ asmlinkage __visible void do_softirq(void) > > pending = local_softirq_pending(); > > - if (pending && !ksoftirqd_running()) > + if (pending && !ksoftirqd_running(pending)) > do_softirq_own_stack(); > > local_irq_restore(flags); > @@ -352,7 +356,7 @@ void irq_enter(void) > > static inline void invoke_softirq(void) > { > - if (ksoftirqd_running()) > + if (ksoftirqd_running(local_softirq_pending())) > return; > > if (!force_irqthreads) { Hi Linus, Patch makes sense to me, although I was not able to test it myself. I set a RPi3 machine here with vanilla Kernel 4.14.11 running a standard raspbian distribution (with elevator=deadline). Right now, I'm trying to reproduce the bug with dvbv5-zap. I may eventually do more tests on some other slow machines. Usually, applications like tvheadend records just one channel. So, instead of a ~58 Mbits/s payload, it uses, typically, ~11 Mbits/s for a HD channel. This is usually filtered by hardware. Here, I'm forcing to record the entire TS, in order to make easier to reproduce the issue. So, I'm forcing a condition that it is usually worse than real usecases (at last for HD - I I don't have any DVB stream here with a 4K channel). >From what I checked so far, with vanila upstream Kernel on RPi3, just receiving a DVB stream - or receiving it and writing to /dev/null works with or without your patch. The problem starts to happen when there are concurrency with writes. On my preliminar tests, writing to a file on an ext4 partition at a USB stick loses data up to the point to make it useless (1/4 of the data is lost!). However, writing to a class 10 microSD card is doable. If you're curious enough, this is what I'm doing (that are the results while using class 10 microSD card): $ FILE=/tmp/out.ts; for i in $(seq 1 6); do echo "step $i"; rm $FILE 2>/dev/null; dvbv5-zap -l universal -c ~/vivo-channels.conf NBR -o $FILE -P -t60 2>&1|grep -E "(buffer|received)"; du $FILE 2>/dev/null; done step 1 Setting buffer length to 7250000 buffer overrun buffer overrun buffer overrun buffer overrun buffer overrun buffer overrun buffer overrun received 347504652 bytes (5656 Kbytes/sec) 339368 /tmp/out.ts step 2 Setting buffer length to 7250000 buffer overrun received 408995880 bytes (6656 Kbytes/sec) 399416 /tmp/out.ts step 3 Setting buffer length to 7250000 received 412999716 bytes (6722 Kbytes/sec) 403328 /tmp/out.ts step 4 Setting buffer length to 7250000 buffer overrun received 415564788 bytes (6763 Kbytes/sec) 405832 /tmp/out.ts step 5 Setting buffer length to 7250000 received 412999716 bytes (6722 Kbytes/sec) 403324 /tmp/out.ts step 6 Setting buffer length to 7250000 received 408366080 bytes (6646 Kbytes/sec) 398796 /tmp/out.ts My plan is to do more tests along this week, and try to tweak a little bit both userspace and kernelspace, in order to see if I can get better results. Thanks, Mauro ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: dvb usb issues since kernel 4.9 2018-01-09 17:42 ` Mauro Carvalho Chehab @ 2018-01-09 17:55 ` Linus Torvalds 2018-01-09 21:26 ` Jesper Dangaard Brouer 1 sibling, 0 replies; 47+ messages in thread From: Linus Torvalds @ 2018-01-09 17:55 UTC (permalink / raw) To: Mauro Carvalho Chehab Cc: Peter Zijlstra, Alan Stern, Ingo Molnar, Josef Griebichler, Greg Kroah-Hartman, USB list, Eric Dumazet, Rik van Riel, Paolo Abeni, Hannes Frederic Sowa, Jesper Dangaard Brouer, linux-kernel, netdev, Jonathan Corbet, LMML, David Miller On Tue, Jan 9, 2018 at 9:42 AM, Mauro Carvalho Chehab <mchehab@s-opensource.com> wrote: > > On my preliminar tests, writing to a file on an ext4 partition at a > USB stick loses data up to the point to make it useless (1/4 of the data > is lost!). However, writing to a class 10 microSD card is doable. Note that most USB sticks are horrible crap. They can have write latencies counted in _seconds_. You can cause VM issues and various other non-hardware stalls with them, simply because something gets stuck waiting for a page writeout that should take a few ms on any reasonable hardware, but ends up talking half a second or more. For example, even really well-written software that tries to do things like threaded write-behind to smooth out the IO will be _totally_ screwed by the USB stick behavior (where you might write a few MB at high speeds, and then the next write - however small - takes a second because the stupid USB stick does a synchronous garbage collection. Suddenly all that clever software that tried to keep things moving along smoothly without any hiccups, and tried hard to make the USB bus have a nice constant loadm can't do anything at all about the crap hardware. So when testing writes to USB sticks, I'm not convinced you're actually testing any USB bus limitations or even really any other hardware limitations than the USB stick itself. Linus ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: dvb usb issues since kernel 4.9 2018-01-09 17:42 ` Mauro Carvalho Chehab 2018-01-09 17:55 ` Linus Torvalds @ 2018-01-09 21:26 ` Jesper Dangaard Brouer 2018-01-10 3:02 ` Mike Galbraith 1 sibling, 1 reply; 47+ messages in thread From: Jesper Dangaard Brouer @ 2018-01-09 21:26 UTC (permalink / raw) To: Mauro Carvalho Chehab Cc: Linus Torvalds, Peter Zijlstra, Alan Stern, Ingo Molnar, Josef Griebichler, Greg Kroah-Hartman, USB list, Eric Dumazet, Rik van Riel, Paolo Abeni, Hannes Frederic Sowa, linux-kernel, netdev, Jonathan Corbet, LMML, David Miller On Tue, 9 Jan 2018 15:42:35 -0200 Mauro Carvalho Chehab <mchehab@s-opensource.com> wrote: > Em Mon, 8 Jan 2018 11:51:04 -0800 Linus Torvalds <torvalds@linux-foundation.org> escreveu: > [...] > Patch makes sense to me, although I was not able to test it myself. The patch also make sense to me. I've done some basic testing with it on my high-end Broadwell system (that I use for 100Gbit/s testing). As expected the network overload case still works, as NET_RX_SOFTIRQ is not matched. > I set a RPi3 machine here with vanilla Kernel 4.14.11 running a > standard raspbian distribution (with elevator=deadline). I found a Raspberry Pi Model B+ (I think, BCM2835), that I loaded the LibreELEC distro on. One of the guys even created an image for me with a specific kernel[1] (that I just upgraded the system with). [1] https://forum.libreelec.tv/thread/4235-dvb-issue-since-le-switched-to-kernel-4-9-x/?postID=77031#post77031 > My plan is to do more tests along this week, and try to tweak a little > bit both userspace and kernelspace, in order to see if I can get > better results. I've previously experienced that you can be affected by the scheduler granularity, which is adjustable (with CONFIG_SCHED_DEBUG=y): $ grep -H . /proc/sys/kernel/sched_*_granularity_ns /proc/sys/kernel/sched_min_granularity_ns:2250000 /proc/sys/kernel/sched_wakeup_granularity_ns:3000000 The above numbers were confirmed on the RPi2 (see[2]). With commit 4cd13c21b207 ("softirq: Let ksoftirqd do its job"), I expect/assume that softirq processing latency is bounded by the sched_wakeup_granularity_ns, which with 3 ms is not good enough for their use-case. Thus, if you manage to reproduce the case, try to see if adjusting this can mitigate the issue... Their system have non-preempt kernel, should they use PREEMPT? LibreELEC:~ # uname -a Linux LibreELEC 4.14.10 #1 SMP Tue Jan 9 17:35:03 GMT 2018 armv7l GNU/Linux [2] https://forum.libreelec.tv/thread/4235-dvb-issue-since-le-switched-to-kernel-4-9-x/?postID=76999#post76999 -- Best regards, Jesper Dangaard Brouer MSc.CS, Principal Kernel Engineer at Red Hat LinkedIn: http://www.linkedin.com/in/brouer ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: dvb usb issues since kernel 4.9 2018-01-09 21:26 ` Jesper Dangaard Brouer @ 2018-01-10 3:02 ` Mike Galbraith 0 siblings, 0 replies; 47+ messages in thread From: Mike Galbraith @ 2018-01-10 3:02 UTC (permalink / raw) To: Jesper Dangaard Brouer, Mauro Carvalho Chehab Cc: Linus Torvalds, Peter Zijlstra, Alan Stern, Ingo Molnar, Josef Griebichler, Greg Kroah-Hartman, USB list, Eric Dumazet, Rik van Riel, Paolo Abeni, Hannes Frederic Sowa, linux-kernel, netdev, Jonathan Corbet, LMML, David Miller On Tue, 2018-01-09 at 22:26 +0100, Jesper Dangaard Brouer wrote: > > I've previously experienced that you can be affected by the scheduler > granularity, which is adjustable (with CONFIG_SCHED_DEBUG=y): > > $ grep -H . /proc/sys/kernel/sched_*_granularity_ns > /proc/sys/kernel/sched_min_granularity_ns:2250000 > /proc/sys/kernel/sched_wakeup_granularity_ns:3000000 > > The above numbers were confirmed on the RPi2 (see[2]). With commit > 4cd13c21b207 ("softirq: Let ksoftirqd do its job"), I expect/assume that > softirq processing latency is bounded by the sched_wakeup_granularity_ns, > which with 3 ms is not good enough for their use-case. Note of caution wrt twiddling sched_wakeup_granularity_ns: it must remain < sched_latency_ns/2 else you effectively disable wakeup preemption completely, turning CFS into a tick granularity scheduler. -Mike ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: dvb usb issues since kernel 4.9 2018-01-08 19:51 ` Linus Torvalds 2018-01-09 17:42 ` Mauro Carvalho Chehab @ 2018-07-17 11:54 ` Hanna Hawa 2018-07-17 17:09 ` Linus Torvalds 1 sibling, 1 reply; 47+ messages in thread From: Hanna Hawa @ 2018-07-17 11:54 UTC (permalink / raw) To: torvalds Cc: corbet, davem, edumazet, gregkh, griebichler.josef, hannes, jbrouer, linux-kernel, linux-media, linux-usb, mchehab, mingo, netdev, pabeni, peterz, riel, stern, dmaengine, vkoul, dan.j.williams, nadavh, thomas.petazzoni, Omri Itach Hi, I'm a software developer working in Marvell SoC team. I'm facing kernel panic issue while running raid 5 on sata disks connected to Macchiatobin (Marvell community board with Armada-8040 SoC with 4 ARMv8 cores of CA72) Raid 5 built with Marvell DMA engine and async_tx mechanism (ASYNC_TX_DMA [=y]); the DMA driver (mv_xor_v2) uses a tasklet to clean the done descriptors from the queue. The panic (see below) occurs while building the RAID-5 (mdadm) or while writing/reading to the raid partition. After some debug/bisect/diff, found that patch "softirq: Let ksoftirqd do its job" is problematic patch. - Using v4.14.0 and problematic patch reverted - no timout issue. - Using v4.14.0 (including softirq patch) and the additional fix proposed by Linus - no timeout issue. As others have reported in this thread, the softirq change is causing some regression. Would it be possible to either revert the patch or apply a fix such as the one proposed by Linus ? Below panic message: [ 25.371495] mv_xor_v2 f0400000.xor: dma_sync_wait: timeout! [ 25.377101] Kernel panic - not syncing: async_tx_quiesce: DMA error waiting for transaction [ 25.377101] [ 25.386973] CPU: 0 PID: 1417 Comm: md0_raid5 Not tainted 4.14.0 #16 [ 25.393264] Hardware name: Marvell Armada 8040 DB board (DT) [ 25.398946] Call trace: [ 25.401410] [<ffff000008089310>] dump_backtrace+0x0/0x380 [ 25.406831] [<ffff0000080896a4>] show_stack+0x14/0x20 [ 25.411904] [<ffff00000890fa78>] dump_stack+0x98/0xb8 [ 25.416976] [<ffff0000080c8ef0>] panic+0x118/0x280 [ 25.421788] [<ffff000008386a44>] async_tx_quiesce+0x74/0x78 [ 25.427382] [<ffff000008386ca4>] async_memcpy+0x1a4/0x2a0 [ 25.432806] [<ffff000008747f9c>] async_copy_data.isra.16+0x1b4/0x280 [ 25.439186] [<ffff00000874b6fc>] raid_run_ops+0x514/0x1320 [ 25.444694] [<ffff000008751550>] handle_stripe+0x1040/0x2848 [ 25.450377] [<ffff000008752f98>] handle_active_stripes.isra.28+0x240/0x460 [ 25.457279] [<ffff000008753468>] raid5d+0x2b0/0x450 [ 25.462177] [<ffff00000875ead4>] md_thread+0x104/0x160 [ 25.467338] [<ffff0000080e638c>] kthread+0xfc/0x128 [ 25.472234] [<ffff000008085354>] ret_from_fork+0x10/0x1c [ 25.477571] Kernel Offset: disabled [ 25.481073] CPU features: 0x002000 [ 25.484487] Memory Limit: none [ 25.487556] ---[ end Kernel panic - not syncing: async_tx_quiesce: DMA error waiting for transaction [ 25.487556] Thanks, Hanna ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: dvb usb issues since kernel 4.9 2018-07-17 11:54 ` Hanna Hawa @ 2018-07-17 17:09 ` Linus Torvalds 2018-07-17 18:07 ` Hanna Hawa 2018-07-17 22:21 ` Mauro Carvalho Chehab 0 siblings, 2 replies; 47+ messages in thread From: Linus Torvalds @ 2018-07-17 17:09 UTC (permalink / raw) To: hannah Cc: Jonathan Corbet, David Miller, Eric Dumazet, Greg Kroah-Hartman, Josef Griebichler, Hannes Frederic Sowa, Jesper Dangaard Brouer, Linux Kernel Mailing List, Linux Media Mailing List, USB list, Mauro Carvalho Chehab, Ingo Molnar, Network Development, Paolo Abeni, Peter Zijlstra, Rik van Riel, Alan Stern, dma, vkoul, Dan Williams, nadavh, thomas.petazzoni, omrii On Tue, Jul 17, 2018 at 4:58 AM Hanna Hawa <hannah@marvell.com> wrote: > > After some debug/bisect/diff, found that patch "softirq: Let ksoftirqd > do its job" is problematic patch. Ok, this thread died down without any resolution. >- Using v4.14.0 (including softirq patch) and the additional fix > proposed by Linus - no timeout issue. Are you talking about the patch that made HI_SOFTIRQ and TASKLET_SOFTIRQ special, and had this: #define SOFTIRQ_NOW_MASK ((1 << HI_SOFTIRQ) | (1 << TASKLET_SOFTIRQ)) in it? I think I'll just commit the damn thing. It's hacky, but it's simple, and it never got applied because we had smarter suggestions. But the smarter suggestions never ended up being applied either, so.. Linus ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: dvb usb issues since kernel 4.9 2018-07-17 17:09 ` Linus Torvalds @ 2018-07-17 18:07 ` Hanna Hawa 2018-07-17 22:21 ` Mauro Carvalho Chehab 1 sibling, 0 replies; 47+ messages in thread From: Hanna Hawa @ 2018-07-17 18:07 UTC (permalink / raw) To: Linus Torvalds Cc: Jonathan Corbet, David Miller, Eric Dumazet, Greg Kroah-Hartman, Josef Griebichler, Hannes Frederic Sowa, Jesper Dangaard Brouer, Linux Kernel Mailing List, Linux Media Mailing List, USB list, Mauro Carvalho Chehab, Ingo Molnar, Network Development, Paolo Abeni, Peter Zijlstra, Rik van Riel, Alan Stern, dma, vkoul, Dan Williams, nadavh, thomas.petazzoni, omrii Hi Linus, On 07/17/2018 08:09 PM, Linus Torvalds wrote: > On Tue, Jul 17, 2018 at 4:58 AM Hanna Hawa <hannah@marvell.com> wrote: >> >> After some debug/bisect/diff, found that patch "softirq: Let ksoftirqd >> do its job" is problematic patch. > > Ok, this thread died down without any resolution. > >> - Using v4.14.0 (including softirq patch) and the additional fix >> proposed by Linus - no timeout issue. > > Are you talking about the patch that made HI_SOFTIRQ and > TASKLET_SOFTIRQ special, and had this: > > #define SOFTIRQ_NOW_MASK ((1 << HI_SOFTIRQ) | (1 << TASKLET_SOFTIRQ)) > > in it? yes, exactly.. Link to the patch: https://git.linuxtv.org/mchehab/experimental.git/commit/?h=v4.15%2bmedia%2bdwc2&id=ccf833fd4a5b99c3d3cf2c09c065670f74a230a7 Thanks, Hanna > > I think I'll just commit the damn thing. It's hacky, but it's simple, > and it never got applied because we had smarter suggestions. But the > smarter suggestions never ended up being applied either, so.. > > Linus > ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: dvb usb issues since kernel 4.9 2018-07-17 17:09 ` Linus Torvalds 2018-07-17 18:07 ` Hanna Hawa @ 2018-07-17 22:21 ` Mauro Carvalho Chehab 1 sibling, 0 replies; 47+ messages in thread From: Mauro Carvalho Chehab @ 2018-07-17 22:21 UTC (permalink / raw) To: Linus Torvalds Cc: hannah, Jonathan Corbet, David Miller, Eric Dumazet, Greg Kroah-Hartman, Josef Griebichler, Hannes Frederic Sowa, Jesper Dangaard Brouer, Linux Kernel Mailing List, Linux Media Mailing List, USB list, Mauro Carvalho Chehab, Ingo Molnar, Network Development, Paolo Abeni, Peter Zijlstra, Rik van Riel, Alan Stern, dma, vkoul, Dan Williams, nadavh, thomas.petazzoni, omrii Hi Linus, Em Tue, 17 Jul 2018 10:09:28 -0700 Linus Torvalds <torvalds@linux-foundation.org> escreveu: > On Tue, Jul 17, 2018 at 4:58 AM Hanna Hawa <hannah@marvell.com> wrote: > > > > After some debug/bisect/diff, found that patch "softirq: Let ksoftirqd > > do its job" is problematic patch. > > Ok, this thread died down without any resolution. > > >- Using v4.14.0 (including softirq patch) and the additional fix > > proposed by Linus - no timeout issue. > > Are you talking about the patch that made HI_SOFTIRQ and > TASKLET_SOFTIRQ special, and had this: > > #define SOFTIRQ_NOW_MASK ((1 << HI_SOFTIRQ) | (1 << TASKLET_SOFTIRQ)) > > in it? > > I think I'll just commit the damn thing. It's hacky, but it's simple, > and it never got applied because we had smarter suggestions. But the > smarter suggestions never ended up being applied either, so.. Yeah, IMHO the best would be to apply your patch[1], c/c stable up to 4.9. Nothing prevents applying a better/smarter solution once we have it. From my side, I can keep testing whatever smart suggestions people propose. Yet, better to have one fix on our hand than two fixes flying around. [1] e. g. https://git.linuxtv.org/mchehab/experimental.git/commit/?h=v4.15%2bmedia%2bdwc2&id=ccf833fd4a5b99c3d3cf2c09c065670f74a230a7 Regards, Mauro ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: dvb usb issues since kernel 4.9 2018-01-08 19:15 ` Alan Stern 2018-01-08 19:51 ` Linus Torvalds @ 2018-01-26 14:17 ` Mauro Carvalho Chehab 2018-01-26 19:37 ` Mauro Carvalho Chehab 1 sibling, 1 reply; 47+ messages in thread From: Mauro Carvalho Chehab @ 2018-01-26 14:17 UTC (permalink / raw) To: Alan Stern Cc: Linus Torvalds, Ingo Molnar, Josef Griebichler, Greg Kroah-Hartman, USB list, Eric Dumazet, Rik van Riel, Paolo Abeni, Hannes Frederic Sowa, Jesper Dangaard Brouer, linux-kernel, netdev, Jonathan Corbet, LMML, Peter Zijlstra, David Miller, John Youn, Felipe Balbi, Grigor Tovmasyan Hi Alan, Em Mon, 8 Jan 2018 14:15:35 -0500 (EST) Alan Stern <stern@rowland.harvard.edu> escreveu: > On Mon, 8 Jan 2018, Linus Torvalds wrote: > > > Can somebody tell which softirq it is that dvb/usb cares about? > > I don't know about the DVB part. The USB part is a little difficult to > analyze, mostly because the bug reports I've seen are mostly from > people running non-vanilla kernels. I suspect that the main reason for people not using non-vanilla Kernels is that, among other bugs, the dwc2 upstream driver has serious troubles handling ISOCH traffic. Using Kernel 4.15-rc7 from this git tree: https://git.linuxtv.org/mchehab/experimental.git/log/?h=softirq_fixup (e. g. with the softirq bug partially reverted with Linux patch, and the DWC2 deferred probe fixed) With a PCTV 461e device, with uses em28xx driver + Montage frontend (with is the same used on dvbsky hardware - except for em28xx). This device doesn't support bulk for DVB, just ISOCH. The drivers work fine on x86. Using a test signal at the bit rate of 56698,4 Kbits/s, that's what happens, when capturing less than one second of data: $ dvbv5-zap -c ~/dvb_channel.conf "tv brasil" -l universal -X 100 -m -t2dvbv5-zap -c ~/dvb_channel.conf "tv brasil" -l universal -X 100 -m -t2 Using LNBf UNIVERSAL Universal, Europe Freqs : 10800 to 11800 MHz, LO: 9750 MHz Freqs : 11600 to 12700 MHz, LO: 10600 MHz using demux 'dvb0.demux0' reading channels from file '/home/mchehab/dvb_channel.conf' tuning to 11468000 Hz (0x00) Signal= -33.90dBm Lock (0x1f) Signal= -33.90dBm C/N= 30.28dB postBER= 2.33x10^-6 dvb_dev_set_bufsize: buffer set to 6160384 dvb_set_pesfilter to 0x2000 354.08s: Starting capture 354.73s: only read 59220 bytes 354.73s: Stopping capture [ 354.000827] dwc2 3f980000.usb: DWC OTG HCD EP DISABLE: bEndpointAddress=0x84, ep->hcpriv=116f41b2 [ 354.000859] dwc2 3f980000.usb: DWC OTG HCD EP RESET: bEndpointAddress=0x84 [ 354.010744] dwc2 3f980000.usb: --Host Channel 5 Interrupt: Frame Overrun-- ... (hundreds of thousands of Frame Overrun messages) [ 354.660857] dwc2 3f980000.usb: --Host Channel 5 Interrupt: Frame Overrun-- [ 354.660935] dwc2 3f980000.usb: DWC OTG HCD URB Dequeue [ 354.660959] dwc2 3f980000.usb: Called usb_hcd_giveback_urb() [ 354.660966] dwc2 3f980000.usb: urb->status = 0 [ 354.660992] dwc2 3f980000.usb: DWC OTG HCD URB Dequeue [ 354.661001] dwc2 3f980000.usb: Called usb_hcd_giveback_urb() [ 354.661008] dwc2 3f980000.usb: urb->status = 0 [ 354.661054] dwc2 3f980000.usb: DWC OTG HCD URB Dequeue [ 354.661065] dwc2 3f980000.usb: Called usb_hcd_giveback_urb() [ 354.661072] dwc2 3f980000.usb: urb->status = 0 [ 354.661107] dwc2 3f980000.usb: DWC OTG HCD URB Dequeue [ 354.661120] dwc2 3f980000.usb: Called usb_hcd_giveback_urb() [ 354.661127] dwc2 3f980000.usb: urb->status = 0 [ 354.661146] dwc2 3f980000.usb: DWC OTG HCD URB Dequeue [ 354.661158] dwc2 3f980000.usb: Called usb_hcd_giveback_urb() [ 354.661165] dwc2 3f980000.usb: urb->status = 0 Kernel was compiled with: CONFIG_USB_DWC2=y CONFIG_USB_DWC2_HOST=y # CONFIG_USB_DWC2_PERIPHERAL is not set # CONFIG_USB_DWC2_DUAL_ROLE is not set # CONFIG_USB_DWC2_PCI is not set CONFIG_USB_DWC2_DEBUG=y # CONFIG_USB_DWC2_VERBOSE is not set # CONFIG_USB_DWC2_TRACK_MISSED_SOFS is not set CONFIG_USB_DWC2_DEBUG_PERIODIC=y As reference, that's the output of lsusb for the PCTV usb hardware: $ lsusb -v -d 2013:0258 Bus 001 Device 005: ID 2013:0258 PCTV Systems Couldn't open device, some information will be missing Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 64 idVendor 0x2013 PCTV Systems idProduct 0x0258 bcdDevice 1.00 iManufacturer 3 iProduct 1 iSerial 2 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 41 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0x80 (Bus Powered) MaxPower 500mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 0 bInterfaceProtocol 0 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x84 EP 4 IN bmAttributes 1 Transfer Type Isochronous Synch Type None Usage Type Data wMaxPacketSize 0x0000 1x 0 bytes bInterval 1 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 1 bNumEndpoints 1 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 0 bInterfaceProtocol 0 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x84 EP 4 IN bmAttributes 1 Transfer Type Isochronous Synch Type None Usage Type Data wMaxPacketSize 0x03ac 1x 940 bytes bInterval 1 Cheers, Mauro ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: dvb usb issues since kernel 4.9 2018-01-26 14:17 ` Mauro Carvalho Chehab @ 2018-01-26 19:37 ` Mauro Carvalho Chehab 2018-01-29 13:51 ` Mauro Carvalho Chehab 0 siblings, 1 reply; 47+ messages in thread From: Mauro Carvalho Chehab @ 2018-01-26 19:37 UTC (permalink / raw) To: Alan Stern Cc: Linus Torvalds, Ingo Molnar, Josef Griebichler, Greg Kroah-Hartman, USB list, Eric Dumazet, Rik van Riel, Paolo Abeni, Hannes Frederic Sowa, Jesper Dangaard Brouer, linux-kernel, netdev, Jonathan Corbet, LMML, Peter Zijlstra, David Miller, John Youn, Felipe Balbi, Grigor Tovmasyan Em Fri, 26 Jan 2018 12:17:37 -0200 Mauro Carvalho Chehab <mchehab@s-opensource.com> escreveu: > Hi Alan, > > Em Mon, 8 Jan 2018 14:15:35 -0500 (EST) > Alan Stern <stern@rowland.harvard.edu> escreveu: > > > On Mon, 8 Jan 2018, Linus Torvalds wrote: > > > > > Can somebody tell which softirq it is that dvb/usb cares about? > > > > I don't know about the DVB part. The USB part is a little difficult to > > analyze, mostly because the bug reports I've seen are mostly from > > people running non-vanilla kernels. > > I suspect that the main reason for people not using non-vanilla Kernels > is that, among other bugs, the dwc2 upstream driver has serious troubles > handling ISOCH traffic. > > Using Kernel 4.15-rc7 from this git tree: > https://git.linuxtv.org/mchehab/experimental.git/log/?h=softirq_fixup > > (e. g. with the softirq bug partially reverted with Linux patch, and > the DWC2 deferred probe fixed) > > With a PCTV 461e device, with uses em28xx driver + Montage frontend > (with is the same used on dvbsky hardware - except for em28xx). > > This device doesn't support bulk for DVB, just ISOCH. The drivers work > fine on x86. > > Using a test signal at the bit rate of 56698,4 Kbits/s, that's what > happens, when capturing less than one second of data: > > $ dvbv5-zap -c ~/dvb_channel.conf "tv brasil" -l universal -X 100 -m -t2dvbv5-zap -c ~/dvb_channel.conf "tv brasil" -l universal -X 100 -m -t2 > Using LNBf UNIVERSAL > Universal, Europe > Freqs : 10800 to 11800 MHz, LO: 9750 MHz > Freqs : 11600 to 12700 MHz, LO: 10600 MHz > using demux 'dvb0.demux0' > reading channels from file '/home/mchehab/dvb_channel.conf' > tuning to 11468000 Hz > (0x00) Signal= -33.90dBm > Lock (0x1f) Signal= -33.90dBm C/N= 30.28dB postBER= 2.33x10^-6 > dvb_dev_set_bufsize: buffer set to 6160384 > dvb_set_pesfilter to 0x2000 > 354.08s: Starting capture > 354.73s: only read 59220 bytes > 354.73s: Stopping capture > > [ 354.000827] dwc2 3f980000.usb: DWC OTG HCD EP DISABLE: bEndpointAddress=0x84, ep->hcpriv=116f41b2 > [ 354.000859] dwc2 3f980000.usb: DWC OTG HCD EP RESET: bEndpointAddress=0x84 > [ 354.010744] dwc2 3f980000.usb: --Host Channel 5 Interrupt: Frame Overrun-- > ... (hundreds of thousands of Frame Overrun messages) > [ 354.660857] dwc2 3f980000.usb: --Host Channel 5 Interrupt: Frame Overrun-- > [ 354.660935] dwc2 3f980000.usb: DWC OTG HCD URB Dequeue > [ 354.660959] dwc2 3f980000.usb: Called usb_hcd_giveback_urb() > [ 354.660966] dwc2 3f980000.usb: urb->status = 0 > [ 354.660992] dwc2 3f980000.usb: DWC OTG HCD URB Dequeue > [ 354.661001] dwc2 3f980000.usb: Called usb_hcd_giveback_urb() > [ 354.661008] dwc2 3f980000.usb: urb->status = 0 > [ 354.661054] dwc2 3f980000.usb: DWC OTG HCD URB Dequeue > [ 354.661065] dwc2 3f980000.usb: Called usb_hcd_giveback_urb() > [ 354.661072] dwc2 3f980000.usb: urb->status = 0 > [ 354.661107] dwc2 3f980000.usb: DWC OTG HCD URB Dequeue > [ 354.661120] dwc2 3f980000.usb: Called usb_hcd_giveback_urb() > [ 354.661127] dwc2 3f980000.usb: urb->status = 0 > [ 354.661146] dwc2 3f980000.usb: DWC OTG HCD URB Dequeue > [ 354.661158] dwc2 3f980000.usb: Called usb_hcd_giveback_urb() > [ 354.661165] dwc2 3f980000.usb: urb->status = 0 Btw, Just in case, I also applied all recent pending dwc2 patches I found at linux-usb (even trivial unrelated ones) at: https://git.linuxtv.org/mchehab/experimental.git/log/?h=dwc2_patches No differences. ISOCH is still broken. If anyone wants to see the full logs, it is there: https://pastebin.com/XJYyTwPv Cheers, Mauro ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: dvb usb issues since kernel 4.9 2018-01-26 19:37 ` Mauro Carvalho Chehab @ 2018-01-29 13:51 ` Mauro Carvalho Chehab 0 siblings, 0 replies; 47+ messages in thread From: Mauro Carvalho Chehab @ 2018-01-29 13:51 UTC (permalink / raw) To: Alan Stern Cc: Linus Torvalds, Ingo Molnar, Josef Griebichler, Greg Kroah-Hartman, USB list, Eric Dumazet, Rik van Riel, Paolo Abeni, Hannes Frederic Sowa, Jesper Dangaard Brouer, linux-kernel, netdev, Jonathan Corbet, LMML, Peter Zijlstra, David Miller, John Youn, Felipe Balbi, Grigor Tovmasyan Em Fri, 26 Jan 2018 17:37:39 -0200 Mauro Carvalho Chehab <mchehab@s-opensource.com> escreveu: > Em Fri, 26 Jan 2018 12:17:37 -0200 > Mauro Carvalho Chehab <mchehab@s-opensource.com> escreveu: > > > Hi Alan, > > > > Em Mon, 8 Jan 2018 14:15:35 -0500 (EST) > > Alan Stern <stern@rowland.harvard.edu> escreveu: > > > > > On Mon, 8 Jan 2018, Linus Torvalds wrote: > > > > > > > Can somebody tell which softirq it is that dvb/usb cares about? > > > > > > I don't know about the DVB part. The USB part is a little difficult to > > > analyze, mostly because the bug reports I've seen are mostly from > > > people running non-vanilla kernels. > > > > I suspect that the main reason for people not using non-vanilla Kernels > > is that, among other bugs, the dwc2 upstream driver has serious troubles > > handling ISOCH traffic. > > > > Using Kernel 4.15-rc7 from this git tree: > > https://git.linuxtv.org/mchehab/experimental.git/log/?h=softirq_fixup > > > > (e. g. with the softirq bug partially reverted with Linux patch, and > > the DWC2 deferred probe fixed) > > > > With a PCTV 461e device, with uses em28xx driver + Montage frontend > > (with is the same used on dvbsky hardware - except for em28xx). > > > > This device doesn't support bulk for DVB, just ISOCH. The drivers work > > fine on x86. > > > > Using a test signal at the bit rate of 56698,4 Kbits/s, that's what > > happens, when capturing less than one second of data: > > > > $ dvbv5-zap -c ~/dvb_channel.conf "tv brasil" -l universal -X 100 -m -t2dvbv5-zap -c ~/dvb_channel.conf "tv brasil" -l universal -X 100 -m -t2 > > Using LNBf UNIVERSAL > > Universal, Europe > > Freqs : 10800 to 11800 MHz, LO: 9750 MHz > > Freqs : 11600 to 12700 MHz, LO: 10600 MHz > > using demux 'dvb0.demux0' > > reading channels from file '/home/mchehab/dvb_channel.conf' > > tuning to 11468000 Hz > > (0x00) Signal= -33.90dBm > > Lock (0x1f) Signal= -33.90dBm C/N= 30.28dB postBER= 2.33x10^-6 > > dvb_dev_set_bufsize: buffer set to 6160384 > > dvb_set_pesfilter to 0x2000 > > 354.08s: Starting capture > > 354.73s: only read 59220 bytes > > 354.73s: Stopping capture > > > > [ 354.000827] dwc2 3f980000.usb: DWC OTG HCD EP DISABLE: bEndpointAddress=0x84, ep->hcpriv=116f41b2 > > [ 354.000859] dwc2 3f980000.usb: DWC OTG HCD EP RESET: bEndpointAddress=0x84 > > [ 354.010744] dwc2 3f980000.usb: --Host Channel 5 Interrupt: Frame Overrun-- > > ... (hundreds of thousands of Frame Overrun messages) > > [ 354.660857] dwc2 3f980000.usb: --Host Channel 5 Interrupt: Frame Overrun-- > > [ 354.660935] dwc2 3f980000.usb: DWC OTG HCD URB Dequeue > > [ 354.660959] dwc2 3f980000.usb: Called usb_hcd_giveback_urb() > > [ 354.660966] dwc2 3f980000.usb: urb->status = 0 > > [ 354.660992] dwc2 3f980000.usb: DWC OTG HCD URB Dequeue > > [ 354.661001] dwc2 3f980000.usb: Called usb_hcd_giveback_urb() > > [ 354.661008] dwc2 3f980000.usb: urb->status = 0 > > [ 354.661054] dwc2 3f980000.usb: DWC OTG HCD URB Dequeue > > [ 354.661065] dwc2 3f980000.usb: Called usb_hcd_giveback_urb() > > [ 354.661072] dwc2 3f980000.usb: urb->status = 0 > > [ 354.661107] dwc2 3f980000.usb: DWC OTG HCD URB Dequeue > > [ 354.661120] dwc2 3f980000.usb: Called usb_hcd_giveback_urb() > > [ 354.661127] dwc2 3f980000.usb: urb->status = 0 > > [ 354.661146] dwc2 3f980000.usb: DWC OTG HCD URB Dequeue > > [ 354.661158] dwc2 3f980000.usb: Called usb_hcd_giveback_urb() > > [ 354.661165] dwc2 3f980000.usb: urb->status = 0 > > Btw, > > Just in case, I also applied all recent pending dwc2 patches I found at > linux-usb (even trivial unrelated ones) at: > > https://git.linuxtv.org/mchehab/experimental.git/log/?h=dwc2_patches > > No differences. ISOCH is still broken. > > If anyone wants to see the full logs, it is there: > https://pastebin.com/XJYyTwPv Someone pointed me in priv that applying a change at DWC2 BRCM profile to enable uframe_sched might help. So, I wrote this patch: https://git.linuxtv.org/mchehab/experimental.git/commit/?h=v4.15%2bmedia%2bdwc2&id=19abf0026b7bf1bd44aa9d2add9f958935760ded And applied on the top of this branch: https://git.linuxtv.org/mchehab/experimental.git/log/?h=v4.15%2bmedia%2bdwc2 It is based on Kernel 4.15 vanilla. I applied: - all media -next patches that will be sent to Kernel 4.16-rc1; - DWC2 patches submitted by Gregor at linux-usb ML; - Linus softirq test patch: https://git.linuxtv.org/mchehab/experimental.git/commit/?h=v4.15%2bmedia%2bdwc2&id=ccf833fd4a5b99c3d3cf2c09c065670f74a230a7 - A DT patch that enables VCIQ (needed by some GPU drivers): https://git.linuxtv.org/mchehab/experimental.git/commit/?h=v4.15%2bmedia%2bdwc2&id=fd4e9ca6f41d35b6234c30fa29937141e0c09570 - a few debug patches like this one: https://git.linuxtv.org/mchehab/experimental.git/commit/?h=v4.15%2bmedia%2bdwc2&id=f50669c18394f5b5674630e2ebf78a06b023626f I didn't notice any difference. The dwc2 driver is still broken for ISOCH transfers: https://pastebin.com/nL1Fe9X5 Cheers, Mauro ^ permalink raw reply [flat|nested] 47+ messages in thread
end of thread, other threads:[~2018-07-17 22:21 UTC | newest]
Thread overview: 47+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <trinity-35b3a044-b548-4a31-9646-ed9bc83e6846-1513505978471@3c-app-gmx-bs03>
[not found] ` <20171217120634.pmmuhdqyqmbkxrvl@gofer.mess.org>
[not found] ` <20171217112738.4f3a4f9b@recife.lan>
[not found] ` <trinity-1fa14556-8596-44b1-95cb-b8919d94d2d4-1515251056328@3c-app-gmx-bs15>
2018-01-06 19:54 ` dvb usb issues since kernel 4.9 Mauro Carvalho Chehab
2018-01-06 21:07 ` Aw: " Josef Griebichler
2018-01-06 21:44 ` Alan Stern
2018-01-07 11:03 ` Mauro Carvalho Chehab
2018-01-07 15:41 ` Alan Stern
2018-01-07 17:01 ` Aw: " Josef Griebichler
2018-01-08 9:43 ` Mauro Carvalho Chehab
2018-01-08 16:10 ` Alan Stern
2018-01-08 16:26 ` Aw: " Josef Griebichler
2018-01-08 16:31 ` Alan Stern
2018-01-08 17:15 ` Aw: " Josef Griebichler
2018-01-08 17:35 ` Alan Stern
2018-01-08 20:40 ` Jesper Dangaard Brouer
2018-01-08 21:31 ` Jesper Dangaard Brouer
2018-01-08 21:44 ` Peter Zijlstra
2018-01-08 22:16 ` Jesper Dangaard Brouer
2018-01-09 16:51 ` Aw: " Josef Griebichler
2018-01-09 17:27 ` Eric Dumazet
2018-01-09 17:48 ` Linus Torvalds
2018-01-09 17:57 ` Eric Dumazet
2018-01-09 18:58 ` Linus Torvalds
2018-01-09 21:48 ` Eric Dumazet
2018-01-10 9:45 ` Jesper Dangaard Brouer
2018-01-12 21:13 ` Mauro Carvalho Chehab
2018-01-12 21:48 ` Eric Dumazet
2018-01-13 9:09 ` Mauro Carvalho Chehab
2018-01-13 10:46 ` Mauro Carvalho Chehab
2018-01-07 21:23 ` Linus Torvalds
2018-01-08 10:02 ` Mauro Carvalho Chehab
2018-01-08 11:59 ` Jesper Dangaard Brouer
2018-01-08 12:53 ` Mauro Carvalho Chehab
2018-01-08 16:25 ` Alan Stern
2018-01-08 17:55 ` Ingo Molnar
2018-01-08 18:32 ` Linus Torvalds
2018-01-08 19:15 ` Alan Stern
2018-01-08 19:51 ` Linus Torvalds
2018-01-09 17:42 ` Mauro Carvalho Chehab
2018-01-09 17:55 ` Linus Torvalds
2018-01-09 21:26 ` Jesper Dangaard Brouer
2018-01-10 3:02 ` Mike Galbraith
2018-07-17 11:54 ` Hanna Hawa
2018-07-17 17:09 ` Linus Torvalds
2018-07-17 18:07 ` Hanna Hawa
2018-07-17 22:21 ` Mauro Carvalho Chehab
2018-01-26 14:17 ` Mauro Carvalho Chehab
2018-01-26 19:37 ` Mauro Carvalho Chehab
2018-01-29 13:51 ` Mauro Carvalho Chehab
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).