Hi,
I watched some German TV a few days ago while playing with config stuff. I can no longer get a lock on anything at 19.2E. I guess that it is just me but still... Can't understand what might have gone wrong
Tony Grant
tony wrote:
Hi,
I watched some German TV a few days ago while playing with config stuff. I can no longer get a lock on anything at 19.2E. I guess that it is just me but still... Can't understand what might have gone wrong
Tony Grant
Hi,
do you also get a message "Channel unavailable" or something on the OSD? I also cannot watch _any_ channel since I installed a fresh udev-enabled Gentoo with a 2.6.10 kernel. I did setup udev rules and permissions and have a script which creates the devices in /dev/dvb/adapter0, and am able to generate a channels.conf with dvbscan from the dvb-apps suite. But VDR won't work, I tried 1.3.18, 1.3.20, 1.3.21....
Lucian Muresan
PS. first I thought the behaviour would be due to a SourceCaps patch which get#s applied if I use a Gentoo.de ebuild, and found out after some digging in vdr-portal.de that in that case I should have provided som SiurceCap = 1 S19.2E and so on in setup.conf, I did that and the behaviour was the same. Then I compiled VDR without such a patch, to no avail...
Le vendredi 18 février 2005 à 18:05 +0100, Lucian Muresan a écrit :
do you also get a message "Channel unavailable" or something on the OSD?
Yes
I also cannot watch _any_ channel since I installed a fresh udev-enabled Gentoo with a 2.6.10 kernel.
Yes I played with udev
I did setup udev rules and permissions and have a script which creates the devices in /dev/dvb/adapter0, and am able to generate a channels.conf with dvbscan from the dvb-apps suite. But VDR won't work, I tried 1.3.18, 1.3.20, 1.3.21....
This is with my old faithful 1.3.14
I can watch 28.6 no problem.
Cheers Tony
I demand that Lucian Muresan may or may not have written...
tony wrote:
I watched some German TV a few days ago while playing with config stuff. I can no longer get a lock on anything at 19.2E. I guess that it is just me but still... Can't understand what might have gone wrong
do you also get a message "Channel unavailable" or something on the OSD? I also cannot watch _any_ channel since I installed a fresh udev-enabled Gentoo with a 2.6.10 kernel. I did setup udev rules and permissions and have a script which creates the devices in /dev/dvb/adapter0,
You don't need that script any more. The in-kernel drivers have basic sysfs support, ehough for udev to be able to handle the node creation.
and am able to generate a channels.conf with dvbscan from the dvb-apps suite. But VDR won't work, I tried 1.3.18, 1.3.20, 1.3.21....
Are you using the in-kernel drivers? If so, check that the attached patch has been applied to the kernel source. I found it on (IIRC) linux-dvb after noticing that tuning was *very* slow.
Thank you for the answer, Darren.
Darren Salt wrote:
I demand that Lucian Muresan may or may not have written...
tony wrote:
I watched some German TV a few days ago while playing with config stuff. I can no longer get a lock on anything at 19.2E. I guess that it is just me but still... Can't understand what might have gone wrong
do you also get a message "Channel unavailable" or something on the OSD? I also cannot watch _any_ channel since I installed a fresh udev-enabled Gentoo with a 2.6.10 kernel. I did setup udev rules and permissions and have a script which creates the devices in /dev/dvb/adapter0,
You don't need that script any more. The in-kernel drivers have basic sysfs support, ehough for udev to be able to handle the node creation.
I meant the script /etc/udev/dvb.sh:
#!/bin/sh -e echo $1 | sed -e 's#^dvb([0-9]).([^0-9]*)([0-9])#dvb/adapter\1/\2\3#' exit 0
I took it away like you suggested, the devices are created the same, but the ownerships aren't the same anymmore, they do no longer belong to the group "video", although I left the file /etc/udev/permissions.d/51-dvb.permissions which is responsible for this, in place...
and am able to generate a channels.conf with dvbscan from the dvb-apps suite. But VDR won't work, I tried 1.3.18, 1.3.20, 1.3.21....
Are you using the in-kernel drivers? If so, check that the attached patch has been applied to the kernel source. I found it on (IIRC) linux-dvb after noticing that tuning was *very* slow.
Yes, I'm using the in-kernel drivers from 2.6.10. Thank you for this patch, but as much as I hoped that it would solve the problem (what you where saying about it sounded reasonable), the behaviour is unfortunately exactly the same, VDR hangs with "device 1 has no lock, can't attach receiver" on the very first FTA channel it tries to tune on startup, and then I can only shoot him from anothe console. Its really weird, see my other post today http://www.linuxtv.org/pipermail/vdr/2005-February/000171.html
As I understand you're using udev, can you give me some other advice on what else to try/check?
Regards, Lucian
I demand that Lucian Muresan may or may not have written...
Darren Salt wrote:
I demand that Lucian Muresan may or may not have written...
tony wrote:
I watched some German TV a few days ago while playing with config stuff. I can no longer get a lock on anything at 19.2E. I guess that it is just me but still... Can't understand what might have gone wrong
do you also get a message "Channel unavailable" or something on the OSD? I also cannot watch _any_ channel since I installed a fresh udev-enabled Gentoo with a 2.6.10 kernel. I did setup udev rules and permissions and have a script which creates the devices in /dev/dvb/adapter0,
You don't need that script any more. The in-kernel drivers have basic sysfs support, ehough for udev to be able to handle the node creation.
I meant the script /etc/udev/dvb.sh:
Then you should have said so. ;-)
I took it away like you suggested,
Restore it - that one's necessary. I'd assumed that you meant a script which creates the device nodes "by hand", for use with older, non-sysfs, DVB drivers; also, "fresh install, 2.6.10" (to me) implied a kernel upgrade.
and am able to generate a channels.conf with dvbscan from the dvb-apps suite. But VDR won't work, I tried 1.3.18, 1.3.20, 1.3.21....
Are you using the in-kernel drivers? If so, check that the attached patch has been applied to the kernel source. I found it on (IIRC) linux-dvb after noticing that tuning was *very* slow.
Yes, I'm using the in-kernel drivers from 2.6.10. Thank you for this patch, but as much as I hoped that it would solve the problem (what you [were] saying about it sounded reasonable), the behaviour is unfortunately exactly the same, [...]
Not good...
As I understand you're using udev, can you give me some other advice on what else to try/check?
Other than what I've already suggested, no. My DVB-T card is working well (after a few small problems, fixed by use of the get_dvb_firmware script in the kernel documentation).
Le vendredi 18 février 2005 à 18:05 +0100, Lucian Muresan a écrit :
I watched some German TV a few days ago while playing with config stuff. I can no longer get a lock on anything at 19.2E. I guess that it is just me but still... Can't understand what might have gone wrong
OK I have compiled and installed vdr 1.3.21 with vdr-xine 0.7.1 and streamdev + femon
I am pointed at RTL 12188 Mhz - I am losing the carrier from time to time and strength of signal and carrier are topping out at 65%.
Pointed at the satellite with my analog tuner the signal is just fine so this has something to do with the DVB drivers. I am using dvb-kernel drivers loaded by hand.
Cheers
Tony PS Klaus 1.3.21 is much better where it does work (BskyB) congratulations.
tony wrote:
Le vendredi 18 février 2005 à 18:05 +0100, Lucian Muresan a écrit :
I watched some German TV a few days ago while playing with config stuff. I can no longer get a lock on anything at 19.2E. I guess that it is just me but still... Can't understand what might have gone wrong
OK I have compiled and installed vdr 1.3.21 with vdr-xine 0.7.1 and streamdev + femon
I am pointed at RTL 12188 Mhz - I am losing the carrier from time to time and strength of signal and carrier are topping out at 65%.
Pointed at the satellite with my analog tuner the signal is just fine so this has something to do with the DVB drivers. I am using dvb-kernel drivers loaded by hand.
Cheers
Tony PS Klaus 1.3.21 is much better where it does work (BskyB) congratulations.
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Tony, I have a "test" VDR that is running with a Budget Nova-S, I have some BER and very low SNR and STR using Femon. My "Production" VDR with two FF cards has far better signals (according to Femon) and no BER at all. I moved one of the FF cards to this box to check that all is really OK, cabling etc. With the FF I then got no BER, and the kind of STR and SNR values I am used to. As it happens the test machine is about 2M cable away from my multiswitch, the production box is about 10M away. The test box is a Kernel 2.6 with the supplied DVB drivers, the production box is 2.4 with DVB drivers from the middle of last year.
For me the values shown by Femon are very driver dependent. Either that or my Budget card is broken, but running it under windows show normal signal values so I dont think so.
Cheers Brian
Brian wrote:
tony wrote:
Le vendredi 18 février 2005 à 18:05 +0100, Lucian Muresan a écrit :
I watched some German TV a few days ago while playing with config stuff. I can no longer get a lock on anything at 19.2E. I guess that it is just me but still... Can't understand what might have gone wrong
OK I have compiled and installed vdr 1.3.21 with vdr-xine 0.7.1 and streamdev + femon
I am pointed at RTL 12188 Mhz - I am losing the carrier from time to time and strength of signal and carrier are topping out at 65%.
Pointed at the satellite with my analog tuner the signal is just fine so this has something to do with the DVB drivers. I am using dvb-kernel drivers loaded by hand.
Cheers
Tony PS Klaus 1.3.21 is much better where it does work (BskyB) congratulations.
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Tony, I have a "test" VDR that is running with a Budget Nova-S, I have some BER and very low SNR and STR using Femon. My "Production" VDR with two FF cards has far better signals (according to Femon) and no BER at all. I moved one of the FF cards to this box to check that all is really OK, cabling etc. With the FF I then got no BER, and the kind of STR and SNR values I am used to. As it happens the test machine is about 2M cable away from my multiswitch, the production box is about 10M away. The test box is a Kernel 2.6 with the supplied DVB drivers, the production box is 2.4 with DVB drivers from the middle of last year.
For me the values shown by Femon are very driver dependent. Either that or my Budget card is broken, but running it under windows show normal signal values so I dont think so.
Cheers Brian
Haven't looked at BER values and such, but I can confirm that my single Budget Nova-S system is working ok when I boot the non-udev gentoo-2.6.9 with the kernel-supplied drivers and vdr-1.3.14, and not working at all, when booting the fresh installed udev-enbled Gentoo-2.6.10 with the kernel-supplied drivers, and I tried all this FU weekend vdr-1.3.21 back to -20, -18 and -14 on this partition, with no results. I also asked for help in just some pointers where to look for the error in http://www.linuxtv.org/pipermail/vdr/2005-February/000171.html bot I only got a suggestion from Darren Salt in this other thread Tony initiated. what do you think I could try? disable udev and go back to devfs? Downgrade the kernel? Use DVB-CVS drivers? the funny thing is that dvbscan is properly scanning for services at any of the 4 LNBs I have after the 4/1 DiseqC switch, and even dvbtune reports something like this, how does it look like? Any other clues?
htpc root # dvbtune -f 11431000 -p H -s 13350 -v 410 -a 411 -D 0 Using DVB card "ST STV0299 DVB-S" tuning DVB-S to L-Band:8, Pol:H Srate=13350000, 22kHz=off polling.... Getting frontend event FE_STATUS: polling.... Getting frontend event FE_STATUS: FE_HAS_SIGNAL FE_HAS_LOCK FE_HAS_CARRIER FE_HAS_VITERBI FE_HAS_SYNC Bit error rate: 46848 Signal strength: 55675 SNR: 42942 FE_STATUS: FE_HAS_SIGNAL FE_HAS_LOCK FE_HAS_CARRIER FE_HAS_VITERBI FE_HAS_SYNC A/V/TT Filters set
Thanx in advance, Lucian
I demand that Lucian Muresan may or may not have written...
[snip]
I also asked for help in just some pointers where to look for the error in http://www.linuxtv.org/pipermail/vdr/2005-February/000171.html bot I only got a suggestion from Darren Salt in this other thread Tony initiated. what do you think I could try? disable udev and go back to devfs?
That won't affect the drivers at all. It may cause other problems, though: a couple of devfs-related hangs on 2.6.x persuaded me to use udev.
Downgrade the kernel? Use DVB-CVS drivers?
You should try CVS first and if that fails, you can always fall back on a known-good (for DVB) kernel.
[snip]
Le dimanche 20 février 2005 à 19:52 +0000, Darren Salt a écrit :
You should try CVS first and if that fails, you can always fall back on a known-good (for DVB) kernel.
What bugs me is that I can't see what I changed and why would one satellite work and not others. Mr Spock wouldn't like this one bit...
I have been playing with vdr 1.3.21, xine 0.7.1, streamdev and femon and everything works just fine - no even better than the 1.3.14 I was using. I will try with a modified channels.conf that just has astra 19.2E tomorrow evening if I can find the time.
Tony
Darren Salt wrote:
I demand that Lucian Muresan may or may not have written...
[snip]
I also asked for help in just some pointers where to look for the error in http://www.linuxtv.org/pipermail/vdr/2005-February/000171.html bot I only got a suggestion from Darren Salt in this other thread Tony initiated. what do you think I could try? disable udev and go back to devfs?
That won't affect the drivers at all. It may cause other problems, though: a couple of devfs-related hangs on 2.6.x persuaded me to use udev.
Downgrade the kernel? Use DVB-CVS drivers?
You should try CVS first and if that fails, you can always fall back on a known-good (for DVB) kernel.
Thank you, I tried CVS and that's working! Maybe the in-kernel drivers aren't really udev-ready. Anyway, now it's working, and having to load those drivers with the provided script isn't that bad either.
Cheers, Lucian
-
Brian -
Darren Salt -
Lucian Muresan -
tony