Mailing List Archive

At 01:28 PM 7/19/2003 +0200, Akos Maroy wrote:
>Hi,
>
>I'm new to MythTV. I just configured it, but when I try to watch TV using
>mythtvfrontend, I only get one big black screen (and valid audio). but no
>visuals on the screen.
>
>I'm using RedHat 9, and tried mythtvfrontend with both Gnome and KDE. On
>the same system, xawtv shows TV fine.


This should be a FAQ (even including the xawtv part).

The usual explanation for this symptom is that you are running a video
card/X driver that does not properly support XV (that is, the XVideo
extensions to XFree86). Because xawtv does not use XV, the fact that it is
working is NOT a test of the ability of your system to display MythTV
images properly.

To check if it is an XV problem, install xine and see if it will run when
set to use XV ("xine -V xv some_video_file_name"). Or use xvinfo to see if
X reports that your system is capable of XV (though a "yes" on this test is
not definitive, as some XV drivers are buggy).

In any case, the odds are about 100 to 1 that this is an X problem, not a
Myth problem.

If you want help here with it, post again, but include the results of the
tests I've suggested above, and tell us the basics of your setup (what X
version, what video card and X driver, maybe more). I infer that you are
using a combined backend/frontent, but you should confirm that too.



_______________________________________________
mythtv-users mailing list
mythtv-users@snowman.net
http://lists.snowman.net/cgi-bin/mailman/listinfo/mythtv-users

Ray Olszewski wrote:
> In any case, the odds are about 100 to 1 that this is an X problem, not
> a Myth problem.

I'd be really surprised if this was an X problem. I've been using this
very system to watch TV, DVD movies, DivX movies, play games, etc. for
more than 1.5 years now. (and the same TV tuner card on a similar system
for 2 year before that) But see my test results below.

> If you want help here with it, post again, but include the results of
> the tests I've suggested above, and tell us the basics of your setup
> (what X version, what video card and X driver, maybe more). I infer that
> you are using a combined backend/frontent, but you should confirm that too.

some general info:

System: RedHat 9
XFree version: XFree86-4.3.0-2
video card: nVidia GeForce 3, 64MB RAM
driver: nvidia factory driver, version 4349


The xine test: the video is displayed fine, and here is the command line
output:

# xine -V xv /tmp/1.avi
This is xine (X11 gui) - a free video player v0.9.21
(c) 2000-2003 by G. Bartsch and the xine project team.
Built with xine library 1.0.0 (1-beta12)
Found xine library version: 1.0.0 (1-beta12).
XServer Vendor: The XFree86 Project, Inc. Release: 40300000,
Protocol Version: 11, Revision: 0,
Available Screen(s): 1, using 0
Depth: 16.
XShmQueryVersion: 1.1.
-[ xiTK version 0.10.3 ]-
-[ xiTK will use XShm ]-
-[ WM type: (GnomeCompliant) (EWMH) Metacity {Metacity} ]-
Display is not using Xinerama.
main: probing <alsa> audio output plugin
load_plugins: failed to load audio output plugin <alsa>
main: probing <oss> audio output plugin
xine_interface: unknown param 10
xine_interface: unknown param 10
xine_interface: unknown param 10
xine_interface: unknown param 10
vo_scale: invalid ratio, using 4:3
vo_scale: unknown aspect ratio (0) in stream => using 4:3
This file was encoded with DivX503 Build830p


xvinfo output:

