Mythtv

[shadowlordkt]

Originally Posted by stampeder

I don't appreciate that choice of words, particularly since you probably don't know me. I'll say it again - I could do all that with udev rules, but this seemed easier and is just as effective. I have something that works just fine so I haven't bothered with udev rules, nor should anyone have to if they want to do what I did. Use udev if you like, but I don't feel like it.

My sincerest apologies to stampeder. I've been reading your posts for so long and didn't mean to offend. I've seen people on other forums/lists reluctant to use udev as well, so I did not mean to refer to you specifically (although reading my post back it definitely sounds that way -- sorry!).


Anyway, the thing about udev that I like is that every time I've used it, it's a matter of running one command, generating a one-liner text file for each device and then rebooting to test. I'm not an expert on Linux nor MythTV; but if anyone wants help with udev, let me know. I'll do my best.

[ClgShaft]

hey guys,

progress is still being made, I have two 950q's working now, needed something since the 1600 is not working.

here is a copy of dmesg. there is a vmalloc fix for 32 bit, cannot find anything for 64 bit to fix the issue.

[    6.682807] cx18:  Start initialization, version 1.4.0
[    6.682998] cx18-0: Initializing card 0
[    6.683015] cx18-0: Autodetected Hauppauge card
[    6.683142]   alloc irq_desc for 20 on node 0
[    6.683144]   alloc kstat_irqs on node 0
[    6.683154] cx18 0000:04:06.0: PCI INT A -> GSI 20 (level, low) -> IRQ 20
[    6.683163] cx18-0: Unreasonably low latency timer, setting to 64 (was 32)
[    6.688192] cx18-0: cx23418 revision 01010000 (B)
[    6.732365] [drm] Initialized drm 1.1.0 20060810
[    6.919418] tveeprom 0-0050: Hauppauge model 74351, rev F1F5, serial# 7367012
[    6.919422] tveeprom 0-0050: MAC address is 00:0d:fe:70:69:64
[    6.919424] tveeprom 0-0050: tuner model is NXP 18271C2 (idx 155, type 54)
[    6.919426] tveeprom 0-0050: TV standards PAL(B/G) NTSC(M) PAL(I) SECAM(L/L') PAL(D/D1/K) ATSC/DVB Digital (eeprom 0xfc)
[    6.919429] tveeprom 0-0050: audio processor is CX23418 (idx 38)
[    6.919430] tveeprom 0-0050: decoder processor is CX23418 (idx 31)
[    6.919433] tveeprom 0-0050: has no radio
[    6.919434] cx18-0: Autodetected Hauppauge HVR-1600
[    6.919436] cx18-0: Simultaneous Digital and Analog TV capture supported
[    7.001147] au0828: i2c bus registered
[    7.041353] nvidia: module license 'NVIDIA' taints kernel.
[    7.041356] Disabling lock debugging due to kernel taint
[    7.472094] tveeprom 2-0050: Hauppauge model 72001, rev B3F0, serial# 4768233
[    7.472097] tveeprom 2-0050: MAC address is 00:0d:fe:48:c1:e9
[    7.472100] tveeprom 2-0050: tuner model is Xceive XC5000 (idx 150, type 76)
[    7.472102] tveeprom 2-0050: TV standards NTSC(M) ATSC/DVB Digital (eeprom 0x88)
[    7.472104] tveeprom 2-0050: audio processor is AU8522 (idx 44)
[    7.472105] tveeprom 2-0050: decoder processor is AU8522 (idx 42)
[    7.472107] tveeprom 2-0050: has no radio, has IR receiver, has no IR transmitter
[    7.472109] hauppauge_eeprom: hauppauge eeprom: model=72001
[    7.698531] nvidia 0000:01:00.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18
[    7.698540] nvidia 0000:01:00.0: setting latency timer to 64
[    7.698544] vgaarb: device changed decodes: PCI:0000:01:00.0,olddecodes=io+mem,decodes=none:owns=io+mem
[    7.698774] NVRM: loading NVIDIA UNIX x86_64 Kernel Module  260.19.29  Wed Dec  8 12:08:56 PST 2010
[    7.700407] cs5345 0-004c: chip found @ 0x98 (cx18 i2c driver #0-0)
[    7.705370] cx18-0: Registered device video0 for encoder MPEG (64 x 32.00 kB)
[    7.705373] DVB: registering new adapter (cx18)
[    7.759257] au8522 2-0047: creating new instance
[    7.759259] au8522_decoder creating new instance...
[    7.763138] tuner 2-0061: chip found @ 0xc2 (au0828)
[    7.774073] cx18-0: frontend initialization failed
[    7.774220] cx18-0: DVB failed to register
[    7.774253] cx18-0: Registered device video32 for encoder YUV (20 x 101.25 kB)
[    7.774272] cx18-0: Registered device vbi0 for encoder VBI (20 x 51984 bytes)
[    7.774295] cx18-0: Registered device video24 for encoder PCM audio (256 x 4.00 kB)
[    7.774645] cx18-0: Error -1 registering devices
[    7.777117] cx18-0: Error -1 on initialization
[    7.777133] cx18: probe of 0000:04:06.0 failed with error -1
[    7.777160] cx18:  End initialization

something to do with allocating enough memory. i have also read the issue could be with the 1600 and nvidia.

thanks

[Knight]

Sorry for not replying earlier guys, I did not have time last weeks and I had inet problems for the last couple of days...

Originally Posted by stampeder

I'm not enthused about learning how to write in udev rule syntax (I had enough of that for one lifetime with Sendmail administration over the years!)

Ouch! I played with it somewhat but I much prefer Postfix...

I could do all that with udev rules, but this seemed easier and is just as effective.

Thanks! That's certainly an interesting solution to enforce a specific load order of each module.

Thank you!

Nick

[Knight]

Unfortunately, the codes can vary from one piece of hardware to the next.

I actually have a few udev rules that works pretty nicely for the cards I have (or had) in my backend (PVR-150, PVR-500, HVR-2250, etc...) which work pretty nicely but they depend on the fact that I only have one of each (they identify the cards using things which are specific to those cards but not a specific card.

If you can paste the results of the following command, I can try to write the rule for you. To save space, only paste the block which refers to HVR-950.

udevadm info -a -p $(udevadm info -q path -n /dev/dvb/adapter0/dvr0)

Thanks but it's not for me, it's for ClgShaft which sometimes have a problem with the loading order of his cards...

Have a nice day!

Nick

[Knight]

Sorry ClgShaft, I had some inet problems...

Originally Posted by ClgShaft

hey guys,

progress is still being made, I have two 950q's working now, needed something since the 1600 is not working.

Ouch, don't say you weren't warned...

(Some devs don't like this card since the analog part of it is a frame grabber...)

something to do with allocating enough memory. i have also read the issue could be with the 1600 and nvidia.

Not sure that's actually a memory issue, only Andy Walls or Hans Verkuil could probably easily say for sure...

I noticed you logged on yesterday on IRC on the #mythtv-users channels at around the same times Andy Walls was on the #linuxtv channel. Funny thing is he was helping somebody else with (other) HVR-1600 issues...

I can't say I like what he said, it looks like the most recent drivers have issues with kernels below 2.6.37 so if it's a driver issue it looks like you might have to wait until Fedora has a 2.6.37 kernel (unless you want to compile you own? ).

Have a nice day!

Nick

[stampeder]

I don't have a patch to submit but I've always wished mythsetup on the backend gave the administrator the choice during tuner device installation to force a chosen loading order of the devices. That would either require an internal MythTV solution similar to my script or else the ability for MythTV to supercede or write udev and other hardware administration automation rules.

[Knight]

(hmm, I thought I had replied to this but it looks like I didn't...)

Stampeder you could always make a feature request (for now it's still a wiki page but a switch to something better is being considered...).

I have my doubt that something tightly integrated to MythTV would be done though as it would make porting to other platforms even more difficult than it currently is (and a lot of effort both by devs and non-devs have been put in it in recent years).

Funny thing is that some of these cards have actually serial numbers and/or MAC addresses (yep...) that could be used to uniquely identify them.

I think the v4l/dvb guys would be in a much better position to add support for this (or at least support it in their API so that other apps, such as MythTV, could use it).

Have a nice day!

Nick

[DHR]

Stampeder: I have a bunch of identical tuners in one of my boxes (HVR-1600's). I'm running MythBuntu 10.04 LTS. I found a solution that works for me, even if it isn't as easy as I'd like.

The key observation is that somebody (v4l?) adds symlinks in /dev that allow you to address a tuner card by PCI slot! Try the command "ls -l /dev/v4l/by-path". On my machine, I get:

lrwxrwxrwx 1 root root 12 2011-01-28 16:56 pci-0000:01:04.0-video-index0 -> ../../video1
lrwxrwxrwx 1 root root 13 2011-01-28 16:56 pci-0000:01:04.0-video-index1 -> ../../video33
lrwxrwxrwx 1 root root 10 2011-01-28 16:56 pci-0000:01:04.0-video-index2 -> ../../vbi1
lrwxrwxrwx 1 root root 13 2011-01-28 16:56 pci-0000:01:04.0-video-index3 -> ../../video25
lrwxrwxrwx 1 root root 12 2011-01-28 16:56 pci-0000:01:05.0-video-index0 -> ../../video2
lrwxrwxrwx 1 root root 13 2011-01-28 16:56 pci-0000:01:05.0-video-index1 -> ../../video34
lrwxrwxrwx 1 root root 10 2011-01-28 16:56 pci-0000:01:05.0-video-index2 -> ../../vbi2
lrwxrwxrwx 1 root root 13 2011-01-28 16:56 pci-0000:01:05.0-video-index3 -> ../../video26
lrwxrwxrwx 1 root root 12 2011-01-28 16:56 pci-0000:01:06.0-video-index0 -> ../../video0
lrwxrwxrwx 1 root root 13 2011-01-28 16:56 pci-0000:01:06.0-video-index1 -> ../../video32
lrwxrwxrwx 1 root root 10 2011-01-28 16:56 pci-0000:01:06.0-video-index2 -> ../../vbi0
lrwxrwxrwx 1 root root 13 2011-01-28 16:56 pci-0000:01:06.0-video-index3 -> ../../video24

When I use mythtv-setup to setup the tuners, it automatically gives me /dev/videoX as options but I manually type in the longer path /dev/v4l/by-path/... This gives me a stable binding to a particular card (slot).

[stampeder]

DHR the `ls -l /dev/v4l/by-path` string gives a listing of the analogue side of the tuner devices, while /dev/dvb shows the digital devices that I have needed to enforce a loading order upon. I don't have any problems with how my 2 ivtv analogue devices are loading.

[DHR]

Originally Posted by stampeder

DHR the `ls -l /dev/v4l/by-path` string gives a listing of the analogue side of the tuner devices, while /dev/dvb shows the digital devices that I have needed to enforce a loading order upon.

I see. That's inconvenient.

The /dev/vv4l/by-path links seem to be built by /lib/udev/rules.d/60-persistent-v4l.rules.

I don't actually understand those rules. In particular, what this does isn't clear (/lib/udev/v4l_id is undocumented):

IMPORT{program}="v4l_id $tempnode"

I would guess that it sets some of the $env variables.

Still, it might be a starting point.

I tried /lib/udev/v4l_id by hand. I don't immediately see how adding these definitions to the environment would have an effect:

$ /lib/udev/v4l_id /dev/video0 
ID_V4L_VERSION=2
ID_V4L_PRODUCT=Hauppauge HVR-1600
ID_V4L_CAPABILITIES=:capture:audio:tuner:radio:

/lib/udev/path_id's behaviour isn't clear

# /lib/udev/path_id /dev/dvb/adapter0/demux0
unable to access '/dev/dvb/adapter0/demux0'

There are (poor) manpages path_id(8) and udev(7). path_id(8) doesn't seem to be installed on my system but Google finds it. "apt-file search /usr/share/man/man8/path_id.8.gz" yields nothing.

[shadowlordkt]

Originally Posted by stampeder

I don't have a patch to submit but I've always wished mythsetup on the backend gave the administrator the choice during tuner device installation to force a chosen loading order of the devices. That would either require an internal MythTV solution similar to my script or else the ability for MythTV to supercede or write udev and other hardware administration automation rules.

MythTV generally tries to keep itself isolated from the Operating System level stuff like this. The devs would probably say something along the lines of udev does that job already. From what I have seen over my many years of using MythTV is that they roll out support for the latest devices pretty quickly, and one way that is achieved is by taking a hands-off approach to dealing hardware drivers. If someone else writes Linux driver comes for it; and can get it to work, MythTV hooks into it pretty quickly.

If anyone remembers the old IVTV days when users first started using PVR-500s alongside PVR-250s and bttv -- it was pretty difficult to get MythTV to accept patches for certain hardware specific issues; since the preferred solution was to resolve the issue at the OS level.

However, maybe forced-loading-order like what Stampeder suggested could be put into something at the distro level (Mythbuntu, Mythdora). That's probably where one could get the most acceptance.

[ClgShaft]

Hey guys,

Been a while, thread is on page two.

I still have not be able to run two different or similar tuner cards on the same backend. I have tried the 950q x 2, 2250, and 1600. The 1600 and 950 have been complete failures, the 2250 works for both digitL and analog. The issue I am getting now Is with using 2 2250's. If I have both working, if I watch anything on the newer one it crashes the kernel, the saa7164 crashes the kernel. If I use just one if them, no issues, it is only if both are setup on the backend.

Anyone know how to fix? Do I need a udev rule?

Anyone have a good guide to setup lirc for a digital cable box?

Thanks

[shadowlordkt]

Kernel crashes are frequently caused by poorly-written hardware drivers. In that case, udev rules are not likely to be of any assistance, unless the wrong signal is being sent to the wrong tuner.

Do the tv tuners work simultaneously outside of MythTV? Unfortunately, I'm don't know which Linux-based TV tuning program are available. Way back when, I used tvtime with analog cards.

[ClgShaft]

The kernel crash is directly related to the saa7164 2250 fw. I don't have anything else to try the tuner cards with, I just use mythtv.

[stampeder]

The easiest way to see what is going on is to rename the firmware file so that when the driver's call for it is made it cannot be loaded, and then reboot the machine. Check dmesg output to see that the firmware load failed as expected. If it shows that everything kept running after it could not find the firmware then you have found the smoking gun. At that point if you really want to be sure, use rmmod to remove the driver, rename the firmware to it's original name, and use modprobe to reload the driver (which will call and load the firmware). Does the kernel crash if you do it that way? If so, the firmware file is probably corrupted so I'd delete it and download it again for retesting. If it keeps happening after that then I'd be wondering if it is the correct firmware file for those cards.