Mailing List Archive

On Thu, 19 Jun 2014 19:21:04 +1200, you wrote:

>My MythTV woes continue.
>
>Now after some indeterminate length of time (less than 24 hours)
>recordings stop. In the logs there is no sign of them.
>
>After a reboot recordings happen as usual.
>
>I can find no sign of errors in mysql logs.
>
>How can I start to diagnose the problem?

If you look at the Upcoming Recordings list, are your recordings still
there? What does mythbackend.log actually show around the time of the
a scheduled recording that did not happen? If you shut down
mythbackend after recordings have failed ("stop mythtv-backend"), does
the log show anything then? Does it shut down cleanly? Is your
database OK - is anything reported in the daily email from the
/etc/cron.daily/optimize_mythdb run? If you are not set up to receive
those emails, try running that command manually from a root prompt or
sudo.

To get more relevant data logged, you should probably add the "-v
record" option to the end of the line in /etc/init/mythtv-backend.conf
that runs mythbackend. Then do the command "restart mythtv-backend"
(not while recording, obviously).

Are all your tuners working? Go to WatchTV, then use the M -> Source
-> Switch Input menu to change to one multirec tuner from each of your
physical tuners and make sure each tuner is working.

_______________________________________________
mythtvnz mailing list
mythtvnz@lists.linuxnut.co.nz
http://lists.ourshack.com/mailman/listinfo/mythtvnz
Archives http://www.gossamer-threads.com/lists/mythtv/mythtvnz/

On Thu, 19 Jun 2014 19:41:39 +1200, you wrote:

>On Thu, 19 Jun 2014 19:21:04 +1200, you wrote:
>
>>My MythTV woes continue.
>>
>>Now after some indeterminate length of time (less than 24 hours)
>>recordings stop. In the logs there is no sign of them.
>>
>>After a reboot recordings happen as usual.
>>
>>I can find no sign of errors in mysql logs.
>>
>>How can I start to diagnose the problem?
>
>If you look at the Upcoming Recordings list, are your recordings still
>there? What does mythbackend.log actually show around the time of the
>a scheduled recording that did not happen? If you shut down
>mythbackend after recordings have failed ("stop mythtv-backend"), does
>the log show anything then? Does it shut down cleanly? Is your
>database OK - is anything reported in the daily email from the
>/etc/cron.daily/optimize_mythdb run? If you are not set up to receive
>those emails, try running that command manually from a root prompt or
>sudo.
>
>To get more relevant data logged, you should probably add the "-v
>record" option to the end of the line in /etc/init/mythtv-backend.conf
>that runs mythbackend. Then do the command "restart mythtv-backend"
>(not while recording, obviously).
>
>Are all your tuners working? Go to WatchTV, then use the M -> Source
>-> Switch Input menu to change to one multirec tuner from each of your
>physical tuners and make sure each tuner is working.

One more thing to check - is the partition with your database on it
full? Do you have a runaway log file? That can may mythbackend do
exactly as you are describing, although I do not see why rebooting
would free up enough space in that case - maybe there is a runaway
file in /tmp as that gets deleted on reboot.

_______________________________________________
mythtvnz mailing list
mythtvnz@lists.linuxnut.co.nz
http://lists.ourshack.com/mailman/listinfo/mythtvnz
Archives http://www.gossamer-threads.com/lists/mythtv/mythtvnz/

On Thu, Jun 19, 2014 at 10:22 PM, Stephen Worthington
<stephen_agent@jsw.gen.nz> wrote:
>
> On Thu, 19 Jun 2014 19:41:39 +1200, you wrote:
>
> >On Thu, 19 Jun 2014 19:21:04 +1200, you wrote:
> >
> >>My MythTV woes continue.
> >>
> >>Now after some indeterminate length of time (less than 24 hours)
> >>recordings stop. In the logs there is no sign of them.
> >>
> >>After a reboot recordings happen as usual.
> >>
> >>I can find no sign of errors in mysql logs.
> >>
> >>How can I start to diagnose the problem?
> >
> >If you look at the Upcoming Recordings list, are your recordings still
> >there? What does mythbackend.log actually show around the time of the
> >a scheduled recording that did not happen? If you shut down
> >mythbackend after recordings have failed ("stop mythtv-backend"), does
> >the log show anything then? Does it shut down cleanly? Is your
> >database OK - is anything reported in the daily email from the
> >/etc/cron.daily/optimize_mythdb run? If you are not set up to receive
> >those emails, try running that command manually from a root prompt or
> >sudo.
> >
> >To get more relevant data logged, you should probably add the "-v
> >record" option to the end of the line in /etc/init/mythtv-backend.conf
> >that runs mythbackend. Then do the command "restart mythtv-backend"
> >(not while recording, obviously).
> >
> >Are all your tuners working? Go to WatchTV, then use the M -> Source
> >-> Switch Input menu to change to one multirec tuner from each of your
> >physical tuners and make sure each tuner is working.
>
> One more thing to check - is the partition with your database on it
> full? Do you have a runaway log file? That can may mythbackend do
> exactly as you are describing, although I do not see why rebooting
> would free up enough space in that case - maybe there is a runaway
> file in /tmp as that gets deleted on reboot.
>

Not sure if this still happens in the latest version (I'm still on
0.25.something), but another possibility is if a drive a storage group
uses was accessible when the backend starts but becomes inaccessible
some time after. Doesn't have to be an active storage group either. I
added an 'old' storage group to that accessed a share on a NAS. If the
NAS was initially visible to Myth but disappears (e.g. I turned it
off) recordings after the drive disappeared failed even though the
'old' storage group is never recorded directly to. I can't recall
whether the failure was logged.

