[mythtv-users] Epia frontend fails LiveTV, Recordings OK.

[Kenneth Aafløy]

> Isaac wrote:
> > Could be a number of things:
> > - A socket timeout bug that was fixed post-0.13
> 
> Could be...
> 
> > I'd give CVS a try, first.
> 
> I tested the CVS version a couple of days ago, and the `in flux(tm)`
> store seektable by frame patch (or something else) had a 
> horrible effect
> on most of my recordings (as reported indirectly in a posting with
> Subject: Open Source CLE266 Hardware Success). However, I'll 
> try the CVS
> version again at least, and report back whatever noice(tm) 
> appears (with
> details).

Just updated and recompiled both backend and frontend, and on the first
try, the same message appeared on the frontend. The second time and
third time, the frontend started playing the LiveTV feed, but the output
was a color frenzy. The forth try yeilded a picture, but a bunch of
prebuffering pause messages (about 1-2 a second). The fifth time I got
this, and the frontend got a hard lock:

2003-12-18 04:33:24 Connecting to backend server: 10.1.1.1:6543 (try 1
of 5)
Input #0, mpeg, from 'rbuf://10.1.1.1:6543/media/rec/ringbuf23.nuv':
  Stream #0.0: Video: mpegvideo_via, 720x576, 25.00 fps
  Stream #0.1: Audio: mp2, 48000 Hz, stereo, 256 kb/s
2003-12-18 04:33:33 Opening OSS audio device '/dev/dsp'.
VIA Init: 720x576
Using VIA CLE266 Hardware Decoding
2003-12-18 04:33:34 Changing from None to WatchingLiveTV
[mpegvideo_via @ 0x847a8a8]slice below image (151 >= 36)
[mpegvideo_via @ 0x847a8a8]slice below image (149 >= 36)

Now, some of these might be related to Ivor's open source CLE266
hardware decoder, specifically the color frenzy and espessially the
hard-lock. But the other two, seems to be located it MythTV's realm.

Kenneth