[Freevo-users] IVTV-record bugs and problems
Hi, I'm trying to set freevo with a pvr350 card using the IVTV record plugin. DEBUG=1 is set in the local_config. I'm using the freevo and mmpython cvs version on gentoo. python 2.3.3 This is the first error I get when using the ivtv record plugin : 2004/07/06 18:25 CEST [*RecordServer*] vnorm: PAL 2004/07/06 18:25 CEST [*RecordServer*] Setting Input to 4 2004/07/06 18:25 CEST [*RecordServer*] Setting Channel to E9 2004/07/06 18:25 CEST [*RecordServer*] USING STANDARD FREQUENCY: chan=E9, freq=203250 2004/07/06 18:25 CEST [*RecordServer*] Video Opened at /dev/video1 2004/07/06 18:25 CEST [*RecordServer*] Exception in thread Thread-1: 2004/07/06 18:25 CEST [*RecordServer*] Traceback (most recent call last): 2004/07/06 18:25 CEST [*RecordServer*] File /usr/lib/python2.3/threading.py, line 436, in __bootstrap 2004/07/06 18:25 CEST [*RecordServer*] self.run() 2004/07/06 18:25 CEST [*RecordServer*] File /usr/lib/python2.3/site-packages/freevo/tv/plugins/ivtv_record.py, line 197, in run 2004/07/06 18:25 CEST [*RecordServer*] if DEBUG: v.print_settings() 2004/07/06 18:25 CEST [*RecordServer*] File /usr/lib/python2.3/site-packages/freevo/tv/ivtv.py, line 146, in print_settings 2004/07/06 18:25 CEST [*RecordServer*] tv.v4l2.Videodev.print_settings(self)2004/07/06 18:25 CEST [*RecordServer*] File /usr/lib/python2.3/site-packages/freevo/tv/v4l2.py, line 314, in print_settings 2004/07/06 18:25 CEST [*RecordServer*] print 'Driver: %s' % self.driver 2004/07/06 18:25 CEST [*RecordServer*] File /usr/lib/python2.3/site-packages/twisted/python/log.py, line 307, in write 2004/07/06 18:25 CEST [*RecordServer*] d = (self.buf + data).split('\n') 2004/07/06 18:25 CEST [*RecordServer*] UnicodeDecodeError: 'ascii' codec can't decode byte 0xc4 in position 13: ordinal not in range(128) 2004/07/06 18:25 CEST [*RecordServer*] in v4l2.py there are some print statements and I get a Unidecode error when setting these ptint statements in comment I can go on. The second problem is NTSC = PAL. I am a pal user, ivtv driver is installed correctly I can capture without problems when I do cat /dev/video1 somefile.mpg The result is a 720x576 mpeg file with sound. My pvr350 card is /dev/video1, /dev/video0 is a from the dvb card that isn't configured in freevo at the moment. When capturing with freevo I get a 720x480 mpeg file. This are some lines from my local_config file -- TV_REC_SIZE = (720, 576) TV_RECORD_DIR = '/usr/local/freevo/record' TV_RECORDFILE_MASK = '%%m-%%d %%Hh%%M %(progname)s' TV_SETTINGS = 'PAL 4 europe-east /dev/video1' IVTV_OPTIONS = { 'input' : 4, 'resolution': '720x576', 'aspect': 3, 'audio_bitmask' : 233, 'bframes' : 3, 'bitrate_mode' : 1, 'bitrate' : 400, 'bitrate_peak' : 800, 'dnr_mode' : 0, 'dnr_spatial' : 0, 'dnr_temporal' : 0, 'dnr_type' : 0, 'framerate' : 0, 'framespergop' : 15, 'gop_closure' : 1, 'pulldown' : 0, 'stream_type' : 10 } VIDEO_GROUPS = [ VideoGroup(vdev=/dev/video1, adev=None, input_num=4, tuner_norm=CONF.tv, tuner_chanlist=CONF.chanlist, desc='Cable', group_type=ivtv, recordable=True), ] - When looking at the kernel messages I see the ivtv size changes when recording with freevo. I added an extra print statement to see that the vnorm the recordserver gets is PAL, here is the recordserver log file : -- 2004/07/06 18:35 CEST [*RecordServer*] vnorm: PAL 2004/07/06 18:35 CEST [*RecordServer*] Setting Input to 4 2004/07/06 18:35 CEST [*RecordServer*] Setting Channel to E9 2004/07/06 18:35 CEST [*RecordServer*] USING STANDARD FREQUENCY: chan=E9, freq=203250 2004/07/06 18:35 CEST [*RecordServer*] Video Opened at /dev/video1 2004/07/06 18:35 CEST [*RecordServer*] Enumerating supported Standards. 2004/07/06 18:35 CEST [*RecordServer*] 0: 0x3000 NTSC 2004/07/06 18:35 CEST [*RecordServer*] 1: 0xff PAL 2004/07/06 18:35 CEST [*RecordServer*] 2: 0x7f SECAM 2004/07/06 18:35 CEST [*RecordServer*] Current Standard is: 0xff 2004/07/06 18:35 CEST [*RecordServer*] Enumerating supported Inputs. 2004/07/06 18:35 CEST [*RecordServer*] 0: Composite 0 2004/07/06 18:35 CEST [*RecordServer*] 1: Composite 1 2004/07/06 18:35 CEST [*RecordServer*] 2: Composite 2 2004/07/06 18:35 CEST [*RecordServer*] 3: Composite 3 2004/07/06 18:35 CEST [*RecordServer*] 4: Tuner 0 2004/07/06 18:35 CEST [*RecordServer*] 5: Composite 4 2004/07/06 18:35 CEST [*RecordServer*] 6: S-Video 0 2004/07/06 18:35 CEST [*RecordServer*] 7: S-Video 1 2004/07/06 18:35 CEST [*RecordServer*] 8: S-Video 2
Re: [Freevo-users] IVTV-record bugs and problems
Bart Heremans wrote: Hi, Hi, I'm trying to set freevo with a pvr350 card using the IVTV record plugin. DEBUG=1 is set in the local_config. I'm using the freevo and mmpython cvs version on gentoo. python 2.3.3 This is the first error I get when using the ivtv record plugin : 2004/07/06 18:25 CEST [*RecordServer*] vnorm: PAL 2004/07/06 18:25 CEST [*RecordServer*] Setting Input to 4 2004/07/06 18:25 CEST [*RecordServer*] Setting Channel to E9 2004/07/06 18:25 CEST [*RecordServer*] USING STANDARD FREQUENCY: chan=E9, freq=203250 2004/07/06 18:25 CEST [*RecordServer*] Video Opened at /dev/video1 2004/07/06 18:25 CEST [*RecordServer*] Exception in thread Thread-1: 2004/07/06 18:25 CEST [*RecordServer*] Traceback (most recent call last): 2004/07/06 18:25 CEST [*RecordServer*] File /usr/lib/python2.3/threading.py, line 436, in __bootstrap 2004/07/06 18:25 CEST [*RecordServer*] self.run() 2004/07/06 18:25 CEST [*RecordServer*] File /usr/lib/python2.3/site-packages/freevo/tv/plugins/ivtv_record.py, line 197, in run 2004/07/06 18:25 CEST [*RecordServer*] if DEBUG: v.print_settings() 2004/07/06 18:25 CEST [*RecordServer*] File /usr/lib/python2.3/site-packages/freevo/tv/ivtv.py, line 146, in print_settings 2004/07/06 18:25 CEST [*RecordServer*] tv.v4l2.Videodev.print_settings(self)2004/07/06 18:25 CEST [*RecordServer*] File /usr/lib/python2.3/site-packages/freevo/tv/v4l2.py, line 314, in print_settings 2004/07/06 18:25 CEST [*RecordServer*] print 'Driver: %s' % self.driver 2004/07/06 18:25 CEST [*RecordServer*] File /usr/lib/python2.3/site-packages/twisted/python/log.py, line 307, in write 2004/07/06 18:25 CEST [*RecordServer*] d = (self.buf + data).split('\n') 2004/07/06 18:25 CEST [*RecordServer*] UnicodeDecodeError: 'ascii' codec can't decode byte 0xc4 in position 13: ordinal not in range(128) 2004/07/06 18:25 CEST [*RecordServer*] in v4l2.py there are some print statements and I get a Unidecode error when setting these ptint statements in comment I can go on. I am using a PVR-250 and started having the same problem a while ago after updating my driver. Which version of ivtv are you using? I tried messing around with Unicode and String objects but nothing really worked for me. I was beginning to think that the driver is returning bad data or the interface has changed. I ultimately ended up commenting those prints out (Driver, Card, Version). The second problem is NTSC = PAL. I am a pal user, ivtv driver is installed correctly I can capture without problems when I do cat /dev/video1 somefile.mpg The result is a 720x576 mpeg file with sound. My pvr350 card is /dev/video1, /dev/video0 is a from the dvb card that isn't configured in freevo at the moment. When capturing with freevo I get a 720x480 mpeg file. This are some lines from my local_config file -- TV_REC_SIZE = (720, 576) Hmm, I think TV_REC_SIZE may be ignored by the ivtv code. IVTV_OPTIONS = { ... 'resolution': '720x576', ... } ... 2004/07/06 18:35 CEST [*RecordServer*] Width: 720, Height: 480 -- So the video standard is correct but the resolution is incorrect. AM I missing something ? I don't think you're missing anything. Maybe the setCodec interface hace changed slightly, the explicit set to '720x576' fails and it defaults back to NTSC resolution? I should have a chance to take a closer look a bit later. -Rob --- This SF.Net email sponsored by Black Hat Briefings Training. Attend Black Hat Briefings Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com ___ Freevo-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freevo-users
Re: [Freevo-users] IVTV-record bugs and problems
On Tue, 2004-07-06 at 16:16 -0300, Rob Shortt wrote: I am using a PVR-250 and started having the same problem a while ago after updating my driver. Which version of ivtv are you using? I tried messing around with Unicode and String objects but nothing really worked for me. I was beginning to think that the driver is returning bad data or the interface has changed. I ultimately ended up commenting those prints out (Driver, Card, Version). I'm using one with Chris Kennedys IVTV patches http://kmos.org/~ckennedy/ivtv/ : ivtv-0.1.10-pre2-ck98p.tgz TV_REC_SIZE = (720, 576) Hmm, I think TV_REC_SIZE may be ignored by the ivtv code. I thaught so, was just to be sure I don't think you're missing anything. Maybe the setCodec interface hace changed slightly, the explicit set to '720x576' fails and it defaults back to NTSC resolution? I should have a chance to take a closer look a bit later. -Rob Thanks, maybe I will use another driver if I find one that works well with 2.6 kernel, 0.1.9 won't compile And another question, is it possible with the video groups to use more than one tuner, a searched the mailing list but don't really know how to set it up. there are three tuners in the pc 1) dvb-s haupage nexus 2) pvr350 3) bttv didn't really try more than one at the moment because I'm already stuck with the pvr350. (I got in wortking some months ago in my pc, now it is in my brothers). the bttv card was working well alone, never used the dbv-s card with freevo. --- This SF.Net email sponsored by Black Hat Briefings Training. Attend Black Hat Briefings Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com ___ Freevo-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freevo-users
Re: [Freevo-users] IVTV-record bugs and problems
Hi, ck ivtv patches are outputting this info when passing a ioctl QUERYCAP_ST on the video device. Driver: ivtvrÎàâÒÍó¼Ä Card: Vanilla iTVC15 card qÎâ[À Version: 266 Capabilities: 17236019 Enumerating supported Standards. 0: 0x3000 NTSC 1: 0xff PAL 2: 0x7f SECAM In v4l2.py QUERYCAP_ST is defined like this. QUERYCAP_ST = 16s32s32sLL16x QUERYCAP_NO = _IOR('V', 0, QUERYCAP_ST) Not sure what to make of this mumbo jumbo ;-) Rob can you explain what you are trying to do here with 16s32s32sLL16x ? Willing to help if you got some pointers. Bart, if you set DEBUG to 0 it doesn't try to print out the QUERYCAP ioctl output and all should work as excpected. /Robert Tuesday, July 6, 2004, 6:31:21 PM, Bart wrote: On Tue, 2004-07-06 at 16:16 -0300, Rob Shortt wrote: I am using a PVR-250 and started having the same problem a while ago after updating my driver. Which version of ivtv are you using? I tried messing around with Unicode and String objects but nothing really worked for me. I was beginning to think that the driver is returning bad data or the interface has changed. I ultimately ended up commenting those prints out (Driver, Card, Version). I'm using one with Chris Kennedys IVTV patches http://kmos.org/~ckennedy/ivtv/ : ivtv-0.1.10-pre2-ck98p.tgz TV_REC_SIZE = (720, 576) Hmm, I think TV_REC_SIZE may be ignored by the ivtv code. I thaught so, was just to be sure I don't think you're missing anything. Maybe the setCodec interface hace changed slightly, the explicit set to '720x576' fails and it defaults back to NTSC resolution? I should have a chance to take a closer look a bit later. -Rob Thanks, maybe I will use another driver if I find one that works well with 2.6 kernel, 0.1.9 won't compile And another question, is it possible with the video groups to use more than one tuner, a searched the mailing list but don't really know how to set it up. there are three tuners in the pc 1) dvb-s haupage nexus 2) pvr350 3) bttv didn't really try more than one at the moment because I'm already stuck with the pvr350. (I got in wortking some months ago in my pc, now it is in my brothers). the bttv card was working well alone, never used the dbv-s card with freevo. --- This SF.Net email sponsored by Black Hat Briefings Training. Attend Black Hat Briefings Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com ___ Freevo-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freevo-users --- This SF.Net email sponsored by Black Hat Briefings Training. Attend Black Hat Briefings Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com ___ Freevo-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freevo-users
Re: [Freevo-users] IVTV-record bugs and problems
Robert Winder wrote: Driver: ivtvrÎàâÒÍó¼Ä Card: Vanilla iTVC15 card qÎâ[À Yeah, that junk's causing problems. QUERYCAP_ST = 16s32s32sLL16x QUERYCAP_NO = _IOR('V', 0, QUERYCAP_ST) Not sure what to make of this mumbo jumbo ;-) Rob can you explain what you are trying to do here with 16s32s32sLL16x ? Willing to help if you got some pointers. Heh. Ok, start by reading: http://www.python.org/doc/2.3.4/lib/module-struct.html We need to turn the results of the QUERYCAP_NO (really a hex number) driver ioctl call into something python and understands. def querycap(self): val = struct.pack( QUERYCAP_ST, , , , 0, 0 ) r = fcntl.ioctl(self.device, long(QUERYCAP_NO), val) return struct.unpack( QUERYCAP_ST, r ) That function gives us a list returned by the ioctl. Also note in the struct pack line: , , , 0, 0; a string, string, string, int, int. Well in C these tyles are more complec, and from reading the v4l header file you can see the struct returned has members like 16 char array, 2 - 32 char arrays, 2 - unsigned longs, and 16 bytes of padding. Ok, so this one probably doesn't ring a bell now because I just remembered Thomas was the one who made this file, and I think that was based on another project, so, perhaps the interface has changed. Maybe someone should review the v4l or ivtv header files and compare all the struct packing/unpacking. I will take a peek later perhaps but atm I'm a bit busy. -Rob --- This SF.Net email sponsored by Black Hat Briefings Training. Attend Black Hat Briefings Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com ___ Freevo-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freevo-users