_______________________________________________
mythtvnz mailing list
mythtvnz@lists.linuxnut.co.nz
http://lists.ourshack.com/mailman/listinfo/mythtvnz
Archives http://www.gossamer-threads.com/lists/mythtv/mythtvnz/

On Thu, 19 Jun 2014 22:40:01 +1200, you wrote:

>On Thu, Jun 19, 2014 at 10:22 PM, Stephen Worthington
><stephen_agent@jsw.gen.nz> wrote:
>>
>> On Thu, 19 Jun 2014 19:41:39 +1200, you wrote:
>>
>> >On Thu, 19 Jun 2014 19:21:04 +1200, you wrote:
>> >
>> >>My MythTV woes continue.
>> >>
>> >>Now after some indeterminate length of time (less than 24 hours)
>> >>recordings stop. In the logs there is no sign of them.
>> >>
>> >>After a reboot recordings happen as usual.
>> >>
>> >>I can find no sign of errors in mysql logs.
>> >>
>> >>How can I start to diagnose the problem?
>> >
>> >If you look at the Upcoming Recordings list, are your recordings still
>> >there? What does mythbackend.log actually show around the time of the
>> >a scheduled recording that did not happen? If you shut down
>> >mythbackend after recordings have failed ("stop mythtv-backend"), does
>> >the log show anything then? Does it shut down cleanly? Is your
>> >database OK - is anything reported in the daily email from the
>> >/etc/cron.daily/optimize_mythdb run? If you are not set up to receive
>> >those emails, try running that command manually from a root prompt or
>> >sudo.
>> >
>> >To get more relevant data logged, you should probably add the "-v
>> >record" option to the end of the line in /etc/init/mythtv-backend.conf
>> >that runs mythbackend. Then do the command "restart mythtv-backend"
>> >(not while recording, obviously).
>> >
>> >Are all your tuners working? Go to WatchTV, then use the M -> Source
>> >-> Switch Input menu to change to one multirec tuner from each of your
>> >physical tuners and make sure each tuner is working.
>>
>> One more thing to check - is the partition with your database on it
>> full? Do you have a runaway log file? That can may mythbackend do
>> exactly as you are describing, although I do not see why rebooting
>> would free up enough space in that case - maybe there is a runaway
>> file in /tmp as that gets deleted on reboot.
>>
>
>Not sure if this still happens in the latest version (I'm still on
>0.25.something), but another possibility is if a drive a storage group
>uses was accessible when the backend starts but becomes inaccessible
>some time after. Doesn't have to be an active storage group either. I
>added an 'old' storage group to that accessed a share on a NAS. If the
>NAS was initially visible to Myth but disappears (e.g. I turned it
>off) recordings after the drive disappeared failed even though the
>'old' storage group is never recorded directly to. I can't recall
>whether the failure was logged.

That is not a problem if you make sure you have one level of directory
on the drive for the storage group. If you have a partition mounted
as /mnt/rec3 say, and then have the storage group write directly to
/mnt/rec3, then there is no way for mythbackend to know if the drive
is there or if it will end up storing to the root partition because
the drive is unmounted. But if you make a recordings directory on the
drive and set the storage group to point to that, ie to
/mnt/rec3/recordings, then mythbackend will know that the drive is
unmounted if it can not see the recordings directory and will not
write to that storage group.

_______________________________________________
mythtvnz mailing list
mythtvnz@lists.linuxnut.co.nz
http://lists.ourshack.com/mailman/listinfo/mythtvnz
Archives http://www.gossamer-threads.com/lists/mythtv/mythtvnz/

On 19/06/2014 11:39 PM, Stephen Worthington wrote:
> On Thu, 19 Jun 2014 22:40:01 +1200, you wrote:
>> Not sure if this still happens in the latest version (I'm still on
>> 0.25.something), but another possibility is if a drive a storage group
>> uses was accessible when the backend starts but becomes inaccessible
>> some time after. Doesn't have to be an active storage group either. I
>> added an 'old' storage group to that accessed a share on a NAS. If the
>> NAS was initially visible to Myth but disappears (e.g. I turned it
>> off) recordings after the drive disappeared failed even though the
>> 'old' storage group is never recorded directly to. I can't recall
>> whether the failure was logged.
> That is not a problem if you make sure you have one level of directory
> on the drive for the storage group. If you have a partition mounted
> as /mnt/rec3 say, and then have the storage group write directly to
> /mnt/rec3, then there is no way for mythbackend to know if the drive
> is there or if it will end up storing to the root partition because
> the drive is unmounted. But if you make a recordings directory on the
> drive and set the storage group to point to that, ie to
> /mnt/rec3/recordings, then mythbackend will know that the drive is
> unmounted if it can not see the recordings directory and will not
> write to that storage group.
>
>
Thanks, I may not have done that, I'll have to try it again. This
storage group was never written to (no recording schedules used it) but
I assume the backend tests it anyway.

_______________________________________________
mythtvnz mailing list
mythtvnz@lists.linuxnut.co.nz
http://lists.ourshack.com/mailman/listinfo/mythtvnz
Archives http://www.gossamer-threads.com/lists/mythtv/mythtvnz/

On 19/06/14 19:41, Stephen Worthington wrote:
> On Thu, 19 Jun 2014 19:21:04 +1200, you wrote:
>
>> My MythTV woes continue.
[snip]
>>
>> How can I start to diagnose the problem?
>
> If you look at the Upcoming Recordings list, are your recordings still
> there? What does mythbackend.log actually show around the time of the
> a scheduled recording that did not happen? If you shut down
> mythbackend after recordings have failed ("stop mythtv-backend"), does
> the log show anything then? Does it shut down cleanly? Is your