# xvinfo
X-Video Extension version 2.2
screen #0
Adaptor #0: "video4linux"
number of ports: 1
port base: 105
operations supported: PutVideo
supported visuals:
depth 16, visualID 0x21
depth 16, visualID 0x23
depth 16, visualID 0x24
depth 16, visualID 0x25
depth 16, visualID 0x26
depth 16, visualID 0x27
depth 16, visualID 0x28
depth 16, visualID 0x29
depth 16, visualID 0x2a
depth 16, visualID 0x2b
number of attributes: 11
"XV_ENCODING" (range -1000 to 1000)
client settable attribute
client gettable attribute (current value is 0)
"XV_BRIGHTNESS" (range -1000 to 1000)
client settable attribute
client gettable attribute (current value is 0)
"XV_CONTRAST" (range -1000 to 1000)
client settable attribute
client gettable attribute (current value is -160)
"XV_SATURATION" (range -1000 to 1000)
client settable attribute
client gettable attribute (current value is -20)
"XV_HUE" (range -1000 to 1000)
client settable attribute
client gettable attribute (current value is 0)
"XV_MUTE" (range 0 to 1)
client settable attribute
client gettable attribute (current value is 0)
"XV_FREQ" (range 0 to 16000)
client settable attribute
client gettable attribute (current value is 11508)
"XV_COLORKEY" (range 0 to 16777215)
client settable attribute
client gettable attribute (current value is 2110)
"XV_AUTOPAINT_COLORKEY" (range 0 to 1)
client settable attribute
client gettable attribute (current value is 1)
"XV_SET_DEFAULTS" (range 0 to 0)
client settable attribute
"XV_ITURBT_709" (range 0 to 1)
client settable attribute
client gettable attribute (current value is 0)
number of encodings: 21
encoding ID #0: "pal-television"
size: 768 x 576
rate: 0.020000
encoding ID #1: "ntsc-television"
size: 640 x 480
rate: 0.016683
encoding ID #2: "secam-television"
size: 768 x 576
rate: 0.020000
encoding ID #3: "palnc-television"
size: 640 x 576
rate: 0.020000
encoding ID #4: "palm-television"
size: 640 x 576
rate: 0.020000
encoding ID #5: "paln-television"
size: 768 x 576
rate: 0.020000
encoding ID #6: "ntscjp-television"
size: 640 x 480
rate: 0.016683
encoding ID #7: "pal-composite1"
size: 768 x 576
rate: 0.020000
encoding ID #8: "ntsc-composite1"
size: 640 x 480
rate: 0.016683
encoding ID #9: "secam-composite1"
size: 768 x 576
rate: 0.020000
encoding ID #10: "palnc-composite1"
size: 640 x 576
rate: 0.020000
encoding ID #11: "palm-composite1"
size: 640 x 576
rate: 0.020000
encoding ID #12: "paln-composite1"
size: 768 x 576
rate: 0.020000
encoding ID #13: "ntscjp-composite1"
size: 640 x 480
rate: 0.016683
encoding ID #14: "pal-svideo"
size: 768 x 576
rate: 0.020000
encoding ID #15: "ntsc-svideo"
size: 640 x 480
rate: 0.016683
encoding ID #16: "secam-svideo"
size: 768 x 576
rate: 0.020000
encoding ID #17: "palnc-svideo"
size: 640 x 576
rate: 0.020000
encoding ID #18: "palm-svideo"
size: 640 x 576
rate: 0.020000
encoding ID #19: "paln-svideo"
size: 768 x 576
rate: 0.020000
encoding ID #20: "ntscjp-svideo"
size: 640 x 480
rate: 0.016683
Adaptor #1: "NV10 Video Overlay"
number of ports: 1
port base: 106
operations supported: PutImage
supported visuals:
depth 16, visualID 0x21
depth 16, visualID 0x23
depth 16, visualID 0x24
depth 16, visualID 0x25
depth 16, visualID 0x26
depth 16, visualID 0x27
depth 16, visualID 0x28
depth 16, visualID 0x29
depth 16, visualID 0x2a
depth 16, visualID 0x2b
depth 16, visualID 0x22
depth 16, visualID 0x2c
depth 16, visualID 0x2d
depth 16, visualID 0x2e
depth 16, visualID 0x2f
depth 16, visualID 0x30
depth 16, visualID 0x31
depth 16, visualID 0x32
depth 16, visualID 0x33
depth 16, visualID 0x34
number of attributes: 9
"XV_DOUBLE_BUFFER" (range 0 to 1)
client settable attribute
client gettable attribute (current value is 1)
"XV_COLORKEY" (range 0 to 16777215)
client settable attribute
client gettable attribute (current value is 2110)
"XV_AUTOPAINT_COLORKEY" (range 0 to 1)
client settable attribute
client gettable attribute (current value is 1)
"XV_SET_DEFAULTS" (range 0 to 0)
client settable attribute
"XV_BRIGHTNESS" (range -512 to 511)
client settable attribute
client gettable attribute (current value is -2)
"XV_CONTRAST" (range 0 to 8191)
client settable attribute
client gettable attribute (current value is 4094)
"XV_SATURATION" (range 0 to 8191)
client settable attribute
client gettable attribute (current value is 4094)
"XV_HUE" (range 0 to 360)
client settable attribute
client gettable attribute (current value is 0)
"XV_ITURBT_709" (range 0 to 1)
client settable attribute
client gettable attribute (current value is 0)
maximum XvImage size: 2046 x 2046
Number of image formats: 4
id: 0x32595559 (YUY2)
guid: 59555932-0000-0010-8000-00aa00389b71
bits per pixel: 16
number of planes: 1
type: YUV (packed)
id: 0x32315659 (YV12)
guid: 59563132-0000-0010-8000-00aa00389b71
bits per pixel: 12
number of planes: 3
type: YUV (planar)
id: 0x59565955 (UYVY)
guid: 55595659-0000-0010-8000-00aa00389b71
bits per pixel: 16
number of planes: 1
type: YUV (packed)
id: 0x30323449 (I420)
guid: 49343230-0000-0010-8000-00aa00389b71
bits per pixel: 12
number of planes: 3
type: YUV (planar)
Adaptor #2: "NV05 Video Blitter"
number of ports: 32
port base: 107
operations supported: PutImage
supported visuals:
depth 16, visualID 0x21
depth 16, visualID 0x23
depth 16, visualID 0x24
depth 16, visualID 0x25
depth 16, visualID 0x26
depth 16, visualID 0x27
depth 16, visualID 0x28
depth 16, visualID 0x29
depth 16, visualID 0x2a
depth 16, visualID 0x2b
depth 16, visualID 0x22
depth 16, visualID 0x2c
depth 16, visualID 0x2d
depth 16, visualID 0x2e
depth 16, visualID 0x2f
depth 16, visualID 0x30
depth 16, visualID 0x31
depth 16, visualID 0x32
depth 16, visualID 0x33
depth 16, visualID 0x34
no port attributes defined
maximum XvImage size: 2046 x 2046
Number of image formats: 5
id: 0x32595559 (YUY2)
guid: 59555932-0000-0010-8000-00aa00389b71
bits per pixel: 16
number of planes: 1
type: YUV (packed)
id: 0x32315659 (YV12)
guid: 59563132-0000-0010-8000-00aa00389b71
bits per pixel: 12
number of planes: 3
type: YUV (planar)
id: 0x59565955 (UYVY)
guid: 55595659-0000-0010-8000-00aa00389b71
bits per pixel: 16
number of planes: 1
type: YUV (packed)
id: 0x30323449 (I420)
guid: 49343230-0000-0010-8000-00aa00389b71
bits per pixel: 12
number of planes: 3
type: YUV (planar)
id: 0x3
guid: 03000000-0000-0010-8000-00aa00389b71
bits per pixel: 32
number of planes: 1
type: RGB (packed)
depth: 24
red, green, blue masks: 0xff0000, 0xff00, 0xff


