[mythtv-users] UNSUBSCRIBE

Russo, Nathan A. NATHAN.A.RUSSO at saic.com
Fri Sep 23 14:46:24 UTC 2011



-----Original Message-----
From: mythtv-users-bounces at mythtv.org
[mailto:mythtv-users-bounces at mythtv.org] On Behalf Of
mythtv-users-request at mythtv.org
Sent: Friday, September 23, 2011 5:00 AM
To: mythtv-users at mythtv.org
Subject: mythtv-users Digest, Vol 102, Issue 56

Send mythtv-users mailing list submissions to
	mythtv-users at mythtv.org

To subscribe or unsubscribe via the World Wide Web, visit
	http://www.mythtv.org/mailman/listinfo/mythtv-users
or, via email, send a message with subject or body 'help' to
	mythtv-users-request at mythtv.org

You can reach the person managing the list at
	mythtv-users-owner at mythtv.org

When replying, please edit your Subject line so it is more specific than
"Re: Contents of mythtv-users digest..."


Today's Topics:

   1. Re: trunk gentoo ebuilds and logrotate (Raymond Wagner)
   2. Re: trunk gentoo ebuilds and logrotate (Bill Meek)
   3. release schedule for 0.25? (Paul)
   4. Re: release schedule for 0.25? (Nick Morrott)
   5. Re: Recorded program playing back different program than
      scheduled (Michael T. Dean)
   6. Re: VMWare move. Firewire - ? Need input (Raymond Wagner)
   7. Re: Recorded program playing back different program than
      scheduled (David Watkins)
   8. Re: Firewire recording works in LiveTV but scheduled
      recordings unreliable (Les Noland)
   9. Re: Firewire recording works in LiveTV but scheduled
      recordings unreliable (Les Noland)
  10. Re: Recorded program playing back different program	than
      scheduled (Andre)
  11. Re: Recording issues with I/O load (Stefan Lands)
  12. Re: Channel listing on mythweb from PDA fixed with
downgrade
      (Anthony Rooney)
  13. Re: Recording issues with I/O load (Simon Hobson)
  14. Re: Storing recordings on network share (Simon Hobson)
  15. Re: Storing recordings on network share (belcampo)
  16. Re: Recording issues with I/O load (Stefan Lands)


----------------------------------------------------------------------

Message: 1
Date: Thu, 22 Sep 2011 20:13:50 -0400
From: Raymond Wagner <raymond at wagnerrp.com>
Subject: Re: [mythtv-users] trunk gentoo ebuilds and logrotate
To: Discussion about MythTV <mythtv-users at mythtv.org>
Message-ID: <4E7BCF3E.4080305 at wagnerrp.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