The recordings are still there and the log has nothing

Jun 19 17:55:09 gently mythbackend[1605]: I HouseKeeping
housekeeper.cpp:225 (R\
unHouseKeeping) Running housekeeping thread
Jun 19 18:00:09 gently mythbackend[1605]: I HouseKeeping
housekeeper.cpp:225 (R\
unHouseKeeping) Running housekeeping thread

Should have recorded both news programmes

> database OK - is anything reported in the daily email from the
> /etc/cron.daily/optimize_mythdb run? If you are not set up to receive

That file does not exist

> those emails, try running that command manually from a root prompt or
> sudo.

>
> To get more relevant data logged, you should probably add the "-v
> record" option to the end of the line in /etc/init/mythtv-backend.conf
> that runs mythbackend. Then do the command "restart mythtv-backend"
> (not while recording, obviously).

Hmm... More logs! OK


> Are all your tuners working? Go to WatchTV, then use the M -> Source
> -> Switch Input menu to change to one multirec tuner from each of your
> physical tuners and make sure each tuner is working.
>

I have tested that. No they are not. forgot that in my original email.

> One more thing to check - is the partition with your database on it
> full? Do you have a runaway log file? That can may mythbackend do

No. It is not full.

Thanks for your attention. I have to go away for 3 days now so I'll
check the logs on my return to see if there is anything more interesting
in there.

Worik

> _______________________________________________
> mythtvnz mailing list
> mythtvnz@lists.linuxnut.co.nz
> http://lists.ourshack.com/mailman/listinfo/mythtvnz
> Archives http://www.gossamer-threads.com/lists/mythtv/mythtvnz/
> .
>


--
The only true evil is turning people into things....
Granny Weatherwax
worik.stanton@gmail.com 021-1680650, (03) 4821804
Aotearoa (New Zealand)

On Fri, 20 Jun 2014 09:18:53 +1200, you wrote:

>On 19/06/14 19:41, Stephen Worthington wrote:
>> On Thu, 19 Jun 2014 19:21:04 +1200, you wrote:
>>
>>> My MythTV woes continue.
>[snip]
>>>
>>> How can I start to diagnose the problem?
>>
>> If you look at the Upcoming Recordings list, are your recordings still
>> there? What does mythbackend.log actually show around the time of the
>> a scheduled recording that did not happen? If you shut down
>> mythbackend after recordings have failed ("stop mythtv-backend"), does
>> the log show anything then? Does it shut down cleanly? Is your
>
>The recordings are still there and the log has nothing
>
>Jun 19 17:55:09 gently mythbackend[1605]: I HouseKeeping
>housekeeper.cpp:225 (R\
>unHouseKeeping) Running housekeeping thread
>Jun 19 18:00:09 gently mythbackend[1605]: I HouseKeeping
>housekeeper.cpp:225 (R\
>unHouseKeeping) Running housekeeping thread
>
>Should have recorded both news programmes

OK, so the problem would seem to have happened further back in time.
But I am surprised that there is nothing logged if your schedule is
still showing the scheduled recordings at that time.

>> database OK - is anything reported in the daily email from the
>> /etc/cron.daily/optimize_mythdb run? If you are not set up to receive
>
>That file does not exist

It is always a good idea to have the automatic daily optimise enabled.
Run mythbuntu-control-centre and go to the MySQL tab. Set the two
options:

Enable daily MySQL DB Optimse/Repair cron job
Enable MySQL performance tweaks

and Apply them.

You should also already have smartd installed to monitor you hard
drives via SMART and email you if any problems occur (smartmontools
package). Doing that normally also gets you to install email on the
box (postfix and mailx packages if I remember correctly), and having
them installed allows cron jobs such as optimise_mythdb to email you
their results. To see those emails, you need to run a command prompt
as root and run the mail command. You can also set things up so that
the emails are sent on to an external email address such as your
regular email address.

>> those emails, try running that command manually from a root prompt or
>> sudo.
>
>>
>> To get more relevant data logged, you should probably add the "-v
>> record" option to the end of the line in /etc/init/mythtv-backend.conf
>> that runs mythbackend. Then do the command "restart mythtv-backend"
>> (not while recording, obviously).
>
>Hmm... More logs! OK
>
>
>> Are all your tuners working? Go to WatchTV, then use the M -> Source
>> -> Switch Input menu to change to one multirec tuner from each of your
>> physical tuners and make sure each tuner is working.
>>
>
>I have tested that. No they are not. forgot that in my original email.

So the tuners have stopped working at some point before you notice the
lack of recordings. That is a big symptom. You need to go back
through the logs (including syslog and kern.log) from when recordings
fail to see if there is anything about the tuners. And you should try
"restart mythtv-backend" rather than a reboot to see if that gets
things working again - it might be the tuners are working but
mythbackend is not talking to them. And check they are still there
when the problem happens - do "ls -al /dev/dvb*". If mythbackend
could not see the tuners, it should have been marking all the
scheduled recordings as conflicts.

>> One more thing to check - is the partition with your database on it
>> full? Do you have a runaway log file? That can may mythbackend do
>
>No. It is not full.
>
>Thanks for your attention. I have to go away for 3 days now so I'll
>check the logs on my return to see if there is anything more interesting
>in there.
>
>Worik

_______________________________________________
mythtvnz mailing list
mythtvnz@lists.linuxnut.co.nz
http://lists.ourshack.com/mailman/listinfo/mythtvnz
Archives http://www.gossamer-threads.com/lists/mythtv/mythtvnz/

