* 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-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 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-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 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
* 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
* 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: 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: 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: 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: 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: 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: 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: 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: 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 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-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-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
* 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
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).