[23:02] <nox-> & moin
[00:26] <crope> nox-: pong
[00:28] <nox-> moin crope, have you noticed reception issues with some rtl28xxu tuners recently?
[00:29] <nox-> someone it seems the driver is less sensitive now...
[00:30] <nox-> (with 0x1d19:0x1101 and nooelec 0x0bda:0x2838 at least, others still seem ok)
[00:32] <nox-> working: 4f4274af7009890f0d4724909bf9038193955489, broken: 4f671fe2f9523a1ea206f63fe60a7c7b3a56d5c7
[00:38] <nox-> nooelec gets corrupted streams after channel switch, 0x1d19:0x1101 receives nothing anymore at all
[00:42] <nox-> s/someone/somehow/
[00:45] <crope> there is no commit 4f671fe2f9523a1ea206f63fe60a7c7b3a56d5c7
[00:46] <crope> nox-: which tree has commit 4f671fe2f9523a1ea206f63fe60a7c7b3a56d5c7 ?
[00:47] <nox-> git://github.com/torvalds/linux.git media_tree apparently
[00:47] <nox-> or is that the wrong one?
[00:47] <crope> nox-: which is commit name and date?
[00:48] <nox-> hmm thats what hps wrote
[00:48] <nox-> guess ill ask him
[00:50] <crope> I did a lot of changes recently to rtl2832u driver. some potential mistakes could be for example register caching, some volatile register is cached
[00:52] <nox-> i c...
[00:54] <nox-> this is supposed to be a 4.0rc tree
[00:58] <nox-> i seem to have https://github.com/torvalds/linux/blob/master/drivers/media/dvb-frontends/rtl2832.c
[01:00] <crope> nox-: could you remove register caching and try if it helps
[01:00] <nox-> where is that?
[01:00] <crope> dev->regmap_config.cache_type = REGCACHE_RBTREE,
[01:00] <crope> change it to dev->regmap_config.cache_type = REGCACHE_NONE,
[01:06] <nox-> hmm nope, thats even worse
[01:06] <nox-> now even the rtl28xxu tuners that still worked are broken
[01:10] <crope> how many tuners you have?
[01:11] <crope> all rtl2832u devices were not broken, but only one?
[01:11] <nox-> yeah two were broken
[01:12] <nox-> i have 4 or 5 or so
[01:12] <nox-> <nox-> someone it seems the driver is less sensitive now...
[01:12] <nox-> <nox-> (with 0x1d19:0x1101 and nooelec 0x0bda:0x2838 at least, others still seem ok)
[01:12] <crope> those numbers does not say anything
[01:12] <nox-> 0x0ccd:0x00d3 now is broken too
[01:12] <crope> which are RF tuner IC used?
[01:13] <nox-> oh
[01:13] <nox-> r820t was one broken one
[01:13] <nox-> https://wiki.freebsd.org/WebcamCompat - mine are in ther
[01:13] <nox-> e
[01:15] <crope> what is tuners for those others?
[01:16] <nox-> http://rtlsdr.org/hardware-usb
[01:16] <nox-> E4000 now is broken too
[01:16] <nox-> (after your patch)
[01:17] <nox-> that one still worked before
[01:18] <nox-> FC2580 might be the other broken one
[01:18] <nox-> (somehow i thought it was FC0013, hmm)
[01:18] <nox-> 0x1d19 0x1101 FC2580 Dexatek DK DVB-T Dongle (Logilink VG0002A)
[01:21] <FSanches> mchehab: Hello, here's Felipe Sanches. I talked to you at some conference (probably at FISL) a few years ago.
[01:22] <FSanches> mchehab: I was working on a userspace driver for a Zinwell ISDB-T 1-Seg USB receiver
[01:22] <FSanches> mchehab: it was like 5 years ago, I guess.
[01:23] <mchehab> hi FSanches
[01:23] <FSanches> Recently I found the device in a box here in my house and got interested in working on it again
[01:23] <FSanches> I improved the code a bit but still did not get it to work properly
[01:23] <FSanches> I also started to port it to kernel-space
[01:24] <FSanches> I'm commiting to a fork of your linux-media tree hosted at my github account here: https://github.com/felipesanches/linux-media/commits/zinwell
[01:25] <FSanches> I do have access to the datasheet of the tuner (Maxim MAX2163) but I lack documentation on the other 2 chips:
[01:26] <FSanches> MegaChips MA50159
[01:26] <FSanches> and Somagic SMI-2020CBE
[01:27] <crope> nox-: for me it seems to work, though I saw some I2C errors when used VLC... I think there could not be big issue as I havent got any bug reports...
[01:27] <FSanches> so, it means my work is based on USB sniffer logs of the device while it was being controlled by the crappy proprietary windows program
[01:28] <nox-> well 4.0rc is still quite new so maybe you'll get the reports later
[01:28] <mchehab> FSanches: ok. usb sniffing should work
[01:28] <mchehab> especially for 1seg
[01:28] <FSanches> mchehab: Lucas Villa Real is also working with me on this
[01:28] <nox-> crope, and i tested using vdr...
[01:28] <FSanches> maybe you know him...
[01:29] <mchehab> yes, I know him
[01:29] <FSanches> :-)
[01:29] <mchehab> don't hear about him for a while
[01:30] <FSanches> So... it seems to me that the SMI-2020CBE chip is the one responsible for working as an i2c bridge over USB to allow the driver to communicate with the other 2 chips
[01:31] <mchehab> it would be nice if you had the demod datasheet
[01:31] <crope> nox-: I tested with VLC and dvbscan. And I have surely tested it using tzap, dvbv5-zap and dvbv5-scan when I did those changes as those are the tools I am using. usually I will get bug reports in a few days after patches are committed to media/master if there is big issues
[01:32] <mchehab> as isdb-t has lots of parameters to set there
[01:32] <mchehab> and it should be a little hard to get
[01:32] <mchehab> yet, thankfully, most demods work in "auto" mode
[01:32] <nox-> crope, lets me test using vlc too
[01:32] <nox-> crope, getting corrupted streams with r820t
[01:32] <nox-> with vlc
[01:33] <mchehab> getting everything they need from the TMCC carrier
[01:33] <crope> nox-: is your signal very weak?
[01:34] <nox-> it is kinda weak but worked with eaerlier driver versions
[01:34] <FSanches> let me ask you something simple... Is this i2c bridging over usb functionality the thing that characterizes a "dvb_frontend" in the code ?
[01:35] <nox-> crope, as i said it looks like the driver has become less sensitive
[01:35] <nox-> still waiting for picture with e4000...
[01:36] <nox-> ..on vlc
[01:37] <FSanches> As far as I can tell (by searching the current media codebase) this chip (Somagic SMI2020CBE) is still not supported by Linux so I'll have to add some code for that. Should I start fresh or should I append it to an existing source module? I mean... it is hard to classify this one grouped to other already supported devices. For instance, is there any ISDB-T device already supported?
[01:38] <crope> nox-: e4000 works too. what it reports as a NNR?
[01:38] <crope> CNR
[01:38] <crope> Lock (0x1f) Signal= 93.73% C/N= 27.25dB postBER= 0
[01:39] <nox-> where do i see that with vlc?
[01:40] <crope> vlc does not show any signal statistics
[01:40] <crope> use dvbv5-zap
[01:40] <nox-> ah ok
[01:40] <nox-> ill ise vdr-pluging-femon
[01:40] <nox-> use
[01:41] <nox-> no str reading, snd 00f3
[01:41] <nox-> snr
[01:41] <nox-> (0%)
[01:41] <crope> Lock (0x1f) Signal= 92.94% C/N= 32.67dB postBER= 0
[01:41] <crope> first CNR was e4000 and second one r820t
[01:42] <nox-> mind you with e4000 this is only broken with your oneliner patch
[01:42] <nox-> let me remove that and test again
[01:43] <nox-> now vdr works again but snr is still as low
[01:57] <nox-> ..and vlc gets no picture, only vdr does
[02:02] <nox-> vlc is weird, i dont even see how i switch channels...
[02:02] <nox-> (i get picture with r820t w/o your oneliner patch)
[02:06] <crope> you have to make playlist first which contains all the channels. after that could could pick channel from playlist
[02:06] <nox-> hm ok i just entered mux freq...
[02:07] <nox-> but anyway, vlc is broken with e4000 here
[02:07] <FSanches> mchehab: I just got my first good isochronous responses from the Zinwell ISDB-T device :-)
[02:08] <FSanches> I'll finish porting this userspace script to kernelspace and hopefully I'll get this thing working on Linux! I'm very excited about it! Woo-hoo!!!
[02:09] <nox-> crope, and your oneliner patch only makes reception worse here
[02:10] <nox-> crope, so i suppose there are still bugs
[02:30] <nox-> bbl
[02:36] *** nox- has quit IRC (Quit: nox-)
[02:43] <lokita23> ola
[02:43] <lokita23> hola
[02:43] <lokita23> q tal
[02:44] *** lokita23 has quit IRC (Quit: lokita23)
[03:30] <mchehab> FSanches: sorry, was busy with other things...
[03:31] <mchehab> a dvb_frontend is actually a tuner + demod
[03:31] <mchehab> (and SEC, for DVB-S/S2)
[03:32] <mchehab> except for max2163, you should write a new set of drivers, as those chips are different than the ones we use
[03:32] <mchehab> I think we have already a driver for max216x
[03:32] <mchehab> if so, the best is to try to reuse it