On Fri, 20 Jun 2014 08:05:12 +1200, you wrote:

>
>On 19/06/2014 11:39 PM, Stephen Worthington wrote:
>> On Thu, 19 Jun 2014 22:40:01 +1200, you wrote:
>>> Not sure if this still happens in the latest version (I'm still on
>>> 0.25.something), but another possibility is if a drive a storage group
>>> uses was accessible when the backend starts but becomes inaccessible
>>> some time after. Doesn't have to be an active storage group either. I
>>> added an 'old' storage group to that accessed a share on a NAS. If the
>>> NAS was initially visible to Myth but disappears (e.g. I turned it
>>> off) recordings after the drive disappeared failed even though the
>>> 'old' storage group is never recorded directly to. I can't recall
>>> whether the failure was logged.
>> That is not a problem if you make sure you have one level of directory
>> on the drive for the storage group. If you have a partition mounted
>> as /mnt/rec3 say, and then have the storage group write directly to
>> /mnt/rec3, then there is no way for mythbackend to know if the drive
>> is there or if it will end up storing to the root partition because
>> the drive is unmounted. But if you make a recordings directory on the
>> drive and set the storage group to point to that, ie to
>> /mnt/rec3/recordings, then mythbackend will know that the drive is
>> unmounted if it can not see the recordings directory and will not
>> write to that storage group.
>>
>>
>Thanks, I may not have done that, I'll have to try it again. This
>storage group was never written to (no recording schedules used it) but
>I assume the backend tests it anyway.

I have never checked the code, but I have always assumed that
mythbackend only checked the storage groups whenever it wrote to them.
When it displays the Watch Recordings list, it checks each recording
file to see if it can find it in any storage group and greys out any
it can not find, so that is done on a file-by-file basis rather than
on a per storage group basis. The database does not store the
location of recording files - MythTV has to search all storage groups
each time it wants to find a recording file. Which is really useful
as you can then easily move recording files to a new storage group on
a new drive when you run out of space.

_______________________________________________
mythtvnz mailing list
mythtvnz@lists.linuxnut.co.nz
http://lists.ourshack.com/mailman/listinfo/mythtvnz
Archives http://www.gossamer-threads.com/lists/mythtv/mythtvnz/

> Are all your tuners working? Go to WatchTV, then use the M -> Source
> -> Switch Input menu to change to one multirec tuner from each of your
> physical tuners and make sure each tuner is working.
>

I have tested that. No they are not. forgot that in my original email.


Worik




I had this once before. Quite a long time ago..
Here is my trail of destruction.

I had no recordings to watch. They were there in the
Checked so many logs that I'm OVER logs.
After EVENTUALLY trying live TV, I saw no lock, AHA! the dish must be
out.
I spent ages fiddling with the dish (shoulda checked it against a known
good set top box first)
Yup. it worked just fine before adjustments ://
I then surmised tuners must have stopped working. Odd that both cards
would fail together.
No problems, I had 2 cards spare so swapped them in. Bugger. Still no
live TV.
Swapped the cards back to the originals.
Next I deleted the tuners from myth, & then re-installed them.
Re scanned the channels, and BINGO! it all worked.
Wrote THAT in my little book of MythTV gotchas.

Not sure why, or how, or what happened. I never did figure it out - I
had muddied the waters with my
fiddling too much to find the root cause of the problem.

Noel.

On 20/06/14 13:24, Stephen Worthington wrote:
>> >
>> >I have tested that. No they are not. forgot that in my original email.
> So the tuners have stopped working at some point before you notice the
> lack of recordings. That is a big symptom. You need to go back
> through the logs (including syslog and kern.log) from when recordings
> fail to see if there is anything about the tuners. And you should try
> "restart mythtv-backend" rather than a reboot to see if that gets
> things working again - it might be the tuners are working but
> mythbackend is not talking to them. And check they are still there
> when the problem happens - do "ls -al /dev/dvb*". If mythbackend
> could not see the tuners, it should have been marking all the
> scheduled recordings as conflicts.
>

Restarting myth-backend is what I did originally. I am 800 miles from
my box now so I cannot test it but I am fairly sure that was not enough.
Which does make it clear I am looking, probably, at a problem with the
tuners, but the complete lack of log stuff is puzzling. When I get home
we will see if the more verbose logs are more revealing.


Perhaps if the tuners are off line myth simply does not bother to record
until they come back. Now I am making wild guesses.

What should I be looking for in the system logs/myth logs for the moment
of failure of the tuners?

lastly my myth set-up is a dogs breakfast. I moved machines several
times and each time struggled to keep my recordings. I have looked on
the interweb and it does seem that it is more trouble than it is worth.
When my NAS gets back from the shop I think I will cut my losses and
through away all old data and start from scratch.

IMO mythtv is suffering from trying to do far too much, and it is
therefore much too complex and hence unstable and fragile. I run an
apache web-server that does as much complex stuff, but you would not
know from the trouble it gives me, very little.

W


--
The only true evil is turning people into things....
Granny Weatherwax
worik.stanton@gmail.com 021-1680650, (03) 4821804
Aotearoa (New Zealand)

