Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: MythTV: Users

Playback causes recording stream corruption

 

 

MythTV users RSS feed   Index | Next | Previous | View Threaded


benrigby at gmail

Mar 28, 2006, 5:30 PM

Post #1 of 8 (697 views)
Permalink
Playback causes recording stream corruption

Hi,

I've recently upgraded to 0.19 (via atrpms) on my FC3 myth box and run
into a problem. The problem might not be new, or necessarily causes by
0.19 but it does seem to be exacerbated by it.

My problem is that watching a recording (or Live TV) seems to cause
some sort of corruption in any recordings being made. When the myth
box is not in use for playback, and recordings are near perfect (very
occasional video or audio artifacts). When a recording is made while
I'm watching it or something else previously recorded, then there are
significant artifacts. Often the recording is completely unwatchable
for sections lasting up to 3 minutes. The corruption definitely seems
to be occuring on the recording side of things, not the playback side
of things beacuse I can go back later and play it again and the same
corruption will occur.

The box is an Athlon 64 3000+ with 512 MB RAM in a shuttle case with
an Nforce3-250 based MB. CPU usage stays around 20% when recording and
playing back at once. Recordings are SDTV via a DVICO FusionHDTV DVB-T
Lite. Playback is via a geforce 5200 using s-video out.

I ran the mythbackend with -v record and have attached the log file.
At the start of the file you can see the output I get when trying to
record while playing back a file (in this case it was Live TV so I was
playing back the same time). These messages continue for as long as I
record. Here's a snippet of what I get:

2006-03-28 17:23:31.095 DVBRec(0): Packet dropped due to uncorrectable error.
2006-03-28 17:23:31.095 DVBRec(0): Packet dropped due to uncorrectable error.
2006-03-28 17:23:31.095 DVBRec(0): Packet dropped due to uncorrectable error.
2006-03-28 17:23:31.095 DVBRec(0): PID 0x200 discontinuity detected
2006-03-28 17:23:31.095 DVBRec(0): PID 0x28b discontinuity detected
2006-03-28 17:23:31.111 DVBRec(0): PID 0x28a discontinuity detected
2006-03-28 17:23:31.112 DVBRec(0): Packet dropped due to uncorrectable error.
2006-03-28 17:23:31.112 DVBRec(0): Packet dropped due to uncorrectable error.
2006-03-28 17:23:31.112 DVBRec(0): Packet dropped due to uncorrectable error.
2006-03-28 17:23:31.112 DVBRec(0): Packet dropped due to uncorrectable error.
2006-03-28 17:23:31.112 DVBRec(0): PID 0x200 discontinuity detected
2006-03-28 17:23:31.112 DVBRec(0): PID 0x28a discontinuity detected

At the bottom of the log is the output from a recording while I'm not
watching anything. The recording starts at 8pm and finishes at 8:45pm
in the log. There are 0 of these messages above and the recording is
pretty much perfect.

Has anyone seen this before? Can anyone tell me what might be causing
this? I'm not sure what other information to provide, but will do my
best to provide anything that might help.

Thanks,

Ben
Attachments: recordingproblem.log (20.9 KB)


ajlill at ajlc

Mar 29, 2006, 10:15 AM

Post #2 of 8 (680 views)
Permalink
Re: Playback causes recording stream corruption [In reply to]

"Ben Rigby" <benrigby[at]gmail.com> writes:

> Hi,
>
> I've recently upgraded to 0.19 (via atrpms) on my FC3 myth box and run
> into a problem. The problem might not be new, or necessarily causes by
> 0.19 but it does seem to be exacerbated by it.
>
> My problem is that watching a recording (or Live TV) seems to cause
> some sort of corruption in any recordings being made. When the myth
> box is not in use for playback, and recordings are near perfect (very
> occasional video or audio artifacts). When a recording is made while
> I'm watching it or something else previously recorded, then there are
> significant artifacts. Often the recording is completely unwatchable
> for sections lasting up to 3 minutes. The corruption definitely seems
> to be occuring on the recording side of things, not the playback side
> of things beacuse I can go back later and play it again and the same
> corruption will occur.

It could be that your backend just can't keep up with the video
stream. I get the following messages a lot more since going to 0.19:

Mar 29 05:01:16 freevo kernel: ivtv0: All encoder MPEG stream buffers are full. Dropping data.
Mar 29 05:01:16 freevo kernel: ivtv0: Cause: the application is not reading fast enough.

The real cause seems to be that while recording, the same thread
that's reading from the device is also inserting rows in the
recoredemarkup table. Lately, after a lot of monkeying to make other
things not run during recording, I've found that I get these errors
whenever a recording starts. Coincidently, for the first 30 seconds of
a recording, the inserts are done every 5 seconds and after, every 30.

I'm working on a patch that will spin those database updates into
their own thread. If it works, it might fix you too.
--
Tony Lill, Tony.Lill[at]AJLC.Waterloo.ON.CA
President, A. J. Lill Consultants fax/data (519) 650 3571
539 Grand Valley Dr., Cambridge, Ont. N3H 2S2 (519) 241 2461
--------------- http://www.ajlc.waterloo.on.ca/ ----------------
"Welcome to All Things UNIX, where if it's not UNIX, it's CRAP!"
_______________________________________________
mythtv-users mailing list
mythtv-users[at]mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users


benrigby at gmail

Mar 29, 2006, 4:28 PM

Post #3 of 8 (671 views)
Permalink
Re: Playback causes recording stream corruption [In reply to]

On 3/30/06, Tony Lill <ajlill[at]ajlc.waterloo.on.ca> wrote:
> It could be that your backend just can't keep up with the video
> stream. I get the following messages a lot more since going to 0.19:
>
> Mar 29 05:01:16 freevo kernel: ivtv0: All encoder MPEG stream buffers are full. Dropping data.
> Mar 29 05:01:16 freevo kernel: ivtv0: Cause: the application is not reading fast enough.
>
> The real cause seems to be that while recording, the same thread
> that's reading from the device is also inserting rows in the
> recoredemarkup table. Lately, after a lot of monkeying to make other
> things not run during recording, I've found that I get these errors
> whenever a recording starts. Coincidently, for the first 30 seconds of
> a recording, the inserts are done every 5 seconds and after, every 30.
>

Hi Tony,

I haven't seen either of those messages on my system. And my problems
are consistent across the length of a recording, I haven't noticed
them as more prevalent during the first 30 seconds. But please send
you patch my way, I'll have a look at anything.

It does appear that the backend doesn't seem able to keep up with the
recording, but I'm at a loss as to why. Even recording and playing
back at once I only get to about 20% CPU usage. The hard drive is a
fairly new drive, and whilst I'm not sure how to check, I'd be
suprised if it couldn't keep up with one recording stream being
written, and one playback stream being read. This is digital SDTV on a
fairly powerful system, it shouldn't be pushing any of the boundaries
of performance. Are there buffers involved in writing recordings to
disk and reading for playback? Can I increase them?

As I haven't seen anyone else report this problem, and there must be
heaps of people recording digital SD streams so the problem must be to
do with my hardware or configuration. I'm hoping one of the more
knowledgable myth users might be able to point me in the right
direction with some further troubleshooting, or some possible cures.
_______________________________________________
mythtv-users mailing list
mythtv-users[at]mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users


beww at beww

Mar 29, 2006, 4:57 PM

Post #4 of 8 (669 views)
Permalink
Re: Playback causes recording stream corruption [In reply to]

On Mar 29, 2006, at 5:28 PM, Ben Rigby wrote:

