Canadian TV, Computing and Home Theatre Forums banner

Mythtv

76K views 397 replies 31 participants last post by  mwalma 
#1 ·
Mythtv has announced version 0.22 release candidate 1 is now available. Hopefully all goes well and a stable 0.22 will come out shortly.

The release notes are here.
 
#332 ·
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.

Code:
[    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
 
#335 ·
Sorry ClgShaft, I had some inet problems...

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... :p

(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? :p ).

Have a nice day!

Nick
 
#334 ·
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.

Code:
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
 
#336 ·
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.
 
#341 ·
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.
 
#337 ·
(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
 
#338 ·
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).
 
#340 ·
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):
Code:
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:
Code:
$ /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
Code:
# /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.
 
#342 ·
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
 
#343 ·
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.
 
#345 ·
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.
 
#346 ·
ClgShaft, the crash you get is in the code that talks to the firmware, not in the firmware itself (IIRC your problem is in saa7164-bus, this appears to be code that establish a communication zone with the firmware).

While it is possible that this could be caused by a bug in the firmware I would suspect the driver.

shadowlordkt, he has an udev rule that tries to map the tuners of two different cards to the same symlink, I don't know how gracefully udev handles that...

[The udev rule in question is derived from an udev rule I have for my own HVR-2250 (which surprisingly had a different ID) and depends on the fact that there is only one card of each type.]

stampeder. the firmware is OK AFAIK and works fine if there's only one HVR-2250 in the pc...

Best bet to get to the bottom of this would be to post on the #linuxtv channel on freenode, post on the Linux media mailing list or try to contact Steven Toth through his blog on Kernellabs.

Have a nice day,

Nick
 
#347 ·
Hey guys,

I defined sone better input groups last night and no crashes through the night.

I would like to add one or two digital cable boxes via svideo. Does anyone have a dummy guide to lirc? I have already done yum install lirc.

On the 2250 can I control one or two cable boxes?

Thanks
 
#348 ·
I have to admit; I have zero-experience with IR blasters, as my Shaw/DCT-6200 cable box is controlled via firewire.

However, the Hauppauge's product page for the HVR-2250 says:

WinTV-HVR-2250 now supports an on-board IR receiver and blaster, which can control up to two external set top boxes.
http://www.hauppauge.com/site/products/data_hvr2250.html

Historically, Hauppauge's products have been Linux-friendly, but I don't know if anyone has the HVR-2250 IR blaster working in Linux (yet).
 
#349 ·
Hey guys,

I followed the lirc setup from here

I then googled dct700 channel change script and created the dct700 file in /etc/lirc/ and edited /etc/lirc/lircd, file did not exist, and of course created the channel change script in /usr/local/bin

When the channel change script is in the backend I get no signal lock, and permission denied error on the log. I tried chmod +x to the channel change script.

What did I miss or where did I go wrong?

Thanks
 
#350 ·
I now have an error that says that my blaster does not allow sending.

I have lirc, lirc remote, lirc libs, and lirc Dev installed.

The mce wiki I cannot make by following their steps.

I can get the hardware.conf to output my stb info, but can't test.

I have the dct700 info in lircd.conf

Thanks
 
#351 ·
HELP!!! :eek:

As described in the Help me Build New HTPC thread, I bought a new motherboard, CPU and RAM for my Myth box and am keeping my existing case/psu, video card, tuner card and hard drive.

My old box was a Pendum D (805) with 512 MB of RAM

I replaced it with a Gigabyte GA-880GM-UD2H, AMD Athlon II X2 (245e) and a matched pair of Kingston 1GB DDR3 DIMs (2GB total).

For reference, my video card is a fanless NVIDIA 9500GT and I am running MythBuntu 10.10

On the weekend I swapped out the mobo/CPU/RAM and when I went to boot the new system, everything just hung and I ended up with a console login prompt. At first I was getting the message "Too Many Connections" but a quick Google showed that the problem was likely with HD audio. I couldn't find a Bias setting to turn it off (the manual said to use a software tool) so I disabled the on-board audio as a test and the message went away, but it still wouldn't boot properly.