On Fri, Jun 20, 2014 at 3:24 PM, Worik Stanton <worik.stanton@gmail.com> wrote:
> On 20/06/14 13:24, Stephen Worthington wrote:
>>> >
>>> >I have tested that. No they are not. forgot that in my original email.
>> So the tuners have stopped working at some point before you notice the
>> lack of recordings. That is a big symptom. You need to go back
>> through the logs (including syslog and kern.log) from when recordings
>> fail to see if there is anything about the tuners. And you should try
>> "restart mythtv-backend" rather than a reboot to see if that gets
>> things working again - it might be the tuners are working but
>> mythbackend is not talking to them. And check they are still there
>> when the problem happens - do "ls -al /dev/dvb*". If mythbackend
>> could not see the tuners, it should have been marking all the
>> scheduled recordings as conflicts.
>>
>
> Restarting myth-backend is what I did originally. I am 800 miles from
> my box now so I cannot test it but I am fairly sure that was not enough.
> Which does make it clear I am looking, probably, at a problem with the
> tuners, but the complete lack of log stuff is puzzling. When I get home
> we will see if the more verbose logs are more revealing.
>
>
> Perhaps if the tuners are off line myth simply does not bother to record
> until they come back. Now I am making wild guesses.
>
> What should I be looking for in the system logs/myth logs for the moment
> of failure of the tuners?
>
> lastly my myth set-up is a dogs breakfast. I moved machines several
> times and each time struggled to keep my recordings. I have looked on
> the interweb and it does seem that it is more trouble than it is worth.
> When my NAS gets back from the shop I think I will cut my losses and
> through away all old data and start from scratch.
>
> IMO mythtv is suffering from trying to do far too much, and it is
> therefore much too complex and hence unstable and fragile. I run an
> apache web-server that does as much complex stuff, but you would not
> know from the trouble it gives me, very little.

Worik, don't take this the wrong way but I detect operator error or
over fiddling.

There are many people using mythtv all over the world, and using it
successfully. You seem to have an inordinate number of problems.

One problem that can arise is that the database becomes a little
fragile when you make a lot of changes to tuners, and channel lineups.
A fresh start is one option. However so is deleting all your tuners
and starting again. Your channel lineups will be kept.

Anyway I suggest keeping everything as simple as possible. NZ has a
very low number of easily recordable channels - freeview. (If you are
using a sky box as well and recording through the 'analogue hole' it
is a bit more complex, and obviously more channels to contend with.)

But freeview only, either -T or -S is a very trivial mythtv setup when
compared to what a lot of myth installations in other markets are
coping with.

Starting from scratch may indeed be a good idea, leverage what you
have learned from your first dip into mythtv. Keep it simple.


>
> W
>
>
> --
> The only true evil is turning people into things....
> Granny Weatherwax
> worik.stanton@gmail.com 021-1680650, (03) 4821804
> Aotearoa (New Zealand)
>
>
> _______________________________________________
> mythtvnz mailing list
> mythtvnz@lists.linuxnut.co.nz
> http://lists.ourshack.com/mailman/listinfo/mythtvnz
> Archives http://www.gossamer-threads.com/lists/mythtv/mythtvnz/
>

_______________________________________________
mythtvnz mailing list
mythtvnz@lists.linuxnut.co.nz
http://lists.ourshack.com/mailman/listinfo/mythtvnz
Archives http://www.gossamer-threads.com/lists/mythtv/mythtvnz/

On Fri, Jun 20, 2014 at 7:25 PM, Nick Rout <nick.rout@gmail.com> wrote:

> Anyway I suggest keeping everything as simple as possible. NZ has a
> very low number of easily recordable channels - freeview. (If you are
> using a sky box as well and recording through the 'analogue hole' it
> is a bit more complex, and obviously more channels to contend with.)
>
> But freeview only, either -T or -S is a very trivial mythtv setup when
> compared to what a lot of myth installations in other markets are
> coping with.
>
> Starting from scratch may indeed be a good idea, leverage what you
> have learned from your first dip into mythtv. Keep it simple.
>

And once it's working, don't mess with it. Don't upgrade myth unless there
is some feature that you really want and don't upgrade anything else at
all. I don't even bother with security related updates - my myth box is not
accessible from the internet.

Cheers,
Steve

On Fri, Jun 20, 2014 at 9:53 PM, Steve Hodge <stevehodge@gmail.com> wrote:
> On Fri, Jun 20, 2014 at 7:25 PM, Nick Rout <nick.rout@gmail.com> wrote:
>>
>> Anyway I suggest keeping everything as simple as possible. NZ has a
>> very low number of easily recordable channels - freeview. (If you are
>> using a sky box as well and recording through the 'analogue hole' it
>> is a bit more complex, and obviously more channels to contend with.)
>>
>> But freeview only, either -T or -S is a very trivial mythtv setup when
>> compared to what a lot of myth installations in other markets are
>> coping with.
>>
>> Starting from scratch may indeed be a good idea, leverage what you
>> have learned from your first dip into mythtv. Keep it simple.
>
>
> And once it's working, don't mess with it. Don't upgrade myth unless there
> is some feature that you really want and don't upgrade anything else at all.
> I don't even bother with security related updates - my myth box is not
> accessible from the internet.

I have to say I update myth all the time with no problems (although
always latest+fixes, never master). But then again I don't mess with
the database manually, I don't install plugins that mess with the dB,
I use LTS releases of ubuntu only. My database has kept going through
many versions now, I'm not sure how to tell how old it is but at least
since 2008. In fact June 16 2008 is my oldest (although not
necessarily the first on this database.) I guess I missed that
anniversary by a few days!



>
> Cheers,
> Steve
>
> _______________________________________________
> mythtvnz mailing list
> mythtvnz@lists.linuxnut.co.nz
> http://lists.ourshack.com/mailman/listinfo/mythtvnz
> Archives http://www.gossamer-threads.com/lists/mythtv/mythtvnz/
>