On 9/22/2011 18:38, Bill Meek wrote:
> The 'find' and '-exec' stuff I added are gone and replaced (by 
> wagnerrp) with his python script (line 79 needs another trailing ')'.)
>
>    os.unlink(os.path.join(self.path, self.filename)

Whoops.  I tested the logic with the print statement commented out
directly above.  I admit, I never actually ran the script completely,
allowing it to delete.

> The script expects only the new MythTV log file name formats as in:
>
>   application.date.pid.log{.#}{.gz}
>
> and it aborts on file names like mythfrontend.log or my local files 
> (like LocalShutdown.log etc.)

There is now a regular expression filter that it simply ignores those
files that don't match the expected pattern.

As for the ebuilds, I'm putting together an updated version tonight that
will optionally set up log rotation, and a cronjob to run this script.


------------------------------

Message: 2
Date: Thu, 22 Sep 2011 19:32:05 -0500
From: Bill Meek <keemllib at gmail.com>
Subject: Re: [mythtv-users] trunk gentoo ebuilds and logrotate
To: mythtv-users at mythtv.org
Message-ID: <1316737925.1818.54.camel at ofc0.local>
Content-Type: text/plain; charset="UTF-8"

On Thu, 2011-09-22 at 20:13 -0400, Raymond Wagner wrote:
...

Thank you. v0.25pre-3358-gcd002d2 logcleanup.py works fine
now. My glob.glob(...) solution was /almost/ posted too );

Bill




------------------------------

Message: 3
Date: Fri, 23 Sep 2011 10:47:25 +1000
From: Paul <mylists at wilsononline.id.au>
Subject: [mythtv-users] release schedule for 0.25?
To: mythtv-users <mythtv-users at mythtv.org>
Message-ID: <4E7BD71D.3020508 at wilsononline.id.au>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Just curious to see if 0.25 is nearing completion yet?

thanks


------------------------------

Message: 4
Date: Fri, 23 Sep 2011 02:22:14 +0100
From: Nick Morrott <knowledgejunkie at gmail.com>
Subject: Re: [mythtv-users] release schedule for 0.25?
To: Discussion about MythTV <mythtv-users at mythtv.org>
Message-ID:
	
<CAOQWjw16rY7a0gzhGOG=Fu3-Ht857rbxOZw9tuAecH2pTD3PvA at mail.gmail.com>
Content-Type: text/plain; charset=UTF-8

On 23 September 2011 01:47, Paul <mylists at wilsononline.id.au> wrote:
> Just curious to see if 0.25 is nearing completion yet?

http://code.mythtv.org/trac/roadmap

Nick

-- 
Nick Morrott

MythTV Official wiki: http://mythtv.org/wiki/
MythTV users list archive:
http://www.gossamer-threads.com/lists/mythtv/users

"An investment in knowledge always pays the best interest." - Benjamin
Franklin


------------------------------

Message: 5
Date: Thu, 22 Sep 2011 21:40:09 -0400
From: "Michael T. Dean" <mtdean at thirdcontact.com>
Subject: Re: [mythtv-users] Recorded program playing back different
	program than scheduled
To: Discussion about MythTV <mythtv-users at mythtv.org>
Message-ID: <4E7BE379.3010405 at thirdcontact.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

On 09/22/2011 06:18 AM, David Watkins wrote:
>> Another regular timeslot recording is also recording the wrong
channel and
>> some of the other schedules are working OK.  I have 2 tuners in the
system
>> version 0.24.  Does anyone have any ideas how I should troubleshoot
and fix?
> Look in the backend log is a good place to start.
>
> I have a similar problem where my backend tries to tune to the
> incorrect channel, but fails because that channel doesn't exist on the
> multiplex it's trying to use.  The backend appears to go to the
> correct multiplex but uses the wrong Programme Allocation Table (PAT)
> reference, belonging to a different channel on a different multiplex.
>
> http://www.gossamer-threads.com/lists/mythtv/users/491913
>
> I assume that you're using DVB-T?  Are you using EIT for programme
> information or xmltv?
>
> I've just found out that:
>
> The failure has occurred on the same programme two weeks in a row(like
you) .
> The incorrect channel (PAT reference)  appears to be random but (so
> far) always one that uses EIT for its programme data (I have a mix
> where some channels use EIT and some use xmltv).  I use EIT for radio
> and News channels and I rarely record from these.
>
> I'm running 0.25, what about you?
>
> My next step is to ramp up the detail in the backend log to see if I
> get any more information.

Have you guys tried rescanning your channels?  Sounds like the 
broadcasts have changed since you scanned.

Mike


------------------------------

Message: 6
Date: Fri, 23 Sep 2011 01:07:11 -0400
From: Raymond Wagner <raymond at wagnerrp.com>
Subject: Re: [mythtv-users] VMWare move. Firewire - ? Need input
To: Discussion about MythTV <mythtv-users at mythtv.org>
Message-ID: <4E7C13FF.9030504 at wagnerrp.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

On 9/22/2011 17:05, Mark wrote:
> On 09/22/2011 02:49 PM, Eric Sharkey wrote:
>> On Thu, Sep 22, 2011 at 3:15 PM, Mark<markhsa at gmail.com>   wrote:
>>> I am moving from Hardware to Vmware ESX 5.
>>> My only concern is channel changing on my Motorola HD DCT-6200
>> Why do you want to move to vmware?
>>
>> Eric
>> _______________________________________________
>> mythtv-users mailing list
>> mythtv-users at mythtv.org
>> http://www.mythtv.org/mailman/listinfo/mythtv-users
> Consolidating machines, saving power, entertaining myself with new
> technology....

Is there any reason you cannot consolidate machines and save power while

not using virtual machines?  There are several mechanisms that allow you

to isolate different userlands, while maintaining a single kernel, and 
allowing full hardware access.


------------------------------

Message: 7
Date: Fri, 23 Sep 2011 09:19:45 +0100
From: David Watkins <watkinshome at gmail.com>
Subject: Re: [mythtv-users] Recorded program playing back different
	program than scheduled
To: Discussion about MythTV <mythtv-users at mythtv.org>
Message-ID:
	
<CAJzO0N6SHBmOJKC7vVmJagfjniWMNi1P2aK+fXkcWxj1bjN3-w at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

> Have you guys tried rescanning your channels? ?Sounds like the
> broadcasts have changed since you scanned.
>

I have.  It's not a trivial process though - I scan both capture
cards, delete a few duplicates by hand and then run a script to set
Callsign, Visibilty, xmltvid etc, so it's possible that, if I made a
mistake, then I made the same mistake on the rescan.

I'm still getting plenty of successful recordings on the channels
concerned though which would imply that the scanning is OK, wouldn't
it?

What I've done now is enabled '-v dvbcam, record --loglevel debug' in
the mythbackend log and I've noted the mplexid and sourceid fields
from my channel table so , if it happens again, I should get a bit
more information.


------------------------------

Message: 8
Date: Fri, 23 Sep 2011 03:40:48 -0500
From: "Les Noland" <lnoland at xnet.com>
Subject: Re: [mythtv-users] Firewire recording works in LiveTV but
	scheduled	recordings unreliable
To: "'Discussion about MythTV'" <mythtv-users at mythtv.org>
Message-ID: <84F2D50369954DA2A976D07DCA519B57 at HPNotebookLes>
Content-Type: text/plain;	charset="us-ascii"



-----Original Message-----
From: mythtv-users-bounces at mythtv.org
[mailto:mythtv-users-bounces at mythtv.org] On Behalf Of Michael T. Dean
Sent: Wednesday, September 21, 2011 9:45 PM
To: Discussion about MythTV
Subject: Re: [mythtv-users] Firewire recording works in LiveTV but
scheduled
recordings unreliable

On 09/13/2011 08:56 AM, Les Noland wrote:
> From:  Michael T. Dean
>> On 09/12/2011 06:21 PM, Raymond Wagner wrote:
>>> On Sun, 28 Aug 2011 10:32:56 -0500, "Les Noland" wrote:
>>>> 2011-08-24 07:10:15.654 TFW, Error: Opening file
>>>> '/6410_20110824071000.mpg'.
>>>>     eno: Permission denied (13)
>>>>
>>>> NOTE: This makes it look as if it was trying to put the recording
file
>>>> into the root directory where it has no permissions to create
files.
That
>>>> makes no sense -- none of my storage directories are the root
directory
and
>>>> in the cases where it works properly it certainly doesn't store
anything in
>>>> the root directory.
>>> Can you paste the output of the MySQL query "SELECT * FROM
storagegroup;"?
>> and please start mythbackend with the command-line argument: 
>> mythbackend -v file,extra and attach a log file showing a failed 
>> recording--ideally the complete log file from start up until the 
>> failed recording. 
>
>
> One more thing which may be relevant: the directories currently in the
> storage group are NFS mounted on both the master and slave backends so
they
> are not local in either place.
>

I guess that means the requested log files are not relevant?

Mike
_______________________________________________
mythtv-users mailing list
mythtv-users at mythtv.org
http://www.mythtv.org/mailman/listinfo/mythtv-users

OK.  I guess I see why the first time I posted the log files didn't
work.  I
tried posting them again and got a message that my email was being held
because the message body was too big (>40K)  There's no way the message
body
was greater than 40K, but the attached logfile was.  I will try zipping
the
files and resending.

- Les




------------------------------

Message: 9
Date: Fri, 23 Sep 2011 03:42:00 -0500
From: "Les Noland" <lnoland at xnet.com>
Subject: Re: [mythtv-users] Firewire recording works in LiveTV but
	scheduled	recordings unreliable
To: "'Discussion about MythTV'" <mythtv-users at mythtv.org>
Message-ID: <7BCF78AB2A8A469486D5CF90C5485544 at HPNotebookLes>
Content-Type: text/plain; charset="us-ascii"

3rd try
>>-----Original Message-----
>From: mythtv-users-bounces at mythtv.org
[mailto:mythtv-users-bounces at mythtv.org] On Behalf Of Michael T. Dean
>Sent: Monday, September 12, 2011 5:37 PM
>To: Discussion about MythTV
>Subject: Re: [mythtv-users] Firewire recording works in LiveTV but
scheduled recordings unreliable
>
>On 09/12/2011 06:21 PM, Raymond Wagner wrote:
>> On Sun, 28 Aug 2011 10:32:56 -0500, "Les Noland" wrote:
>>> 2011-08-24 07:10:15.654 TFW, Error: Opening file
>>> '/6410_20110824071000.mpg'.
>>>    eno: Permission denied (13)
>>>
>>> NOTE: This makes it look as if it was trying to put the recording
file
into the root directory where it has no permissions to create files.
That
makes no sense -- none of my storage directories are the root directory
and
in the cases where it works properly it certainly doesn't store anything
in
the root directory.
>> Can you paste the output of the MySQL query "SELECT * FROM
storagegroup;"?
>
>and please start mythbackend with the command-line argument:
>
>mythbackend -v file,extra
>
>and attach a log file showing a failed recording--ideally the complete 
>log file from start up until the failed recording.
>
>Mike
>_______________________________________________
>mythtv-users mailing list
>mythtv-users at mythtv.org
>http://www.mythtv.org/mailman/listinfo/mythtv-users

OK -- it took a little doing but I finally got there.  I deleted my
local
definition of the "Default" storage group on my slave backend so that it
would go back to using the one on the master, but every time I tried to
run
a test, it would record fine because it kept picking a local directory.
I
finally had to go back and temporarily delete from the master's Default
storage group any local directories so that all directories were remote.
Then when I ran the test, it failed as before.

I have attached the backend log and the output from the storagegroup
query.
A lot of the initial error messages in the log are due to the fact that
I
removed directories from the storage group so now it can't find some of
the
previously recorded shows, but the error demonstrating the problem is at
the
end of the file where it tried to record the movie "Marnie" but failed.



-------------- next part --------------
A non-text attachment was scrubbed...
Name: FirewireFailLog.zip
Type: application/x-zip-compressed
Size: 14665 bytes
Desc: not available
Url :
http://www.mythtv.org/pipermail/mythtv-users/attachments/20110923/dade3d
87/attachment-0001.bin 

------------------------------

Message: 10
Date: Fri, 23 Sep 2011 10:19:22 +0100
From: Andre <mythtv-list at dinkum.org.uk>
Subject: Re: [mythtv-users] Recorded program playing back different
	program	than scheduled
To: Discussion about MythTV <mythtv-users at mythtv.org>
Message-ID: <9674CDAA-B35D-4B09-80BE-DAE10263E2AE at dinkum.org.uk>
Content-Type: text/plain; charset=us-ascii


On 23 Sep 2011, at 09:19, David Watkins wrote:

>> Have you guys tried rescanning your channels?  Sounds like the
>> broadcasts have changed since you scanned.
>> 
> 
> I have.  It's not a trivial process though - I scan both capture
> cards, delete a few duplicates by hand and then run a script to set
> Callsign, Visibilty, xmltvid etc, so it's possible that, if I made a
> mistake, then I made the same mistake on the rescan.

I recently started using a variation of the cleanup script on the wiki
and after a few days discovered that some recordings were from the wrong
channel. I was very confused because manual test recordings were fine
and some of my scheduled recordings were fine too. It wasn't a couple of
switched channels, I had some BBC HD recordings that contained a
different channel yet others were fine, the other channel was working
fine in it's own right too.

In the end I found that I made some mistakes in the script and I was
ending up with some channels sharing the same channel number. Record on
the named channel rules worked fine, record an any channel rules were
fine if the wanted channel was first in the channel list but recorded
the wrong channel if the wanted channel was second.

Maybe your problem is different but the symptoms sound similar and I
found it very confusing for a day or two.


> 
> I'm still getting plenty of successful recordings on the channels
> concerned though which would imply that the scanning is OK, wouldn't
> it?
> 
> What I've done now is enabled '-v dvbcam, record --loglevel debug' in
> the mythbackend log and I've noted the mplexid and sourceid fields
> from my channel table so , if it happens again, I should get a bit
> more information.
> _______________________________________________
> mythtv-users mailing list
> mythtv-users at mythtv.org
> http://www.mythtv.org/mailman/listinfo/mythtv-users
> 



------------------------------

Message: 11
Date: Fri, 23 Sep 2011 11:58:52 +0200
From: Stefan Lands <e350notifier at alice.de>
Subject: Re: [mythtv-users] Recording issues with I/O load
To: mythtv-users at mythtv.org
Message-ID: <4E7C585C.1060104 at alice.de>
Content-Type: text/plain; charset=ISO-8859-15

Well, thank you very much to Ian and Warpme for your help.

The raid used to be fully synchronized and speed seemed to be OK. But as
you pointed out correctly, this is not a mythtv related problem.

I tried a little bit more and disconnected the HDDs which contain the
raid. So PC was only running with one HDD containing OS and
mythtv-recording-directories. I produced heavy load to this disk
(recording, watching live-tv on a different frontend, nfs-transfer of
recorded mpgs via GB-LAN, doing md5sums of recording-directories) and
noticed no errors any more.

This lead me to the decision to take a quite radical step and kill the
raid5-array. Instead of this I build a simple group of these disks via
LVM as one big virtual disk. It took me 2 days to copy the old archived
recordings from external USB2.0 back to the computer.

Any further tests lead to no errors anymore. So the problem seemed to be
the raid itself. I don't know if this is a kernel-issue, or probably
related to the fact, that one of the raid-disks has 4kb-block size,
while the other ones have 512byte blocks. The partitions seemed to be
aligned properly. I couldn't find any IRQ-conflicts either.

So for now this case is closed. I reconfigured my backup-scripts to do
backups more frequently. The raid5 would have been quite a 1st degree
insurance against diskfailure. Sadly this doesn't work for me. Happily
the new backend now works as expected (except for the raid).



------------------------------

Message: 12
Date: Fri, 23 Sep 2011 19:45:41 +0930
From: "Anthony Rooney" <rooneyo at iinet.net.au>
Subject: Re: [mythtv-users] Channel listing on mythweb from PDA fixed
	with	downgrade
To: "'Discussion about MythTV'" <mythtv-users at mythtv.org>
Message-ID: <000001cc79d9$bf932f20$3eb98d60$@iinet.net.au>
Content-Type: text/plain;	charset="us-ascii"


> My front end/back end systems run Mandriva 2010.2, with the exception
of a
> compatible Minimyth front end.
> 
> It is perfectly possible for me to select a front-end only setup to
load
onto my
> front end machines with this distro. Maybe others offer it too.
> 
> I know that this is not a "recommended" arrangement, but I have had no
> problem with it.
> 
> The Minimyth distribution is net-booted from another server and is
also
> front-end only, although even there it is possible to enable a slave
backend
> where required.
> 
> A side issue to using Mandriva is that the Mythweb files are unusable,
and
I
> had to download a tarball from the website and unpack it. Hardly
rocket
> science.

I loaded Myth frontend on the client machines from the Applications
section
of Ubuntu which offered the frontend and backend separately.  I chose
just
the frontend however it installed both  - like it or not as if it was a
dependency.  I can see the value in having a secondary backend however I
cannot understand why having a single Front -end installation should not
be
"recommended".  What is the architectural reason for this is a pure
Backend
/ Frontend configuration?  You should have the flexibility to choose
according to your needs.  It appears it was a decision of the designers
that
was not fully considered which I found somewhat counter intuitive.  It's
good that Mandriva gives you the additional flexibility.





------------------------------

Message: 13
Date: Fri, 23 Sep 2011 11:19:23 +0100
From: Simon Hobson <linux at thehobsons.co.uk>
Subject: Re: [mythtv-users] Recording issues with I/O load
To: Discussion about MythTV <mythtv-users at mythtv.org>
Message-ID: <p06240807caa20ce2c3c9 at simon.thehobsons.co.uk>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Stefan Lands wrote:

>This lead me to the decision to take a quite radical step and kill the
>raid5-array. Instead of this I build a simple group of these disks via
>LVM as one big virtual disk.

Just a heads up that this isn't the best way to use disks for Myth
recordings.

Myth will quite happily use multiple directories - so you can let it 
put recordings on 3 disks. Done this way, if you lose a disk, then 
you only lose the recordings that are on that one disk.

If you make a large volume group with LVM, then you have no 
redundancy and the loss of any single drive will mean the loss of 
everything in the VG.

-- 
Simon Hobson

Visit http://www.magpiesnestpublishing.co.uk/ for books by acclaimed
author Gladys Hobson. Novels - poetry - short stories - ideal as
Christmas stocking fillers. Some available as e-books.


------------------------------

Message: 14
Date: Fri, 23 Sep 2011 11:24:09 +0100
From: Simon Hobson <linux at thehobsons.co.uk>
Subject: Re: [mythtv-users] Storing recordings on network share
To: Discussion about MythTV <mythtv-users at mythtv.org>
Message-ID: <p06240808caa20dc2f830 at simon.thehobsons.co.uk>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Travis Tabbal wrote:

>Generally speaking, I agree, larger buffers are probably called for 
>on HD material, but even if you buffer a few gig, at some point the 
>HDD has to catch up, or you lose data.

True, but I figure there are few things that are going to cause such 
IO (or at least seeking) that will preventing the disk catching up 
within a few minutes. I don't mind an occasional stutter during 
playback, but having recordings corrupted to the point of 
unwatchability is more than a tad annoying.

-- 
Simon Hobson

Visit http://www.magpiesnestpublishing.co.uk/ for books by acclaimed
author Gladys Hobson. Novels - poetry - short stories - ideal as
Christmas stocking fillers. Some available as e-books.


------------------------------

Message: 15
Date: Fri, 23 Sep 2011 12:48:59 +0200
From: belcampo <belcampo at zonnet.nl>
Subject: Re: [mythtv-users] Storing recordings on network share
To: Discussion about MythTV <mythtv-users at mythtv.org>
Message-ID: <4E7C641B.8070001 at zonnet.nl>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

On 09/23/2011 12:24 PM, Simon Hobson wrote:
> Travis Tabbal wrote:
>
>> Generally speaking, I agree, larger buffers are probably called for
>> on HD material, but even if you buffer a few gig, at some point the
>> HDD has to catch up, or you lose data.
What are we talking about, in terms of large buffers, I mean. Even 6 
concurrent HD-streams of probably <= 20Mb/s only generate 120Mb/s being 
15MB/s, with todays drives easily being capable of > 80MB/s.
> True, but I figure there are few things that are going to cause such
> IO (or at least seeking) that will preventing the disk catching up
> within a few minutes. I don't mind an occasional stutter during
> playback, but having recordings corrupted to the point of
> unwatchability is more than a tad annoying.
>



------------------------------

Message: 16
Date: Fri, 23 Sep 2011 13:04:40 +0200
From: Stefan Lands <e350notifier at alice.de>
Subject: Re: [mythtv-users] Recording issues with I/O load
To: mythtv-users at mythtv.org
Message-ID: <4E7C67C8.1030704 at alice.de>
Content-Type: text/plain; charset=ISO-8859-15

Am 23.09.2011 12:19, schrieb Simon Hobson:
> Just a heads up that this isn't the best way to use disks for Myth
> recordings. Myth will quite happily use multiple directories - so you
> can let it put recordings on 3 disks. Done this way, if you lose a
> disk, then you only lose the recordings that are on that one disk. If
> you make a large volume group with LVM, then you have no redundancy
> and the loss of any single drive will mean the loss of everything in
> the VG. 

Well, as I mentioned earlier, the mythtv-recording-directories are not
located on the LVM, there's a dedicated disk now for those. The VG holds
old recordings which were converted to x.264, and are frequently saved
to external disks as backup. So if one drive of the VG fails, I simply
have to restore the backup.


------------------------------

_______________________________________________
mythtv-users mailing list
mythtv-users at mythtv.org
http://www.mythtv.org/mailman/listinfo/mythtv-users

End of mythtv-users Digest, Vol 102, Issue 56
*********************************************


More information about the mythtv-users mailing list