> On 3/30/06, Tony Lill <ajlill[at]ajlc.waterloo.on.ca> wrote:
>> It could be that your backend just can't keep up with the video
>> stream. I get the following messages a lot more since going to 0.19:
>>
>> Mar 29 05:01:16 freevo kernel: ivtv0: All encoder MPEG stream
>> buffers are full. Dropping data.
>> Mar 29 05:01:16 freevo kernel: ivtv0: Cause: the application is
>> not reading fast enough.
>>
>> The real cause seems to be that while recording, the same thread
>> that's reading from the device is also inserting rows in the
>> recoredemarkup table. Lately, after a lot of monkeying to make other
>> things not run during recording, I've found that I get these errors
>> whenever a recording starts. Coincidently, for the first 30
>> seconds of
>> a recording, the inserts are done every 5 seconds and after, every
>> 30.
>>
>
> Hi Tony,
>
> I haven't seen either of those messages on my system. And my problems
> are consistent across the length of a recording, I haven't noticed
> them as more prevalent during the first 30 seconds. But please send
> you patch my way, I'll have a look at anything.
>
> It does appear that the backend doesn't seem able to keep up with the
> recording, but I'm at a loss as to why. Even recording and playing
> back at once I only get to about 20% CPU usage. The hard drive is a
> fairly new drive, and whilst I'm not sure how to check, I'd be
> suprised if it couldn't keep up with one recording stream being
> written, and one playback stream being read. This is digital SDTV on a
> fairly powerful system, it shouldn't be pushing any of the boundaries
> of performance. Are there buffers involved in writing recordings to
> disk and reading for playback? Can I increase them?
>
> As I haven't seen anyone else report this problem, and there must be
> heaps of people recording digital SD streams so the problem must be to
> do with my hardware or configuration. I'm hoping one of the more
> knowledgable myth users might be able to point me in the right
> direction with some further troubleshooting, or some possible cures.


Sorry to ask such an obvious question, but are you sure that DMA is
enabled for your drive ???

If so, maybe try "hdparm -tT /dev/hd(n)" to make sure the transfer
rate is what it should be.
_______________________________________________
mythtv-users mailing list
mythtv-users[at]mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users


ajlill at ajlc

Mar 30, 2006, 5:32 PM

Post #5 of 8 (660 views)
Permalink
Re: Playback causes recording stream corruption [In reply to]

Brian Wood <beww[at]beww.org> writes:

> On Mar 29, 2006, at 5:28 PM, Ben Rigby wrote:
>
>> On 3/30/06, Tony Lill <ajlill[at]ajlc.waterloo.on.ca> wrote:
>>> It could be that your backend just can't keep up with the video
>>> stream. I get the following messages a lot more since going to 0.19:
>>>
>>> Mar 29 05:01:16 freevo kernel: ivtv0: All encoder MPEG stream
>>> buffers are full. Dropping data.
>>> Mar 29 05:01:16 freevo kernel: ivtv0: Cause: the application is
>>> not reading fast enough.
>>>
>>> The real cause seems to be that while recording, the same thread
>>> that's reading from the device is also inserting rows in the
>>> recoredemarkup table. Lately, after a lot of monkeying to make other
>>> things not run during recording, I've found that I get these errors
>>> whenever a recording starts. Coincidently, for the first 30
>>> seconds of
>>> a recording, the inserts are done every 5 seconds and after, every
>>> 30.
>>>
>>
>> Hi Tony,
>>
>> I haven't seen either of those messages on my system. And my problems
>> are consistent across the length of a recording, I haven't noticed
>> them as more prevalent during the first 30 seconds. But please send
>> you patch my way, I'll have a look at anything.

Well, those are specific to the hauppage card, but your messages
looked like the reader was getting out of sync with the data, which
could mean that it's dropping data, so I'm guessing it's the same root
cause.

I've got the patch running now, if it makes a difference, I'll post it
to trac.

>> It does appear that the backend doesn't seem able to keep up with the
>> recording, but I'm at a loss as to why. Even recording and playing
>> back at once I only get to about 20% CPU usage. The hard drive is a
>> fairly new drive, and whilst I'm not sure how to check, I'd be
>> suprised if it couldn't keep up with one recording stream being
>> written, and one playback stream being read. This is digital SDTV on a
>> fairly powerful system, it shouldn't be pushing any of the boundaries
>> of performance. Are there buffers involved in writing recordings to
>> disk and reading for playback? Can I increase them?

There's some config in one of the menus for HD ring buffer size, or
something like that, I'm not sure if that does what you
want. Otherwise look in libs/libmythtv/tv_rec.cpp, and look for calls
to ringBuffer->SetWriteBufferSize(). It's not called for all the
recorders, some just use the default (near the top pf
ThreadedFileWriter.cpp).

As long as dma is working, the disk should be able to keep up with the
data. When I do a cp, I can get over 30MB/s, and my video stream is only
about 700k.