_______________________________________________
mythtvnz mailing list
mythtvnz@lists.linuxnut.co.nz
http://lists.ourshack.com/mailman/listinfo/mythtvnz
Archives http://www.gossamer-threads.com/lists/mythtv/mythtvnz/

On Fri, Jun 20, 2014 at 10:03 PM, Nick Rout <nick.rout@gmail.com> wrote:

> On Fri, Jun 20, 2014 at 9:53 PM, Steve Hodge <stevehodge@gmail.com> wrote:
>
> > And once it's working, don't mess with it. Don't upgrade myth unless
> there
> > is some feature that you really want and don't upgrade anything else at
> all.
> > I don't even bother with security related updates - my myth box is not
> > accessible from the internet.
>
> I have to say I update myth all the time with no problems (although
> always latest+fixes, never master). But then again I don't mess with
> the database manually, I don't install plugins that mess with the dB,
> I use LTS releases of ubuntu only. My database has kept going through
> many versions now, I'm not sure how to tell how old it is but at least
> since 2008. In fact June 16 2008 is my oldest (although not
> necessarily the first on this database.) I guess I missed that
> anniversary by a few days!
>

My problems were probably more to do with running Gentoo that updating Myth
per se. Issues like updated myth core packages without updated plugins such
as mythmusic or mythvideo. I know there was at least one update where myth
changed it's handling of dates in the database which caused problems for
some people. I've also had problems with lirc and kernel upgrades and other
packages myth depends on. If you're updating an entire system (e.g. from
one mythbuntu release to another) this is probably not an issue. However,
"if it ain't broke, don't fix it" is extremely sound advice, especially if
you lack the time, patience or knowledge to diagnose and resolve the
resulting issues (and I definitely lack the patience these days, at least).

Cheers,
Steve

On 20/06/14 19:25, Nick Rout wrote:
> There are many people using mythtv all over the world, and using it
> successfully. You seem to have an inordinate number of problems.

I am having a lot of problems.

Do not take this the wrong way also, but a lot of people have a lot of
problems with Myth. I too had a stable setup that ran for over a yaar
(I forget how long). The problem is that once problems start, because
of Myth TV's huge list of things it does, they multiply like rabbits.

I am a user of a lot of complex computer systems over the years, and
Myth is good, for what its design philosophy is. (Back in the day
controlling large collections of printers using MS Windows is the worst
example I can think of off of the top of my head, though the IP
protection on the SUN compilers cost a client of mine a day at contract
rates back in 2001).

I think that MythTV has a design philosophy that I am uncomfortable
with. It is very capable, a wonderful example of a large and complex
system. And I will keep using it as it is the best there is. But I
cannot help but think that a 'unix philosophy' would be better.

That would be a collection of programmes that can copy from a digital
tuner to disk, programmes to play those files, a programme to configure
the tuners, a file in which the minimally useful details of those
programmes are kept and the whole caboodle stiched together with cron
jobs would be an improvement.

It would not have all the bells and whistles - the search functions, the
way Myth will keep a search for years and record much loved programmes
after you have forgotten they existed... But it would be easier to set
up and it would be less fragile.

When Myth started, IMO, things were not so simple. Configuring tuner
cards was the most finicky part of the process IIRC. In these days of
digital tuners it is one of the simplest parts.

Opinions are easy to have and easy to express. I will quieten down now
about mine unless I build such a system, and given my workload that is
unlikely!

Cutting my losses and reconfiguring on known good hardware is a much
better approach.


W
--
The only true evil is turning people into things....
Granny Weatherwax
worik.stanton@gmail.com 021-1680650, (03) 4821804
Aotearoa (New Zealand)

On Sat, Jun 21, 2014 at 9:49 AM, Worik Stanton <worik.stanton@gmail.com> wrote:
> On 20/06/14 19:25, Nick Rout wrote:
>> There are many people using mythtv all over the world, and using it
>> successfully. You seem to have an inordinate number of problems.
>
> I am having a lot of problems.
>
> Do not take this the wrong way also, but a lot of people have a lot of
> problems with Myth. I too had a stable setup that ran for over a yaar
> (I forget how long). The problem is that once problems start, because
> of Myth TV's huge list of things it does, they multiply like rabbits.
>
> I am a user of a lot of complex computer systems over the years, and
> Myth is good, for what its design philosophy is. (Back in the day
> controlling large collections of printers using MS Windows is the worst
> example I can think of off of the top of my head, though the IP
> protection on the SUN compilers cost a client of mine a day at contract
> rates back in 2001).
>
> I think that MythTV has a design philosophy that I am uncomfortable
> with. It is very capable, a wonderful example of a large and complex
> system. And I will keep using it as it is the best there is. But I
> cannot help but think that a 'unix philosophy' would be better.
>
> That would be a collection of programmes that can copy from a digital
> tuner to disk,

Mythbackend

> programmes to play those files,

mythfrontend

> a programme to configure
> the tuners,

mythtv-setup

>a file in which the minimally useful details of those
> programmes are kept

Keeping absolutely every setting in the database (apart form the
whereabouts and authentication details of the dB) makes it difficult
for a lot of people, but is also a strength.

>and the whole caboodle stiched together with cron
> jobs would be an improvement.
>

mythbackend has a very sophisiticated scheduer, which handles
situations a lot more complex than cron could ever do.


> It would not have all the bells and whistles - the search functions, the
> way Myth will keep a search for years and record much loved programmes
> after you have forgotten they existed... But it would be easier to set
> up and it would be less fragile.

If you want something simpler, tvheadend may be for you. It is
certainly worth a look, although it is pretty well a one man band as
far as coders is concerned, and that is another sort of stability I
would be worried about. It also has a XBMC frontend that apparently
functions well. I think you wil find it a LOT less flexible than myth
though.


