PVR-150 on 6-STABLE: success and mini HOWTO

[Danny Pansters]

On Friday 21 December 2007 00:36:34 User Mat wrote:
> On Dec 20, usleepless at gmail.com wrote:
> > Hi Danny, Mat,
> >
> > ...
> >
> > as the author of the pvrxxx version of the pvr250 driver, i have been
> > reading along.
>
>     Did you see the my patch in the previous message to get pvrxxx to
>     compile on -current?
>
> > Danny, thanks for your mini howto, and it is nice to read it was
> > pretty straightforward for you.
> >
> > i noticed a couple of things:
> >
> > 1. some version of mythtv fails to probe the inputs. this needs to be
> > investigated: there is a problem with the v4l(2)-header-files, or the
> > v4l(2) api actually changed ( i seem to recall something about his ).
> > i would like to know the exact version of mythtv which fails to probe
> > the inputs.
>
>      mythtv-0.20.2.tar.bz2 built outside of the ports tree with a few
>      patches from the port and one or two local hacks.
>
>      It's the probing and setting of inputs that failing.  The
>      following log snippets are from mythtv after I faked out some
>      routine that matches probed inputs to the values in database --
>      before the hack, it could read the names so it returned 0 avail
>      inputs thus not capture.
>
> from mythbackend
>
> 2007-12-20 17:55:54.189 Connected to database 'mythconverg' at host:
> localhost 2007-12-20 17:55:54.210 Could not query inputs.
>                         eno: Inappropriate ioctl for device (25)
> 2007-12-20 17:55:54.211 Channel(/dev/cxm0): SetInputAndFormat() failed
> 2007-12-20 17:55:54.212 Channel(/dev/cxm0): SetInputAndFormat() failed
> 2007-12-20 17:55:54.212 TVRec(1) Error: Setting start channel '66' failed,
>                         and backup '1' failed as well.
> 2007-12-20 17:55:54.218 New DB scheduler connection
>
> from ktrace -di mythbackend
>
>  28476 initial thread CALL  open(0x2afb0b60,O_RDWR,<unused>0)
>  28476 initial thread NAMI  "/dev/cxm0"
>  28476 initial thread RET   open 4
>  28476 initial thread CALL  ioctl(0x4,0x40685600 ,0xbfbfdefc)
>  28476 initial thread RET   ioctl 0
>  28476 initial thread CALL  ioctl(0x4,0x40685600 ,0xbfbfdeb8)
>  28476 initial thread RET   ioctl 0
>  28476 initial thread CALL  gettimeofday(0xbfbfd8e8,0)
>  28476 initial thread RET   gettimeofday 0
>
> ...
>
>  28476 initial thread CALL  ioctl(0x4,0x40685600 ,0xbfbfdb1c)
>  28476 initial thread RET   ioctl 0
>  28476 initial thread CALL  ioctl(0x4,0xc04c561a ,0xbfbfdc98)
>  28476 initial thread RET   ioctl -1 errno 25 Inappropriate ioctl for
> device 28476 initial thread CALL  ioctl(0x4,0x403c7601 ,0xbfbfdce4)
>  28476 initial thread RET   ioctl -1 errno 25 Inappropriate ioctl for
> device
>
> > 2. the driver is not designed for multiple reading. however, it must
> > be able to be opened more than once because the tuner is not a
> > separate device. this makes tuning while watching possible.
>
>     I wonder if one can open a device for neither reading or writing,
>     only IOCTLs?  Anyway, I've panic'ed my machine several times
>     because of this.
>
> > 3. switching back from svhs is not possible?
>
>     I not clear on the question.  Switching to the tuner after
>     switching to svideo/composite does not work.
>     'pvr250-setchannel -m 1'  will also panic my machine.
>
> > 4. supporting tvtime and other linux tv-viewers is on my wishlist too:
> > a v4l(2) compatible reading api needs to be implemented.
> >
> > 5. i experimented with the "3:2 pulldown" flag of the encoder. i think
> > the current driver mistakenly enables 3:2 pulldown. fixing this will
> > improve fast moving scenes ( sports ) and sliding texts.
>
>     A question to all: Given an infinite amount of CPU what is the
>     best possible deinterlacing strategy/filter for mplayer?

What I posted. Plus it's very low on cpu here (HW acc via nvidia helps of 
course):

last pid: 16657;  load averages:  0.16,  0.16,  0.15   up 1+05:56:41  01:11:02
97 processes:  2 running, 95 sleeping
CPU states: 13.2% user,  0.4% nice,  1.5% system,  2.0% interrupt, 82.9% idle
Mem: 373M Active, 367M Inact, 188M Wired, 53M Cache, 111M Buf, 9080K Free
Swap: 2048M Total, 4K Used, 2048M Free

  PID USERNAME    THR PRI NICE   SIZE    RES STATE    TIME   WCPU COMMAND
 1006 danny         1  96    0 71988K 58392K select  22:53  0.39% Xorg
 1089 danny         1  96    0 31772K 21320K select   7:27  0.10% kdeinit
15835 danny         3  98    0 43048K 31020K RUN     25:14  0.00% mplayer
 1094 danny         1  96    0 27780K 17328K select   8:52  0.00% kdeinit
13833 danny         1  96    0   120M   108M select   2:06  0.00% kdeinit
 1088 danny         3  20  -76 13280K  7980K kserel   2:05  0.00% artsd
15882 danny         1 106   10 39576K 19468K select   1:25  0.00% npviewer.bin
 1068 danny         1  96    0 37616K 26624K select   1:24  0.00% kdeinit
15917 danny         3  20    0 61004K 47528K kserel   1:04  0.00% kmail
  832 root          1  96    0  2860K  1236K select   0:35  0.00% hald-addon-s
 1080 danny         1  96    0 32020K 21760K select   0:27  0.00% kdeinit
 1076 danny         1  96    0 27484K 17056K select   0:25  0.00% kdeinit
  808 mysql         5  20    0 57308K 24544K kserel   0:23  0.00% mysqld
15836 danny         1   8    0 35660K 25588K nanslp   0:22  0.00% mplayer

BTW, it's been running for several hours now, and no audio stutter yet, it 
gobbles a bit if I do something that appears to require a lot of resources 
relative to the processes running  (such as de-iconifying/minimizing kmail -- 
gasp) but then happily plays on.

And the image on smaller window sizes (e.g. 320x240) is good too now, no 
more "movement stripes" or -- at certain sizes which seem to be 
multiples/divides of the usual SDTV sizes -- what seems like a resonance 
effect causing very notable "waves" in the picture which may last for seconds 
(same as on bktr).

Dan

Dan