[14:22] <funman> mchehab: https://pastebin.com/hvCNgWcB why can't I tune with dvbv5-zap, while dvblast works ? [14:29] <mchehab> funman: there was as a bug on libdvbv5 affecting some LNBf that was fixed recently [14:29] <mchehab> are you trying with the latest version from git? [14:30] <mchehab> (a new stable release with those bugs fixed was just released this week - probably it didn't reach distros yet) [14:30] <funman> hm let me check [14:30] <funman> no it's a bit older [14:31] <funman> well it's a git checkout but not up to date [14:31] <mchehab> ok, please check if the newest version solved the issue [14:32] <funman> nope [14:32] <mchehab> could you pastebin what happens with logs enabled? [14:33] <funman> https://pastebin.com/7Hi0bUkm not much more [14:35] <mchehab> what matters most there is this: [14:35] <mchehab> frequency: 10995.00 MHz, high_band: 0 [14:35] <mchehab> L-Band frequency: 1245.00 MHz (offset = 9750.00 MHz) [14:36] <funman> well i note that dvblast doesn't have a lnb setting [14:36] <mchehab> maybe it assumes universal LNBf [14:37] <mchehab> try to tune with "-l universal" instead of "-l extended" [14:37] <funman> same result [14:37] <mchehab> (fyi, the parameter is case-insensitive) [14:37] <funman> ah ok, will save a keystroke :) [14:38] <mchehab> hmm.. it should be tuning at 1250 MHz instead of 1245 MHz [14:38] <mchehab> (11000 - 9750) [14:39] <mchehab> hmm... frequency is 10995000 [14:39] <mchehab> ok, then it is tuning to the right frequency [14:39] <mchehab> (it is weird to se a fractional frequency like that) [14:41] <mchehab> funman: are you sure that the settings at dvblast.conf are identical to the ones at test.chan ? [14:42] <funman> mchehab: dvblast.conf only holds network destinations, all the settings are given on the command line [14:42] <funman> I took the frequency from http://www.satelliweb.com/index.php?section=livef [14:42] <funman> $ ./dvblast -u --delsys DVBS -a 0 -f 10995000 -v 18 -s 4937000 -c dvblast.conf [14:43] <funman> -f freq -s srate -v voltage -a adapter --delsys sys (-u is no PID filtering) [14:46] <mchehab> bbiab - lunch [14:50] <funman> is there another app than zap i could use to tune ? [14:50] <funman> and what about reading the current frontend settings [14:57] <iive> mchehab: if you have a moment. Do you know anything about the v4l-cx2341x* firmware? [14:59] <iive> so far it seems the firmware has been available on ivtvdriver.org but that website is gone. [14:59] <iive> the firmware is needed by the latest kernel driver. [15:37] <funman> the ioctls are different: https://pastebin.com/sR1E0BFV [15:38] <funman> if I add MODULATION = QPSK to my test.chan, zap tells me ERROR command MODULATION (4) not found during store [15:40] <funman> i hope the DTV_TUNE parameter value is uninitialized and should be [15:48] <mchehab> iive: didn't know. You'll be able to get it from fedora's ivtv-firmware package [15:48] <mchehab> there's a catch, though: the license there doesn't allow redistributing it [15:48] <mchehab> so, we can't put at linuxtv.org [15:48] <mchehab> as only Red Hat has permission [15:49] <mchehab> to distribute [15:49] <mchehab> (and the other parties that received the firmware directly from Hauppauge) [15:49] <iive> can you put a link to that RH package in linuxtv.org website? [15:49] <mchehab> I guess so [15:50] <mchehab> the problem is that Fedora only maintains a distro for one year [15:51] <mchehab> after that, the package pointed there can vanish (depending on the mirror's policies) [15:51] <mchehab> it might point to rpmfind, instead: https://www.rpmfind.net/linux/rpm2html/search.php?query=ivtv-firmware [15:51] <funman> is it possible to extract it from a windows driver ? [15:51] <mchehab> not sure [15:51] <mchehab> probably yes - never tried [15:51] <iive> i think it has been extracted from such driver in the first place [15:52] <funman> assuming the windows driver would stay available from manufacturer [15:52] <iive> the question is, can the windows driver still be downloaded? [15:52] <mchehab> no. Hauppauge provided it [15:52] <mchehab> on that time, they believed that the license terms were OK [15:52] <mchehab> it was one of the first trials to make a firmware available on Linux [15:53] <mchehab> for media devices [15:53] <mchehab> I tried to solve it, years later, exchanging e-mails with Hauppauge and Connexant [15:53] <mchehab> without success [15:53] <mchehab> Hauppauge can't change the license without Conexant's ack [15:54] <mchehab> and Conexant was saying that the firmware Hauppauge was making available was the wrong one for the encoder [15:54] <mchehab> according with their records [15:54] <mchehab> (on that time, they weren't working with this chipset anymore) [15:55] <mchehab> so, they couldn't give permission for us to use a firmware that they didn't know its origin [15:56] <iive> https://web.archive.org/web/20150521230226/http://ivtvdriver.org:80/index.php/Firmware [15:57] <iive> mchehab: could conexant provide their version of the encoder for this chipset? [16:00] <funman> mchehab: does the difference in the ioctls ring a bell ? [16:00] <mchehab> I ended by removing the non-working encoder firmware from our website [16:00] <mchehab> (with was identical to another firmware there) [16:02] <mchehab> iive: I don't have contacts at Conexant anymore [16:03] <mchehab> maybe Hauppauge could store it somewhere, but we need to ask them [16:03] <mchehab> funman: DTV_TUNE doesn't require a parameter [16:03] <b-rad> tell me the exact fw filename and i'll talk to my boss [16:04] <funman> that's what I understand, i'm printing dtv_property.u.data here [16:04] <funman> i was thinking of either MODULATION, either the ordering of the parameters [16:04] <mchehab> b-rad: the firmwares we received from Conexant with redistribution rights are at: https://www.linuxtv.org/downloads/firmware/#conexant [16:05] <mchehab> they're shipped on standard linux-firmware tree [16:05] <mchehab> the one missing is called v4l-cx23885-enc.fw [16:05] <b-rad> ok i'll inquire [16:06] <mchehab> According with Conexant, the right one would be https://www.linuxtv.org/downloads/firmware/v4l-cx23885-enc-broken.fw, but this is known to not work [16:06] <mchehab> (so, I renamed it to -broken) [16:06] <mchehab> s/known to not work/known not to work/ [16:07] <mchehab> b-rad: thanks! [16:08] <b-rad> will let you know what they tell me [16:09] <mchehab> OK [16:09] <mchehab> they provided Red Hat with a license [16:09] <mchehab> so, they got Conexant's ack to distribute it [16:10] <mchehab> (it was at the time Steven was working at Hauppauge) [16:10] <mchehab> he may have more details [16:11] <mchehab> The issue is what's written on those license files: [16:11] <mchehab> /usr/share/doc/ivtv-firmware/license-end-user.txt [16:11] <mchehab> /usr/share/doc/ivtv-firmware/license-oemihvisv.txt [16:12] <mchehab> that prevents us to put the firmware at linuxtv, as it is not an end-user nor an OEM [16:14] <mchehab> basically, the end-user license forbids redistribution; the OEM license allows [16:15] <mchehab> neither kernel.org (where linux-firmware is stored) nor linuxtv.org is OEM - or end-user [16:20] <mchehab> b-rad: that's the package that Fedora and other distros used: https://web.archive.org/web/20150906125159/http://dl.ivtvdriver.org/ivtv/firmware/ivtv-firmware.tar.gz [16:21] <mchehab> on Debian/Ubuntu, this is at https://packages.debian.org/jessie/firmware-ivtv, as non-free [16:22] <mchehab> (probably because it restricts redistribution) [16:22] <mchehab> funman: back to your tuning issue [16:22] <mchehab> the parameter's order doesn't matter either [16:23] <mchehab> modulation is ignored for DVB-S [16:23] <mchehab> as there's just one modulation type [16:23] <mchehab> QPSK [16:25] <mchehab> if it requires a different modulation, then it is, instead, DVB-S2 [16:25] <mchehab> hmm... [16:25] <mchehab> maybe it is the timeout time whose default can be shorter on libdvbv5 [16:25] <funman> hm [16:26] <funman> no luck with -t 10 [16:26] <mchehab> try to change it to DVB-S2 [16:27] <mchehab> and add the DTV_MODULATION [16:27] <funman> that can't be [16:27] <funman> nope [16:31] <funman> hm I dont see a DTV_CLEAR [16:32] <mchehab> the only possible differences I'm seeing between dvblast and dvbv5-zap is modulation and timeout [16:32] <mchehab> from what you pointed at https://pastebin.com/sR1E0BFV [16:32] <mchehab> what driver are you using? [16:32] <mchehab> and what kernel? [16:32] <funman> 4.14.1-041401-generic from ubuntu [16:33] <funman> using ddbridge [16:34] <funman> https://pastebin.com/mNqDSGh2 [16:37] <funman> I removed DTV_CLEAR from dvblast and it still syncs [16:38] <mchehab> DTV_CLEAR just cleanups the cache [16:38] <mchehab> shouldn't be needed [16:39] <mchehab> use strace -e ioctl ./dvbv5-zap -v -l UNIVERSAL -a 0 -c test.chan TEST -t 10 [16:40] <funman> https://pastebin.com/rJY4ceme [16:47] <mchehab> I'm missing the ioctls that would be setting the LNBf [16:48] <funman> you mean they're missing from zap ? [16:48] <mchehab> yes [16:48] <mchehab> setting voltage [16:48] <funman> can i help? [16:49] <mchehab> I'm seeing if I can test it locally [16:50] <iive> mchehab: a little bit confused, isn't v4l-cx23885 for entirely different chipset than v4l-cx2341x one? [16:51] <mchehab> iive: the IP is the same, afaikt [16:52] <mchehab> I mean: both chipsets contain the same encoder/decoder IP block [16:52] <mchehab> as far as I can tell [16:52] <mchehab> you may need to rename the firmware file [16:52] * mchehab is unsure about what cx2341x driver expects [16:56] <mchehab> $ git grep v4l-cx drivers/media/ [16:56] <mchehab> drivers/media/i2c/cx25840/cx25840-firmware.c:#define CX2388x_FIRMWARE "v4l-cx23885-avcore-01.fw" [16:56] <mchehab> drivers/media/i2c/cx25840/cx25840-firmware.c:#define CX231xx_FIRMWARE "v4l-cx231xx-avcore-01.fw" [16:56] <mchehab> drivers/media/i2c/cx25840/cx25840-firmware.c:#define CX25840_FIRMWARE "v4l-cx25840.fw" [16:56] <mchehab> drivers/media/pci/cx18/cx18-av-firmware.c:#define FWFILE "v4l-cx23418-dig.fw" [16:56] <mchehab> drivers/media/pci/cx18/cx18-firmware.c:#define CX18_CPU_FIRMWARE "v4l-cx23418-cpu.fw" [16:56] <mchehab> drivers/media/pci/cx18/cx18-firmware.c:#define CX18_APU_FIRMWARE "v4l-cx23418-apu.fw" [16:56] <mchehab> drivers/media/pci/cx23885/cx23885-417.c:#define CX23885_FIRM_IMAGE_NAME "v4l-cx23885-enc.fw" [16:56] <mchehab> drivers/media/pci/ivtv/ivtv-firmware.c:#define IVTV_DECODE_INIT_MPEG_FILENAME "v4l-cx2341x-init.mpg" [16:56] <mchehab> drivers/media/usb/cx231xx/cx231xx-417.c:#define CX231xx_FIRM_IMAGE_NAME "v4l-cx23885-enc.fw" [16:57] <mchehab> iive: what driver are you using? [16:58] <iive> ivtv [16:58] <iive> firmware: v4l-cx2341x-init.mpg [16:58] <iive> firmware: v4l-cx2341x-dec.fw [16:58] <iive> firmware: v4l-cx2341x-enc.fw [16:59] <mchehab> as far as I can tell, the firmwares are the same: [16:59] <mchehab> v4l-cx23885-enc.fw [16:59] <mchehab> v4l-cx23885-dec.fw [16:59] <mchehab> the *.mpg is not really a firmware [16:59] <mchehab> just an mpeg header [17:00] <iive> it's a little bit too big for that. [17:02] <iive> does this mean the init.mpg is just dumped at the start of encoding, so the result is mpeg file that could be played? [17:03] <mchehab> at #v4l, you may ping awalls and hverkuil - they know more about ivtv [17:03] <mchehab> but I almost sure I tested it in the past [17:04] <iive> i will, but probably not right now. [17:04] <mchehab> the ones I use on my machine are those: [17:04] <mchehab> -rwxr-xr-x. 1 root root 262144 Dez 11 2014 v4l-cx2341x-dec.fw [17:04] <mchehab> -rwxr-xr-x. 1 root root 376836 Dez 11 2014 v4l-cx2341x-enc.fw [17:04] <mchehab> -rwxr-xr-x. 1 root root 155648 Dez 11 2014 v4l-cx2341x-init.mpg [17:05] <iive> same size. I think the driver checks it. [17:08] <mchehab> b-rad: it seems that the firmwares required for ivtv are different [17:08] <mchehab> see above [17:09] <mchehab> iive: I don't think it checks for an specific size [17:10] <mchehab> anyway, I'm almost sure the IP block is the same on both chipsets - but the firmware shipped was a different version [17:10] <mchehab> (at least from what I remind from past discussions with CX developers) [17:11] <mchehab> funman: I'll try to do some tests here [17:12] <mchehab> I need to fix some things first... there's somewhing wrong on my test machine [17:13] <iive> mchehab: ivtv0: Unable to open firmware v4l-cx2341x-enc.fw (must be 376836 bytes) [17:13] <iive> that's why I think it checks it. [17:13] <mchehab> gah [17:14] <mchehab> #define IVTV_FW_ENC_SIZE (376836) [17:14] <mchehab> #define IVTV_FW_DEC_SIZE (256*1024) [17:15] <mchehab> yes, you're right [17:15] <mchehab> it checks [17:16] * mchehab wonders if the restriction is removed, if the firmwares provided by connexant would work [17:16] <mchehab> they were meant to cx23885 [17:16] <mchehab> perhaps the IP block on cx2341x require an older firmware set [17:29] <funman> mchehab: thanks, talk to you tomorrow [17:29] * funman is in UTC+1 [17:32] <mchehab> ok. ttyl [18:02] <mchehab> # strace -e ioctl dvbv5-scan ~/test2.conf -l universal -S0 [18:02] <mchehab> ioctl(3, FE_SET_VOLTAGE, 0x1) = 0 [18:02] <mchehab> ioctl(3, FE_SET_TONE, 0x1) = 0 [18:02] <mchehab> ioctl(3, FE_DISEQC_SEND_MASTER_CMD, 0x7ffe533faf91) = 0 [18:02] <mchehab> ioctl(3, FE_DISEQC_SEND_BURST, 0) = 0 [18:02] <mchehab> ioctl(3, FE_SET_TONE, 0x1) = 0 [18:02] <mchehab> funman: you forgot to use "-S0". [18:02] <mchehab> without that, dvbv5 utils will assume that you don't want to turn on DiSEqC [18:03] <mchehab> It is likely a bug to accept an Universal LNBf without DiSEqC [18:04] <mchehab> it should at least warn [18:24] <mchehab> funman: added a patch to check it: https://git.linuxtv.org/v4l-utils.git/commit/?id=655a8e3e412f [19:03] <funman> mchehab: no more luck with -S0