Re: [linux-dvb] Bad TS from dvb-t recording?
Torbjörn Lundquist wrote: That solved it! Thanks. But how do I record a specific program in a mux? If I point out the video and sound pids for a program with dvbstream -f 522000 -o -tm 8 1249 1248 recordings/test.ts The stream does not play in VLC. can you try with the wildcard pid 8192. dvbstream -f 522000 -o -tm 8 8192 recordings/test.ts it just means get all the TS (supposed your carddriver are good to dump all the stream without hardware pid filtering AND you are on a large enough link i.e. NOT on a USB 1.1 bus!) as i told you, it's a 24Mbps streams (3MB per sec) at least here in italy, this is the usual bit rate for DVB-T transmission BTW in DVB-H transmission there's only a mere 5Mbps net payload .. we already have two or three in Bologna. mobile tv is all about reliability thru redundancy! then play it with VLC and should be able to wade thru the hierarchy of the TS and show you all the services available in the mux in the Navigation menu. tell us it works this way AND you'll be on the right track. it could not work AFAIK ONLY IF you have a really poor signal but the resulting file should show it. do this simple comparison between: - size_of_dump - time_of_rec_in_seconds * 3MB if they are similar, you have a good ts, if the size of the dump is really short, you don't have a good ts. anyway, i see you get all the relevant table of this mux, so you should be able to dump a quite clean stream. now, i just see in this mux the presence of MHP interactive applications. this is actually my main business here in italy, so i'd like to ask you if you can put on a website a 3 min full dump (should be a 500MB size..) to let my download it (then you can erase it..). i like to study what's going on abroad! bye andrea venturi Here are the pids I got from dvbsnoop: dvbsnoop -s pidscan dvbsnoop V1.4.00 -- http://dvbsnoop.sourceforge.net/ - Transponder PID-Scan... - PID found:0 (0x) [SECTION: Program Association Table (PAT)] PID found:1 (0x0001) [SECTION: Conditional Access Table (CAT)] PID found: 18 (0x0012) [SECTION: Event Information Table (EIT) - other transport stream, present/following] PID found: 41 (0x0029) [SECTION: DVB CA message section (EMM/ECM)] PID found: 57 (0x0039) [SECTION: DVB CA message section (EMM/ECM)] PID found: 870 (0x0366) [SECTION: Program Map Table (PMT)] PID found: 871 (0x0367) [SECTION: MHP- Application Information Table (AIT)] PID found: 872 (0x0368) [SECTION: DSM-CC - Download Data Messages (DDB)] PID found: 878 (0x036e) [PES: ISO/IEC 13818-3 or ISO/IEC 11172-3 audio stream] PID found: 879 (0x036f) [PES: ITU-T Rec. H.262 | ISO/IEC 13818-2 or ISO/IEC 11172-2 video stream] PID found: 880 (0x0370) [SECTION: Program Map Table (PMT)] PID found: 1002 (0x03ea) [SECTION: DSM-CC - Download Data Messages (DDB)] PID found: 1004 (0x03ec) [PES: private_stream_1] PID found: 1010 (0x03f2) [SECTION: Program Map Table (PMT)] PID found: 1011 (0x03f3) PID found: 1012 (0x03f4) [SECTION: DSM-CC - Download Data Messages (DDB)] PID found: 1016 (0x03f8) [PES: ISO/IEC 13818-3 or ISO/IEC 11172-3 audio stream] PID found: 1017 (0x03f9) [PES: private_stream_1] PID found: 1018 (0x03fa) [PES: ISO/IEC 13818-3 or ISO/IEC 11172-3 audio stream] PID found: 1019 (0x03fb) [PES: ITU-T Rec. H.262 | ISO/IEC 13818-2 or ISO/IEC 11172-2 video stream] PID found: 1021 (0x03fd) [SECTION: MHP- Application Information Table (AIT)] PID found: 1022 (0x03fe) [SECTION: DSM-CC - Download Data Messages (DDB)] PID found: 1026 (0x0402) [PES: ISO/IEC 13818-3 or ISO/IEC 11172-3 audio stream] PID found: 1027 (0x0403) [PES: private_stream_1] PID found: 1028 (0x0404) [PES: ISO/IEC 13818-3 or ISO/IEC 11172-3 audio stream] PID found: 1029 (0x0405) [PES: ITU-T Rec. H.262 | ISO/IEC 13818-2 or ISO/IEC 11172-2 video stream] PID found: 1241 (0x04d9) [SECTION: MHP- Application Information Table (AIT)] PID found: 1242 (0x04da) [SECTION: DSM-CC - U-N messages (DSI or DII)] PID found: 1248 (0x04e0) [PES: ISO/IEC 13818-3 or ISO/IEC 11172-3 audio stream] PID found: 1249 (0x04e1) [PES: ITU-T Rec. H.262 | ISO/IEC 13818-2 or ISO/IEC 11172-2 video stream] PID found: 1280 (0x0500) [SECTION: Program Map Table (PMT)] PID found: 1290 (0x050a) [SECTION: Program Map Table (PMT)] PID found: 5050 (0x13ba) [SECTION: Program Map Table (PMT)] PID found: 5070 (0x13ce) [SECTION: Program Map Table (PMT)] PID found: 5180 (0x143c) [SECTION: Program Map Table (PMT)] PID found: 8191 (0x1fff) ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Bad TS from dvb-t recording?
Thanks. When I tried with 8192 it worked. But then I got all programs in the mux and the file got extremely big so I want only one program in my recording. When I come home I will try with some other pid configurations. My goal is to have VLC to play the TS-stream, with lipsync. When playing with mplayer I got video and audio out of sync. How do I fix that? Andrea, I'll come back to you with the MUX-recording. Regards /Torbjörn 2007/3/9, Andrea Venturi [EMAIL PROTECTED]: Torbjörn Lundquist wrote: That solved it! Thanks. But how do I record a specific program in a mux? If I point out the video and sound pids for a program with dvbstream -f 522000 -o -tm 8 1249 1248 recordings/test.ts The stream does not play in VLC. can you try with the wildcard pid 8192. dvbstream -f 522000 -o -tm 8 8192 recordings/test.ts it just means get all the TS (supposed your carddriver are good to dump all the stream without hardware pid filtering AND you are on a large enough link i.e. NOT on a USB 1.1 bus!) as i told you, it's a 24Mbps streams (3MB per sec) at least here in italy, this is the usual bit rate for DVB-T transmission BTW in DVB-H transmission there's only a mere 5Mbps net payload .. we already have two or three in Bologna. mobile tv is all about reliability thru redundancy! then play it with VLC and should be able to wade thru the hierarchy of the TS and show you all the services available in the mux in the Navigation menu. tell us it works this way AND you'll be on the right track. it could not work AFAIK ONLY IF you have a really poor signal but the resulting file should show it. do this simple comparison between: - size_of_dump - time_of_rec_in_seconds * 3MB if they are similar, you have a good ts, if the size of the dump is really short, you don't have a good ts. anyway, i see you get all the relevant table of this mux, so you should be able to dump a quite clean stream. now, i just see in this mux the presence of MHP interactive applications. this is actually my main business here in italy, so i'd like to ask you if you can put on a website a 3 min full dump (should be a 500MB size..) to let my download it (then you can erase it..). i like to study what's going on abroad! bye andrea venturi Here are the pids I got from dvbsnoop: dvbsnoop -s pidscan dvbsnoop V1.4.00 -- http://dvbsnoop.sourceforge.net/ - Transponder PID-Scan... - PID found:0 (0x) [SECTION: Program Association Table (PAT)] PID found:1 (0x0001) [SECTION: Conditional Access Table (CAT)] PID found: 18 (0x0012) [SECTION: Event Information Table (EIT) - other transport stream, present/following] PID found: 41 (0x0029) [SECTION: DVB CA message section (EMM/ECM)] PID found: 57 (0x0039) [SECTION: DVB CA message section (EMM/ECM)] PID found: 870 (0x0366) [SECTION: Program Map Table (PMT)] PID found: 871 (0x0367) [SECTION: MHP- Application Information Table (AIT)] PID found: 872 (0x0368) [SECTION: DSM-CC - Download Data Messages (DDB)] PID found: 878 (0x036e) [PES: ISO/IEC 13818-3 or ISO/IEC 11172-3 audio stream] PID found: 879 (0x036f) [PES: ITU-T Rec. H.262 | ISO/IEC 13818-2 or ISO/IEC 11172-2 video stream] PID found: 880 (0x0370) [SECTION: Program Map Table (PMT)] PID found: 1002 (0x03ea) [SECTION: DSM-CC - Download Data Messages (DDB)] PID found: 1004 (0x03ec) [PES: private_stream_1] PID found: 1010 (0x03f2) [SECTION: Program Map Table (PMT)] PID found: 1011 (0x03f3) PID found: 1012 (0x03f4) [SECTION: DSM-CC - Download Data Messages (DDB)] PID found: 1016 (0x03f8) [PES: ISO/IEC 13818-3 or ISO/IEC 11172-3 audio stream] PID found: 1017 (0x03f9) [PES: private_stream_1] PID found: 1018 (0x03fa) [PES: ISO/IEC 13818-3 or ISO/IEC 11172-3 audio stream] PID found: 1019 (0x03fb) [PES: ITU-T Rec. H.262 | ISO/IEC 13818-2 or ISO/IEC 11172-2 video stream] PID found: 1021 (0x03fd) [SECTION: MHP- Application Information Table (AIT)] PID found: 1022 (0x03fe) [SECTION: DSM-CC - Download Data Messages (DDB)] PID found: 1026 (0x0402) [PES: ISO/IEC 13818-3 or ISO/IEC 11172-3 audio stream] PID found: 1027 (0x0403) [PES: private_stream_1] PID found: 1028 (0x0404) [PES: ISO/IEC 13818-3 or ISO/IEC 11172-3 audio stream] PID found: 1029 (0x0405) [PES: ITU-T Rec. H.262 | ISO/IEC 13818-2 or ISO/IEC 11172-2 video stream] PID found: 1241 (0x04d9) [SECTION: MHP- Application Information Table (AIT)] PID found: 1242 (0x04da) [SECTION: DSM-CC - U-N messages (DSI or DII)] PID found: 1248 (0x04e0) [PES: ISO/IEC 13818-3 or ISO/IEC 11172-3 audio stream] PID found: 1249 (0x04e1) [PES: ITU-T Rec. H.262 | ISO/IEC 13818-2 or ISO/IEC 11172-2 video stream] PID found: 1280 (0x0500) [SECTION: Program Map Table (PMT)] PID found: 1290 (0x050a) [SECTION: Program Map Table (PMT)] PID found: 5050 (0x13ba) [SECTION: Program Map Table (PMT)]
Re: [linux-dvb] Bad TS from dvb-t recording?
Torbjörn Lundquist wrote: When playing with mplayer I got video and audio out of sync. How do I fix that? maybe during the first few seconds, but after little time it will resync -- Email.it, the professional e-mail, gratis per te: http://www.email.it/f Sponsor: Video Corsi GRATIS - Scopri come imparare velocemente e senza stress (Internet, Informatica, Web Marketing, Hobby Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?midQ45d=9-3 ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] Chronos Video Shuttle 2 - Philips Chipset 7134
The problem with this card is that I can get it working right. I am loading the driver this way: modprobe saa7134 card=3 What is the proper card number and tuner number for this card. I can not find it in here : http://www.linuxtv.org/v4lwiki/index.php/CARDLIST.saa7134 01:06.0 Multimedia controller: Philips Semiconductors SAA7133/SAA7135 Video Broadcast Decoder (rev d1) Subsystem: Philips Semiconductors Unknown device Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- Latency: 64 (3750ns min, 9500ns max) Interrupt: pin A routed to IRQ 17 Region 0: Memory at d800 (32-bit, non-prefetchable) [size=2K] Capabilities: access denied I have the same card but with a diferent chipset: 01:06.0 Multimedia controller: Philips Semiconductors SAA7134/SAA7135HL Video Broadcast Decoder (rev 01) Subsystem: Philips Semiconductors Unknown device Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- Latency: 64 (3750ns min, 9500ns max) Interrupt: pin A routed to IRQ 17 Region 0: Memory at dc00 (32-bit, non-prefetchable) [size=1K] Capabilities: access denied It it working much better. Linux live18 2.6.18.3 #5 SMP Mon Dec 4 11:36:09 EET 2006 i686 athlon-4 i386 GNU/Linux ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Bad TS from dvb-t recording?
When playing with mplayer I got video and audio out of sync. How do I fix that? maybe during the first few seconds, but after little time it will resync I have sometimes the same problem, and that can be solved by starting with some additional chaching: mplayer -cache 8000 -- Peter ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Bad TS from dvb-t recording?
Torbjörn Lundquist wrote: Thanks. When I tried with 8192 it worked. But then I got all programs in the mux and the file got extremely big so I want only one program in my recording. of course. this is something you should achieve dumping only the PID contained in the PMT table of the service you are after. dvbsnoop will help you. When I come home I will try with some other pid configurations. My goal is to have VLC to play the TS-stream, with lipsync. i'd like to give my point of view. maybe someone who know can comment on it.. AFAIK in the linux dvb software stack there are two different kind of problems. 1. correct buffer management, i.e. the PCR restamping issue. in general, in a transport stream with a fixed bit rate, each service has a counter called PCR useful to get exactly filled (not to much: overrun; not to low,: underrun) the small buffers in the remote decoder when you strip down all the PIDs except the ones you need for a single service, you are going to modify the rate of the saved stream SO you'll need to modify (restamp) the PCR to maintain the consistency of this counter.. otherwise you are going to see (during the replay of the stream on a decoder) artifacts coming from the underrun and overrun.. anyway, when you feed a video decoder like VLC on a PC, you don't see this kind of things because in a pc usually there is plenty of space in the buffers AND you have flow control, so the decoder can stop and start the reads from the file when it has full or empty buffers. but this is something we need to cope with, if we want to move to a better management of the MPEG TS features (expecially in constrained / embedded environment or in multicast/IPTV) BTW i just see (IIRC in some DVR dumps) that there are some tricks implemented to fake this PCR feature, using for example another counter (64 bits), in the head of each TS packets, where the recorder saves the position of the packet in the original full TS, so when the DVR makes the replay of the single service dump, i suppose it fills the decoding pipeline with NULL packets between every TS packet not adjacent, this way it restores correctly the original bit rate without any hard computation.. clever and easy! 2. lipsync (DTS/PTS fields). to get in sync audio and video streams there are these two fields with counters inside, and they are all about when decode and present (i.e. send to the screen and to the audio decoder) the video and audio frames.. how well are these fields supported in the linux video players, i don't know.. but it seems to me something valuable to be investigated if we want to improve the linux video applications. IMHO we shoudln't need to enlarge buffers or wait some time just to get insync audio and video IF the HW decoders are capable to do it sooner, better and with less resource.. it's just a matter of better software (in the long run) but of course, this is free (as freedom) software, so, thanks god AND all the people already working on it with this open attitude; it's already too much!! :-) i'd like to say we can do something on this topic, but we are working more on the infrastructure of DVB networks so it could be we can put something out WRT the PCR/fakePCR issues (and reduce artifacts and/or memory footprint in DVB applications) like a smart DVB remultiplexer, an improvement of our software TS manipulator called JustDvb-It: http://krusty.cineca.it/vpweb/cgi-bin/blosxom.cgi [yes, i know it seems dead since long time, but we are still working on it..] but we are not working on the lipsync issues because we are using HW boxed decoders. hope it helps When playing with mplayer I got video and audio out of sync. How do I fix that? Andrea, I'll come back to you with the MUX-recording. fine bye andrea venturi Regards /Torbjörn 2007/3/9, Andrea Venturi [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]: Torbjörn Lundquist wrote: That solved it! Thanks. But how do I record a specific program in a mux? If I point out the video and sound pids for a program with dvbstream -f 522000 -o -tm 8 1249 1248 recordings/test.ts The stream does not play in VLC. can you try with the wildcard pid 8192. dvbstream -f 522000 -o -tm 8 8192 recordings/test.ts it just means get all the TS (supposed your carddriver are good to dump all the stream without hardware pid filtering AND you are on a large enough link i.e. NOT on a USB 1.1 bus!) as i told you, it's a 24Mbps streams (3MB per sec) at least here in italy, this is the usual bit rate for DVB-T transmission BTW in DVB-H transmission there's only a mere 5Mbps net payload .. we already have two or three in Bologna. mobile tv is all about reliability thru redundancy! then play it with VLC and should be able to wade thru the hierarchy of the TS and show you all the services available in the mux in the
Re: [linux-dvb] bug in szap-utility
Original-Nachricht Datum: Tue, 06 Mar 2007 20:14:16 +0100 Von: Michel Verbraak [EMAIL PROTECTED] An: linux-dvb@linuxtv.org CC: Betreff: Re: [linux-dvb] bug in szap-utility Uwe Bugla schreef: Hi folks, as part of the Debain package dvb-utils 1.1.1-2 the szap utility has the following bug: 1. The start transponder file of Eutelsat Hotbird13.0E contains a H as description of the polarization. 2. Unfortunately this H is being interpreted as V. 3. So if you try to produce a transponder list with the start transponder you are trapped as nothing works! To see the error yourself, try the following example in the console: szap -r -a0 -c trapz.txt -n1 where trapz.txt looks like this: Hotbird-13.0E:12539:H:1:27500 With which program did you create the trapz.txt file? Salut Michel, with a program called pere which is a new revolutionary development as it scans a lot of more accurate as scan or dvbscan ever did! But please ignore that and see the szap bug instead. The error only happens with H, not with V, OK? My scan or scandvb program creates only lower cases polarization characters (v or h). I think the szap program only recognizes lowercase by design. In the console you will see the right frequency and the right symbol rate. But the polarization will be printed out as V (vertical) instead of H (horizontal). In other words: The bug is: szap cannot set equal the letter h with the letter H Regards Uwe P. S.: I solved the problem by a TCL-TK workaround, but it rather should be solved in the sourcecode, shouldn't it? So can someone reading this please fix that bug in the source code? ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb Regards Uwe -- Feel free - 10 GB Mailbox, 100 FreeSMS/Monat ... Jetzt GMX TopMail testen: www.gmx.net/de/go/mailfooter/topmail-out ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] bug in szap-utility
Original-Nachricht Datum: Tue, 6 Mar 2007 18:55:51 +0100 Von: Marcel Siegert [EMAIL PROTECTED] An: Uwe Bugla [EMAIL PROTECTED] CC: linux-dvb@linuxtv.org, [EMAIL PROTECTED] Betreff: Re: [linux-dvb] bug in szap-utility On Tuesday 06 March 2007, Uwe Bugla wrote: Hi folks, as part of the Debain package dvb-utils 1.1.1-2 the szap utility has the following bug: 1. The start transponder file of Eutelsat Hotbird13.0E contains a H as description of the polarization. 2. Unfortunately this H is being interpreted as V. 3. So if you try to produce a transponder list with the start transponder you are trapped as nothing works! To see the error yourself, try the following example in the console: szap -r -a0 -c trapz.txt -n1 where trapz.txt looks like this: Hotbird-13.0E:12539:H:1:27500 In the console you will see the right frequency and the right symbol rate. But the polarization will be printed out as V (vertical) instead of H (horizontal). In other words: The bug is: szap cannot set equal the letter h with the letter H Regards Uwe P. S.: I solved the problem by a TCL-TK workaround, but it rather should be solved in the sourcecode, shouldn't it? So can someone reading this please fix that bug in the source code? hi, could you please try if a --- a/util/szap/szap.c Fri Feb 02 02:16:24 2007 +0100 +++ b/util/szap/szap.c Tue Mar 06 18:53:39 2007 +0100 @@ -496,7 +496,7 @@ again: if (!(field = strsep(tmp, :))) goto syntax_err; -pol = (field[0] == 'h' ? 0 : 1); +pol = (tolower(field[0]) == 'h' ? 0 : 1); if (!(field = strsep(tmp, :))) goto syntax_err; would fix that problem? if reported fine, i'll commit that. thanks marcel Thanks Marcel, I am going to download the source code and try your patch. Gimme a couple of days time please. Thanks and regards Uwe -- Feel free - 10 GB Mailbox, 100 FreeSMS/Monat ... Jetzt GMX TopMail testen: www.gmx.net/de/go/mailfooter/topmail-out ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] bug in szap-utility
On Friday 09 March 2007, Uwe Bugla wrote: Original-Nachricht Datum: Tue, 06 Mar 2007 20:14:16 +0100 Von: Michel Verbraak [EMAIL PROTECTED] An: linux-dvb@linuxtv.org CC: Betreff: Re: [linux-dvb] bug in szap-utility Uwe Bugla schreef: Hi folks, as part of the Debain package dvb-utils 1.1.1-2 the szap utility has the following bug: 1. The start transponder file of Eutelsat Hotbird13.0E contains a H as description of the polarization. 2. Unfortunately this H is being interpreted as V. 3. So if you try to produce a transponder list with the start transponder you are trapped as nothing works! To see the error yourself, try the following example in the console: szap -r -a0 -c trapz.txt -n1 where trapz.txt looks like this: Hotbird-13.0E:12539:H:1:27500 With which program did you create the trapz.txt file? Salut Michel, with a program called pere which is a new revolutionary development as it scans a lot of more accurate as scan or dvbscan ever did! But please ignore that and see the szap bug instead. The error only happens with H, not with V, OK? My scan or scandvb program creates only lower cases polarization characters (v or h). I think the szap program only recognizes lowercase by design. In the console you will see the right frequency and the right symbol rate. But the polarization will be printed out as V (vertical) instead of H (horizontal). In other words: The bug is: szap cannot set equal the letter h with the letter H Regards Uwe P. S.: I solved the problem by a TCL-TK workaround, but it rather should be solved in the sourcecode, shouldn't it? So can someone reading this please fix that bug in the source code? ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb Regards Uwe hi uwe, yes, your predication is correct on the is does not happen at v or V for polarization. if you have a look at the sources, and also at my proposed patch - i am still waiting for your answer - szap just check[s|ed] for the h and if that is NOT present is assumes v. so everything else than a h or (with my patch applied) H will be treated as vertical. regards marcel ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Bad TS from dvb-t recording?
Le vendredi 09 mars 2007 10:38, Torbjörn Lundquist a écrit : Thanks. When I tried with 8192 it worked. But then I got all programs in the mux and the file got extremely big so I want only one program in my recording. When I come home I will try with some other pid configurations. My goal is to have VLC to play the TS-stream, with lipsync. Kaffeine does insert pat and pmt in its TS records, so vlc plays them. -- Christophe Thommeret ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] Re: Nova-T 500 Channel scanning + EIT + Kernel oops...
I got this off list, Henrik I hope you don't mind me going back to the list.. From: Henrik Beckman [EMAIL PROTECTED] If someone could run usbsnoop on their windows installed nova-t 500 it might be useful to look on how it looks in the windows stream ? Since I have another PC with windows installed I put the card to the windows machine, installed the 3.3c drivers from www.hauppauge.co.uk and took a trace with SniffUsb 2.0 [1]. The trace is a bit large (over 600M compressed), but it is available at http://brigitte.dna.fi/~apm/UsbSnoop.log.gz - will take over an hour to tricle over my link and the machine can go down whenever I need to e.g. power cycle to get new firmware loaded or something. There is also a version processed with the parser.pl from the mbrechberger hg repo as http://brigitte.dna.fi/~apm/UsbSnoop.txt.gz which is only a bit over 200M. If someone wants the logs mail me so I know not to reboot during transfer. I tried to extract also firmware from the trace with very questionable method of inspecting the start and end patterns of the firmwares I have and just cutting the matching part from the traffic. The result is at http://brigitte.dna.fi/~apm/dvb-usb-dib0700-h3.3c.fw, but with this fw the frontend does not attach, i.e. not very useful, probably broken. [1] http://www.pcausa.com/Utilities/UsbSnoop/default.htm -- http://www.iki.fi/~ananaza/ ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] bug in szap-utility
Original-Nachricht Datum: Fri, 9 Mar 2007 13:52:07 +0100 Von: Marcel Siegert [EMAIL PROTECTED] An: linux-dvb@linuxtv.org CC: Uwe Bugla [EMAIL PROTECTED] Betreff: Re: [linux-dvb] bug in szap-utility On Friday 09 March 2007, Uwe Bugla wrote: Original-Nachricht Datum: Tue, 06 Mar 2007 20:14:16 +0100 Von: Michel Verbraak [EMAIL PROTECTED] An: linux-dvb@linuxtv.org CC: Betreff: Re: [linux-dvb] bug in szap-utility Uwe Bugla schreef: Hi folks, as part of the Debain package dvb-utils 1.1.1-2 the szap utility has the following bug: 1. The start transponder file of Eutelsat Hotbird13.0E contains a H as description of the polarization. 2. Unfortunately this H is being interpreted as V. 3. So if you try to produce a transponder list with the start transponder you are trapped as nothing works! To see the error yourself, try the following example in the console: szap -r -a0 -c trapz.txt -n1 where trapz.txt looks like this: Hotbird-13.0E:12539:H:1:27500 With which program did you create the trapz.txt file? Salut Michel, with a program called pere which is a new revolutionary development as it scans a lot of more accurate as scan or dvbscan ever did! But please ignore that and see the szap bug instead. The error only happens with H, not with V, OK? My scan or scandvb program creates only lower cases polarization characters (v or h). I think the szap program only recognizes lowercase by design. In the console you will see the right frequency and the right symbol rate. But the polarization will be printed out as V (vertical) instead of H (horizontal). In other words: The bug is: szap cannot set equal the letter h with the letter H Regards Uwe P. S.: I solved the problem by a TCL-TK workaround, but it rather should be solved in the sourcecode, shouldn't it? So can someone reading this please fix that bug in the source code? ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb Regards Uwe hi uwe, yes, your predication is correct on the is does not happen at v or V for polarization. if you have a look at the sources, and also at my proposed patch - i am still waiting for your answer - szap just check[s|ed] for the h and if that is NOT present is assumes v. so everything else than a h or (with my patch applied) H will be treated as vertical. regards marcel Marcel, again: Thanks for your help. But please give me some time, OK? I aint no robot, OK? No sweat please, take it slow, OK? Regards Uwe -- Feel free - 10 GB Mailbox, 100 FreeSMS/Monat ... Jetzt GMX TopMail testen: www.gmx.net/de/go/mailfooter/topmail-out ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [RFC] Reviewed development procedures DVBMaintainer
That someone fucks up and talks bullshit, that's to be expected from a human being. But that's something entirely different than malice. In January 2006 I got told that I should implement the xc3028 just as all other external tuner modules are implemented without a tuner-core dependency, it end up that the tuner-core would need modularization since all external v4l tuners are compiled into the tuner-core. Markus, I suspect the other person gave the best advice they could at the time. Maybe that advise is no longer true or valid. Either way, the person offered the best advise I suspect. Maybe in the future you should seek advise from multiple sources to validate any long term development approach. For anyone to turn around and complain sounds petty and unprofessional. If you're really interested in moving the general Linux community forward then you will stop henceforth blaming other people and aggressively push two or three alternative solutions. If you are passionate enough about your work then you need to promote your ideas enough that people either accept one of your suggestions, or recommend an alternative approach. Passion and perseverance is required, not moaning. Likewise, the other developers have an obligation to review your ideas and discuss/describe the areas of concern, offering constructive feedback. It's unacceptable to refuse a colleagues patch and not offer any advise. I know this has NOT happened. I know alternatives were given to you. I suggest you stop the bickering and begin working with your Linux peers again, help us to find the right solution. Half working drivers and/or badly integrated features are one of the major reasons people turn to Windows instead of Linux. I hereby offer to help review any alternative suggestions you may have without bias or prejudice. I'll need other members to help. Regards, Steve (Sorry, off topic but based on recent discussion in IRC this had to be addressed) ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [RFC] Reviewed development procedures DVBMaintainer
On 3/9/07, Steven Toth [EMAIL PROTECTED] wrote: That someone fucks up and talks bullshit, that's to be expected from a human being. But that's something entirely different than malice. In January 2006 I got told that I should implement the xc3028 just as all other external tuner modules are implemented without a tuner-core dependency, it end up that the tuner-core would need modularization since all external v4l tuners are compiled into the tuner-core. Markus, I suspect the other person gave the best advice they could at the time. Maybe that advise is no longer true or valid. Either way, the person offered the best advise I suspect. Maybe in the future you should seek advise from multiple sources to validate any long term development approach. everyone is welcome to reply, but usually not too many participate here. For anyone to turn around and complain sounds petty and unprofessional. If you're really interested in moving the general Linux community forward sorry that's not on me I already showed up quite alot interest by writing and discovering how many em28xx devices work even without having the proper specs for it. I'm also behind bugreports and normal user help I receive on a daily basis and there are already several thousand mails about it in my mailaccount. I just spent too much time on it for getting cut down by people who don't want to go forward. Also these 8000 lines of new code didn't write themself. then you will stop henceforth blaming other people and aggressively push two or three alternative solutions. If you are passionate enough about your work then you need to promote your ideas enough that people either accept one of your suggestions, or recommend an alternative approach. Passion and perseverance is required, not moaning. Likewise, the other developers have an obligation to review your ideas and discuss/describe the areas of concern, offering constructive feedback. It's unacceptable to refuse a colleagues patch and not offer any advise. I know this has NOT happened. I know alternatives were given to you. What alternatives do you mean? * writing several wrappers around a core driver? -- is this really acceptable, what are the pros/cons of that approach? * writing one wrapper for dvb? - same what are the pros/cons. * it also got stated out if there's any way to merge tuner core code with dvb-pll (in that case only dvb_tuner_ops) it would be welcome (got also only mentioned only by a few devs) I triggered 2 discussions about that already and the participation of other developers was quite low. - * looking at the saa7134-dvb hybrid driver, which I did and I took the v4l infrastructure for tuning to dvb channels since it was done that way too, of course some DVB guys didn't like that approach either when they saw it the first time... I suggest you stop the bickering and begin working with your Linux peers again, help us to find the right solution. sorry I'm getting pissed, for every approach I presented for now I had some code as well and it gets nacked without improvement suggestions. Also it has to be said that other hybrid implementations aren't well implemented and still need some improvement.. Half working drivers and/or badly integrated features are one of the major reasons people turn to Windows instead of Linux. how can a driver work properly if the base of it gets bombed all the time. I hereby offer to help review any alternative suggestions you may have without bias or prejudice. I'll need other members to help. that's great and appreciated, so if you want a history of the previous discussions let me know. There you'll also see that any review from Mauro end up in an accepted improvement, this just proves that other ways are possible too. Markus ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] Fwd: [Kaffeine-user] DVB-T channel list de-Regensburg
From a kaffeine user ... Christoph -- Weitergeleitete Nachricht -- Subject: [Kaffeine-user] DVB-T channel list de-Regensburg Date: Donnerstag, 8. März 2007 23:15 From: Robert Heel [EMAIL PROTECTED] To: [EMAIL PROTECTED] Hi, there isn't a channel list de-Regensburg, so I created one :-) Have fun, Robert # DVB-T Regensburg (Germany) # Generated by Robert Heel [EMAIL PROTECTED] # K07 - ARD-Bouquet (DasErste, Phoenix, arte, EinsPlus) T 19150 7MHz 3/4 NONE QAM16 8k 1/4 NONE # K28 - BR-Bouquet (Bayrisches FS, BR-alpha, SWR Fernsehen) T 53000 8MHz 2/3 NONE QAM16 8K 1/4 NONE # K53 - ZDF-Bouquet (ZDF, 3sat, Doku/KiKa, ZDFdigitext) T 73000 8MHz 2/3 NONE QAM16 8K 1/4 NONE --- ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [PATCH] v4l-dvb: add $DESTDIR support
Trent Piepho wrote:
On Thu, 8 Mar 2007, Ludwig Nussel wrote:
Trent Piepho wrote:
Following patch adds $DESTDIR support so one can install the kernel
modules into a directory other than / as non-root user. That's
useful when building an rpm or compiling for a different machine.
-print OUT \t/sbin/depmod -a \${KERNELRELEASE}\n\n;
+print OUT \tif [ -w / ]; then /sbin/depmod -a \${KERNELRELEASE};
fi\n\n;
This doesn't seem correct. Shouldn't it be:
print OUT \t/sbin/depmod -a \$(KERNELRELEASE) \$(if \$(DESTDIR),-b
\$(DESTDIR))\n\n;
One needs to run depmod when the modules get installed to their final
location.
$DESTDIR is incomplete so it doesn't make sense to run depmod here already.
When compiling an RPM package DESTDIR may not be the final location, but
that is not the only reason one might want to use DESTDIR. One could
repair a mounted root fs after booting from a rescue CD or be trying to
create a bootable MythTV image.
Well, obviously noone cared about such exotic use cased yet. Anyways here a
patch that adds your change as well, please apply.
Signed-off-by: Ludwig Nussel [EMAIL PROTECTED]
diff -r f71d56dfeb0d v4l/scripts/make_makefile.pl
--- a/v4l/scripts/make_makefile.pl Wed Mar 07 12:28:33 2007 -0200
+++ b/v4l/scripts/make_makefile.pl Fri Mar 09 15:45:49 2007 +0100
@@ -134,12 +134,12 @@ print OUT [EMAIL PROTECTED] --strip-debug \$(in
while (my ($dir, $files) = each %instdir) {
print OUT [EMAIL PROTECTED] -e \\\nInstalling \$(KDIR26)/$dir
files:\\n;
- print OUT [EMAIL PROTECTED] -d \$(KDIR26)/$dir\n;
+ print OUT [EMAIL PROTECTED] -d \$(DESTDIR)\$(KDIR26)/$dir\n;
print OUT [EMAIL PROTECTED] i in , join(' ', keys %$files), ;do ;
print OUT if [ -e \\$\$i\ ]; then echo -n \\$\$i \;;
- print OUT install -m 644 -c \$\$i \$(KDIR26)/$dir; fi; done;
echo;\n\n;
+ print OUT install -m 644 -c \$\$i \$(DESTDIR)\$(KDIR26)/$dir; fi;
done; echo;\n\n;
}
-print OUT \t/sbin/depmod -a \${KERNELRELEASE}\n\n;
+print OUT \t/sbin/depmod -a \$(KERNELRELEASE) \$(if \$(DESTDIR),-b
\$(DESTDIR))\n\n;
# Creating Remove rule
print OUT media-rminstall::\n;
@@ -149,13 +149,13 @@ while ( my ($dir, $files) = each(%instdi
print OUT [EMAIL PROTECTED] -e \\\nRemoving old \$(KDIR26)/$dir
files:\\n;
print OUT [EMAIL PROTECTED]', join(' ', keys %$files), '; ;
- print OUT for i in \$\$files;do if [ -e \$(KDIR26)/$dir/\$\$i ]; then
;
+ print OUT for i in \$\$files;do if [ -e
\$(DESTDIR)\$(KDIR26)/$dir/\$\$i ]; then ;
print OUT echo -n \\$\$i \;;
- print OUT rm \$(KDIR26)/$dir/\$\$i; fi; done; ;
+ print OUT rm \$(DESTDIR)\$(KDIR26)/$dir/\$\$i; fi; done; ;
- print OUT for i in \$\$files;do if [ -e \$(KDIR26)/$dir/\$\$i.gz ];
then ;
+ print OUT for i in \$\$files;do if [ -e
\$(DESTDIR)\$(KDIR26)/$dir/\$\$i.gz ]; then ;
print OUT echo -n \\$\$i.gz \;;
- print OUT rm \$(KDIR26)/$dir/\$\$i.gz; fi; done; echo;\n\n;
+ print OUT rm \$(DESTDIR)\$(KDIR26)/$dir/\$\$i.gz; fi; done;
echo;\n\n;
}
# Print dependencies of Makefile.media
cu
Ludwig
--
(o_ Ludwig Nussel
//\ SUSE Labs
V_/_ http://www.suse.de/
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg)
___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [PATCH] Keeping track of dependencies with dvb_attach()
On 8/31/06, Andrew de Quincey [EMAIL PROTECTED] wrote: On Saturday 19 August 2006 08:52, Trent Piepho wrote: When using dynamic dependencies with dvb_attach(), which module is using another doesn't show up with lsmod. The problem is that when a card driver attaches the frontend with symbol_request(), the kernel increments the use count of the frontend module, but doesn't keep track of which module it was the called symbol_request(). This patch will fix it so that the kernel does keep track. Sounds great to me - I thought it was weird the kernel didn't keep track of them already. think we shouldn't just forget that patch, can you submit it to the lkml too? Mauro pointed me out that this patch is already available, so there's no need to reimplement it for me :) cheers, Markus ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Re: Nova-T 500 Channel scanning + EIT + Kernel oops...
Hi, No problem, hopefully someone will take a peek. www.struct.se/vp7045a.html me struggling with firmwares, probably the same technique, but anyway. Are there any differences in the windows stream ? /Henrik On 3/9/07, Antti P Miettinen [EMAIL PROTECTED] wrote: I got this off list, Henrik I hope you don't mind me going back to the list.. From: Henrik Beckman [EMAIL PROTECTED] If someone could run usbsnoop on their windows installed nova-t 500 it might be useful to look on how it looks in the windows stream ? Since I have another PC with windows installed I put the card to the windows machine, installed the 3.3c drivers from www.hauppauge.co.uk and took a trace with SniffUsb 2.0 [1]. The trace is a bit large (over 600M compressed), but it is available at http://brigitte.dna.fi/~apm/UsbSnoop.log.gz - will take over an hour to tricle over my link and the machine can go down whenever I need to e.g. power cycle to get new firmware loaded or something. There is also a version processed with the parser.pl from the mbrechberger hg repo as http://brigitte.dna.fi/~apm/UsbSnoop.txt.gz which is only a bit over 200M. If someone wants the logs mail me so I know not to reboot during transfer. I tried to extract also firmware from the trace with very questionable method of inspecting the start and end patterns of the firmwares I have and just cutting the matching part from the traffic. The result is at http://brigitte.dna.fi/~apm/dvb-usb-dib0700-h3.3c.fw, but with this fw the frontend does not attach, i.e. not very useful, probably broken. [1] http://www.pcausa.com/Utilities/UsbSnoop/default.htm -- http://www.iki.fi/~ananaza/ ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Bad TS from dvb-t recording?
Thanks for the tip but I dont use X on the backend server and the frontend is a webbrowser enabled stb. Maybe I should describe what I would like to do: I would like to have a backend server that records dvb-t recordings and then stream them to my webbased set top box or another browser in the network. Most prefferable would be to have a VOD-server (the stb supports that) so I could use trickplay. Any tips? Best Regards /Torbjörn 2007/3/9, Christophe Thommeret [EMAIL PROTECTED]: Le vendredi 09 mars 2007 10:38, Torbjörn Lundquist a écrit: Thanks. When I tried with 8192 it worked. But then I got all programs in the mux and the file got extremely big so I want only one program in my recording. When I come home I will try with some other pid configurations. My goal is to have VLC to play the TS-stream, with lipsync. Kaffeine does insert pat and pmt in its TS records, so vlc plays them. -- Christophe Thommeret ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] kernel OOPSes when changing DVB-T adapter in 2.6.21-rc3
Hi, I am trying change Freecom DVB-T dongle with Leadtek DVB-T dongle and I got this OOPS: -- usb 2-3: new high speed USB device using ehci_hcd and address 2 usb 2-3: configuration #1 chosen from 1 choice dvb-usb: found a 'WideView WT-220U PenType Receiver (Typhoon/Freecom)' in cold state, will try to load a firmware dvb-usb: downloading firmware from file 'dvb-usb-wt220u-02.fw' usbcore: registered new interface driver dvb_usb_dtt200u usb 2-3: USB disconnect, address 2 dvb-usb: generic DVB-USB module successfully deinitialized and disconnected. usb 2-3: new high speed USB device using ehci_hcd and address 3 usb 2-3: configuration #1 chosen from 1 choice dvb-usb: found a 'WideView WT-220U PenType Receiver (Typhoon/Freecom)' in warm state. dvb-usb: will use the device's hardware PID filter (table count: 15). DVB: registering new adapter (WideView WT-220U PenType Receiver (Typhoon/Freecom)). DVB: registering frontend 0 (WideView USB DVB-T)... input: IR-receiver inside an USB DVB receiver as /class/input/input18 dvb-usb: schedule remote query interval to 300 msecs. dvb-usb: WideView WT-220U PenType Receiver (Typhoon/Freecom) successfully initialized and connected. dvb-usb: recv bulk message failed: -110 usb 2-3: USB disconnect, address 3 BUG: unable to handle kernel paging request at virtual address 00100100 printing eip: c027552d *pde = 36209067 *pte = Oops: [#1] PREEMPT Modules linked in: dvb_usb_dtt200u dvb_usb dvb_core dvb_pll ppp_deflate zlib_deflate bsd_comp ppp_async ppp_generic slhc bnep rfcomm hidp l2cap lp fuse eeprom hci_usb bluetooth eth1394 usbhid 8250_pci 8250 serial_core nsc_ircc snd_intel8x0m snd_intel8x0 snd_ac97_codCT 24ec irda ide_cd ac97_bus snd_pcm snd_timer snd parport_pc cdrom crc_ccitt ohci1394 ieee1394 8139too mii snd_page_alloc parport ohci_hcd i2c_i801 psmouse pcspkr iTCO_wdt iTCO_vendor_support rtc uhci_hcd ehci_hcd CPU:0 EIP:0060:[c027552d]Not tainted VLICT 24 EFLAGS: 00010206 (2.6.21-rc3 #2) EIP is at evdev_disconnect+0x87/0xae eax: ebx: 000ffcf0 ecx: c1916000 edx: f616e000 esi: e7520dc0 edi: f697d800 ebp: f697dec4 esp: c1917e78 ds: 007b es: 007b fs: 00d8 gs: ss: 0068 Process khubd (pid: 130, ti=c1916000 task=c18fea70 task.ti=c1916000) Stack: c037b488 e7520df0 c0273983 e33ba000 f6f7fc18 fcc2a420 f1673800 fcc1319f e33ba000 fcc122da fcc29502 f6f7fc18 fcc2a420 f1673800 fcc12386 f6f7fc18 fcc2a420 f6f7fc00 c0266522 ffed f6f7fc18 fcc2a44c Call Trace: [c0273983] input_unregister_device+0x89/0x111 [fcc1319f] dvb_usb_remote_exit+0x27/0x32 [dvb_usb] [fcc122da] dvb_usb_exit+0xb/0x87 [dvb_usb] [fcc12386] dvb_usb_device_exit+0x30/0x44 [dvb_usb] [c0266522] usb_unbind_interface+0x3e/0x7c [c023e037] __device_release_driver+0x6e/0x8b [c023e421] device_release_driver+0x1d/0x32 [c023dadb] bus_remove_device+0x5b/0x69 [c023c612] device_del+0xfa/0x152 [c0264128] usb_disable_device+0x5c/0xbb [c0260e2c] usb_disconnect+0x82/0x114 [c02618e9] hub_thread+0x375/0xa76 [c02d3061] __sched_text_start+0x4a9/0x54c [c0115301] __wake_up_common+0x31/0x4f [c012880b] autoremove_wake_function+0x0/0x35 [c0261574] hub_thread+0x0/0xa76 [c0128750] kthread+0xa0/0xc8 [c01286b0] kthread+0x0/0xc8 [c0104823] kernel_thread_helper+0x7/0x10 === Code: e8 fc 0e ea ff 8b 5e 4c eb 1b 8d 83 08 04 00 00 b9 06 00 02 00 ba 1d 00 00 00 e8 b5 df ee ff 8b 9b 10 04 00 00 81 eb 10 04 00 00 8b 83 10 04 00 00 0f 18 00 90 8d 93 10 04 00 00 8d 46 4c 39 c2 EIP: [c027552d] evdev_disconnect+0x87/0xae SS:ESP 0068:c1917e78 - Thanks for fix Michal ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [PATCH] v4l-dvb: add $DESTDIR support
On Fri, 9 Mar 2007, Ludwig Nussel wrote: This doesn't seem correct. Shouldn't it be: print OUT \t/sbin/depmod -a \$(KERNELRELEASE) \$(if \$(DESTDIR),-b \$(DESTDIR))\n\n; One needs to run depmod when the modules get installed to their final location. $DESTDIR is incomplete so it doesn't make sense to run depmod here already. When compiling an RPM package DESTDIR may not be the final location, but that is not the only reason one might want to use DESTDIR. One could repair a mounted root fs after booting from a rescue CD or be trying to create a bootable MythTV image. Also consider what would happen if someone tried to rebuild the rpm as root or another user who would write to /. The modules would be installed in the rpm buildroot, but depmod would be run on their system modules. If the kernel v4l-dvb is being built against isn't the one that is being run, then they'll get a new directory in /lib/modules when they build the rpm. Well, obviously noone cared about such exotic use cased yet. Anyways here a patch that adds your change as well, please apply. Patch applied. ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Problems with KNC1 DVB-C
Rudy Zijlstra wrote: hi all, On kernel 2.6.19.1 the KNC1 is working correctly. On 2.6.20.1 and 2.6.21-rc2 i get problems though, and the device is not fully loaded. I've attached the dmesg output. Anybody an idea how to progress? I have the feeling the i2c communicaton is not working correctly. How to solve this? Could you please test if it works again, if you replace SAA7146_USE_I2C_IRQ by SAA7146_I2C_SHORT_DELAY in budget-av.c? @all: Can someone confirm this problem with card type 1894:0021 (KNC1 DVB-C Plus)? Oliver -- VDR Remote Plugin 0.3.9 available at http://www.escape-edv.de/endriss/vdr/ ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [PATCH] dvb-core: Fix several locking related problems.
Johannes Stezenbach wrote: On Mon, Mar 05, 2007 at 06:19:01PM +0100, Oliver Endriss wrote: From 'Linux Device Drivers' (replace 'down' by 'mutex_lock'): | ... | down decrements the value of the semaphore and waits as long as need | be. down_ interruptible does the same, but the operation is | interruptible. The interruptible version is almost always the one you | will want; it allows a user-space process that is waiting on a | semaphore to be interrupted by the user. You do not, as a general | rule, want to use noninterruptible operations unless there truly is no ^^ | alternative. Noninterruptible operations are a good way to create ^^^ | unkillable processes (the dreaded D state seen in ps), and annoy | your users. Using down_interruptible requires some extra care, | however, if the operation is interrupted, the function returns a | nonzero value, and the caller does not hold the semaphore. Proper use | of down_interruptible requires always checking the return value and | responding accordingly. | ... I don't think this advice applies to mutexes (at least if the mutexes are used in the usual way to protect some common data). For event semaphores, you block waiting for an event, and if the event doesn't happen (maybe you wait for an irq), you need a way out or you're screwed. So using down_interruptible() is what you want. Mutexes, however, are supposed to be held only while manipulating some shared data. So the code looks *always* like this: mutex_lock(mtx); do_something_with_shared_data(); mutex_unlock(mtx); Now if some process sleeps uninterruptibly in mutex_lock(), some other process holds the mutex and sleeps in do_something(). If it wedges up, you either have some locking bug (someone forgot a mutex_unlock()), or it wedged up in do_something(), and you got to fix *that*. Well, your example is simple. Locking is easy if there is only one mutex involved. But there are a lot of mutexes/spinlocks/event semaphores in various layers of the subsystem. I simply cannot tell whether a deadlock may happen under some rare conditions or not... mutex_unlock_interruptible() would only help to paper over locking bugs, and its use in dvb-core comes from a straight conversion from down_interruptible(), which itself was used because it was once useful during development. How that the signal handling was found to be buggy I think it's much better to use mutex_lock() instead of fixing the mutex_unlock_interruptible() usage. BTW, some statistics: linux-2.6.20$ grep -r '\mutex_lock\' . | wc -l 3080 linux-2.6.20$ grep -r '\mutex_lock_interruptible\' . | wc -l 236 Ok, to make it short: Please proceed and apply this patch, or convert all occurrences of mutex_lock_interruptible() to mutex_lock() if you prefer. dvb_core is not my working area. ;-) Oliver -- VDR Remote Plugin 0.3.9 available at http://www.escape-edv.de/endriss/vdr/ ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [RFC] Reviewed development procedures DVBMaintainer
Hi all, I've been thinking hard the last days what I could possibly say that would make things better and not worse. Mission Impossible :-( I apologize in advance if I step on someone's toes. But I'm not going to point fingers at anyone as I think this isn't a single person's fault but more of a collective fuckup. On Fri, Mar 09, 2007, Markus Rechberger wrote: On 3/9/07, Steven Toth [EMAIL PROTECTED] wrote: I suspect the other person gave the best advice they could at the time. Maybe that advise is no longer true or valid. Either way, the person offered the best advise I suspect. Maybe in the future you should seek advise from multiple sources to validate any long term development approach. everyone is welcome to reply, but usually not too many participate here. Well, generally I have the impression that there is a lot of activity on linux-dvb. And just like you don't participate in _every_ thread, but just the ones which you are interested in, so is everyone else. No one participates in a discussion if - they don't get what it's all about - or they don't care about it - or they expect to be flamed or ignored Or the other way 'round, if you're interested in feedback: - explain the background so that _everyone_ can understand it, not just the core developers; if you can post patches instead of a description what the patches would look like, please do - show people why it is important _for them_ -- no one cares if it's only important for _you_ - be patient -- not everyone has time to fully dig into it right away, so the initial comments are likely to be superficial and/or just plain wrong; usually if you can show someone that their comment was wrong, they feel challenged to dig deeper into it to give you better comments; you must be careful not to hurt anyone's feelings, otherwise discussion stops pretty quickly Sounds like hard work? You bet it is! Likewise, the other developers have an obligation to review your ideas and discuss/describe the areas of concern, offering constructive feedback. It's unacceptable to refuse a colleagues patch and not offer any advise. I know this has NOT happened. I know alternatives were given to you. ... I suggest you stop the bickering and begin working with your Linux peers again, help us to find the right solution. sorry I'm getting pissed, for every approach I presented for now I had some code as well and it gets nacked without improvement suggestions. Also it has to be said that other hybrid implementations aren't well implemented and still need some improvement.. About one year ago there was exactly the same thing: Clash of opinions about how to integrate xc3028, and then a huge (and to me completely incomprehensible) fight followed. Apparently everyone involved was so fed up with it that they didn't want to touch the issue for a year, and now: - the issue is still unsolved (surprise!) - last year's fight still hangs over it like a dark cloud and prevents any useful discussion I have no clue about the technical issues of this proposal and can't comment on it, however I am convinced that the technical issues are minor compared to the problems in the social interaction between the developers. I've read through the irc log, and I couldn't help noticing: http://linuxtv.org/irc/linuxtv/index.php?date=2007-02-27 - Both mrec and mkrufky seemed to have predetermined expectations on the outcome of the discussion: - mrec: they'll NAK it anyway - mkrufky: he won't listen to anyone anyway - It seems mws made a reasonable effort to understand mrec's proposal, but most of the time mws and mrec are talking past each other, and are finally arriving at the conclusion that the other one is just too stupid to get it. Maybe a hint that irc is not an adequate medium for this kind of discussions? - mkrufky coolly watches the action, apparently satisfied to see his preconceptions confirmed; otherwise doesn't seem to want to help the issue at all Commentary: - Apparently irc sucks. I believe the mailing list is a much better medium for this kind of discussions. - The proposal posting sucked (according to my criteria from above). http://linuxtv.org/pipermail/linux-dvb/2007-February/016302.html Especially since Markus says on irc he has working code, I can't understand why he didn't just post the patches. Then there would have been no guesswork, everyone could've seen immediately how it works and what the consequences of this change are. - I cannot see any malicious behaviour in this. Sure Mike was pretty unhelpful, which I think was lame measured by the role he plays among the DVB developers. But in the light of last years xc3028 trouble I can understand that he doesn't have any incentive to help the issue. - I doubt Mike would block a technically flawless patch just because he doesn't like the author. If he tried to, he wouldn't succeed because I believe the other members of
[linux-dvb] Re: [PATCH] dvb-core: Fix several locking related problems.
On Sun, Mar 04, 2007 at 05:45:54PM +, Simon Arlott wrote:
Fix several instances of dvb-core functions using mutex_lock_interruptible
and returning -ERESTARTSYS where the calling function will either never
retry or never check the return value.
These cause a race condition with dvb_dmxdev_filter_free and
dvb_dvr_release, both of which are filesystem release functions whose
return value is ignored and will never be retried. When this happens it
becomes impossible to open dvr0 again (-EBUSY) since it has not been
released properly.
Signed-off-by: Simon Arlott [EMAIL PROTECTED]
Acked-By: Johannes Stezenbach [EMAIL PROTECTED]
I can't test this but to me it looks good.
Mauro, could you please pick it up and keep it in the
linuxtv.org repository for a while for testing?
Thanks,
Johannes
---
On 04/03/07 15:41, Andreas Oberritter wrote:
please send an updated patch together with
Signed-off-by line to Mauro [EMAIL PROTECTED] and ask him to apply
it for inclusion into the -mm tree for further testing.
Unless there are other -mm trees I've not heard about, presumably I should
just do this myself. Doesn't linux-dvb have it's own development tree this
would get better tested in?
The dvb_dvr_release change has been working for me for 6 months and the
dvb_dmxdev_filter_free (dvb_dmxdev_filter_free) change looks equivalent.
See http://www.linuxtv.org/pipermail/linux-dvb/2007-February/016120.html
for an example of the bug before and after fixing.
All the other changes run ok for me but should have lockdep enabled when
testing (if there's a possible deadlock somewhere, using _interruptible
will hide it).
drivers/media/dvb/dvb-core/dmxdev.c| 12 +++-
drivers/media/dvb/dvb-core/dvb_demux.c | 21 +++--
drivers/media/dvb/dvb-core/dvbdev.c|9 +++--
3 files changed, 13 insertions(+), 29 deletions(-)
diff --git a/drivers/media/dvb/dvb-core/dmxdev.c
b/drivers/media/dvb/dvb-core/dmxdev.c
index fc77de4..a5c0e1a 100644
--- a/drivers/media/dvb/dvb-core/dmxdev.c
+++ b/drivers/media/dvb/dvb-core/dmxdev.c
@@ -180,8 +180,7 @@ static int dvb_dvr_release(struct inode *inode, struct
file *file)
struct dvb_device *dvbdev = file-private_data;
struct dmxdev *dmxdev = dvbdev-priv;
- if (mutex_lock_interruptible(dmxdev-mutex))
- return -ERESTARTSYS;
+ mutex_lock(dmxdev-mutex);
if ((file-f_flags O_ACCMODE) == O_WRONLY) {
dmxdev-demux-disconnect_frontend(dmxdev-demux);
@@ -673,13 +672,8 @@ static int dvb_demux_open(struct inode *inode, struct
file *file)
static int dvb_dmxdev_filter_free(struct dmxdev *dmxdev,
struct dmxdev_filter *dmxdevfilter)
{
- if (mutex_lock_interruptible(dmxdev-mutex))
- return -ERESTARTSYS;
-
- if (mutex_lock_interruptible(dmxdevfilter-mutex)) {
- mutex_unlock(dmxdev-mutex);
- return -ERESTARTSYS;
- }
+ mutex_lock(dmxdev-mutex);
+ mutex_lock(dmxdevfilter-mutex);
dvb_dmxdev_filter_stop(dmxdevfilter);
dvb_dmxdev_filter_reset(dmxdevfilter);
diff --git a/drivers/media/dvb/dvb-core/dvb_demux.c
b/drivers/media/dvb/dvb-core/dvb_demux.c
index fcff5ea..6d8d1c3 100644
--- a/drivers/media/dvb/dvb-core/dvb_demux.c
+++ b/drivers/media/dvb/dvb-core/dvb_demux.c
@@ -673,8 +673,7 @@ static int dmx_ts_feed_stop_filtering(struct
dmx_ts_feed *ts_feed)
struct dvb_demux *demux = feed-demux;
int ret;
- if (mutex_lock_interruptible(demux-mutex))
- return -ERESTARTSYS;
+ mutex_lock(demux-mutex);
if (feed-state DMX_STATE_GO) {
mutex_unlock(demux-mutex);
@@ -748,8 +747,7 @@ static int dvbdmx_release_ts_feed(struct dmx_demux *dmx,
struct dvb_demux *demux = (struct dvb_demux *)dmx;
struct dvb_demux_feed *feed = (struct dvb_demux_feed *)ts_feed;
- if (mutex_lock_interruptible(demux-mutex))
- return -ERESTARTSYS;
+ mutex_lock(demux-mutex);
if (feed-state == DMX_STATE_FREE) {
mutex_unlock(demux-mutex);
@@ -916,8 +914,7 @@ static int dmx_section_feed_stop_filtering(struct
dmx_section_feed *feed)
struct dvb_demux *dvbdmx = dvbdmxfeed-demux;
int ret;
- if (mutex_lock_interruptible(dvbdmx-mutex))
- return -ERESTARTSYS;
+ mutex_lock(dvbdmx-mutex);
if (!dvbdmx-stop_feed) {
mutex_unlock(dvbdmx-mutex);
@@ -942,8 +939,7 @@ static int dmx_section_feed_release_filter(struct
dmx_section_feed *feed,
struct dvb_demux_feed *dvbdmxfeed = (struct dvb_demux_feed *)feed;
struct dvb_demux *dvbdmx = dvbdmxfeed-demux;
- if (mutex_lock_interruptible(dvbdmx-mutex))
- return -ERESTARTSYS;
+ mutex_lock(dvbdmx-mutex);
if (dvbdmxfilter-feed != dvbdmxfeed) {
mutex_unlock(dvbdmx-mutex);
@@ -1016,8 +1012,7 @@ static int
[linux-dvb] usbreplay seg fault
hi, usbreplay seg faults playing back all of my usbsnoop.log - chrome tmp # ./usbreplay analyzed.log Segmentation fault - Im parsing them with parser.pl perl parserl.pl usbsnoop.log analyzed.log im using x86_64 environment. however it segfaults under a i686 environment aswell. please let me know what i can do to get this working, Im on irc at the moment. regards julian (sunru) ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] usbreplay seg fault
Hi, On 3/10/07, Julian [EMAIL PROTECTED] wrote: hi, usbreplay seg faults playing back all of my usbsnoop.log - chrome tmp # ./usbreplay analyzed.log Segmentation fault - Im parsing them with parser.pl perl parserl.pl usbsnoop.log analyzed.log im using x86_64 environment. however it segfaults under a i686 environment aswell. please let me know what i can do to get this working, Im on irc at the moment. as answered in irc, I separated usbreplay from the v4l-dvb package since its an own project which should get some extra attention. the sourcecode is available at: http://mcentral.de/hg/~mrec/usbreplay try to debug that tool with gdb. The bug will very likely be a.) no access to your usb bus or b.) no device attached or c.) some allocation didn't work out I didn't spend too much time on that tool it just satisfied my needs for now. Patches and/or traces are welcome. Markus regards julian (sunru) ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb -- Markus Rechberger ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] revised initial tuning data for au-Melbourne
Hi, I'm not certain exactly what should be in dvb-apps-2e83ebcb51de/util/scan/dvb-t/au-Melbourne but things work better if channel 7's guard interval is changed. With the tarball I downloaded a few days ago scan au-Melbourne temp does not put anything into temp about channel 7, after changing the guard interval output for channel 7 is also put into temp. The exact same temp file is created if the last six fields of each line in au-Melbourne is changed to AUTO. Strangely, a lot of tuning failed messages went to standard error with all of the input files; original, changed GI, and six fields of AUTO. My tuner is an MSI [EMAIL PROTECTED] A/D PCI card -lspci -s 05:07 05:07.0 Multimedia controller: Philips Semiconductors SAA7133/SAA7135 Video Broadcast Decoder (rev d1) -lspci -s 05:07 -n 05:07.0 0480: 1131:7133 (rev d1) It is a hybrid LifeView LR306 clone. -- sig goes here... Peter D. # Australia / Melbourne (Mt Dandenong transmitters) # T freq bw fec_hi fec_lo mod transmission-mode guard-interval hierarchy # ABC T 22650 7MHz 3/4 NONE QAM64 8k 1/16 NONE # Seven T 17750 7MHz 2/3 NONE QAM64 8k 1/16 NONE # Nine T 191625000 7MHz 3/4 NONE QAM64 8k 1/16 NONE # Ten T 21950 7MHz 3/4 NONE QAM64 8k 1/16 NONE # SBS T 536625000 7MHz 2/3 NONE QAM64 8k 1/8 NONE # Australia / Melbourne (Mt Dandenong transmitters) # T freq bw fec_hi fec_lo mod transmission-mode guard-interval hierarchy # ABC T 22650 7MHz AUTO AUTO AUTO AUTO AUTO AUTO # Seven T 17750 7MHz AUTO AUTO AUTO AUTO AUTO AUTO # Nine T 191625000 7MHz AUTO AUTO AUTO AUTO AUTO AUTO # Ten T 21950 7MHz AUTO AUTO AUTO AUTO AUTO AUTO # SBS T 536625000 7MHz AUTO AUTO AUTO AUTO AUTO AUTO ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
