[22:53] <swiftgeek> i'm really starting to understand why eg. samsung doesn't pay for code anymore but for documentation xD
[09:40] <mchehab> swiftgeek: very few devices support bandwidth auto-select...
[09:41] <mchehab> sending bandwith 0 (auto) is something that userspace should be prepared to handle, as this can fail
[09:41] <mchehab> and this will fail or do the wrong thing with most devices
[09:42] <mchehab> what some drivers used to do is to just assume some bandwidth (either 6 MHz or 8 MHz) and try to lock on it, returning a lock fail otherwise
[09:42] <mchehab> they usually don't try to autodetect
[09:43] <mchehab> with regards to RC, better to talk with crope
[09:43] <mchehab> via e-mail usually works better
[09:43] <mchehab> (e-mail to the ML)
[10:29] <swiftgeek> R820t is tuner
[10:31] <swiftgeek> and an improvement to behaviour described be you would be to have module parameter with default bandwidth then
[10:32] <swiftgeek> *by uou
[10:33] <swiftgeek> brand new behaviour from kernel is wierd
[10:33] <swiftgeek> *weird
[10:45] <iive> i think the case here is that vlc looses lock and tried to retune on the frequency.
[10:46] <iive> mchehab: can you help swiftgeek with bisecting the driver change, by compiling module out of the kernel tree?
[10:51] <mchehab> swiftgeek: that sounds a VLC bug. VLC was supposed to pass a proper bandwidth parameter to the Kernel
[10:52] <mchehab> filling bandwith with zero and hoping for the best is not how this was supposed to work
[10:52] <swiftgeek> but it works on 3.19
[10:52] <mchehab> maybe for your case
[10:52] <mchehab> for people on other countries, this will fail
[10:52] <mchehab> because bandwidth is per region
[10:52] <swiftgeek> so which is why i said that module parameter would be an improvement
[10:53] <mchehab> the improvement would be to add a parameter at vlc to allow specifying it
[10:53] <mchehab> or to properly read the frequency files that contains the bandwidth
[10:54] <swiftgeek> vlc can specify but hmm, automatic worked on older kernel :>
[10:54] <mchehab> btw, for me, it sounds more like a wrong configuration file
[10:54] <mchehab> swiftgeek: no, automatic didn't work.. rt820 doesn't support automatic
[10:54] <mchehab> nor rtl28xx
[10:55] <mchehab> it was just assuming 8MHz, I guess
[10:55] <swiftgeek> which is fine thing to do
[10:55] <mchehab> as most countries in Europe have both 8MHz and 6MHz channels...
[10:55] <mchehab> only half of the channels are tuned
[10:55] <swiftgeek> better would be to pass it as module parameter
[10:56] <swiftgeek> and now it's still weird because if you assume 100% perfect signal - it still works!
[10:56] <mchehab> (they use different bandwidths for UHF or VHF)
[10:56] <mchehab> that's Country-dependent
[10:56] <mchehab> as it actually depends about how the local regulator defined...
[10:57] <mchehab> and if both VHF and UHF bands are present or not on your city
[10:57] <swiftgeek> i understand that part very well no need to explain
[10:58] <swiftgeek> just notice that stupid remote has a parameter in many modules (that are loaded for one tuner) and this behaviour has none :P
[10:59] <swiftgeek> also probably autodetection that is made in software could have some parameter on how much it should wait for proper frame
[10:59] <swiftgeek> or whatever it is waiting for
[11:00] <mchehab> well, enabling remote controller does have an impact at the machine performance and at the power consumption
[11:00] <mchehab> as, on most devices, a task needs to be created to poll the RC
[11:00] <swiftgeek> oh right
[11:00] <mchehab> so, disabling RC saves battery/power
[11:01] <swiftgeek> makes me wonder if i could disable in eeprom D
[11:01] <mchehab> we don't add parameters to set DVB tuning parameters
[11:02] <mchehab> bandwidth _IS_ a required DVB tuning parameter
[11:02] <mchehab> and a driver should fail if those parameters don't match
[11:02] <mchehab> what's there at the physical channel
[11:03] <mchehab> btw, DVB API does report if automatic bandwidth is allowed, via a capability flag (FE_CAN_BANDWIDTH_AUTO)
[11:03] <mchehab> this is there since ever
[11:04] <swiftgeek> with those two lines kinda solved then
[11:04] <swiftgeek> but vlc doesn't know ;D
[11:04] <mchehab> if rtl28xx is telling that FE_CAN_BANDWIDTH_AUTO is supported and bandwidth == 0 doesn't work, this is a bug
[11:04] <mchehab> but, if it doesn't tell that, then this is a VLC bug
[11:04] <swiftgeek> wait
[11:05] <mchehab> VLC should NOT send bandwith = 0, if the device doesn't have FE_CAN_BANDWIDTH_AUTO
[11:05] <swiftgeek> can FE_CAN_BANDWIDTH_AUTO be unsupported AND can bandwidth==0 work?
[11:05] <mchehab> if so, this is a Kernel bug
[11:05] <swiftgeek> because this is what happens on perfect signal
[11:07] <swiftgeek> and can i get FE_CAN_BANDWIDTH_AUTO somehow?
[11:07] <mchehab> struct dvb_frontend_info
[11:07] <mchehab> #define FE_GET_INFO _IOR('o', 61, struct dvb_frontend_info)
[11:08] <swiftgeek> i meant without writing my own code
[11:16] <swiftgeek> and outside of tree compilation would be nice
[11:18] <swiftgeek> dvb-fe-tool
[11:18] <swiftgeek> surprised that autocompletion found it and not google
[11:19] <swiftgeek> then this tool should be enough to post the bug to vlc with nice description
[11:21] <swiftgeek> http://www.linuxtv.org/wiki/index.php/How_to_Obtain,_Build_and_Install_V4L-DVB_Device_Drivers so this would work, right?
[11:24] <swiftgeek> mchehab: sorry for being cranky i just have bad time with device trees :P
[11:25] <swiftgeek> i see many things on introduction level and nothing towards real life
[17:20] <swiftgeek> mchehab: hope u not mad at me, i'm very thankful for that FE_CAN_BANDWIDTH_AUTO thing ;)
[17:21] <mchehab> swiftgeek: not at all... just too busy here
[17:22] <swiftgeek> just saying cuz sometimes devs feel underappreciated or sth :P
[17:23] <swiftgeek> which in turn can lead to lennart-type behavior in some ppl
[17:25] <swiftgeek> i hope he will grow up from it eventually
[17:27] <mchehab> heh
[17:28] <swiftgeek> if you saw his tantrums on irc (never in person) you know what i mean :D
[17:29] <swiftgeek> sometimes i wish there was an indiegogo to fund some redhat person to smack him with dunno huge inflated hammer balloon thing every time he starts his drama
[17:31] <swiftgeek> or maybe we need beer-drone delivery to devs to calm hem ;D
[17:31] <swiftgeek> *them
[18:33] <Squ4lli> i cant get working my dvb-t card, i think there is a problem with tda9887 http://pastebin.com/raw.php?i=FYciY6a8 HELP
[18:41] <Squ4lli> Can someone help me plz? i have try everything
[18:45] <Squ4lli> and this message keep spawning in dmesg tda1004x: setting up plls for 53MHz sampling clock
[18:45] <Squ4lli> [ 2970.188010] tda1004x: found firmware revision 29 -- ok
[18:46] <Squ4lli> i think there is a conflict between analog/dvd, its an hybrid card but i need only dvb
[18:46] <Squ4lli> i meant dvb
[19:27] <Squ4lli> thx for help