I figured since I am using the same video card and it is the only proprietary driver, I shouldn't need to re-install MythBuntu. Is this a bad assumption? If I need to do a re-install, what is the best way to go about it to avoid loosing my existing recordings (I wish I had separate boot and data drives)?

If you need more info, tell me what you want and I will try and get it. If I can't get it fixed soon, I may have to throw the old mobo back in to keep my wife happy.

Thanks for your help.
 
#352 ·
Roger,
Since you get to a prompt, I would guess X isn't starting correctly.
Look for errors (lines starting with) EE in Xorg.0.log in /var/log/. That should give you some hints. kern.log or dmesg might provide some useful info as well.
I assume you've disabled the onboard video in the bios, or at least set it to use your video card first.

You shouldn't have to do a reinstall. But if you do, backup your database,http://www.mythtv.org/wiki/Database_Backup_and_Restore copy your recordings to some other media, and then if you have to start from scratch again, you can.
 
#353 ·
roger1818:

Obviously opinions differ. Personally, I would not attempt to change the motherboard in a system without reinstalling Linux. I think Linux does some hardware autodetection upon installation and configures the OS to suit the specific components on the old motherboard.

However, if you follow vejostde's advice on copying your recordings to another HDD and backing up your database, a reformat/reinstall should go pretty smoothly.
 
#355 ·
Thanks vejostde. I will have a look at that tonight.

Yes, I did disable the on-board video in the BIOS (though I did forget at first).

Silly me forgot to do a database backup before starting this process, so it looks like there is more than one reason to put the old mobo back in tonight (preferably in time to record the Bachelorette tonight for my wife or else I am really in the dog house). And I also need to cut the grass ;). Sounds like a busy night.
 
#356 ·
Before swapping back my old mobo last night (which I did successfully and on time ;)), I captured the error files suggested by vejostde. The Error lines in the Xorg.0.log are as follows:

Code:
[    22.017] (EE) NVIDIA(0): Failed to initialize the NVIDIA graphics device PCI:1:0:0. 
[    22.017] (EE) NVIDIA(0):     Please check your system's kernel log for additional error
[    22.017] (EE) NVIDIA(0):     messages and refer to Chapter 8: Common Problems in the
[    22.017] (EE) NVIDIA(0):     README for additional information.
[    22.017] (EE) NVIDIA(0): Failed to initialize the NVIDIA graphics device!
[    22.017] (EE) Screen(s) found, but none have a usable configuration.
so it looks like it the proprietary video driver is having troubles. Maybe I should have switched to the open source driver before doing the swap.

The entire kern.log is a bit big to post here, but here is the last bit where it is trying to load the video driver.

