[mythtv-users] Mything thomething

[Simon Hobson]

Fluf wrote:

>Dare you to delete all your channel, transponder, input card and 
>source data from setup. Then re-set-it up again. (You get to keep 
>the searches .. hehe, now watch with delight as the channel numbers 
>don't match up if you set a particular channel?)

Had to do that several times just over a year ago as we had our 
"digital switchover" and they messed around with the channels several 
times. OK, it comes under your category of needing to know SQL, but 
there are several scripts on the Wiki (I wrote one of them) where you 
can put in key data (such as Callsign-Channel number mappings) and it 
will reset them in one go.


Jay Ashworth wrote:

>But since there's no reasonable way to back out an upgrade, what
>can you do, when you "upgrade it", and it goes in the toilet?

Personally I can roll back my system completely to it's state on any 
day for the last few months. It's something called "a backup" and is 
not the responsibility of an application developer. Myth is not alone 
in this, I don't think any of my systems have the facility built in - 
Mac OS X doesn't*, Debian doesn't**, and I don't think any of the 
applications I have with their own updaters have it.

* You can do it with Time Machine - but that's "a backup". OK it's a 
finction that comes included with the OS, but it's still not a built 
in "I want to roll back this update" function.

** You can do it manually (but it's a faff, been there, done it) IFF 
you still have the .debs for the older package versions available.

I think the only system I've used that DID have that facility was the 
SCO OpenServer I used to manage. There you could roll back 
updates/patches - but only in reverse order to how they were applied. 
Ie, if you applied A, B, and C, then to rollback B you would have to 
rollback C, then B, then reapply C.


Joe Henley wrote:
>I gotta agree with "fluffkinuk at yahoo."
>...
>What takes so long?  Little to no documentation (sorry, what was written
>for a version three rounds ago and is mostly complete is NOT
>sufficient).  Documentation written by someone who thinks they are
>writing it for someone who already knows how to do it.  Documentation
>which some say is inferior to reading the code (really, are you
>serious?).  I'm old enough to remember the old IBM mainframe and
>mf/language documentation.  Completely unintelligible, unless you
>already knew what to do -- then it served fairly well as a cross
>reference.  Some of what I read today is worse.  And there seem to be
>some folks who openly applaud that type of documentation with a wave of
>the hand and a "if you don't write code to enhance the product, don't
>complain about the product."

I agree to a point, but I have to point out that some FOSS projects 
have excellent documentation - and some commercial software has 
documentation far worse than Myth. It's a fundamental problem that 
writing GOOD documentation is hard, in some ways harder than coding 
(that's not an invitation to start a flame war).
In the commercial world, IFF the management decide to spend the 
budget on it, you can pay the right people to do the job properly. 
More often than not, the wrong people are pressganged into it and the 
results are predictable.
In the FOSS world (at least outside of the projects with 
sponsorship), you have to take what skills get volunteered. Given how 
small my contribution is, I am not going to criticise those are are 
trying - even though they may not be the right people or have enough 
spare time.

In general, the people that are building a system are NOT the right 
people to be writing the documentation. Firstly, the skills are 
usually different, secondly they "know where they are going" and so 
it's easy to miss things out that are obvious to them but may be 
completely obscure to the target audience. I see the same thing with 
road signage - all too often, the people designing direction signs 
are familiar with the area and so cannot see when they've left a gap !


Tyler T wrote:

>I would embrace US ATSC EIT as a primary listings input path (though
>SD/XMLTV would still be supported). I'm convinced Myth users/devs only
>scoff at ATSC EIT because it was poor when ATSC was new.

Here I would strongly disagree. The correct approach is as it is now 
- a modular input system that allows for the fact that not all users 
are in the USA ! This is an area where IMO the devs have got it spot 
on - you select the listings input method based on what is available 
in your area, and if there's still a choice, your preference.



But having said all the above, I'm still on 0.21. Yes it took me some 
time to get it working - for a while there were some issues that just 
prevented it compiling. Since I have had it working, I would never go 
back. I am going to be looking at upgrading shortly, but I'll be 
upgrading my hardware at the same time and so have the luxury of 
parallel running till I get the new system up and running.
Just to make life difficult for myself, I'll also be looking at going 
HD since there are reports of the PCTV NanoStick T2 290e working.

-- 
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.