>
> When Myth started, IMO, things were not so simple. Configuring tuner
> cards was the most finicky part of the process IIRC. In these days of
> digital tuners it is one of the simplest parts.
>
> Opinions are easy to have and easy to express. I will quieten down now
> about mine unless I build such a system, and given my workload that is
> unlikely!
>
> Cutting my losses and reconfiguring on known good hardware is a much
> better approach.

Yep and as I say KISS!

>
>
> W
> --
> The only true evil is turning people into things....
> Granny Weatherwax
> worik.stanton@gmail.com 021-1680650, (03) 4821804
> Aotearoa (New Zealand)
>
>
> _______________________________________________
> mythtvnz mailing list
> mythtvnz@lists.linuxnut.co.nz
> http://lists.ourshack.com/mailman/listinfo/mythtvnz
> Archives http://www.gossamer-threads.com/lists/mythtv/mythtvnz/
>

_______________________________________________
mythtvnz mailing list
mythtvnz@lists.linuxnut.co.nz
http://lists.ourshack.com/mailman/listinfo/mythtvnz
Archives http://www.gossamer-threads.com/lists/mythtv/mythtvnz/

On Fri, Jun 20, 2014 at 11:10 PM, Steve Hodge <stevehodge@gmail.com> wrote:
> On Fri, Jun 20, 2014 at 10:03 PM, Nick Rout <nick.rout@gmail.com> wrote:
>>
>> On Fri, Jun 20, 2014 at 9:53 PM, Steve Hodge <stevehodge@gmail.com> wrote:
>>
>> > And once it's working, don't mess with it. Don't upgrade myth unless
>> > there
>> > is some feature that you really want and don't upgrade anything else at
>> > all.
>> > I don't even bother with security related updates - my myth box is not
>> > accessible from the internet.
>>
>> I have to say I update myth all the time with no problems (although
>> always latest+fixes, never master). But then again I don't mess with
>> the database manually, I don't install plugins that mess with the dB,
>> I use LTS releases of ubuntu only. My database has kept going through
>> many versions now, I'm not sure how to tell how old it is but at least
>> since 2008. In fact June 16 2008 is my oldest (although not
>> necessarily the first on this database.) I guess I missed that
>> anniversary by a few days!
>
>
> My problems were probably more to do with running Gentoo that updating Myth
> per se.

Yeah at least in a ubuntu LTS environment you know your versions of
kernel lirc etc won't change markedly until you update to the next
LTS 2 years later.

Having said that I use a remote that is purely HID based and doesn't
touch or depend on lirc. It has an easily configurable keymap and is
easy to switch keymaps when, eg, switching from myth to xbmc and back.

I also use HDHR tuners which are less likely to suffer problems on a
kernel update than a PCI or USB tuner.


>Issues like updated myth core packages without updated plugins such
> as mythmusic or mythvideo.

Don't do music on the TV and I use xbmc for videos, but yes that would
present a problem.

>I know there was at least one update where myth
> changed it's handling of dates in the database which caused problems for
> some people. I've also had problems with lirc and kernel upgrades and other
> packages myth depends on. If you're updating an entire system (e.g. from one
> mythbuntu release to another) this is probably not an issue. However, "if it
> ain't broke, don't fix it" is extremely sound advice, especially if you lack
> the time, patience or knowledge to diagnose and resolve the resulting issues
> (and I definitely lack the patience these days, at least).
>
> Cheers,
> Steve
>
> _______________________________________________
> mythtvnz mailing list
> mythtvnz@lists.linuxnut.co.nz
> http://lists.ourshack.com/mailman/listinfo/mythtvnz
> Archives http://www.gossamer-threads.com/lists/mythtv/mythtvnz/
>

_______________________________________________
mythtvnz mailing list
mythtvnz@lists.linuxnut.co.nz
http://lists.ourshack.com/mailman/listinfo/mythtvnz
Archives http://www.gossamer-threads.com/lists/mythtv/mythtvnz/

On Sat, Jun 21, 2014 at 9:49 AM, Worik Stanton <worik.stanton@gmail.com>
wrote:

> I think that MythTV has a design philosophy that I am uncomfortable
> with. It is very capable, a wonderful example of a large and complex
> system. And I will keep using it as it is the best there is. But I
> cannot help but think that a 'unix philosophy' would be better.
>

My opinion is that the backend architecture is pretty good. There are ugly
bits, such as the way that multirec got hacked in, but overall it's proven
to be flexible and powerful. It is complex, because it supports a huge
variety of hardware types and configurations. I think the error reporting
and documentation could be better.

I'm less impressed with the frontend design. I think it was a mistake to
partition media by source/file type (tv separate to audio separate to
video), they should have been partitioned by the type of content (movies,
series, music, other video). There should be little or no difference in the
UI between a series I've recorded and a series I've imported from DVD.


> That would be a collection of programmes that can copy from a digital
> tuner to disk, programmes to play those files, a programme to configure
> the tuners, a file in which the minimally useful details of those
> programmes are kept and the whole caboodle stiched together with cron
> jobs would be an improvement.
>

You've left out the most important part of the whole system: the scheduler.
I think you'd find that by the time you'd written that you'd be a lot
closer to mythbackend that to your collection of separate programs.

It would not have all the bells and whistles - the search functions, the
> way Myth will keep a search for years and record much loved programmes
> after you have forgotten they existed... But it would be easier to set
> up and it would be less fragile.
>

