Tvheadend

Benjamin Challinor wrote:

Yes - to get it to build i needed to make one alteration otherwise I got the symbol issue with remote controller support.

Try make menuconfig, then change ‘Remote Controller Support’ from <M> to <*>. By default it builds remote controller support as modules and that always leads to the error above. Switching to built in to the kernel sorts that issue out.

However I find limited success in using this at present as in the UK 2 particular DVB-T2 muxes fail to tune properly - seeming to take 5-10 seconds to stabilise using this device, but works fine with others muxes. Both muxes are fine with other tuners, so looks like there are some issues remaining.

Hi. I have the same problem. The HD muxes (DVB-T2) take longer to stabilise than Tvheadend expects, so a stream seems to fail. A recording is okay though.
I thought there might be a setting within tvheadend to wait but it seems not :-(

Anthony

Oddly, only 2 DVB-T2 muxes are a problem - the lower frequency ones. Another 3rd DVB-T2 mux works perfectly every time. No tvheadend setting changes this, so seems to be a driver issue most likely

If you're in the UK then this may be due to the work for "700MHz clearance" - the temporary COM-A & COM-B T2/HD muxes typically have lower ERP than the old muxes and may well be on frequencies in a different aerial group to those they replaced, so if you have a grouped aerial, maybe near the coverage margins or behind obstructions then the signal strength for those muxes may be far lower, and I'm not sure how well the Xbox One tuner copes with marginal signals. Have you compared signal strength / quality for those muxes with the others using a TV or something else with a diagnostic readout?
Take a look at the Coverage Checker (detailed view) at http://www.digitaluk.co.uk/ for more information.
Lots of very good information on aerial basics at http://www.aerialsandtv.com/atvschoiceofaerials.html

Yes, it’s COM 7&8 which are problematic, which are quarter power compared to the working DVB-T2 mux, so it could be related. However, on the few occasions when the tuner eventually works, its rock solid. Further, mygica t230 tuners also in use work perfectly on all muxes and both tuners agree on the signal strength on all muxes.

So difficult to say what’s going on at present. We switch over to clear 700mhz in a few days, so should be on full power on all muxes then which should rule that out or not

Hi,
I tend to agree with Benjamin, I think it is not the signal.
Using dvbv5-zap on monitor on a DVB-T2 mux with the main HD channels I get the following;

pi@raspberrypi:~ $ dvbv5-zap -c dvb_channel.conf "bbc two hd" -m > /dev/null
using demux '/dev/dvb/adapter0/demux0'
reading channels from file 'dvb_channel.conf'
service has pid type 05: 7110 7108
tuning to 482167000 Hz
(0x00)
Lock (0x1f) Quality= Good Signal= 82.11% C/N= 28.80dB UCB= 11273538 PER= 0
dvb_set_pesfilter to 0x2000
Lock (0x1f) Quality= Poor Signal= 82.11% C/N= 28.80dB UCB= 11274164 PER= 611x10^-3
Lock (0x1f) Quality= Poor Signal= 82.21% C/N= 28.35dB UCB= 11275067 PER= 578x10^-3
Lock (0x1f) Quality= Poor Signal= 82.21% C/N= 28.15dB UCB= 11276011 PER= 646x10^-3
Lock (0x1f) Quality= Poor Signal= 82.11% C/N= 28.55dB UCB= 11276963 PER= 607x10^-3
Lock (0x1f) Quality= Poor Signal= 82.21% C/N= 28.52dB UCB= 11277868 PER= 574x10^-3
Lock (0x1f) Quality= Poor Signal= 82.21% C/N= 28.80dB UCB= 11278795 PER= 594x10^-3
Lock (0x1f) Quality= Good Signal= 82.11% C/N= 27.71dB UCB= 11278795 PER= 0
Lock (0x1f) Quality= Good Signal= 82.21% C/N= 28.55dB UCB= 11278795 PER= 0
Lock (0x1f) Quality= Good Signal= 82.11% C/N= 28.58dB UCB= 11278795 PER= 0
Lock (0x1f) Quality= Good Signal= 82.11% C/N= 28.20dB UCB= 11278795 PER= 0
Lock (0x1f) Quality= Good Signal= 82.11% C/N= 29.13dB UCB= 11278795 PER= 0
Lock (0x1f) Quality= Good Signal= 82.11% C/N= 28.32dB UCB= 11278795 PER= 0
Lock (0x1f) Quality= Good Signal= 82.11% C/N= 29.16dB UCB= 11278795 PER= 0

whereas a DVB-T mux tunes straight away

dvbv5-zap -c dvb_channel.conf "bbc two" -m > /dev/null
using demux '/dev/dvb/adapter0/demux0'
reading channels from file 'dvb_channel.conf'
service has pid type 05: 7105 7103
tuning to 530000000 Hz
(0x00)
Lock (0x1f) Quality= Good Signal= 79.86% C/N= 32.46dB UCB= 11278795 PER= 0
dvb_set_pesfilter to 0x2000
Lock (0x1f) Quality= Good Signal= 79.86% C/N= 32.61dB UCB= 11278795 PER= 0
Lock (0x1f) Quality= Good Signal= 79.57% C/N= 32.53dB UCB= 11278795 PER= 0
Lock (0x1f) Quality= Good Signal= 79.47% C/N= 32.53dB UCB= 11278795 PER= 0
Lock (0x1f) Quality= Good Signal= 79.47% C/N= 32.31dB UCB= 11278795 PER= 0

Anthony

I'm waiting for the clearance/mux changes to occur on Sutton Coldfield. I can receive Waltham but that's pretty much useless as it's for the east & not west.

Ok, post retuning now the DVB-T2 mux at 602Mhz that has problems with this tuner has moved to a higher frequency and continues to have problems there (but as always it’s fine with the mygica T230). At 602mhz is a DVB-T mux now, and that tunes perfectly every time. Which shows that it’s not likely the tuner itself as it’s locking on to the signal in both cases. It seems the issue is more related to the demodulation. Another mux that was DVB-T and worked fine is now DVB-T2 and doesn’t work, back that up.

Interestingly, the only DVB-T2 mux that works fine is at a fractional frequency (.833). However changing the other muxes slightly doesn’t help

Hi, Since I upgraded the kernel as suggested I've not had any issues with reception, although as discussed it does take a while to lock.
I recently upgraded from a rpi2 to an rpi3 and i am getting a few crashes, maybe once every couple of days. Should I recompile? I need to reboot to fix it.

[179079.020715] usb 1-1.5: USB disconnect, device number 6
[179079.029719] Unable to handle kernel NULL pointer dereference at virtual address 00000014
[179079.035363] pgd = 80004000
[179079.037849] [00000014] *pgd=00000000
[179079.040497] Internal error: Oops: 5 [#1] SMP ARM
[179079.042539] Modules linked in: bnep hci_uart bluetooth ecdh_generic nfsd tun ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack ip_tables x_tables tda18250(O) mn88472(O) dvb_usb_dib0700(O) dib7000m(O) dib0090(O) dib0070(O) dib3000mc(O) dibx000_common(O) brcmfmac dvb_usb(O) brcmutil dvb_core(O) cfg80211 rfkill snd_bcm2835(C) snd_pcm snd_timer snd uio_pdrv_genirq sg uio fixed fuse ipv6
[179079.056807] CPU: 0 PID: 30674 Comm: kdvb-ad-0-fe-0 Tainted: G C O 4.14.22-v7+ #1096
[179079.061850] Hardware name: BCM2835
[179079.064399] task: b5101e00 task.stack: b910a000
[179079.067026] PC is at mn88472_sleep+0x24/0x60 [mn88472]
[179079.069670] LR is at dvb_usb_fe_sleep+0x40/0x5c [dvb_usb]
[179079.072314] pc : [<7f4820b8>] lr : [<7f35c6f4>] psr: 20000013
[179079.075017] sp : b910bef8 ip : b910bf10 fp : b910bf0c
[179079.077735] r10: 00000000 r9 : 80cb7b94 r8 : b910a000
[179079.080451] r7 : b96bf800 r6 : b96bf9ac r5 : b9cc6a38 r4 : 00000000
[179079.083130] r3 : b921e800 r2 : 00000030 r1 : 0000000c r0 : b71ec018
[179079.085732] Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user
[179079.088430] Control: 10c5383d Table: 350e806a DAC: 00000055
[179079.091170] Process kdvb-ad-0-fe-0 (pid: 30674, stack limit = 0xb910a210)
[179079.093988] Stack: (0xb910bef8 to 0xb910c000)
[179079.096734] bee0: 7f482094 b71ec018
[179079.101946] bf00: b910bf24 b910bf10 7f35c6f4 7f4820a0 b71ec018 00000001 b910bf7c b910bf28
[179079.107038] bf20: 7f32e5e0 7f35c6c0 807774d8 ba385d40 b71ec254 b96bf994 00000000 00000000
[179079.112140] bf40: b5101e00 801603f8 b910bf48 b910bf48 adae4e1c adae4e00 00000000 b726fd80
[179079.117394] bf60: b71ec018 7f32e334 adae4e1c b523bcd8 b910bfac b910bf80 8013d474 7f32e340
[179079.122965] bf80: 80102dd0 b726fd80 8013d338 00000000 00000000 00000000 00000000 00000000
[179079.128794] bfa0: 00000000 b910bfb0 8010812c 8013d344 00000000 00000000 00000000 00000000
[179079.134842] bfc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[179079.141196] bfe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000 00000000
[179079.147742] [<7f4820b8>] (mn88472_sleep [mn88472]) from [<7f35c6f4>] (dvb_usb_fe_sleep+0x40/0x5c [dvb_usb])
[179079.154481] [<7f35c6f4>] (dvb_usb_fe_sleep [dvb_usb]) from [<7f32e5e0>] (dvb_frontend_thread+0x2ac/0x4c4 [dvb_core])
[179079.161521] [<7f32e5e0>] (dvb_frontend_thread [dvb_core]) from [<8013d474>] (kthread+0x13c/0x16c)
[179079.168585] [<8013d474>] (kthread) from [<8010812c>] (ret_from_fork+0x14/0x28)
[179079.172200] Code: e5903228 e3a0100c e3a02030 e5934074 (e5940014)
[179079.176270] ---[ end trace cfa36aec2070f59a ]---
[179079.180331] usb 1-1.5: dvb_frontend_stop: warning: thread b5101e00 won't exit


Oh no,
I upgraded the kernel (rpi-update), rebuilt, and it's doing this all the time now, as soon as I plug the tuner in.
Any suggestions?

Anthony

Hi anthony

same problem here, can i go to an older kernel build?

by
MZman

Hi,
You can revert to the standard kernel with
sudo apt-get install --reinstall raspberrypi-bootloader raspberrypi-kernel
then rebooting.

according to https://github.com/Hexxeh/rpi-update
you can revert to a specific kernel revision using a specific hash, for example;
sudo rpi-update b79886968bff850bbebd1f7d72ab5ac26803255e
should be reverting to 4.14.33 according to
https://github.com/Hexxeh/rpi-firmware/commits/master

My last build that crashed now and again was from 28/2 so that would be 4.14.22, assuming it was the kernel and not the dvb drivers.

How are you downloading the header files to compile? I seem to need to use rpi-source each time and it takes forever as it is downloading and unzipping lots of files. That said I was deleting them after I compiled, I've moved them to my external drive now I found the -d option!

Anthony

Anthony

Hi, Just in case this is helpful, I tried upgrading to stretch which has a 4.14 kernel by default. This gives the same behaviour.
I should say though that the stack trace when it crashes on boot is slightly different from what I posted above (I guess it isn't crashing sleeping)

Apr 23 19:07:56 raspberrypi kernel: [ 29.785862] Unable to handle kernel NULL pointer dereference at virtual address 00000000
Apr 23 19:07:56 raspberrypi kernel: [ 29.788039] pgd = b53c8000
Apr 23 19:07:56 raspberrypi kernel: [ 29.789056] [00000000] *pgd=00000000
Apr 23 19:07:56 raspberrypi kernel: [ 29.790082] Internal error: Oops: 5 [#1] SMP ARM
Apr 23 19:07:56 raspberrypi kernel: [ 29.791121] Modules linked in: cmac bnep hci_uart btbcm serdev bluetooth ecdh_generic tun ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 tda18250(O) nf_nat_ipv4 $
Apr 23 19:07:56 raspberrypi kernel: [ 29.798479] CPU: 1 PID: 843 Comm: tvheadend Tainted: G C O 4.14.34-v7+ #1110
Apr 23 19:07:56 raspberrypi kernel: [ 29.801170] Hardware name: BCM2835
Apr 23 19:07:56 raspberrypi kernel: [ 29.802538] task: b03a0000 task.stack: b00b2000
Apr 23 19:07:56 raspberrypi kernel: [ 29.803968] PC is at dvb_frontend_open+0x288/0x35c [dvb_core]
Apr 23 19:07:56 raspberrypi kernel: [ 29.805395] LR is at dvb_frontend_open+0x60/0x35c [dvb_core]
Apr 23 19:07:56 raspberrypi kernel: [ 29.806764] pc : [<7f1e0f6c>] lr : [<7f1e0d44>] psr: 60000013
Apr 23 19:07:56 raspberrypi kernel: [ 29.808155] sp : b00b3d38 ip : b00b3d38 fp : b00b3d84
Apr 23 19:07:56 raspberrypi kernel: [ 29.809530] r10: 00000000 r9 : b04fc800 r8 : b04fc800
Apr 23 19:07:56 raspberrypi kernel: [ 29.810905] r7 : b9539cc0 r6 : ae7e3580 r5 : ad088afc r4 : b8c9b818
Apr 23 19:07:56 raspberrypi kernel: [ 29.812263] r3 : 00000000 r2 : ffffffff r1 : 00000000 r0 : 00000000
Apr 23 19:07:56 raspberrypi kernel: [ 29.813584] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user
Apr 23 19:07:56 raspberrypi kernel: [ 29.814956] Control: 10c5383d Table: 353c806a DAC: 00000055
Apr 23 19:07:56 raspberrypi kernel: [ 29.816344] Process tvheadend (pid: 843, stack limit = 0xb00b2210)
Apr 23 19:07:56 raspberrypi kernel: [ 29.817751] Stack: (0xb00b3d38 to 0xb00b4000)
Apr 23 19:07:56 raspberrypi kernel: [ 29.819128] 3d20: b00b3d5c b00b3d48
Apr 23 19:07:56 raspberrypi kernel: [ 29.821759] 3d40: 8079aa2c 80799d74 b00b2000 7f1eb034 b00b3d6c b8d55a30 8079aa84 b9539cc0
Apr 23 19:07:56 raspberrypi kernel: [ 29.824313] 3d60: ae7e3580 b8d55a30 af6fda00 b9539cc0 00000000 00000000 b00b3da4 b00b3d88
Apr 23 19:07:56 raspberrypi kernel: [ 29.826865] 3d80: 7f1d891c 7f1e0cf0 7f1e6278 80d11538 7f1eb6c8 b8d55a30 b00b3dd4 b00b3da8
Apr 23 19:07:56 raspberrypi kernel: [ 29.829482] 3da0: 8028f090 7f1d8880 b9539cc8 00000003 b9539cc0 b8d55a30 b9539cc8 8028efb0
Apr 23 19:07:56 raspberrypi kernel: [ 29.832252] 3dc0: 00000000 b00b3f5c b00b3dfc b00b3dd8 8028676c 8028efbc b9539cc0 b00b3ea8
Apr 23 19:07:56 raspberrypi kernel: [ 29.835166] 3de0: af82dd80 b8d55a30 00000000 b00b3f5c b00b3e1c b00b3e00 80287a18 80286578
Apr 23 19:07:56 raspberrypi kernel: [ 29.838200] 3e00: b03a0000 b00b3ea8 00000000 00020002 b00b3ea4 b00b3e20 80298fa8 802879c8
Apr 23 19:07:56 raspberrypi kernel: [ 29.841381] 3e20: 80294ae4 8029a1e0 b00b3e78 00000000 b00b3f60 b9dad000 b9dad000 b00b2000
Apr 23 19:07:56 raspberrypi kernel: [ 29.844626] 3e40: 00000001 b00b3f60 00000041 b9539cc0 00000000 00000006 00000000 00000002
Apr 23 19:07:56 raspberrypi kernel: [ 29.847954] 3e60: b8d55a30 b9534410 b86cae58 b00b3e78 8029a528 8029a178 00000000 00000014
Apr 23 19:07:56 raspberrypi kernel: [ 29.851416] 3e80: b00b3f5c b00b3ea8 00000001 80108204 b00b2000 00000000 b00b3f4c b00b3ea8
Apr 23 19:07:56 raspberrypi kernel: [ 29.854939] 3ea0: 8029af88 80298cec b9534410 b86cae58 c1ab409c 00000009 b9dad022 80276eb8
Apr 23 19:07:56 raspberrypi kernel: [ 29.858479] 3ec0: 00000000 b9a91a18 b8d55a30 00000101 00000002 00000c82 00000000 00000000
Apr 23 19:07:56 raspberrypi kernel: [ 29.862007] 3ee0: 00000000 b00b3ee8 ffffff9c 00000014 b9cd2600 b9cd2618 00000000 00000400
Apr 23 19:07:56 raspberrypi kernel: [ 29.865541] 3f00: b00b3f3c b00b3f10 802aa90c 802aa080 00020002 00020002 b9dad000 00000000
Apr 23 19:07:56 raspberrypi kernel: [ 29.869054] 3f20: 00000005 00000002 ffffff9c 00000000 00000014 ffffff9c b9dad000 00000005
Apr 23 19:07:56 raspberrypi kernel: [ 29.872582] 3f40: b00b3f94 b00b3f50 80287df4 8029af24 00000000 b00b3f60 af82dd80 00020002
Apr 23 19:07:56 raspberrypi kernel: [ 29.876109] 3f60: b9530000 00000006 00000100 00000001 00000002 7e8937c0 00000002 00000005
Apr 23 19:07:56 raspberrypi kernel: [ 29.879649] 3f80: 80108204 b00b2000 b00b3fa4 b00b3f98 80287ed0 80287ce0 00000000 b00b3fa8
Apr 23 19:07:56 raspberrypi kernel: [ 29.883173] 3fa0: 80108060 80287eb0 00000002 7e8937c0 7e8937c0 00020002 00000000 00000000
Apr 23 19:07:56 raspberrypi kernel: [ 29.886695] 3fc0: 00000002 7e8937c0 00000002 00000005 00000002 00000000 00000000 7e8937c0
Apr 23 19:07:56 raspberrypi kernel: [ 29.890228] 3fe0: 7e893524 7e893530 00000000 76ba5ea4 80000010 7e8937c0 3abfa861 3abfac61
Apr 23 19:07:56 raspberrypi kernel: [ 29.893840] [<7f1e0f6c>] (dvb_frontend_open [dvb_core]) from [<7f1d891c>] (dvb_device_open+0xa8/0xe8 [dvb_core])
Apr 23 19:07:56 raspberrypi kernel: [ 29.897440] [<7f1d891c>] (dvb_device_open [dvb_core]) from [<8028f090>] (chrdev_open+0xe0/0x1a0)
Apr 23 19:07:56 raspberrypi kernel: [ 29.901005] [<8028f090>] (chrdev_open) from [<8028676c>] (do_dentry_open+0x200/0x328)
Apr 23 19:07:56 raspberrypi kernel: [ 29.904558] [<8028676c>] (do_dentry_open) from [<80287a18>] (vfs_open+0x5c/0x8c)
Apr 23 19:07:56 raspberrypi kernel: [ 29.908109] [<80287a18>] (vfs_open) from [<80298fa8>] (path_openat+0x2c8/0xff8)
Apr 23 19:07:56 raspberrypi kernel: [ 29.909938] [<80298fa8>] (path_openat) from [<8029af88>] (do_filp_open+0x70/0xd4)
Apr 23 19:07:56 raspberrypi kernel: [ 29.913454] [<8029af88>] (do_filp_open) from [<80287df4>] (do_sys_open+0x120/0x1d0)
Apr 23 19:07:56 raspberrypi kernel: [ 29.916969] [<80287df4>] (do_sys_open) from [<80287ed0>] (SyS_open+0x2c/0x30)
Apr 23 19:07:56 raspberrypi kernel: [ 29.918775] [<80287ed0>] (SyS_open) from [<80108060>] (ret_fast_syscall+0x0/0x28)
Apr 23 19:07:56 raspberrypi kernel: [ 29.922262] Code: e3c33d7f e3c3303f e593300c e5933004 (e5933000)
Apr 23 19:07:56 raspberrypi kernel: [ 29.924181] ---[ end trace 95f78df5c9ce3e90 ]---


I’m using kernel 4.14.32 without any crashes at all, on a pi 3b+. 2x tuners attached to a powered usb hub. Would recommend checking for power issues firstly - until I bought an official pi power supply I had random such issues even without an undervoltage warning.

Rpi-source is slow - however it’s actually quite reasonable if you buy an a1 rated sd card - they’re fast at small writes which are the key issue for use

Okay,
I reverted to 4.14.32 and no change. Strange.
Maybe it's the supply, but I found a 2.5 amp charger which should be enough.
I suppose I could switch back to the Rpi2 as I never saw issues there.
Thanks for the help
Anthony

Pi 3 has a much higher power requirement, even without running the tuners off it as well, presuming that is what you are doing.

I found crashes with a pi 3 frequently of a 2amp charger - presume it just wasn’t quite stable enough to power it reliably continuallly.

Just the one tuner but yes.
Anthony

Well, Rpi2 crashed the same way, as soon as I plugged in the tuner.
I'm thinking maybe a new build on the Rpi2 might be the way forward.
Edit. Sorry I mean start a fresh with a new stretch image

Anthony

Hi,
Well that crashes too. I've literally downloaded and installed a new stretch image onto a spare RPi2, built the drivers for the tuner, and used dvbtools to try to scan. Crashes as soon as the program accesses the tuner.
I don't know what else to try.

Anthony

Here are my steps;

Downloaded stretch from https://www.raspberrypi.org/downloads/raspbian/
Rasbian stretch lite 350Mb
Unzip to get image
Then run win32diskimager and write to sd card

Per https://www.raspberrypi.org/forums/viewtopic.php?t=191252
Put a file called ssh onto the boot partition, so ssh is enabled. 
Ssh user pi, password raspberry

Then make and install dvb drivers
sudo apt-get install git git-man libdigest-sha-perl liberror-perl libncurses5-dev libproc-processtable-perl libtinfo-dev patchutils raspberrypi-kernel-headers

Download the xbox config file from
https://tvheadend.org/attachments/download/6361/PiXboxMBConfig.txt
And copy it to the pi via ssh
scp PiXboxMBConfig.txt [email protected]:~/xConfig.txt
cp ~/xConfig.txt ~/media_build/v4l/

git clone --depth=1 git://linuxtv.org/media_build.git
cd media_build/linux
make download
make untar
cd ..
make distclean

Run "sudo make menuconfig", 
Wait for partial compilation to complete
<Load> xConfig.txt,
change remote support from M to * (select Y)
then <Save> as ".config" (note the leading period!) and then <Exit>.

make -j5
sudo make install
cd /lib/firmware
sudo wget http://palosaari.fi/linux/v4l-dvb/firmware/MN88472/02/latest/dvb-demod-mn88472-02.fw
sudo reboot

Reboot was okay, seems to be recognised

[    5.588424] dvb-usb: found a 'Microsoft Xbox One Digital TV Tuner' in cold state, will try to load a firmware
[    5.600724] dvb-usb: downloading firmware from file 'dvb-usb-dib0700-1.20.fw'
[    5.730439] dib0700: firmware started successfully.
[    6.242526] dvb-usb: found a 'Microsoft Xbox One Digital TV Tuner' in warm state.
[    6.243659] dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer.
[    6.243868] dvbdev: DVB: registering new adapter (Microsoft Xbox One Digital TV Tuner)
[    6.567818] mn88472 3-0018: Panasonic MN88472 successfully identified
[    6.617663] tda18250 3-0060: NXP TDA18250BHN/M successfully identified
[    6.620500] usb 1-1.4: DVB: registering adapter 0 frontend 0 (Panasonic MN88472)...
[    6.620951] dvb-usb: Microsoft Xbox One Digital TV Tuner successfully initialized and connected.
[    6.621446] usbcore: registered new interface driver dvb_usb_dib0700

Get dvb-tools
sudo apt-get install dvb-tools
dvbv5-scan ~/ridgehill.txt

And crashes!
[  423.833734] Unable to handle kernel NULL pointer dereference at virtual address 00000000

Hi,
It's definitely not hardware related. I went back to Jessie
http://downloads.raspberrypi.org/raspbian_lite/images/raspbian_lite-2017-07-05/2017-07-05-raspbian-jessie-lite.zip
followed the same steps and it worked
(although I needed to download another firmware file too)

cd /lib/firmware
sudo wget linuxtv.org/downloads/firmware/dvb-usb-dib0700-1.20.fw


I could not get stretch working, even reverting back to a kernel version 4.14.22 and an older version of media_build.

Anthony

Odd. I run stretch without any issues. It’s been upgraded from Jessie and wheezy before that and never had this issue.

So I tried http://downloads.raspberrypi.org/raspbian_lite/images/raspbian_lite-2018-04-19
which is pretty recent. Maybe something changed??

I could try an older one, it just takes a little while :-(

Anthony

Hi all,
I tried upgrading to kernel version 4.14.37 and that works fine!

Anthony

Hi

i have a problem with my build

i cannot run sudo make menuconfig

i get this failure:

make -C /home/pi/media_build/v4l menuconfig
make[1]: Entering directory '/home/pi/media_build/v4l'
make -C /lib/modules/4.14.37-v7+/build -f /home/pi/media_build/v4l/Makefile.kernel config-targets=1 mixed-targets=0 dot-config=0 SRCDIR=/lib/modules/4.14.37-v7+/build v4l-mconf
make[2]: Entering directory '/lib/modules/4.14.37-v7+/build'
/lib/modules/4.14.37-v7+/build/Makefile:273: scripts/Kbuild.include: No such file or directory
/lib/modules/4.14.37-v7+/build/Makefile:510: arch/arm/Makefile: No such file or directory
make[2]: *** No rule to make target 'arch/arm/Makefile'. Stop.
make[2]: Leaving directory '/lib/modules/4.14.37-v7+/build'
Makefile:389: recipe for target '/lib/modules/4.14.37-v7+/build/scripts/kconfig/mconf' failed
make[1]: *** [/lib/modules/4.14.37-v7+/build/scripts/kconfig/mconf] Error 2
make[1]: Leaving directory '/home/pi/media_build/v4l'
Makefile:26: recipe for target 'menuconfig' failed
make: *** [menuconfig] Error 2


You don't have the kernel source to build the drivers, as it isn't a standard kernel, so the raspberrypi-kernel-headers the posts suggest you download won't work
Use the following package to download the appropriate headers
https://github.com/notro/rpi-source/wiki
you can direct where the download will go using -d and need --skip-gcc (as stretch has a later version)

Be warned it downloads a 150Mb compressed file that when expanded has lots of files (65k).

Anthony