Code:
May 30 18:03:31 MythTv2 kernel: [   16.699148] nvidia: module license 'NVIDIA' taints kernel.
May 30 18:03:31 MythTv2 kernel: [   16.699152] Disabling lock debugging due to kernel taint
May 30 18:03:31 MythTv2 kernel: [   16.952519] cx18-alsa: module loading...
May 30 18:03:31 MythTv2 kernel: [   17.112290] nvidia 0000:01:00.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18
May 30 18:03:31 MythTv2 kernel: [   17.112299] nvidia 0000:01:00.0: setting latency timer to 64
May 30 18:03:31 MythTv2 kernel: [   17.112305] vgaarb: device changed decodes: PCI:0000:01:00.0,olddecodes=io+mem,decodes=none:owns=io+mem
May 30 18:03:31 MythTv2 kernel: [   17.112776] NVRM: loading NVIDIA UNIX x86 Kernel Module  260.19.06  Mon Sep 13 06:35:06 PDT 2010
May 30 18:03:31 MythTv2 kernel: [   17.150676] cx18-0: loaded v4l-cx23418-cpu.fw firmware (158332 bytes)
May 30 18:03:32 MythTv2 kernel: [   17.455168] cx18-0: loaded v4l-cx23418-apu.fw firmware V00120000 (141200 bytes)
May 30 18:03:32 MythTv2 kernel: [   17.461534] cx18-0: FW version: 0.0.74.0 (Release 2007/03/12)
May 30 18:03:32 MythTv2 kernel: [   17.590398] type=1400 audit(1306793012.368:10): apparmor="STATUS" operation="profile_replace" name="/sbin/dhclient3" pid=1040 comm="apparmor_parser"
May 30 18:03:32 MythTv2 kernel: [   17.590602] type=1400 audit(1306793012.368:11): apparmor="STATUS" operation="profile_replace" name="/usr/lib/NetworkManager/nm-dhcp-client.action" pid=1040 comm="apparmor_parser"
May 30 18:03:32 MythTv2 kernel: [   17.850883] r8169 0000:02:00.0: eth1: link up
May 30 18:03:32 MythTv2 kernel: [   17.850890] r8169 0000:02:00.0: eth1: link up
May 30 18:03:33 MythTv2 kernel: [   18.433614] cx18-0 843: loaded v4l-cx23418-dig.fw firmware (16382 bytes)
May 30 18:03:33 MythTv2 kernel: [   18.463885] cx18-0 843: verified load of v4l-cx23418-dig.fw firmware (16382 bytes)
May 30 18:03:33 MythTv2 kernel: [   18.727521] svc: failed to register lockdv1 RPC service (errno 97).
May 30 18:03:33 MythTv2 kernel: [   18.728151] NFSD: Using /var/lib/nfs/v4recovery as the NFSv4 state recovery directory
May 30 18:03:33 MythTv2 kernel: [   18.728328] NFSD: starting 90-second grace period
May 30 18:03:36 MythTv2 kernel: [   21.703374] alloc_vmap_area: 15 callbacks suppressed
May 30 18:03:36 MythTv2 kernel: [   21.703377] vmap allocation for size 16781312 failed: use vmalloc=<size> to increase size.
May 30 18:03:36 MythTv2 kernel: [   21.704099] NVRM: failed to map registers!!
May 30 18:03:36 MythTv2 kernel: [   21.704101] NVRM: RmInitAdapter failed! (0x10:0x32:1311)
May 30 18:03:36 MythTv2 kernel: [   21.704105] NVRM: rm_init_adapter(0) failed
May 30 18:03:36 MythTv2 kernel: [   22.016214] vmap allocation for size 16781312 failed: use vmalloc=<size> to increase size.
May 30 18:03:36 MythTv2 kernel: [   22.016946] NVRM: failed to map registers!!
May 30 18:03:36 MythTv2 kernel: [   22.016948] NVRM: RmInitAdapter failed! (0x10:0x32:1311)
May 30 18:03:36 MythTv2 kernel: [   22.016952] NVRM: rm_init_adapter(0) failed
May 30 18:03:36 MythTv2 kernel: [   22.076462] vmap allocation for size 16781312 failed: use vmalloc=<size> to increase size.
May 30 18:03:36 MythTv2 kernel: [   22.077186] NVRM: failed to map registers!!
May 30 18:03:36 MythTv2 kernel: [   22.077188] NVRM: RmInitAdapter failed! (0x10:0x32:1311)
May 30 18:03:36 MythTv2 kernel: [   22.077191] NVRM: rm_init_adapter(0) failed
May 30 18:03:36 MythTv2 kernel: [   22.137757] vmap allocation for size 16781312 failed: use vmalloc=<size> to increase size.
May 30 18:03:36 MythTv2 kernel: [   22.138465] NVRM: failed to map registers!!
May 30 18:03:36 MythTv2 kernel: [   22.138468] NVRM: RmInitAdapter failed! (0x10:0x32:1311)
May 30 18:03:36 MythTv2 kernel: [   22.138471] NVRM: rm_init_adapter(0) failed
May 30 18:03:36 MythTv2 kernel: [   22.198336] vmap allocation for size 16781312 failed: use vmalloc=<size> to increase size.
May 30 18:03:36 MythTv2 kernel: [   22.199047] NVRM: failed to map registers!!
May 30 18:03:36 MythTv2 kernel: [   22.199050] NVRM: RmInitAdapter failed! (0x10:0x32:1311)
May 30 18:03:36 MythTv2 kernel: [   22.199053] NVRM: rm_init_adapter(0) failed
May 30 18:03:36 MythTv2 kernel: [   22.258573] vmap allocation for size 16781312 failed: use vmalloc=<size> to increase size.
May 30 18:03:36 MythTv2 kernel: [   22.259282] NVRM: failed to map registers!!
May 30 18:03:36 MythTv2 kernel: [   22.259284] NVRM: RmInitAdapter failed! (0x10:0x32:1311)
May 30 18:03:36 MythTv2 kernel: [   22.259287] NVRM: rm_init_adapter(0) failed
May 30 18:03:36 MythTv2 kernel: [   22.318957] vmap allocation for size 16781312 failed: use vmalloc=<size> to increase size.
May 30 18:03:36 MythTv2 kernel: [   22.319688] NVRM: failed to map registers!!
May 30 18:03:36 MythTv2 kernel: [   22.319690] NVRM: RmInitAdapter failed! (0x10:0x32:1311)
May 30 18:03:36 MythTv2 kernel: [   22.319694] NVRM: rm_init_adapter(0) failed
May 30 18:03:39 MythTv2 kernel: [   25.929514] EXT4-fs (sda1): re-mounted. Opts: errors=remount-ro,commit=0
May 30 18:03:42 MythTv2 kernel: [   28.272047] eth1: no IPv6 routers present
May 30 18:06:29 MythTv2 kernel: [  195.740278] CE: hpet increased min_delta_ns to 7500 nsec
May 30 18:07:02 MythTv2 kernel: [  228.560280] CE: hpet increased min_delta_ns to 11250 nsec
Not sure what to make of that. I also have the dmesg file, but it doesn't seem to have anything useful in it and it is also too big to post. If you want it let me know.