The problem is when it updates the recordedmarkup table, it
seems to do 30 rows at one go, every 15 seconds. Each insert requires
sending a message to mysql, mysql waking up, doing it's thing,
probably writing to disk, sending a reply back. 30 times, every 15
seconds. When you think aboout it, it's a wonder this ever worked.

>> As I haven't seen anyone else report this problem, and there must be
>> heaps of people recording digital SD streams so the problem must be to
>> do with my hardware or configuration. I'm hoping one of the more
>> knowledgable myth users might be able to point me in the right
>> direction with some further troubleshooting, or some possible cures.

Annoying isn't it. Almost as bad as taking your car into a mechanic
when it starts making a funny noise.

> Sorry to ask such an obvious question, but are you sure that DMA is
> enabled for your drive ???
>
> If so, maybe try "hdparm -tT /dev/hd(n)" to make sure the transfer
> rate is what it should be.
--
Tony Lill, Tony.Lill[at]AJLC.Waterloo.ON.CA
President, A. J. Lill Consultants fax/data (519) 650 3571
539 Grand Valley Dr., Cambridge, Ont. N3H 2S2 (519) 241 2461
--------------- http://www.ajlc.waterloo.on.ca/ ----------------
"Welcome to All Things UNIX, where if it's not UNIX, it's CRAP!"
_______________________________________________
mythtv-users mailing list
mythtv-users[at]mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users


benrigby at gmail

Mar 30, 2006, 10:05 PM

Post #6 of 8 (659 views)
Permalink
Re: Playback causes recording stream corruption [In reply to]

On 3/30/06, Brian Wood <beww[at]beww.org> wrote:
>
> Sorry to ask such an obvious question, but are you sure that DMA is
> enabled for your drive ???
>
> If so, maybe try "hdparm -tT /dev/hd(n)" to make sure the transfer
> rate is what it should be.

Brian,

Nothing wrong with asking the obvious. My linux knowledge is at a
level where very little is really obvious.

/dev/hda:
multcount = 16 (on)
IO_support = 1 (32-bit)
unmaskirq = 1 (on)
using_dma = 1 (on)
keepsettings = 0 (off)
readonly = 0 (off)
readahead = 256 (on)
geometry = 19457/255/63, sectors = 160041885696, start = 0

/dev/hda:
Timing cached reads: 2112 MB in 2.00 seconds = 1054.05 MB/sec
Timing buffered disk reads: 166 MB in 3.03 seconds = 54.72 MB/sec

That all looks ok to me, but I may be missing something.

If it is ok, do you have any other ideas? Even obvious ones are ok.

Thanks,

Ben
_______________________________________________
mythtv-users mailing list
mythtv-users[at]mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users


ajlill at ajlc

Mar 31, 2006, 11:32 AM

Post #7 of 8 (647 views)
Permalink
Re: Playback causes recording stream corruption [In reply to]

Tony Lill <ajlill[at]ajlc.waterloo.on.ca> writes:

> Brian Wood <beww[at]beww.org> writes:
>
>> On Mar 29, 2006, at 5:28 PM, Ben Rigby wrote:
>>
>>> It does appear that the backend doesn't seem able to keep up with the
>>> recording, but I'm at a loss as to why. Even recording and playing
>>> back at once I only get to about 20% CPU usage. The hard drive is a
>>> fairly new drive, and whilst I'm not sure how to check, I'd be
>>> suprised if it couldn't keep up with one recording stream being
>>> written, and one playback stream being read. This is digital SDTV on a
>>> fairly powerful system, it shouldn't be pushing any of the boundaries
>>> of performance. Are there buffers involved in writing recordings to
>>> disk and reading for playback? Can I increase them?
>
> There's some config in one of the menus for HD ring buffer size, or
> something like that, I'm not sure if that does what you
> want. Otherwise look in libs/libmythtv/tv_rec.cpp, and look for calls
> to ringBuffer->SetWriteBufferSize(). It's not called for all the
> recorders, some just use the default (near the top pf
> ThreadedFileWriter.cpp).

Oh I just rememberd, if you do run out of space in the buffer,
mythbackend will log it. I assume you're running it with -v ALL or
something and keeping the output somewhere. Search for IOBOUND. If you
don't see it, then the buffer size is ok, and presumambly the hangup
is with the thread reading the data.

