Got the backend up and running. I am in the process of reinstalling my front-end machine too..
One question...
Am I the ONLY person who has CONSTANT problems with burning CDs that machines can't read? I burned a CD from 3 different machines (2 different media types) before I got one that my backend would read. Now, I put that in the front-end and I get errors! So, I burned another (4th one!) from my front-end's drive (4th machine!) and it wouldn't even verify!!! WTF??
God, this is driving me insane...
The video card in my front-end died, so I had to steal the video card from the back end, which defaulted it to the on-board ATI video. Since I wasn't using the front-end part of my back-end machine, this wasn't too big of a deal. The problem is that this shuffled IRQs around and stuff. Now, I can't things to work right 1/2 the time.
If you remember (I'm personifying the ZERO readers that are reading this), I already didn't have stuff working on boot, so I run a couple of scripts to get stuff to work. Well, that has really stopped working completely (and gotten really OLD).
So, sometime really soon, I am going to reinstall my backend machine and switch from SuSE 9.1 to Ubuntu 6.06 (Dapper Drake). There are so many changes in the OS support for things, I hope this works out well.
Now, I need to find info on HD3000 and PVR500s in Dapper...
*crossing fingers*
0.19 upgrade:
I waited a bit to even approach the 0.19 upgrade. I was seeing a bunch of issues in the mailing list, so I decided to wait. Now, things seem OK, so I decided to look into it.
I had been planning on upgrading the OS of my backend machine, because I was told a long time ago that the V4L drivers for the HD3000 cards would not be supported under Myth anymore. Well, to my great surprise, support is still there. So, I should still be able to run with the same OS and kernel version.
So, I downloaded the 0.19 code (not SVN, but the 0.19 tar files). When I went to compile, I received an error which stated:
/usr/X11R6/lib/libXvMCNVIDIA.so: undefined reference to `XvGetPortAttribute'After a quick google, I found a message from 2003 that said to:
In settings.pro, change the line:
EXTRA_LIBS += -lXvMCNVIDIA -lXvMC
to:
EXTRA_LIBS += -lXvMCNVIDIA -lXvMC -lXv
well, it's done a little differently now.
I edited my settings.pro and found a section that looked like this:
EXTRA_LIBS += $$LOCAL_LIBDIR_OGL
EXTRA_LIBS += $$LOCAL_LIBDIR_X11
EXTRA_LIBS += $$CONFIG_XV_LIBS
EXTRA_LIBS += $$CONFIG_XRANDR_LIBS
EXTRA_LIBS += $$CONFIG_XVMC_LIBS
EXTRA_LIBS += $$CONFIG_OPENGL_VSYNC_LIBS
So, I changed it to this:
EXTRA_LIBS += $$LOCAL_LIBDIR_OGL
EXTRA_LIBS += $$LOCAL_LIBDIR_X11
EXTRA_LIBS += $$CONFIG_XV_LIBS
EXTRA_LIBS += $$CONFIG_XRANDR_LIBS
EXTRA_LIBS += $$CONFIG_XVMC_LIBS
EXTRA_LIBS += $$CONFIG_OPENGL_VSYNC_LIBS
EXTRA_LIBS += $$CONFIG_XV_LIBS
Note the extra XV entry. This causes -lXv to be added both before and after the -lXvMC. This worked for me.
Also note that this only happened on my backend machine and not my front end... Very strange.
Now I have to backup my database and upgrade. Stay tuned...
UPDATE: I ran into the same problem with the mythplugins compile. Same solution worked.
UPDATE: Everything was relatively smooth. I still ran into
this problem, but, since I blogged it, I could fix it quickly.
I also ran into an old problem that I never blogged. On SUSE 9.1, I guess the Xmu library is not in the right (?) place. So, for mythmusic and mythgallery, I have to add "-L/usr/X11R6/lib" to the "LIBS" line in their Makefiles. This fixes an issue with not finding "-lXmu".
Now, I just have to figure out all the new stuff. Netflix integration!?
So... I just dusted off this blog, since I was absent for so long. This meant that things were working fine. I'm watching more TV than ever and things are mostly working fine. I don't like weather interference with my HD stuff, but otherwise, things are pretty good.
I am about to do a couple things:
1) upgrade mythtv to 0.19
2) upgrade ivtv to the latest version (I'm still on 0.3.2.z!)
I will post about these separately soon
My IR keyboard is having some problems.
Occasionally, it repeats the last key I hit about 10 times unless I hit
another key to interrupt it. It's like the keyboard buffer isn't
flushing properly or something.
It's either a driver issue or the infrared receiver part of the
hardware, since the same problem happens with my universal remote too.
Hopefully I'll figure out what's happening. I'd hate to have to set up lircd now...
T
Update: I figured out that this seems somewhat related to the
other light in the room. I had the IR receiver a little off
(pointed in the wrong direction) and the lights were bright. I
reoriented the receiver and things haven't seemed to happen as often at
all (like once every 10 days or more now). So, I think it was
just an issue with direction of the IR signal bouncing around or being
diffused by the light in the room (it also seemed to happen more when
the overhead lights were on).
I didn't realize this, but I did not have alsa set up correctly.
I was using OSS emulation for my AC3 passthrough in myth tv and it worked fine. I just assumed alsa was working properly.
I found out because ogle couldn't pass through DD/DTS at all.
So, I finally dug up the info that I needed this in my /etc/asound.conf file (entire contents):
# Redefine the default device to S/PDIF
pcm.!default {
type plug
slave.pcm "hw:0,1"
}
ctl.!default {
type hw
card 0
}
# Xine doesn't use the "default" device for S/PDIF but this:
pcm.!iec958 {
type plug
slave.pcm "hw:0,1"
}
ctl.!iec958 {
type hw
card 0
}
That did the trick. Now, I'm getting DD/DTS passthrough to my optical spdif, which kicks ass.
T
Getting
Direct Input Codes for Programming Universal
Remote Controls
For those of you looking to
bypass NetCommand and
utilize another universal remote, here's the procedure to get the Mitsubishi remote
control
to transmit
the
direct
input IR
codes for
the TV (worked for a 55813 and a 65909).
1.
To get the Mitsubishi remote control into Direct
Input IR mode, while
holding down the Power button, press
0, 9, 0.
2. To emit the direct input IR code:
*press
the Device rocker button,
*then press one of the following keys corresponding
to the input you want:
Input
1 = 1
Input 2 = 2
Input 3 = 3
Input 4 = 4
Component Input 1 = 5
Component Input 2 = 6
DTV Input = PIP DEV
Monitor Link/DVI = SQV
VGA = QV
Ant A = PIP+
Ant B = PIP-
Ant DTV = PIP/POP
3. To get the Mitsubishi remote control back
to Normal mode, while holding down the Power button, press 9, 3, 5.
I've been running 960x540p for a long time. It is a nice resolution, but HDTV is true 1920x1080i resolution.
So, I decided to try it again (failed previously). I decide to pull out the big guns and use
Powerstrip
to find the right settings. I must say that Powerstrip
rocks. I followed
Mark Rejhon' excellent guide to detect the right modes
on Windows (brought another box down) and it even gives you the XF86
Modelines for what you're doing.
So, I copied all the modelines over to my front-end... and it didn't work. This is what I got:
It's supposed to look like this...
It's supposed to look like this...
--------------------------
| |
| |
| |
| |
| Left Right |
| |
| |
| |
--------------------------
It looks like this....
--------------------------
||
||
||
||
Right || Left
||
||
||
--------------------------
The whole image is scrolled around.
After hours and various incarnations of configuration, including using
the exact same card in my Windows 2000 box, I still had no
progress. Until now. I just found a post that says that
this is a known issue with "newer versions" of nVidia drivers and only
happens in 1080i modes. That makes me want to kill somebody :)
So, now I'm going to try downgrading my drivers and see if I can find one that won't exhibit this issue.
T
Update: I downgraded to 1.0.6629 and it works like a
charm. I had to go back to Windows one more time to tweak, but
it's working now. SWEET!
Update 2: Well, trying to change video modes to "Zoom", which is
trying to take a 4:3 recording with a 16:9 letterboxed image to full
screen, the bottom 1/6 or so of the screen flickers too much to
watch. This is annoying
Update 3:
Here's my XF86Config file
I have a Mitsubishi WS-65909 TV (rear projection CRT 65" HDTV - Diamond series).
So, when I first installed my MythTV boxes, I wanted to
connect the PC to my TV. I noticed that it didn't have DVI
(grrr). I did notice, however that it had VGA (SCORE!).
Then, I noticed that the jack said "640x480" on it. That
sucked. I looked in the manual and it said that it only supports
640x480@60Hz. That was pretty annoying. So, my only choice
was to get the video into the HD Component video input. So, I
bought an
Audio Authority 9a60
so that I could convert the RGBHV signal in the VGA cable to Component
video. So, I played with modelines and everything I could find on
the Net and found out that I could get 960x540 working, but nothing
else. I still had pretty bad overscan, but it looked great, so I went
with it.
When I finally got it all going, I realized that I could
have just bought (or made) an RGBHV breakout cable, because the TV
supports that too (grr). Oh well... no sense buying something else.
Anyway, since I decided to mess with getting the res higher (to 1920x1080i), I was messing around searching on
AVS Forum
and stumbled across someone mentioning the 640x480 limit on the
Mitsubishi televisions. I was thinking to myself "man, that's
pretty lame to support a VGA connector and only support that".
Then, a reply to the post caught my eye. It said that there were
no restrictions on it. They lied.
They LIED. I never doubted the label and the
manual, but it was a lie. I connected the VGA connector to my
MythTV front-end directly (bypassing the AA 9a60) and it
WORKED FINE! Those rotten lying bastards! I wasted > $100 on something I did NOT need to buy.
I realize that they were covering their asses because, if
you just hook up a high refresh rate monitor-like resolution to the TV,
you could probably hurt the TV, but they could have pointed out that
the only
supported resolution is 640x480 and say that it can
support higher resolutions on devices designed to do ATSC signals or
whatever they need to say. They should have just let me know it
was possible.
Anyway,
Ebay, here we come.
T
I am having this error in the Myth backend when I try to delete
2005-06-29 09:54:03.705 /dev/video32 ringbuf avg 0.266425% max 1.40625% samples 143346
2005-06-29 10:02:58.321 /dev/video32 ringbuf avg 0.266155% max 1.40625% samples 143526
2005-06-29 10:04:28.231 Error: offset>181, pes length & current can not be queried
2005-06-29 10:11:52.703 /dev/video32 ringbuf avg 0.26628% max 1.59375% samples 143461
2005-06-29 10:15:53.427 Error: offset>181, pes length & current can not be queried
2005-06-29 10:16:49.475 Error: offset>181, pes length & current can not be queried
2005-06-29 10:20:49.215 /dev/video32 ringbuf avg 0.265448% max 1.875% samples 144034
I have no idea what the deal is... I might just upgrade because it's been a long time.
T
I was having problems with shows showing up as 0 length. I decided to see if upgrading MythTV would work for me.
Once
I upgraded, I was getting lots of issues. The front end is frequently
getting a timeout talking to the backend trying to do almost anything.
The backend spits out "joined null on WriteStringList" and the front
end then locks up.
I thought it was the processor-specific optimizations so I rebuilt and retried.... nothing.
Now,
the weird thing is, I tried running the other front end (same machine
as the backend) and it worked fine. SO, it's just my front-end machine.
So,
I figured... I downloaded the code to the backend... built there... did
a "make distclean" and then transferred the directory over to the front
end. MAYBE the make distclean doesn't clean everything up and there's
some remnant from the other machine that's breaking things. So, I'm
trying to get CVS latest directly from the Front end now (am going to
tar it up first thing).
I'll keep posting so that all (zero) of you can read on :)
Update:
It was preview image generation!!! I had enabled that for fun (hadn't
had it enabled for some reason) and apparently there was a bug in it.
Someone else had the same problem and I saw a dev list posting... He
tracked it down better than I did... yay!
I forgot... on my front-end machine, I get these errors compiling:
metaioid3v2.cpp:443: error: `id3_frame_delete' undeclared (first use this function)
metaioid3v2.cpp: In member function `bool MetaIOID3v2::setComment(id3_tag*, const char*, QString, QString)':
metaioid3v2.cpp:532: error: `id3_frame_new' undeclared (first use this function)
metaioid3v2.cpp:540: error: `id3_frame_delete' undeclared (first use this function)
metaioid3v2.cpp:547: error: `id3_utf8_ucs4duplicate' undeclared (first use this function)
make[2]: *** [metaioid3v2.o] Error 1
I
found out that I have 2 id3tag.h files, so I went into metaioid3v2.h
and changed its include statement for this file to hard code to
"/usr/include/id3tag.h" so that it picks up the right one.
I have no idea why I have 2 of them, but this is what I'm doing now.
T
Wired News: Court Nixes 'Broadcast Flag'I had
[FIX THIS LINK] previously ranted about this topic and can only assume that it was my outburst that swayed the courts in this matter. You're welcome ;)
I'm so psyched about this. I am just waiting for their next tactic... Probably lobbying congress right now.
I'm having a big issue with zero length recordings lately...
Multiple
recordings per day will come up 0 length... it happens immediately.. as
soon as the recording starts, it stays at 0 length, but the card stays
in "recording" state until the end of the show. It really sucks.
I looked in the dmesg output and I see lots of stuff like this:
__ide_do_rw_disk - bad command: dev hda: flags = REQ_RW REQ_NOMERGE REQ_STARTED
REQ_BLOCK_PC
sector 658632, nr/cnr 0/0
bio 00000000, biotail 00000000, buffer 00000000, data 00000000, len 0
cdb: 1b 00 00 00 03 00 00 00 00 00 00 00 00 00 00 00
That could have something to do with it.
So,
right now, I'm downloading a kernel patch from SUSE (whatever the
latest one will be) and hoping that it solves the problem. Also, I
think I might run fsck or whatever the equivalent is for the filesystem
I have (can't remember which one it is right now... xfs?)
Anyway, I'll update when there's a fix.
SO, I took out the old bttv card and put in the PVR-500... I
downloaded the latest ivtv driver (0.3.2z) and tried to compile it. I
got this:
/home/tom/tmp/ivtv-0.3.2z/driver/msp3400.c:131: error: parse error before "int"
/home/tom/tmp/ivtv-0.3.2z/driver/msp3400.c:131: warning: type defaults to `int' in declaration of `module_param'
/home/tom/tmp/ivtv-0.3.2z/driver/msp3400.c:131: warning: function declaration isn't a prototype
/home/tom/tmp/ivtv-0.3.2z/driver/msp3400.c:131: warning: data definition has no type or storage class
....
I
have found many people online that have had this issue, yet I can't
find the solution to the issue. Nobody's responding on the #ivtv-dev
IRC channel either.
Well, time to try emailing the dev list.
Update: - I manually forced all the code to use the "old" way of doing module_param calls, and it seems to be OK now. Stay tuned.
Update:
- I spent most of the day working on that, and it turns out that my
manual code changes caused most of my problems. Right now, I have
s-video input working on both inputs but the audio is just crackly.
Unfortunately, I took a crack at getting the HD3000 cards working and
it didn't work at all :( I'll get it working eventually.
Update:
- I just had to use some different settings for the audio. Here are the
current settings (run in a script) that I use to get my PVR-500 working
(with ivtv driver version 0.3.2z):
modprobe -v tveeprom
modprobe -v cx25840
modprobe -v wm8775
modprobe -v msp3400
modprobe -v tuner
modprobe -v ivtv
sleep 1
ivtvctl -d /dev/video2 -p 0 -u 0x3000 -q 1
ivtvctl -d /dev/video4 -p 0 -u 0x3000 -q 1
I
have no idea if the "sleep 1" is needed, but that's where I left off. I
also don't know why /dev/video2 and /dev/video4 turn out to be the
right ones to use, but it's working, so I'm not messing with it.
Oh,
and, with this IVTV version, you have to change ALL the recording
profiles for PVR cards to record 720x480 because this driver version
doesn't support horizontal scaling.
otherwise, things are
working like a charm (except for the VBI information that shows up as 3
or 4 squiggly lines at the top of the video, which is supposedly normal
because TV overscan usually hides it).