Unless it was designed really well I think it'd be more fragile. It would
be very hard to handle errors between the various programs. If a recording
fails because a tuner is not working you'd want the scheduler to provide an
alternate tuner to use. That's not going to be easy to coordinate.

When Myth started, IMO, things were not so simple. Configuring tuner
> cards was the most finicky part of the process IIRC. In these days of
> digital tuners it is one of the simplest parts.
>

IMO the first stumbling block for Myth users is understanding the model:
video sources, recording groups, storage groups, etc. That stuff isn't
really that difficult and it's not where the problems usually appear. From
my perspective it seems most problems are caused by the external support
programs; the tuner drivers (which were once often difficult to get
working, as you note), the guide data import, lirc, ffmpeg etc. Changing
Myth's architecture wouldn't resolve problems caused by component pieces of
software and the fact that most issues arise from the bits that are already
highly modular suggests to me that further modularisation isn't going to
improve the situation.

The obvious way to make Myth simpler and a better user experience is to
follow Apple's model: limit hardware options and limit configuration
options. But that is not what the sort of people who use Linux want.

Cheers,
Steve

On Sat, Jun 21, 2014 at 5:24 PM, Nick Rout <nick.rout@gmail.com> wrote:

> On Fri, Jun 20, 2014 at 11:10 PM, Steve Hodge <stevehodge@gmail.com>
> wrote:
>
> > My problems were probably more to do with running Gentoo that updating
> Myth
> > per se.
>
> Yeah at least in a ubuntu LTS environment you know your versions of
> kernel lirc etc won't change markedly until you update to the next
> LTS 2 years later.
>

There's a lot to be said for that. I run Gentoo because it's great for
learning about how a complete Linux system works and I like being able to
see exactly which software depends on what. But it really needs to be keep
up to date because if too many packages are updated at once there are
inevitably problems. Even updating 6 monthly is not frequent enough but I
just don't have the time. However, I'm not excited by the idea of
reinstalling with something else either.


> Having said that I use a remote that is purely HID based and doesn't
> touch or depend on lirc. It has an easily configurable keymap and is
> easy to switch keymaps when, eg, switching from myth to xbmc and back.
>

I don't bother with a remote at all, I use a wireless keyboard (one
designed for couch use). But I still need lirc to drive the Sky box.


> I also use HDHR tuners which are less likely to suffer problems on a
> kernel update than a PCI or USB tuner.
>

If I go to DVB-T I'll certainly be getting a HDHR. It looks to be clearly
the best solution.


> >Issues like updated myth core packages without updated plugins such
> > as mythmusic or mythvideo.
>
> Don't do music on the TV and I use xbmc for videos, but yes that would
> present a problem.
>

I don't really do music these days either. I'd switch to xbmc but we use
timestretch a lot and I think that's still not implemented in xmbc, right?

Cheers,
Steve

On Sat, Jun 21, 2014 at 5:46 PM, Steve Hodge <stevehodge@gmail.com> wrote:
> On Sat, Jun 21, 2014 at 5:24 PM, Nick Rout <nick.rout@gmail.com> wrote:
>>
>> On Fri, Jun 20, 2014 at 11:10 PM, Steve Hodge <stevehodge@gmail.com>
>> wrote:
>>
>> > My problems were probably more to do with running Gentoo that updating
>> > Myth
>> > per se.
>>
>> Yeah at least in a ubuntu LTS environment you know your versions of
>> kernel lirc etc won't change markedly until you update to the next
>> LTS 2 years later.
>
>
> There's a lot to be said for that. I run Gentoo because it's great for
> learning about how a complete Linux system works and I like being able to
> see exactly which software depends on what. But it really needs to be keep
> up to date because if too many packages are updated at once there are
> inevitably problems. Even updating 6 monthly is not frequent enough but I
> just don't have the time. However, I'm not excited by the idea of
> reinstalling with something else either.

I used gentoo for quite some time and gave talks on it at CLUG, ran
gentoo installfests and converted many locals to it. But in the end I
valued my time more.

Also it didn't make a usable mythtv at the time (don't ask me how long
ago, but 2007 or before). I unstalled Knoppmyth (then knoppix based)
and it worked out of the box. Eventually I moved to ubuntu on pretty
well everything, or mint on my desktop.


>
>>
>> Having said that I use a remote that is purely HID based and doesn't
>> touch or depend on lirc. It has an easily configurable keymap and is
>> easy to switch keymaps when, eg, switching from myth to xbmc and back.
>
>
> I don't bother with a remote at all, I use a wireless keyboard (one designed
> for couch use). But I still need lirc to drive the Sky box.
>
>>
>> I also use HDHR tuners which are less likely to suffer problems on a
>> kernel update than a PCI or USB tuner.
>
>
> If I go to DVB-T I'll certainly be getting a HDHR. It looks to be clearly
> the best solution.
>

Buy from nicegear, the proprietor is a member here and an all round good guy.


>>
>> >Issues like updated myth core packages without updated plugins such
>> > as mythmusic or mythvideo.
>>
>> Don't do music on the TV and I use xbmc for videos, but yes that would
>> present a problem.
>
>
> I don't really do music these days either. I'd switch to xbmc but we use
> timestretch a lot and I think that's still not implemented in xmbc, right?
>


True, I miss that!

Music is a separate squeezebox infrastructure, although the
logitechmediaserver is on the same box as mythbackend.

Interesting side-discussion, but how do we get Worik sorted?

_______________________________________________
mythtvnz mailing list
mythtvnz@lists.linuxnut.co.nz
http://lists.ourshack.com/mailman/listinfo/mythtvnz
Archives http://www.gossamer-threads.com/lists/mythtv/mythtvnz/