Some interesting notes.
  • It seems as though the backend started OK as it recorded a couple programs (one analog and one digital on my HVR1600), so that is a good sign.
  • MythWeb couldn't talk to the backend though (the web page came up partially with the error).
  • I was able to connect via SSH.

And I was even able to cut the grass afterwords. :)
 
#358 ·
If I remember correctly it was "Unable to connect to the master backend at 127.0.0.1:6543."

The backend definitely was running though as it did successfully record a couple programs. According to this wiki, it could be a SELinux issue (does MythBuntu use SELinux?).

I am not terribly worried if I don't get MythWeb up and running right away. Since the backend is working, my top priority is to get the frontend working.
 
#359 ·
roger,

This line might indicate your problem.
vmap allocation for size 16781312 failed: use vmalloc=<size> to increase size.

Google found this. Where someone had a similar issue.
http://forums.gentoo.org/viewtopic-t-772151.html

And here's a ubuntu specific post for adding that info to your boot line in grub.
http://ubuntuforums.org/showthread.php?t=1539709

kern.log basically holds a copy of what dmesg reported, so either one should provide the info you need.

Hope this helps,
Josh
 
#360 ·
Thank you! That is very helpful!!! Doing more research on this it seems to be a common problem when using both the CX18 driver (needed for the HVR-1600) and the NVIDIA proprietary driver.

I wonder if this could have been the problem I had when trying to upgrade the RAM on my old motherboard (I tried going from 512MB to 1GB and it would no longer boot). I am just not sure why increasing the RAM would cause it to run out of virtual addressing space though. :confused:

One other curiosity is this wiki says "If your 32-bit machine has 1Gb or less of RAM the Linux kernel reserves a minimum of 128Mb for virtual memory addressing (if you have more RAM, it may have reserved slightly more--256Mb at 2GB I think)." yet my machine seems to only have 16Mb. :confused:

Oh well, at least I know know the way forward. I wonder if I can find a hole in the recording schedule to night to try again?
 
This is an older thread, you may not receive a response, and could be reviving an old thread. Please consider creating a new thread.
Top