xdpyinfo output:

# xdpyinfo
name of display: :0.0
version number: 11.0
vendor string: The XFree86 Project, Inc
vendor release number: 40300000
XFree86 version: 4.3.0
maximum request size: 4194300 bytes
motion buffer size: 256
bitmap unit, bit order, padding: 32, LSBFirst, 32
image byte order: LSBFirst
number of supported pixmap formats: 7
supported pixmap formats:
depth 1, bits_per_pixel 1, scanline_pad 32
depth 4, bits_per_pixel 8, scanline_pad 32
depth 8, bits_per_pixel 8, scanline_pad 32
depth 15, bits_per_pixel 16, scanline_pad 32
depth 16, bits_per_pixel 16, scanline_pad 32
depth 24, bits_per_pixel 32, scanline_pad 32
depth 32, bits_per_pixel 32, scanline_pad 32
keycode range: minimum 8, maximum 255
focus: window 0x2600004, revert to Parent
number of extensions: 31
BIG-REQUESTS
DOUBLE-BUFFER
DPMS
Extended-Visual-Information
FontCache
GLX
LBX
MIT-SCREEN-SAVER
MIT-SHM
MIT-SUNDRY-NONSTANDARD
NV-CONTROL
NV-GLX
NVIDIA-GLX
RANDR
RECORD
RENDER
SECURITY
SHAPE
SYNC
TOG-CUP
X-Resource
XC-APPGROUP
XC-MISC
XFree86-Bigfont
XFree86-DGA
XFree86-Misc
XFree86-VidModeExtension
XInputExtension
XKEYBOARD
XTEST
XVideo
default screen number: 0
number of screens: 1

screen #0:
dimensions: 1600x1200 pixels (452x331 millimeters)
resolution: 90x92 dots per inch
depths (7): 16, 1, 4, 8, 15, 24, 32
root window id: 0x8d
depth of root window: 16 planes
number of colormaps: minimum 1, maximum 1
default colormap: 0x20
default number of colormap cells: 64
preallocated pixels: black 0, white 65535
options: backing-store NO, save-unders NO
largest cursor: 64x64
current input event mask: 0xfa203f
KeyPressMask KeyReleaseMask ButtonPressMask
ButtonReleaseMask EnterWindowMask LeaveWindowMask
ButtonMotionMask StructureNotifyMask
SubstructureNotifyMask
SubstructureRedirectMask FocusChangeMask PropertyChangeMask
ColormapChangeMask
number of visuals: 20
default visual id: 0x21
visual:
visual id: 0x21
class: TrueColor
depth: 16 planes
available colormap entries: 64 per subfield
red, green, blue masks: 0xf800, 0x7e0, 0x1f
significant bits in color specification: 8 bits
visual:
visual id: 0x22
class: DirectColor
depth: 16 planes
available colormap entries: 64 per subfield
red, green, blue masks: 0xf800, 0x7e0, 0x1f
significant bits in color specification: 8 bits
visual:
visual id: 0x23
class: TrueColor
depth: 16 planes
available colormap entries: 64 per subfield
red, green, blue masks: 0xf800, 0x7e0, 0x1f
significant bits in color specification: 8 bits
visual:
visual id: 0x24
class: TrueColor
depth: 16 planes
available colormap entries: 64 per subfield
red, green, blue masks: 0xf800, 0x7e0, 0x1f
significant bits in color specification: 8 bits
visual:
visual id: 0x25
class: TrueColor
depth: 16 planes
available colormap entries: 64 per subfield
red, green, blue masks: 0xf800, 0x7e0, 0x1f
significant bits in color specification: 8 bits
visual:
visual id: 0x26
class: TrueColor
depth: 16 planes
available colormap entries: 64 per subfield
red, green, blue masks: 0xf800, 0x7e0, 0x1f
significant bits in color specification: 8 bits
visual:
visual id: 0x27
class: TrueColor
depth: 16 planes
available colormap entries: 64 per subfield
red, green, blue masks: 0xf800, 0x7e0, 0x1f
significant bits in color specification: 8 bits
visual:
visual id: 0x28
class: TrueColor
depth: 16 planes
available colormap entries: 64 per subfield
red, green, blue masks: 0xf800, 0x7e0, 0x1f
significant bits in color specification: 8 bits
visual:
visual id: 0x29
class: TrueColor
depth: 16 planes
available colormap entries: 64 per subfield
red, green, blue masks: 0xf800, 0x7e0, 0x1f
significant bits in color specification: 8 bits
visual:
visual id: 0x2a
class: TrueColor
depth: 16 planes
available colormap entries: 64 per subfield
red, green, blue masks: 0xf800, 0x7e0, 0x1f
significant bits in color specification: 8 bits
visual:
visual id: 0x2b
class: TrueColor
depth: 16 planes
available colormap entries: 64 per subfield
red, green, blue masks: 0xf800, 0x7e0, 0x1f
significant bits in color specification: 8 bits
visual:
visual id: 0x2c
class: DirectColor
depth: 16 planes
available colormap entries: 64 per subfield
red, green, blue masks: 0xf800, 0x7e0, 0x1f
significant bits in color specification: 8 bits
visual:
visual id: 0x2d
class: DirectColor
depth: 16 planes
available colormap entries: 64 per subfield
red, green, blue masks: 0xf800, 0x7e0, 0x1f
significant bits in color specification: 8 bits
visual:
visual id: 0x2e
class: DirectColor
depth: 16 planes
available colormap entries: 64 per subfield
red, green, blue masks: 0xf800, 0x7e0, 0x1f
significant bits in color specification: 8 bits
visual:
visual id: 0x2f
class: DirectColor
depth: 16 planes
available colormap entries: 64 per subfield
red, green, blue masks: 0xf800, 0x7e0, 0x1f
significant bits in color specification: 8 bits
visual:
visual id: 0x30
class: DirectColor
depth: 16 planes
available colormap entries: 64 per subfield
red, green, blue masks: 0xf800, 0x7e0, 0x1f
significant bits in color specification: 8 bits
visual:
visual id: 0x31
class: DirectColor
depth: 16 planes
available colormap entries: 64 per subfield
red, green, blue masks: 0xf800, 0x7e0, 0x1f
significant bits in color specification: 8 bits
visual:
visual id: 0x32
class: DirectColor
depth: 16 planes
available colormap entries: 64 per subfield
red, green, blue masks: 0xf800, 0x7e0, 0x1f
significant bits in color specification: 8 bits
visual:
visual id: 0x33
class: DirectColor
depth: 16 planes
available colormap entries: 64 per subfield
red, green, blue masks: 0xf800, 0x7e0, 0x1f
significant bits in color specification: 8 bits
visual:
visual id: 0x34
class: DirectColor
depth: 16 planes
available colormap entries: 64 per subfield
red, green, blue masks: 0xf800, 0x7e0, 0x1f
significant bits in color specification: 8 bits