And I'm sorry to report that my patch does not appear to make much
difference to my situation. Here it is anyway. I did manage to
create/catch one of these incidents. When I was started watching a
pre-recorded program (that was on an automouned NFS partition, all
disk I/O stopped on my backend for about 5 seconds, and I got the
driver message, and the frontend couldn't open the file, which is new.


Index: libs/libmythtv/programinfo.h
===================================================================
--- libs/libmythtv/programinfo.h (revision 9404)
+++ libs/libmythtv/programinfo.h (working copy)
@@ -219,9 +219,8 @@
void ClearPositionMap(int type) const;
void SetPositionMap(frm_pos_map_t &, int type,
long long min_frm = -1, long long max_frm = -1) const;
- void SetPositionMapDelta(frm_pos_map_t &, int type) const;
+ void SetPositionMapDelta(frm_pos_map_t &, int type);

-
// GUI stuff
void showDetails(void) const;
void EditRecording(void);
@@ -318,8 +317,19 @@
private:
bool ignoreBookmark;
mutable class ScheduledRecording* record;
+
+ QString inUseForWhat;

- QString inUseForWhat;
+ void EndPositionMapThread(void);
+ pthread_t posmapThread;
+ bool posmapThreadRunning;
+ QStringList posmapList;
+ QMutex posmapLock;
+
+ protected:
+ static void *StartPostionMapThread(void *);
+ void posmapWorker(void);
+
};

