[linux-dvb] Any improvment in the HVR-4000 front ?
Hello, anything new ? On http://dev.kewl.org/hvr4000/ one could read : News 21 nov 2007 Imported signal readings from reelbox code. Re-calibrated against a FORTEC receiver (originally dvb2000). This include BER, UCB, strength and quality. Previous strength reading is now quality as confirmed in reelbox code and on FORTEC. News 19 nov 2007 Diseqc command strategy has been reverted to an older method which caches message prior to burst IOCTL. This is now the default and this ought to fix some issues with szap found recently with some switches. The updated derived burst hack strategy still exists but now must be enabled with a module parameter called 'dsec'. See modinfo cx24116 FYI. You may need to enable the hack method for mythtv. Either method ought to work for kaffeine and szap. The status of VDR is unknown, try either. Is there an updated patch for http://jusst.de/hg/multiproto which seems to be the only actual repo with which vdr work ? I just compiled the v4l-dvb with http://dev.kewl.org/hvr4000/v4l-dvb-hg-2007-11-21.diff to test diseqc with szap and a channels.conf made for having all my 3 sat, hi/lo, and h/v : TV5MONDE EUROPE:11597:v:1:22000:45:46:10060 ProSieben:12480:v:1:27500:255:256:898 RTBF SAT:10832:h:1:22000:4194:4195:61998 SexySat:12633:h:1:22000:221:321:12621 Videosexy TV:11623:v:0:27500:221:241:10701 The Spirit Word Channel:12265:v:0:27500:2210:2220:3122 ALO TV:10853:h:0:27500:2109:2110:8628 ASTRO CENTER TV:12245:h:0:27500:1023:1033:1003 BBC HD:10847:v:2:22000:2:2320:6940 EuroNews:12560:v:2:27500:2315:2316:54104 BBC FOUR:10773:h:2:22000:5300:5301:6316 Information TV:12523:h:2:27500:2320:2321:55004 which gives me 6 FE_HAS_LOCK out of 12 which is better. reading channels from file '/home/greg/.szap/channels.conf' zapping to 1 'TV5MONDE EUROPE': sat 1, frequency = 11597 MHz V, symbolrate 2200, vpid = 0x002d, apid = 0x002e sid = 0x274c using '/dev/dvb/adapter1/frontend0' and '/dev/dvb/adapter1/demux0' status 01 | signal c040 | snr | ber | unc | status 01 | signal c5c0 | snr | ber | unc | status 01 | signal c5c0 | snr | ber | unc | status 03 | signal c5c0 | snr | ber | unc | status 01 | signal c5c0 | snr | ber | unc | status 01 | signal c640 | snr | ber | unc | status 03 | signal c640 | snr | ber | unc | status 03 | signal c640 | snr | ber | unc | status 03 | signal c640 | snr | ber | unc | status 01 | signal c5c0 | snr | ber | unc | reading channels from file '/home/greg/.szap/channels.conf' zapping to 2 'ProSieben': sat 1, frequency = 12480 MHz V, symbolrate 2750, vpid = 0x00ff, apid = 0x0100 sid = 0x0382 using '/dev/dvb/adapter1/frontend0' and '/dev/dvb/adapter1/demux0' status 03 | signal c040 | snr | ber | unc | status 03 | signal c840 | snr | ber | unc | status 01 | signal c840 | snr | ber | unc | status 03 | signal c8c0 | snr | ber | unc | status 1f | signal c8c0 | snr ae66 | ber | unc | FE_HAS_LOCK reading channels from file '/home/greg/.szap/channels.conf' zapping to 3 'RTBF SAT': sat 1, frequency = 10832 MHz H, symbolrate 2200, vpid = 0x1062, apid = 0x1063 sid = 0xf22e using '/dev/dvb/adapter1/frontend0' and '/dev/dvb/adapter1/demux0' status 01 | signal c040 | snr | ber | unc | status 01 | signal d440 | snr | ber | unc | status 03 | signal d440 | snr | ber | unc | status 01 | signal d440 | snr | ber | unc | status 01 | signal d4c0 | snr | ber | unc | status 03 | signal d4c0 | snr | ber | unc | status 03 | signal d4c0 | snr | ber | unc | status 03 | signal d540 | snr | ber | unc | status 03 | signal d540 | snr | ber | unc | status 03 | signal d240 | snr | ber | unc | reading channels from file '/home/greg/.szap/channels.conf' zapping to 4 'SexySat': sat 1, frequency = 12633 MHz H, symbolrate 2200, vpid = 0x00dd, apid = 0x0141 sid = 0x314d using '/dev/dvb/adapter1/frontend0' and '/dev/dvb/adapter1/demux0' status 01 | signal c040 | snr | ber | unc | status 01 | signal c5c0 | snr | ber | unc | status 03 | signal c5c0 | snr | ber | unc | status 01 | signal c5c0 | snr | ber | unc | status 03 | signal c640 | snr | ber | unc | status 03 | signal c640 | snr | ber | unc | status 01 | signal c640 | snr | ber | unc | status 01 | signal c640 | snr | ber | unc |
Re: [linux-dvb] Artec T14BR patches (was Adding patches to main repository)
Hi Yousef, Thanks for your patch. But something is wrong with it. There is a - where there should be a + I think you create the patch wrongly: correct should be: patch -ur(other options) old_directory new_directory Can you please send it again? Don't forget your Signed-off-by-line like that: Signed-Off-By: Name emailaddress regards, Patrick. On Thu, 22 Nov 2007, Yousef Lamlum wrote: Thanks Antti, I'm not sure what is meant by a signed-off line, but here are minor changes that add support for Artec T14BR (by treating it as DiBcomm's STK7070-P reference design on which it seems to be based). Thanks for the pointers, this newbie appreciates it. Cheers, Yousef. Antti Palosaari wrote: Yousef Lamlum wrote: Could anyone please point me in the right direction with regards to adding a patch to the the v4l-dvb project? Yesterday I added support for the Artec T14BR and would like to share these minor changes with the rest of the community. If it is only minor change adding new usb-ids then make patch and send it to this list with signed-off line of yours. CC/TO module authors and persons who are done changes to file in question lastly. Ask help same persons and cross your fingers :) regards Antti ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] AF9015 Driver (USB)
Hi. I finally get your driver working very well with my usb-tdt-stick. So you can add to the HW-supported list the BestBuy Easy TV USB Stick (AF9015 + MT2061). If someone is interested, I am running it on an 2.6.9 kernel (minimal changes are to be added to compile v4l with these drivers). Now I am trying to embed these drivers on a [EMAIL PROTECTED] based system, without success yet. It seems that performance has something to do in this reduced environment (not actually sure). If someone is interested or has experience in this task, suggestions are welcome. Please continue reporting new releases for the drivers (I will). Thank you very much Antti and Manu. Cheers, Rafael. Antti Palosaari escribió: morjens I put my version also online if there is someone who wants to play with it. Many Finnish people have reported it working very well with A-Link DTU(m) and Fujitech stick. No any success reports outside Finland still... Latest firmware, version 4.95.0, and the driver patch can be found from link below. http://otit.fi/~crope/v4l-dvb/af9015/ regards Antti Manu Abraham wrote: Hi, I saw your post on the ML also, rather than replying to both, will just add CC to the list. Lindsay Mathieson wrote: Hi Manu, I was trying the af9015 driver you're working on at http://jusst.de/hg/af901x/summary but not having much success - I suspect i have the wrong firmware (got it from http://www.mail-archive.com/linux-dvb@linuxtv.org/msg21157.html). Would you be able to send it to me? The firmwares are here: http://jusst.de/manu/fw/AFA/ The reference fw, uses the newer version, 0x447000 instead of 0x441000 But i don't think there exists a large difference except for some refinements I'm using a DigitalNow TinyTwin USB dual tuner The maxlinear devices are not supported atm, waiting for some complications to be flushed out from the af901x tree. I guess most probably you have the Twin maxlinear device based ones. Can you please do a lsusb and check the vendor and product ID's ? if you add in your vendor and product id's, most probably loading the af901x module, it will tell you about your hardware configuration. Thanks - Lindsay Regards, Manu ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] Remote key repeat on Nova-t-500 - Logitech Harmony
This has been a nagging issue. Not a show stopper, but now that the system is quite stable, i'm willing to look at it. The remote for the Hauppauge Nova-T-500 has no repeat whatsoever. If you press the button and keep it that way, the card give one and only one command. I have tried the repeat=x option for my .lircrc file without any impact. Is there anything that can be done about that? As a work-around solution, there may be the Logitech Harmony avenue, that may have been used by someone on the list. I am a user of such a remote. the cool thing is that the on-line database of devices for the Logitech setup tool knew about the remote, no learning or IR codes was involved :o) But it acts the same wrt repeat. I have seen that there is some manual fine-tuning available on that tool. did anyone use it and manage to get repeated commands from the remote, using a permanent key press, that way? Thanks for your help, I'll be posting the message on the mythtv-users list too, and cross-post an eventual solution from them here. Nico http://www.youplala.net/linux/home-theater-pc ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] dvbstream: Not able to lock to the signal
Hi, I'm trying to capture 1 whole Transport Stream (TS) from my card. These are the output from my dvbstream command: [EMAIL PROTECTED] dvbstream]# ./dvbstream -f 554000 -s 6875 -qam 256 -n 30 8192 test.ts dvbstream v0.7 - (C) Dave Chapman 2001-2004 Released under the GPL. Latest version available from http://www.linuxstb.org/ Tuning to 554000 Hz Using DVB card ST STV0297 DVB-C, freq=554000 tuning DVB-C to 55400, srate=6875000 Getting frontend status Event: Frequency: 55400 SymbolRate: 6874000 FEC_inner: 0 Bit error rate: 0 Signal strength: 841 SNR: 6301 UNC: 0 FE_STATUS: FE_HAS_SIGNAL FE_HAS_LOCK FE_HAS_CARRIER FE_HAS_VITERBI FE_HAS_SYNC dvbstream will stop after 30 seconds (0 minutes) Output to stdout Streaming 1 stream ** However, when I try to play back the file via VLC, I received a lot of these messages (these are just some of the messages): ts warning: discontinuity received 0xf instead of 0xd (pid=33) ts warning: discontinuity received 0x8 instead of 0x7 (pid=35) ts warning: discontinuity received 0x5 instead of 0x2 (pid=34) ts debug: pid[34] unknown ts debug: transport_error_indicator set (pid=35) ts debug: transport_error_indicator set (pid=34) It seems that the TS that I capture from the card has a lot of Transport Continuity count error. Also, when I analyse the Pids through dvbstream, I realise the Pids are actually increasing when the Pids for the normal stream is fixed! Basically, I run the -analyse command print the output to a file When I checked the number of Pids found, it was about 60+ 5 seconds later, it increased to about 70+ and it keeps increasing... However, all this numbers are wrong because I have previously confirmed that the TS itself only has 55 Pids! Is the dvbstream somehow adding the Pids? Have anyone experience this problem before? Or it there a solution to this. Thank you very much. Regards, HY ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] dvbstream- Transport Continuity error Pids
Hi, I'm trying to capture 1 whole Transport Stream (TS) from my card. These are the output from my dvbstream command: [EMAIL PROTECTED] dvbstream]# ./dvbstream -f 554000 -s 6875 -qam 256 -n 30 8192 test.ts dvbstream v0.7 - (C) Dave Chapman 2001-2004 Released under the GPL. Latest version available from http://www.linuxstb.org/ Tuning to 554000 Hz Using DVB card ST STV0297 DVB-C, freq=554000 tuning DVB-C to 55400, srate=6875000 Getting frontend status Event: Frequency: 55400 SymbolRate: 6874000 FEC_inner: 0 Bit error rate: 0 Signal strength: 841 SNR: 6301 UNC: 0 FE_STATUS: FE_HAS_SIGNAL FE_HAS_LOCK FE_HAS_CARRIER FE_HAS_VITERBI FE_HAS_SYNC dvbstream will stop after 30 seconds (0 minutes) Output to stdout Streaming 1 stream ** However, when I try to play back the file via VLC, I received a lot of these messages (these are just some of the messages): ts warning: discontinuity received 0xf instead of 0xd (pid=33) ts warning: discontinuity received 0x8 instead of 0x7 (pid=35) ts warning: discontinuity received 0x5 instead of 0x2 (pid=34) ts debug: pid[34] unknown ts debug: transport_error_indicator set (pid=35) ts debug: transport_error_indicator set (pid=34) It seems that the TS that I capture from the card has a lot of Transport Continuity count error. Also, when I analyse the Pids through dvbstream, I realise the Pids are actually increasing when the Pids for the normal stream is fixed! Basically, I run the -analyse command print the output to a file When I checked the number of Pids found, it was about 60+ 5 seconds later, it increased to about 70+ and it keeps increasing... However, all this numbers are wrong because I have previously confirmed that the TS itself only has 55 Pids! Is the dvbstream somehow adding the Pids? Have anyone experience this problem before? Or it there a solution to this. Thank you very much. Regards, HY ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] dvbstream- Transport Continuity error Pids
Il Thursday 22 November 2007 12:32:08 Hong Yin Lim ha scritto: Hi, I'm trying to capture 1 whole Transport Stream (TS) from my card. These are the output from my dvbstream command: [EMAIL PROTECTED] dvbstream]# ./dvbstream -f 554000 -s 6875 -qam 256 -n 30 8192 test.ts dvbstream v0.7 - (C) Dave Chapman 2001-2004 However, when I try to play back the file via VLC, I received a lot of these messages (these are just some of the messages): ts warning: discontinuity received 0xf instead of 0xd (pid=33) ts warning: discontinuity received 0x8 instead of 0x7 (pid=35) ts warning: discontinuity received 0x5 instead of 0x2 (pid=34) ts debug: pid[34] unknown ts debug: transport_error_indicator set (pid=35) ts debug: transport_error_indicator set (pid=34) It seems that the TS that I capture from the card has a lot of Transport Continuity count error. bad reception? Also, when I analyse the Pids through dvbstream, I realise the Pids are actually increasing when the Pids for the normal stream is fixed! Basically, I run the -analyse command print the output to a file When I checked the number of Pids found, it was about 60+ 5 seconds later, it increased to about 70+ and it keeps increasing... forget it. I never read what -analyse does but surely it's nothing operational However, all this numbers are wrong because I have previously confirmed that the TS itself only has 55 Pids! Is the dvbstream somehow adding the Pids? Have anyone experience this problem before? Or it there a solution to this. Thank you very much. Regards, HY your problem seems to be related to bad reception. Does mplayer show artefacts or complaints when playing that file? ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] dvbscan and kdetv cannot access tv, although mythtv can
Dear all, I am using a Nebula DigiTV USB-T (Zarlink MT352) on a openSuSE 10.3 box (AMD64X2). This works well with MythTV 0.20.2, except that MythTV itself is sufficiently buggy that it has always crashed within an hour of watching 'live' TV. For some reason, neither dvbscan or kdetv seem to be able to access the digital TV card. dvbscan complains that it cannot access the frontend, although the logs as below indicate that the frontend has been created. /dev/dvb/adapter0/scanner0, as well as other devices in adapter0, are present, and have appropriate permissions. In any case, running dvbscan as root does not help. kdetv also complains that it cannot find a TV device. For some reason, no v4l modules are loaded. Manually loading v4l modules does not help. Any idea how I can fix this? Cheerio, David. === Nov 22 18:10:04 Vigor10 kernel: usb 3-1: new high speed USB device using ehci_hcd and address 3 Nov 22 18:10:04 Vigor10 kernel: usb 3-1: new device found, idVendor=0547, idProduct=0201 Nov 22 18:10:04 Vigor10 kernel: usb 3-1: new device strings: Mfr=0, Product=0, SerialNumber=0 Nov 22 18:10:04 Vigor10 kernel: usb 3-1: configuration #1 chosen from 1 choice Nov 22 18:10:04 Vigor10 kernel: dvb-usb: found a 'Nebula Electronics uDigiTV DVB-T USB2.0)' in cold state, will try to load a firmware Nov 22 18:10:04 Vigor10 kernel: dvb-usb: downloading firmware from file 'dvb-usb-digitv-02.fw' Nov 22 18:10:04 Vigor10 kernel: usbcore: registered new interface driver dvb_usb_digitv Nov 22 18:10:04 Vigor10 kernel: usb 3-1: USB disconnect, address 3 Nov 22 18:10:04 Vigor10 kernel: dvb-usb: generic DVB-USB module successfully deinitialized and disconnected. Nov 22 18:10:06 Vigor10 kernel: usb 3-1: new high speed USB device using ehci_hcd and address 4 Nov 22 18:10:06 Vigor10 kernel: usb 3-1: string descriptor 0 read error: -22 Nov 22 18:10:06 Vigor10 kernel: usb 3-1: string descriptor 0 read error: -22 Nov 22 18:10:06 Vigor10 kernel: usb 3-1: new device found, idVendor=0547, idProduct=0201 Nov 22 18:10:06 Vigor10 kernel: usb 3-1: new device strings: Mfr=1, Product=2, SerialNumber=0 Nov 22 18:10:06 Vigor10 kernel: usb 3-1: configuration #1 chosen from 1 choice Nov 22 18:10:06 Vigor10 kernel: dvb-usb: found a 'Nebula Electronics uDigiTV DVB-T USB2.0)' in warm state. Nov 22 18:10:06 Vigor10 kernel: dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer. Nov 22 18:10:06 Vigor10 kernel: DVB: registering new adapter (Nebula Electronics uDigiTV DVB-T USB2.0)). Nov 22 18:10:06 Vigor10 kernel: DVB: registering frontend 0 (Zarlink MT352 DVB-T)... Nov 22 18:10:06 Vigor10 kernel: input: IR-receiver inside an USB DVB receiver as /class/input/input6 Nov 22 18:10:06 Vigor10 kernel: dvb-usb: schedule remote query interval to 1000 msecs. Nov 22 18:10:06 Vigor10 kernel: dvb-usb: Nebula Electronics uDigiTV DVB-T USB2.0) successfully initialized and connected. === ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Artec T14BR patches (was Adding patches to main repository)
Hi,
Thanks you and Lauri for for pointing out my mistake. Here are the
correct patches for the Artec T14BR.
Signed-Off-By: Yousef Lamlum [EMAIL PROTECTED]
Patrick Boettcher wrote:
Hi Yousef,
Thanks for your patch. But something is wrong with it. There is a -
where there should be a +
I think you create the patch wrongly: correct should be:
patch -ur(other options) old_directory new_directory
Can you please send it again?
Don't forget your Signed-off-by-line like that:
Signed-Off-By: Name emailaddress
regards,
Patrick.
On Thu, 22 Nov 2007, Yousef Lamlum wrote:
Thanks Antti,
I'm not sure what is meant by a signed-off line, but here are minor
changes that add support for Artec T14BR (by treating it as DiBcomm's
STK7070-P reference design on which it seems to be based).
Thanks for the pointers, this newbie appreciates it.
Cheers, Yousef.
Antti Palosaari wrote:
Yousef Lamlum wrote:
Could anyone please point me in the right direction with regards to
adding a patch to the the v4l-dvb project? Yesterday I added support for
the Artec T14BR and would like to share these minor changes with the
rest of the community.
If it is only minor change adding new usb-ids then make patch and send
it to this list with signed-off line of yours. CC/TO module authors and
persons who are done changes to file in question lastly. Ask help same
persons and cross your fingers :)
regards
Antti
--- v4l-dvb_backup/linux/drivers/media/dvb/dvb-usb/dib0700_devices.c 2007-11-20 18:25:08.0 +
+++ v4l-dvb/linux/drivers/media/dvb/dvb-usb/dib0700_devices.c 2007-11-20 21:55:35.0 +
@@ -851,6 +851,7 @@
{ USB_DEVICE(USB_VID_COMPRO,USB_PID_COMPRO_VIDEOMATE_U500_PC) },
/* 20 */{ USB_DEVICE(USB_VID_AVERMEDIA, USB_PID_AVERMEDIA_EXPRESS) },
/* 21 */{ USB_DEVICE(USB_VID_GIGABYTE, USB_PID_GIGABYTE_U7000) },
+/* 22 */{ USB_DEVICE(USB_VID_ULTIMA_ELECTRONIC, USB_PID_ARTEC_T14BR) },
{ 0 } /* Terminating entry */
};
MODULE_DEVICE_TABLE(usb, dib0700_usb_id_table);
@@ -1018,7 +1019,7 @@
},
},
- .num_device_descs = 2,
+ .num_device_descs = 3,
.devices = {
{ DiBcom STK7070P reference design,
{ dib0700_usb_id_table[15], NULL },
@@ -1028,6 +1029,10 @@
{ dib0700_usb_id_table[16], NULL },
{ NULL },
},
+ { Artec T14BR DVB-T,
+{ dib0700_usb_id_table[22], NULL },
+{ NULL },
+ }
}
}, { DIB0700_DEFAULT_DEVICE_PROPERTIES,
--- v4l-dvb_backup/linux/drivers/media/dvb/dvb-usb/dvb-usb-ids.h 2007-11-20 18:25:08.0 +
+++ v4l-dvb/linux/drivers/media/dvb/dvb-usb/dvb-usb-ids.h 2007-11-20 23:09:03.0 +
@@ -103,6 +103,7 @@
#define USB_PID_ULTIMA_TVBOX_USB2_WARM 0x810a
#define USB_PID_ARTEC_T14_COLD0x810b
#define USB_PID_ARTEC_T14_WARM0x810c
+#define USB_PID_ARTEC_T14BR0x810f
#define USB_PID_ULTIMA_TVBOX_USB2_FX_COLD 0x8613
#define USB_PID_ULTIMA_TVBOX_USB2_FX_WARM 0x1002
#define USB_PID_UNK_HYPER_PALTEK_COLD 0x005e
___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Artec T14BR patches (was Adding patches to main repository)
Yousef Lamlum wrote: Hi, Thanks you and Lauri for for pointing out my mistake. Here are the correct patches for the Artec T14BR. Signed-Off-By: Yousef Lamlum [EMAIL PROTECTED] Patrick Boettcher wrote: Hi Yousef, Thanks for your patch. But something is wrong with it. There is a - where there should be a + I think you create the patch wrongly: correct should be: patch -ur(other options) old_directory new_directory Can you please send it again? Don't forget your Signed-off-by-line like that: Signed-Off-By: Name emailaddress regards, Patrick. You two are guilty of multiple infractions of top posting. As punishment for this crime, I sentence you both to run your email clients for two weeks without any sort of spam filtering. ;) In future, please don't top post as it makes reading continuity difficult. ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] top-post (was: Re: Artec T14BR patches (was Adding patches to main repository))
On Thu, 22 Nov 2007, CityK wrote: You two are guilty of multiple infractions of top posting. As punishment for this crime, I sentence you both to run your email clients for two weeks without any sort of spam filtering. ;) In future, please don't top post as it makes reading continuity difficult. When this email is not a top-post (is it?), my previous wasn't too. My client is fine, afaik. (nobody ever complained) Patrick ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Artec T14BR patches (was Adding patches to main repository)
CityK wrote: Yousef Lamlum wrote: Hi, Thanks you and Lauri for for pointing out my mistake. Here are the correct patches for the Artec T14BR. Signed-Off-By: Yousef Lamlum [EMAIL PROTECTED] Patrick Boettcher wrote: Hi Yousef, Thanks for your patch. But something is wrong with it. There is a - where there should be a + I think you create the patch wrongly: correct should be: patch -ur(other options) old_directory new_directory Can you please send it again? Don't forget your Signed-off-by-line like that: Signed-Off-By: Name emailaddress regards, Patrick. You two are guilty of multiple infractions of top posting. As punishment for this crime, I sentence you both to run your email clients for two weeks without any sort of spam filtering. ;) In future, please don't top post as it makes reading continuity difficult. Sorry, guilty as charged. It will not happen again! ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] CAM inserted/used reduces signal and SNR ?
Oliver Endriss wrote: Luc Brosens wrote: Hi, side note : the problems in my previous post KNC1 TV-Station S, revision 0x1894, doesn't tune, were related to the PCI-slots of the motherboard I used rebuilt the machine around a new motherboard, both KNC1's are now recognized and able to tune lesson learnt : check the hardware before complaining about the software ... Hm. why does inserting and accessing a CAM reduce the signal and SNR levels ? (even if no descrambling is needed, as for BBC World) how can this be solved ? anyone out there having the same problems ? I guess that the CAM increases the noise on the power supply planes of the card. This might affect the tuner. ;-( CU Oliver so I changed gnutv to only initialise the CAM after obtaining FE_HAS_LOCK apparantly, initialising the CAM is enough to loose the tuning lock, not to return afterwards so this is not a solution here's a run with femon monitoring the tuning status : I start of with the CAM in the slot, and try to gnutv-tune to BBC World (which is not scrambled, so need for the CAM) [EMAIL PROTECTED]:~/dvb-apps femon -a 1 -H FE: ST STV0299 DVB-S (DVBS) status S | signal 63% | snr 49% | ber 14077 | unc 0 | status S | signal 79% | snr 51% | ber 13311 | unc 0 | status S | signal 69% | snr 50% | ber 13776 | unc 0 | status S | signal 82% | snr 52% | ber 13583 | unc 0 | status S | signal 62% | snr 49% | ber 13375 | unc 0 | status S | signal 79% | snr 53% | ber 13563 | unc 0 | status S | signal 80% | snr 49% | ber 13387 | unc 0 | status S | signal 71% | snr 52% | ber 13524 | unc 0 | status S | signal 63% | snr 49% | ber 13565 | unc 0 | status S | signal 81% | snr 52% | ber 13125 | unc 0 | status S | signal 63% | snr 49% | ber 13548 | unc 0 | status S | signal 37% | snr 49% | ber 13420 | unc 0 | status S | signal 62% | snr 49% | ber 13429 | unc 0 | status SC| signal 37% | snr 49% | ber 13627 | unc 0 | status S | signal 60% | snr 50% | ber 12929 | unc 0 | status S | signal 31% | snr 49% | ber 13116 | unc 0 | status S | signal 54% | snr 49% | ber 13085 | unc 0 | status S | signal 75% | snr 49% | ber 13509 | unc 0 | status S | signal 80% | snr 50% | ber 13017 | unc 0 | status S | signal 62% | snr 49% | ber 13280 | unc 0 | status S | signal 67% | snr 50% | ber 13254 | unc 0 | status S | signal 64% | snr 51% | ber 13167 | unc 0 | status S | signal 62% | snr 49% | ber 1 | unc 0 | status S | signal 81% | snr 53% | ber 13535 | unc 0 | status S | signal 62% | snr 49% | ber 14173 | unc 0 | status SC| signal 52% | snr 50% | ber 13901 | unc 0 | status S | signal 63% | snr 49% | ber 13795 | unc 0 | status S | signal 83% | snr 53% | ber 13907 | unc 0 | status S | signal 62% | snr 49% | ber 13942 | unc 0 | status S | signal 48% | snr 49% | ber 14070 | unc 0 | status SC| signal 62% | snr 50% | ber 13688 | unc 0 | status S | signal 31% | snr 49% | ber 13815 | unc 0 | status SC| signal 56% | snr 49% | ber 13550 | unc 0 | status S | signal 62% | snr 49% | ber 14052 | unc 0 | status S | signal 32% | snr 49% | ber 14079 | unc 0 | status S | signal 62% | snr 49% | ber 13345 | unc 0 | status S | signal 21% | snr 41% | ber 0 | unc 0 | no FE_HAS_LOCK achievable, both signal levels and snr are too low so I pull out the CAM (and restart gnutv) the lock is immediate : status SCVYL | signal 80% | snr 84% | ber 0 | unc 0 | FE_HAS_LOCK status SCVYL | signal 80% | snr 84% | ber 0 | unc 0 | FE_HAS_LOCK status SCVYL | signal 79% | snr 84% | ber 0 | unc 0 | FE_HAS_LOCK status SCVYL | signal 79% | snr 84% | ber 0 | unc 0 | FE_HAS_LOCK status SCVYL | signal 79% | snr 84% | ber 0 | unc 0 | FE_HAS_LOCK status SCVYL | signal 79% | snr 84% | ber 0 | unc 0 | FE_HAS_LOCK status SCVYL | signal 79% | snr 84% | ber 0 | unc 0 | FE_HAS_LOCK status SCVYL | signal 79% | snr 84% | ber 0 | unc 0 | FE_HAS_LOCK status SCVYL | signal 79% | snr 84% | ber 0 | unc 0 | FE_HAS_LOCK status SCVYL | signal 80% | snr 84% | ber 0 | unc 0 | FE_HAS_LOCK status SCVYL | signal 78% | snr 84% | ber 0 | unc 0 | FE_HAS_LOCK status SCVYL | signal 79% | snr 84% | ber 0 | unc 0 | FE_HAS_LOCK status SCVYL | signal 80% | snr 84% | ber 0 | unc 0 | FE_HAS_LOCK signal is around 80%, snr a consistent 84% I re-insert the CAM, which is detected by gnutv, and the CAM is initialised tuning lock is lost at once : status S | signal 62% | snr 50% | ber 13585 | unc 0 | status S | signal 31% | snr 49% | ber 13498 | unc 0 | status S | signal 82% | snr 49% | ber 13540 | unc 0 | status S | signal 62% | snr 49% | ber 13984 | unc 0 | status S | signal 62% | snr 50% | ber 13548 | unc 0 | status S | signal 57% | snr 51% | ber 13530 | unc 0 | status SC| signal 39% | snr 48% | ber 14016 | unc 0 | status S | signal 57%
Re: [linux-dvb] CAM inserted/used reduces signal and SNR ?
Luc Brosens wrote: so I changed gnutv to only initialise the CAM after obtaining FE_HAS_LOCK apparantly, initialising the CAM is enough to loose the tuning lock, not to return afterwards so this is not a solution This won't help. The CPU on the CAM is running irrespective whether you are trying to initialize it or not. In fact the CPU usage is much lower at initialization time. here's a run with femon monitoring the tuning status : I start of with the CAM in the slot, and try to gnutv-tune to BBC World (which is not scrambled, so need for the CAM) [EMAIL PROTECTED]:~/dvb-apps femon -a 1 -H FE: ST STV0299 DVB-S (DVBS) status S | signal 63% | snr 49% | ber 14077 | unc 0 | status S | signal 79% | snr 51% | ber 13311 | unc 0 | status S | signal 69% | snr 50% | ber 13776 | unc 0 | status S | signal 31% | snr 49% | ber 13116 | unc 0 | status S | signal 54% | snr 49% | ber 13085 | unc 0 | status S | signal 75% | snr 49% | ber 13509 | unc 0 | status S | signal 80% | snr 50% | ber 13017 | unc 0 | status S | signal 21% | snr 41% | ber 0 | unc 0 | no FE_HAS_LOCK achievable, both signal levels and snr are too low so I pull out the CAM (and restart gnutv) the lock is immediate : status SCVYL | signal 80% | snr 84% | ber 0 | unc 0 | FE_HAS_LOCK status SCVYL | signal 79% | snr 84% | ber 0 | unc 0 | FE_HAS_LOCK status SCVYL | signal 79% | snr 84% | ber 0 | unc 0 | FE_HAS_LOCK status SCVYL | signal 78% | snr 84% | ber 0 | unc 0 | FE_HAS_LOCK signal is around 80%, snr a consistent 84% I re-insert the CAM, which is detected by gnutv, and the CAM is initialised tuning lock is lost at once : status S | signal 62% | snr 50% | ber 13585 | unc 0 | status S | signal 31% | snr 49% | ber 13498 | unc 0 | status S | signal 82% | snr 49% | ber 13540 | unc 0 | even though the signal level drops, it's probably the drop in snr that's causing trouble both cards have the same problem, so it doesn't appear that they're defective (or they both happen to have the same fault, which is unlikely) It looks to me that something is wrong with the frontend drivers (someplace) which causes a phase distortions, alongwith that in that tender state the digital noise from the CA module CPU's adds to it. The tenderness can be possibly attributed to a wrong device setup. You might like to check with your windows installation whether you see the same issue. Most likely, i guess not. If you see the same with windows 99% chance is that that whatever you might do, digital noise is affecting your demodulator and the tuner. question time : how much of a chance do I have of solving this if I somehow increase the signal strength ? would that increase the snr too ? (I could shorten the cables, even if it means relocating the PC) without the CAM, I have a signal strength of 80%. Is that considered a good, strong signal ? (my settop box is happy with it) I asked in a previous post if it's possible to capture scrambled to disk, and descramble later. This is what my settop box does. Is this even theoretically possible (sending data to the CAM from a file instead of from the tuner) ? Anybody know of a utility that supports this ? and now I'm off installing W2K on the damn thing, to see if that works ... Luc Manu ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] DIB 7070P reported as DIB 7000PC
Hi, My DVB device (Artec T14BR) uses the DiBcom 7070P frontend, however v4l-dvb is reporting the device as being based on a 7000PC frontend. The device still works, however the tuner does not seem anywhere near as sensitive as the MT2060 in my now deceased Freecom device. In fact running scan just results in filter timeouts, which means I end up having to use my old channels.conf as produced by my Freecom stick (RIP). Can anyone shed any light on why the device might be reporting itself as having a 7000 frontend? And might this be related to the relatively poor tuner sensitivity? Thanks. ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] no /dev/dvb after loading dvb-usb-vp7045 modules
Hello, installing my Twinhan Magic Box Pro (Model No: VP-704A0) fails because no device in /dev/dvb is created. I followed the steps described in the Linuxtv DVB Wiki. The Wiki tells me that I need the drivers dvb-usb.ko, dvb-usb-vp7045.ko and the firmware dvb-usb-vp7045-01.fw. The drivers exist in my Debian Etch system with kernel 2.6.18-5-k7. So I just added both modules to /etc/modules. Additional I downloaded the firmware from http://linuxtv.org/downloads/firmware/dvb-usb-vp7045-01.fw and copied it to /lib/firmware/ and to /usr/lib/hotplug/firmware/ to be sure udev will find the file. Loading the modules works fine: schawwi:~# dmesg | grep dvb usbcore: registered new driver dvb_usb_vp7045 syslog: Nov 22 22:00:39 localhost kernel: usbcore: registered new driver dvb_usb_vp7045 schawwi:/home/schawwi# lsmod | grep dvb dvb_usb_vp7045 8644 0 dvb_usb18696 1 dvb_usb_vp7045 dvb_core 72552 1 dvb_usb dvb_pll14596 1 dvb_usb i2c_core 20096 11 dvb_usb,dvb_pll,i2c_viapro,w83627hf,i2c_isa,i2c_dev,tuner,tvaudio,bttv,i2c_algo_bit,tveeprom firmware_class 10048 3 dvb_usb,bttv,prism54 usbcore 113412 11 dvb_usb_vp7045,dvb_usb,snd_usb_audio,snd_usb_lib,usblp,usbhid,ipaq,usbserial,ehci_hcd,uhci_hcd Disconnecting and connecting the DVB-Box from and to USB causes the following lines in syslog: Nov 22 22:02:02 localhost kernel: usb 5-5: USB disconnect, address 6 Nov 22 22:02:05 localhost kernel: usb 5-5: new high speed USB device using ehci_hcd and address 7 Nov 22 22:02:05 localhost kernel: usb 5-5: configuration #1 chosen from 1 choice The problem is that no directory /dev/dvb/ is created. I think, that the firmware is not loaded correct. Is this possible? I searched for similar problems and I found reports of syslog where more information than configuration #1 chosen from 1 choice is given. For example the name of the box and loading of the firmware. Has anyone an idea what is wrong? In debian the hotplug package is not installed but the udev package. Is this correct? Thank's a lot! Christian ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] DIB 7070P reported as DIB 7000PC
Hi again, DiB7000PC is the DVB-T demodulator, DiB0070 is the RF tuner. They are put into one package which is called DiB7070P. On Thu, 22 Nov 2007, Yousef Lamlum wrote: My DVB device (Artec T14BR) uses the DiBcom 7070P frontend, however v4l-dvb is reporting the device as being based on a 7000PC frontend. The device still works, however the tuner does not seem anywhere near as sensitive as the MT2060 in my now deceased Freecom device. In fact running scan just results in filter timeouts, which means I end up having to use my old channels.conf as produced by my Freecom stick (RIP). Can anyone shed any light on why the device might be reporting itself as having a 7000 frontend? And might this be related to the relatively poor tuner sensitivity? There is a bug in the LinuxTV driver for this receiver, which I was not yet able to fix... This fix improved dramatically the sensitivity I will try to provide something as soon as possible. best regards, Patrick. -- Mail: [EMAIL PROTECTED] WWW: http://www.wi-bw.tfh-wildau.de/~pboettch/ ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] DIB 7070P reported as DIB 7000PC
Patrick Boettcher wrote: Hi again, DiB7000PC is the DVB-T demodulator, DiB0070 is the RF tuner. They are put into one package which is called DiB7070P. On Thu, 22 Nov 2007, Yousef Lamlum wrote: My DVB device (Artec T14BR) uses the DiBcom 7070P frontend, however v4l-dvb is reporting the device as being based on a 7000PC frontend. The device still works, however the tuner does not seem anywhere near as sensitive as the MT2060 in my now deceased Freecom device. In fact running scan just results in filter timeouts, which means I end up having to use my old channels.conf as produced by my Freecom stick (RIP). Can anyone shed any light on why the device might be reporting itself as having a 7000 frontend? And might this be related to the relatively poor tuner sensitivity? There is a bug in the LinuxTV driver for this receiver, which I was not yet able to fix... This fix improved dramatically the sensitivity I will try to provide something as soon as possible. best regards, Patrick. -- Mail: [EMAIL PROTECTED] WWW: http://www.wi-bw.tfh-wildau.de/~pboettch/ Thanks for the clarification regarding the 7070 Very much looking forward to seeing the effect of the patch. Let me know if you need someone to test it. Thanks again, Yousef. ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