_______________________________________________
mythtv-users mailing list
mythtv-users@snowman.net
http://lists.snowman.net/cgi-bin/mailman/listinfo/mythtv-users

At 09:09 PM 7/19/2003 +0200, Akos Maroy wrote:
>Ray Olszewski wrote:
>>In any case, the odds are about 100 to 1 that this is an X problem, not a
>>Myth problem.
>
>I'd be really surprised if this was an X problem. I've been using this
>very system to watch TV, DVD movies, DivX movies, play games, etc. for
>more than 1.5 years now. (and the same TV tuner card on a similar system
>for 2 year before that) But see my test results below.
[rest deleted]

So would I, now, with the additional information you provided. My initial
response was based on the sketchiness of your report, especially your
reliance on xawtv as the criterion for whether everything else (besides
Myth) was working properly.

Of course, your report was equally sketchy about your Myth setup, as well
as on your hardware. For example, aside from knowing that your tuner card
is 3.5 years old, I still know nothing about it.

You might find it worthwhile to post another followup that includes the
rest of the details about your hardware (round up the usual spspects: CPU
type and speed, RAM, hard disk size, what capture card), mentions what
version of MythTV you are running (at least if it is a distro pre-package,
the main tarball, or CVS), and what procedure you followed to set it up.

In particular, what /dev/* devices are you telling Myth to use when
capturing video and audio? Are they the correct devices (i.e., the same
ones you have xawtv using)?

Does the problem occur only when watching "live" TV, or does it occur when
playing back recorded video in Myth?

Also ... not being a Red Hat user, I'm not certain of this ... but I think
that RH 9.0 is less than 1.5 years old, and I do know that XFree86 4.3.x is
not anywhere close to 1.5 years old ... so you might want to be a bit more
exact about what "this very system" is known to do properly.



_______________________________________________
mythtv-users mailing list
mythtv-users@snowman.net
http://lists.snowman.net/cgi-bin/mailman/listinfo/mythtv-users

Ray Olszewski wrote:
> So would I, now, with the additional information you provided. My
> initial response was based on the sketchiness of your report, especially
> your reliance on xawtv as the criterion for whether everything else
> (besides Myth) was working properly.

I wasn't giving it as a criterion, I was telling this detail since I
though it might be of some use.

> Of course, your report was equally sketchy about your Myth setup, as
> well as on your hardware. For example, aside from knowing that your
> tuner card is 3.5 years old, I still know nothing about it.

Sorry about the missing details. I'm trying to do my best in reporting
relevant information. I guess this very correspondance is the process I
find out what information to report, and in response, I do report it.

So in particular, my tuner card is an AverMedia TVPhone 98 card, which
has a bttv 878 chipset on it. This card has been supported by the bttv
drivers for quite a while now. It also includes an IR remote control,
which is supported by lirc.

> You might find it worthwhile to post another followup that includes the
> rest of the details about your hardware (round up the usual spspects:
> CPU type and speed, RAM, hard disk size, what capture card), mentions

AMD AthlonXP 1800+
512MB RAM
60GB HDD (very little free space left though, about 800MB)
see the tv tuner card above

> what version of MythTV you are running (at least if it is a distro
> pre-package, the main tarball, or CVS), and what procedure you followed
> to set it up.

0.10, source tarball, I followed the documentation to set it up. I
managed to get it working up until the point I called mythtvfrontend,
where the menues came up, but I got stuck with watching TV as I reported
originally.

> In particular, what /dev/* devices are you telling Myth to use when
> capturing video and audio? Are they the correct devices (i.e., the same
> ones you have xawtv using)?

I'm using xawtv with the default settings, which means:

/dev/video0
/dev/dsp
/dev/vbi

and I'm using the same devices. for Input connections, I'm using
/dev/video0 (Television), as this is how I recieve TV programming
(through a coax cable, not S-Video or composite).

One problem was that I the video source, I could not set up tv_grab_hu
as the listings grabber, as it was missing as an option. So I set it to
Germany.

> Does the problem occur only when watching "live" TV, or does it occur
> when playing back recorded video in Myth?

when trying to watch recordings ("watch recordings" option), I get a
problem connecting to the backend server.:


$ mythbackend
Starting up as the master server.
Probed: /dev/video0 - Television
Probed: /dev/video0 - Composite1
Probed: /dev/video0 - S-Video
2003-07-20 12:29:07 unknown socket


$ mythfrontend
connecting to backend server: 127.0.0.1:6543
Segmentation fault


BTW, ports 6543 is being listened on by mythbackend, I can telnet into it.


when trying to watch TV live, I get:

$ mythbackend
Starting up as the master server.
Probed: /dev/video0 - Television
Probed: /dev/video0 - Composite1
Probed: /dev/video0 - S-Video
2003-07-20 12:31:23 adding: destroy as a player 1
2003-07-20 12:31:23 adding: destroy as a player 0
2003-07-20 12:31:23 adding: destroy as a player 0
2003-07-20 12:31:23 adding: destroy as a remote ringbuffer
Changing from None to WatchingLiveTV
strange error flushing buffer ...
Changing from WatchingLiveTV to None
Segmentation fault


$ mythfrontend
connecting to backend server: 127.0.0.1:6543
Changing from None to WatchingLiveTV


> Also ... not being a Red Hat user, I'm not certain of this ... but I
> think that RH 9.0 is less than 1.5 years old, and I do know that XFree86
> 4.3.x is not anywhere close to 1.5 years old ... so you might want to be
> a bit more exact about what "this very system" is known to do properly.

I was refering to the same hardware setup, and the same set of software,
previous versions though. what I wanted to point out is that the system
/ hardware I have is not very new, thus has quite mature driver support.


Akos

_______________________________________________
mythtv-users mailing list
mythtv-users@snowman.net
http://lists.snowman.net/cgi-bin/mailman/listinfo/mythtv-users

This is a reply to the mail originally posted by darkeye. I just joined
the list and I only saw the message in the archive. So was not able to
reply to that mail. Hope the list figures it out.


Anyways, I just wanted to add more info on this.

I have the *exact* same issue. The following is my config.

P4 1500 MHz with 384 MB ram and 40GB harddisk.
It is running Mandrake 9.1 with 2.4.21-0.18mdk kernel.
nVidia GForce 2 MX card and am using the nVidia GForce 2 MX/MX 400
generic driver.

I just bought this AverTV Studio PCI card which has bt878 chip and uses
bttv driver. with FM tuner and IR remote. I want to build myself a
HT+PVR with MythTV. I am breaking my head trying to make it run
properly.

Mandrake come with bttv.0.7.00 driver and xawtv worked well but I had
problems with mythtv. The screen used to go blank as soon as I pressed
watch TV in mythfrontend. The sound comes up though.

After about a min. mythfrontend starts printing the following error msg.

Audio buffer overflow, audio data lost!


I have to kill the front end to get the blank screen of. But the sound
still keeps going on. Then I have to kill the backend and then start
xawtv and then exist it to stop the sound !


Interestingly I had same kind of problem (blank screen) with freevo too
which uses mplayer.

Then I tried compiling and using bttv-0.9.11 and 0.9.12 driver. With
these drivers, the picture was at least displayed. But some IRQ lockup
happens and the screen freezes.

I used to get some IOSYNCEERROR error in mythtv.

This happened in mythtv , freevo and also xawtv, but in lesser frequency
(in that order). With mythtv, It only takes one channel change for it to
happen. So I concluded that 0.9 driver is buggy.

I read somewhere that 0.7.104 if bttv driver is stable ans so I compiled
that driver. But then xawtv plays well like a charm. But mythtv has the
same old problem. (back to square one !!)

With the 0.9 driver when mythtv was playing the video atleast for
sometime, I found that it was taking about 50 to 60 % CPU. But neither
freevo or xawtv took any CPU at all. I did play the TV using mplayer
using XV driver and it worked fine without taking any CPU. From xvinfo
too, I think my card supports XV.

Why is mythtv taking more CPU ?

And how can solve this blank screen problem ?

I installed MythTV from the Mandrake RPMs.

Any help is highly appreciated.

thx,
Saravanan



_______________________________________________
mythtv-users mailing list
mythtv-users@snowman.net
http://lists.snowman.net/cgi-bin/mailman/listinfo/mythtv-users

From the information you posted, I still cannot be certain what your
problem is. OTOH, there are people here who are vastly more expert in the
CVS version of mMyth than I am, and now perhaps one of them will be able to
suggest something helpful. (Some of the error messages you are seeing are
entirely unfamiliar to me, making me think they reflect changes to versions
of Myth newer than what I've run.)

The one red flag I do see in what you last reported is this:

>60GB HDD (very little free space left though, about 800MB)

With that little space left, you are probably into the area reserved for
root, making it difficult for any app that runs under a non-root userid to
create files. Since Myth needs to create rather large files ... video is
anywhere between 500 MB and 2 GB per hour, depending on which encoding you
use ... Myth **may** simply be telling you (admittedly a bit inelegantly)
that it is failing to create the buffer file needed to watch "live" TV.

Someone else more expert than I should really help you at this point,
though, now that your trouble report is a bit more detailed than your
original query.

At 12:33 PM 7/20/2003 +0200, Akos Maroy wrote:
>Ray Olszewski wrote:
>>So would I, now, with the additional information you provided. My initial
>>response was based on the sketchiness of your report, especially your
>>reliance on xawtv as the criterion for whether everything else (besides
>>Myth) was working properly.
>
>I wasn't giving it as a criterion, I was telling this detail since I
>though it might be of some use.
>
>>Of course, your report was equally sketchy about your Myth setup, as well
>>as on your hardware. For example, aside from knowing that your tuner card
>>is 3.5 years old, I still know nothing about it.
>
>Sorry about the missing details. I'm trying to do my best in reporting
>relevant information. I guess this very correspondance is the process I
>find out what information to report, and in response, I do report it.
>
>So in particular, my tuner card is an AverMedia TVPhone 98 card, which has
>a bttv 878 chipset on it. This card has been supported by the bttv drivers
>for quite a while now. It also includes an IR remote control, which is
>supported by lirc.
>
>>You might find it worthwhile to post another followup that includes the
>>rest of the details about your hardware (round up the usual spspects: CPU
>>type and speed, RAM, hard disk size, what capture card), mentions
>
>AMD AthlonXP 1800+
>512MB RAM
>60GB HDD (very little free space left though, about 800MB)
>see the tv tuner card above
>
>>what version of MythTV you are running (at least if it is a distro
>>pre-package, the main tarball, or CVS), and what procedure you followed
>>to set it up.
>
>0.10, source tarball, I followed the documentation to set it up. I managed
>to get it working up until the point I called mythtvfrontend, where the
>menues came up, but I got stuck with watching TV as I reported originally.
>
>>In particular, what /dev/* devices are you telling Myth to use when
>>capturing video and audio? Are they the correct devices (i.e., the same
>>ones you have xawtv using)?
>
>I'm using xawtv with the default settings, which means:
>
>/dev/video0
>/dev/dsp
>/dev/vbi
>
>and I'm using the same devices. for Input connections, I'm using
>/dev/video0 (Television), as this is how I recieve TV programming (through
>a coax cable, not S-Video or composite).
>
>One problem was that I the video source, I could not set up tv_grab_hu as
>the listings grabber, as it was missing as an option. So I set it to Germany.
>
>>Does the problem occur only when watching "live" TV, or does it occur
>>when playing back recorded video in Myth?
>
>when trying to watch recordings ("watch recordings" option), I get a
>problem connecting to the backend server.:
>
>
>$ mythbackend
>Starting up as the master server.
>Probed: /dev/video0 - Television
>Probed: /dev/video0 - Composite1
>Probed: /dev/video0 - S-Video
>2003-07-20 12:29:07 unknown socket
>
>
>$ mythfrontend
>connecting to backend server: 127.0.0.1:6543
>Segmentation fault
>
>
>BTW, ports 6543 is being listened on by mythbackend, I can telnet into it.
>
>
>when trying to watch TV live, I get:
>
>$ mythbackend
>Starting up as the master server.
>Probed: /dev/video0 - Television
>Probed: /dev/video0 - Composite1
>Probed: /dev/video0 - S-Video
>2003-07-20 12:31:23 adding: destroy as a player 1
>2003-07-20 12:31:23 adding: destroy as a player 0
>2003-07-20 12:31:23 adding: destroy as a player 0
>2003-07-20 12:31:23 adding: destroy as a remote ringbuffer
>Changing from None to WatchingLiveTV
>strange error flushing buffer ...
>Changing from WatchingLiveTV to None
>Segmentation fault
>
>
>$ mythfrontend
>connecting to backend server: 127.0.0.1:6543
>Changing from None to WatchingLiveTV
>
>
>>Also ... not being a Red Hat user, I'm not certain of this ... but I
>>think that RH 9.0 is less than 1.5 years old, and I do know that XFree86
>>4.3.x is not anywhere close to 1.5 years old ... so you might want to be
>>a bit more exact about what "this very system" is known to do properly.
>
>I was refering to the same hardware setup, and the same set of software,
>previous versions though. what I wanted to point out is that the system /
>hardware I have is not very new, thus has quite mature driver support.




_______________________________________________
mythtv-users mailing list
mythtv-users@snowman.net
http://lists.snowman.net/cgi-bin/mailman/listinfo/mythtv-users

On Sunday 20 July 2003 08:07 am, Saravanan Subbiah wrote:
<snip>
> This happened in mythtv , freevo and also xawtv, but in lesser frequency
> (in that order). With mythtv, It only takes one channel change for it to
> happen. So I concluded that 0.9 driver is buggy.

It is.

> I read somewhere that 0.7.104 if bttv driver is stable ans so I compiled
> that driver. But then xawtv plays well like a charm. But mythtv has the
> same old problem. (back to square one !!)
>
> With the 0.9 driver when mythtv was playing the video atleast for
> sometime, I found that it was taking about 50 to 60 % CPU. But neither
> freevo or xawtv took any CPU at all. I did play the TV using mplayer
> using XV driver and it worked fine without taking any CPU. From xvinfo
> too, I think my card supports XV.

Send in the exact messages you get from mythbackend and mythfrontend, if you
want someone to be able to help without just guessing what the issue may be.

> Why is mythtv taking more CPU ?

Because it's actually compressing the video and audio and saving it so you can
do timeshifting stuff on live tv, none of your other tests are.

Isaac
_______________________________________________
mythtv-users mailing list
mythtv-users@snowman.net
http://lists.snowman.net/cgi-bin/mailman/listinfo/mythtv-users

I set up a second stand alone MythTV installation. I have been having the
same problems with a blank screen when I would try to view live TV or to
play a previously recorded program.

My problem was that the ALSA sound system was not installed properly. I had
initially tried to run without installing ALSA sound drivers because I saw
some comments that there might be some native support in MythTV 0.10 for
ALSA.

I followed the description of how to install the ALSA in the documentation
and the "blank screen" is gone.

Hopely, this information might help others resolve their problems.

Joel

-----Original Message-----
From: mythtv-users-bounces@snowman.net
[mailto:mythtv-users-bounces@snowman.net]On Behalf Of Isaac Richards
Sent: Sunday, July 20, 2003 10:11 AM
To: Discussion about mythtv
Subject: Re: [mythtv-users] Re:trying to watch TV via mythtvfrontend
producesblank screen


On Sunday 20 July 2003 08:07 am, Saravanan Subbiah wrote:
<snip>
> This happened in mythtv , freevo and also xawtv, but in lesser frequency
> (in that order). With mythtv, It only takes one channel change for it to
> happen. So I concluded that 0.9 driver is buggy.

It is.

> I read somewhere that 0.7.104 if bttv driver is stable ans so I compiled
> that driver. But then xawtv plays well like a charm. But mythtv has the
> same old problem. (back to square one !!)
>
> With the 0.9 driver when mythtv was playing the video atleast for
> sometime, I found that it was taking about 50 to 60 % CPU. But neither
> freevo or xawtv took any CPU at all. I did play the TV using mplayer
> using XV driver and it worked fine without taking any CPU. From xvinfo
> too, I think my card supports XV.

Send in the exact messages you get from mythbackend and mythfrontend, if you
want someone to be able to help without just guessing what the issue may be.

> Why is mythtv taking more CPU ?

Because it's actually compressing the video and audio and saving it so you
can
do timeshifting stuff on live tv, none of your other tests are.

Isaac
_______________________________________________
mythtv-users mailing list
mythtv-users@snowman.net
http://lists.snowman.net/cgi-bin/mailman/listinfo/mythtv-users

_______________________________________________
mythtv-users mailing list
mythtv-users@snowman.net
http://lists.snowman.net/cgi-bin/mailman/listinfo/mythtv-users

Ray Olszewski wrote:
> From the information you posted, I still cannot be certain what your
> problem is. OTOH, there are people here who are vastly more expert in

well, I stated this quite clearly: my problem is, that if I chose the
'watch TV' option in mythfronnted, I get a black screen (and audio of
some TV channel)

> the CVS version of mMyth than I am, and now perhaps one of them will be
> able to suggest something helpful. (Some of the error messages you are

good to hear

> With that little space left, you are probably into the area reserved for
> root, making it difficult for any app that runs under a non-root userid
> to create files. Since Myth needs to create rather large files ... video

not true so. I use the system normally as a regular (non-root) user.

> is anywhere between 500 MB and 2 GB per hour, depending on which
> encoding you use ... Myth **may** simply be telling you (admittedly a
> bit inelegantly) that it is failing to create the buffer file needed to
> watch "live" TV.

still, in this circumstance, it would create these files and then make
them grow. one would experience an out-of-space problem after a while,
when (reguler user) space really runs out.

> Someone else more expert than I should really help you at this point,
> though, now that your trouble report is a bit more detailed than your
> original query.

thanks for your help so far as well!


Akos

_______________________________________________
mythtv-users mailing list
mythtv-users@snowman.net
http://lists.snowman.net/cgi-bin/mailman/listinfo/mythtv-users

> -----Original Message-----
> From: mythtv-users-bounces@snowman.net
> [mailto:mythtv-users-bounces@snowman.net]On Behalf Of Akos Maroy
> Sent: Sunday, July 20, 2003 6:33 AM
> To: Discussion about mythtv
> Subject: Re: [mythtv-users] trying to watch TV via mythtvfrontend
> producesblank screen
>
>

[snip]

>
> So in particular, my tuner card is an AverMedia TVPhone 98 card, which
> has a bttv 878 chipset on it. This card has been supported by the bttv
> drivers for quite a while now. It also includes an IR remote control,
> which is supported by lirc.
>
> > You might find it worthwhile to post another followup that includes the
> > rest of the details about your hardware (round up the usual spspects:
> > CPU type and speed, RAM, hard disk size, what capture card), mentions
>
> AMD AthlonXP 1800+
> 512MB RAM
> 60GB HDD (very little free space left though, about 800MB)
> see the tv tuner card above
>
> > what version of MythTV you are running (at least if it is a distro
> > pre-package, the main tarball, or CVS), and what procedure you followed
> > to set it up.
>
> 0.10, source tarball, I followed the documentation to set it up. I
> managed to get it working up until the point I called mythtvfrontend,
> where the menues came up, but I got stuck with watching TV as I reported
> originally.
>
> > In particular, what /dev/* devices are you telling Myth to use when
> > capturing video and audio? Are they the correct devices (i.e., the same
> > ones you have xawtv using)?
>
> I'm using xawtv with the default settings, which means:
>
> /dev/video0
> /dev/dsp
> /dev/vbi
>
> and I'm using the same devices. for Input connections, I'm using
> /dev/video0 (Television), as this is how I recieve TV programming
> (through a coax cable, not S-Video or composite).
>
> One problem was that I the video source, I could not set up tv_grab_hu
> as the listings grabber, as it was missing as an option. So I set it to
> Germany.

This could be a problem, as the listings grabber serves not only to populate
program listings, but also to initially populate your channel table. So
maybe your German listings grabber is setting your system up to tune
channels that you don't have.

>
> > Does the problem occur only when watching "live" TV, or does it occur
> > when playing back recorded video in Myth?
>
> when trying to watch recordings ("watch recordings" option), I get a
> problem connecting to the backend server.:
>
>
> $ mythbackend
> Starting up as the master server.
> Probed: /dev/video0 - Television
> Probed: /dev/video0 - Composite1
> Probed: /dev/video0 - S-Video
> 2003-07-20 12:29:07 unknown socket
>
>
> $ mythfrontend
> connecting to backend server: 127.0.0.1:6543
> Segmentation fault
>
>

Is your backend on a different machine than the frontend?

[snip]

> > Also ... not being a Red Hat user, I'm not certain of this ... but I
> > think that RH 9.0 is less than 1.5 years old, and I do know
> that XFree86
> > 4.3.x is not anywhere close to 1.5 years old ... so you might
> want to be
> > a bit more exact about what "this very system" is known to do properly.
>
> I was refering to the same hardware setup, and the same set of software,
> previous versions though. what I wanted to point out is that the system
> / hardware I have is not very new, thus has quite mature driver support.

Yes, but 'previous versions' is significant. What might have worked
flawlessly under RedHat 7.1 might not (or at least require different
options) under RedHat 9.

-JAC

_______________________________________________
mythtv-users mailing list
mythtv-users@snowman.net
http://lists.snowman.net/cgi-bin/mailman/listinfo/mythtv-users

Joseph A. Caputo wrote:
> This could be a problem, as the listings grabber serves not only to populate
> program listings, but also to initially populate your channel table. So
> maybe your German listings grabber is setting your system up to tune
> channels that you don't have.

Might be so. But: MythTV tunes in to a valid TV channel, as the audio I
get is from a valid TV channel. Also, starting xawtv after killing
mythfronted brings in a valid TV channel (xawtv does not change / tune
channels on startup, it simply shows the channel the tuner was tuned to
earlier). and when MythTV starts, it doesn't display the 'battle of the
ants' screen (well, the gray chaos thingie) I'd get when I tune into an
empty frequency, but simply the screen is black.

BTW, I have two questions on this issue:

- when I was grabbing the german channels for the first time, it asked
me to give numbers to each channel by hand. what were those numbers? did
their value matter?

- how could I import my xawtv channel list into MythTV, to make sure I
have valid channels

> Is your backend on a different machine than the frontend?

no, it's the same machine.

> Yes, but 'previous versions' is significant. What might have worked
> flawlessly under RedHat 7.1 might not (or at least require different
> options) under RedHat 9.

well, everything worked flawlessly (xawtv, xine, mplayer) with all the
previous installations I had the same hardware :)


Akos

_______________________________________________
mythtv-users mailing list
mythtv-users@snowman.net
http://lists.snowman.net/cgi-bin/mailman/listinfo/mythtv-users

> -----Original Message-----
> From: mythtv-users-bounces@snowman.net
> [mailto:mythtv-users-bounces@snowman.net]On Behalf Of Akos Maroy
> Sent: Tuesday, July 22, 2003 3:26 AM
> To: Discussion about mythtv
> Subject: Re: [mythtv-users] trying to watch TV via mythtvfrontend
> producesblankscreen
>
>
> - how could I import my xawtv channel list into MythTV, to make sure I
> have valid channels


Run 'mythfilldatabase --help' for a list of options for importing xawtv
settings.

-JAC

_______________________________________________
mythtv-users mailing list
mythtv-users@snowman.net
http://lists.snowman.net/cgi-bin/mailman/listinfo/mythtv-users

In short, your guide data is independent on the input. You will, inside
MythTV
1. choose a v4l (or v4l2(?) like the WinTV PVR 250)
2. define program guide data configurations, selecting your region by
zip code and provider
3. associate the guide data config with an input source on the v4l or
v4l2 card
4. run mythfilldatabase, and it will pull guide data from the internet

Depending on how you set it up, MythTV can use the internal tuner to
change channels, or it can execute an external command to change
channels ala IR blaster, or other hack.

Some of this may be incorrect, so anyone feel free to correct me, but I
think I have it.

On Tue, 2003-07-22 at 10:11, Lonny Selinger wrote:
> All,
>
> I was chekcing the archives regarding this cable box and decided to
> buy one for now. My question is regarding the serial port on the box.
> In the manual it mentions that its some high speed data connector (or
> something to that effect), but it looks like people are connecting
> this link to their computers to do channel changing etc on the cable
> box. Am I understanding this correctly?
>
> Also ... if that is how people are managing channel changes, how do
> you populate the database for channels? The way I understand it there
> is only one *channel* on the out from the cable box so wont a discover
> just populate one entry rather then the full list of channels.
>
> Sorry if this sounds like other posts, I just haven't reached the
> point of enlightenment yet ;)
>
> Thanks in advance,
> Lonny
> _______________________________________________
> mythtv-users mailing list
> mythtv-users@snowman.net
> http://lists.snowman.net/cgi-bin/mailman/listinfo/mythtv-users
_______________________________________________
mythtv-users mailing list
mythtv-users@snowman.net
http://lists.snowman.net/cgi-bin/mailman/listinfo/mythtv-users

This makes a lot more sense then what I was thinking lol thank you for
providing my point of enlightenment =D

Now I just need to figure out/research the serial port on the box as
well as the irBlaster port.

Thanks!!
Lonny

> In short, your guide data is independent on the input. You will,
> inside
> MythTV
> 1. choose a v4l (or v4l2(?) like the WinTV PVR 250)
> 2. define program guide data configurations, selecting your region by
> zip code and provider
> 3. associate the guide data config with an input source on the v4l or
> v4l2 card
> 4. run mythfilldatabase, and it will pull guide data from the internet
>
> Depending on how you set it up, MythTV can use the internal tuner to
> change channels, or it can execute an external command to change
> channels ala IR blaster, or other hack.
>
> Some of this may be incorrect, so anyone feel free to correct me, but
> I
> think I have it.

_______________________________________________
mythtv-users mailing list
mythtv-users@snowman.net
http://lists.snowman.net/cgi-bin/mailman/listinfo/mythtv-users