/** \class ProgramList
Index: libs/libmythtv/programinfo.cpp
===================================================================
--- libs/libmythtv/programinfo.cpp (revision 9404)
+++ libs/libmythtv/programinfo.cpp (working copy)
@@ -125,6 +125,8 @@
inUseForWhat = "";

record = NULL;
+
+ posmapThreadRunning = false;
}

/** \fn ProgramInfo::ProgramInfo(const ProgramInfo &other)
@@ -223,6 +225,8 @@
lastInUseTime = other.lastInUseTime;
record = NULL;

+ posmapThreadRunning = false;
+
return *this;
}

@@ -233,6 +237,8 @@
{
if (record != NULL)
delete record;
+ if( posmapThreadRunning == true )
+ EndPositionMapThread();
}

/** \fn ProgramInfo::MakeUniqueKey(void) const
@@ -1375,12 +1381,15 @@
if (playbackHost == "")
playbackHost = m_hostname;

+ // Get the original path it was recorded on
tmpURL = GetRecordFilename(gContext->GetSettingOnHost("RecordFilePrefix",
hostname));

+ // if we are playing back on the recording host, just return it
if (playbackHost == hostname)
return tmpURL;

+ // else if we are playing back on this host, check if the path is accessable, if so, use it
if (playbackHost == m_hostname)
{
QFile checkFile(tmpURL);
@@ -1396,6 +1405,7 @@
return tmpURL;
}

+ // else contruct a url to use myth file transfer protocol
tmpURL = QString("myth://") +
gContext->GetSettingOnHost("BackendServerIP", hostname) + ":" +
gContext->GetSettingOnHost("BackendServerPort", hostname) + "/" +
@@ -2426,12 +2436,63 @@
}
}

+void *ProgramInfo::StartPostionMapThread(void *wotzit)
+{
+ ProgramInfo *pi = (ProgramInfo *)wotzit;
+ VERBOSE(VB_IMPORTANT,QString("Starting position map thread"));
+ pi->posmapWorker();
+ return(NULL);
+}
+
+void ProgramInfo::EndPositionMapThread(void)
+{
+ posmapLock.lock();
+ posmapList.append(QString("done"));
+ posmapLock.unlock();
+ pthread_join(posmapThread, NULL);
+ VERBOSE(VB_IMPORTANT,QString("Ending position map thread"));
+}
+
+void ProgramInfo::posmapWorker(void)
+{
+ MSqlQuery query(MSqlQuery::InitCon());
+ bool done = false;
+
+ while( ! done ) {
+ if( posmapList.empty() ) {
+ sleep(1);
+ } else {
+ posmapLock.lock();
+ QStringList mylist = posmapList;
+ posmapList.clear();
+ posmapLock.unlock();
+ for ( QStringList::Iterator it = mylist.begin(); it != mylist.end(); ++it ) {
+ if( *it == QString("done") ) {
+ done = true;
+ break;
+ }
+ query.prepare(*it);
+ if (!query.exec() || !query.isActive())
+ MythContext::DBError("delta position map insert",
+ query);
+ }
+ mylist.clear();
+ }
+ }
+}
+
void ProgramInfo::SetPositionMapDelta(frm_pos_map_t &posMap,
- int type) const
+ int type)
{
QMap<long long, long long>::Iterator i;
- MSqlQuery query(MSqlQuery::InitCon());
+ // MSqlQuery query(MSqlQuery::InitCon());
+ QString insert;

+ if( posmapThreadRunning == false ) {
+ pthread_create(&posmapThread, NULL, StartPostionMapThread, this);
+ posmapThreadRunning = true;
+ }
+
for (i = posMap.begin(); i != posMap.end(); ++i)
{
long long frame = i.key();
@@ -2447,28 +2508,42 @@

if (isVideo)
{
- query.prepare("INSERT INTO filemarkup"
+ // query.prepare("INSERT INTO filemarkup"
+ // " (filename, mark, type, offset)"
+ // " VALUES"
+ // " ( :PATH , :MARK , :TYPE , :OFFSET );");
+ // query.bindValue(":PATH", pathname);
+ insert = QString("INSERT INTO filemarkup"
" (filename, mark, type, offset)"
" VALUES"
- " ( :PATH , :MARK , :TYPE , :OFFSET );");
- query.bindValue(":PATH", pathname);
+ " ( \"%1\", %2, %3, %4 );")
+ .arg(pathname).arg(i.key()).arg(type).arg(i.data());
}
else
{
- query.prepare("INSERT INTO recordedmarkup"
+ // query.prepare("INSERT INTO recordedmarkup"
+ // " (chanid, starttime, mark, type, offset)"
+ // " VALUES"
+ // " ( :CHANID , :STARTTIME , :MARK , :TYPE , :OFFSET );");
+ // query.bindValue(":CHANID", chanid);
+ // query.bindValue(":STARTTIME", recstartts);
+ insert = QString("INSERT INTO recordedmarkup"
" (chanid, starttime, mark, type, offset)"
" VALUES"
- " ( :CHANID , :STARTTIME , :MARK , :TYPE , :OFFSET );");
- query.bindValue(":CHANID", chanid);
- query.bindValue(":STARTTIME", recstartts);
+ " ( %1 , \"%2\" , %3 , %4 , %5 );")
+ .arg(chanid).arg(recstartts.toString("yyyyMMddhhmmss")).arg(i.key()).arg(type).arg(i.data());
}
- query.bindValue(":MARK", frame_str);
- query.bindValue(":TYPE", type);
- query.bindValue(":OFFSET", offset_str);
+ //query.bindValue(":MARK", frame_str);
+ //query.bindValue(":TYPE", type);
+ //query.bindValue(":OFFSET", offset_str);

- if (!query.exec() || !query.isActive())
- MythContext::DBError("delta position map insert",
- query);
+ //if (!query.exec() || !query.isActive())
+ // MythContext::DBError("delta position map insert",
+ // query);
+ posmapLock.lock();
+ posmapList.append(insert);
+ posmapLock.unlock();
+
}
}

_______________________________________________
mythtv-users mailing list
mythtv-users[at]mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users


khanh at khanh

May 30, 2006, 6:15 PM

Post #8 of 8 (578 views)
Permalink
Re: Playback causes recording stream corruption [In reply to]

I'm also having this problem since going to 0.19 and still have it in
svn revision 9930. I was looking at
http://svn.mythtv.org/trac/ticket/1660, but it doesn't seem to have
gone anywhere. I only have the problem with my one slave backend. It
then causes problems with remote frontends and playback with media on
this backend. Namely, prebuffering pauses causing LiveTV lockups and
MythVideo lockups (NFS mounted). While the errors are occuring, the
whole box seems to be locked from the network. I can't SSH in, but
nothing crashes and the recordings seem fine. I can get back in after
5 to 10 seconds. Sometimes longer...
_______________________________________________
mythtv-users mailing list
mythtv-users[at]mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users

MythTV users RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact lists@gossamer-threads.com
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.