Mailing List Archive: MythTV: Dev

MythTV life-cycle support intentions

1 2

View All

Index | Next | Previous | View Threaded

gary.buhrmaster at gmail

Jul 23, 2012, 5:59 PM

Post #1 of 28 (1548 views)
Permalink

MythTV life-cycle support intentions

A developer question. This is a question that I was unable to find
a documented answer to on either the main web site, nor the wiki.

Historically, it appears by observation, that "back-porting" fixes
from master has been mostly limited to (a) what is possible to
back-port (well, obviously!), and (b) one version. So, for example,
during the (to be) 0.26 development cycle, many fixes were
backported to 0.25, but few to 0.24 (which may be more reflective
of (a) than anything else).

With the pending release of 0.26, does this mean that it is likely
that (with the occasional exception) that fixes in master will
likely be back-ported only to 0.26 and not 0.25 (and likely never
0.24)?

Regardless of the answer, could you point me to the page
that documents the developers intentions for life-cycle
support plans? Note I am not asking for commitments
(details always matter, resources are sometimes not
available, etc.), just the general intentions.

Thanks.

Gary
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-dev

jyavenard at gmail

Jul 23, 2012, 6:14 PM

Post #2 of 28 (1515 views)
Permalink

Re: MythTV life-cycle support intentions [In reply to]

Hi

On 24 July 2012 10:59, Gary Buhrmaster <gary.buhrmaster [at] gmail> wrote:
> Historically, it appears by observation, that "back-porting" fixes
> from master has been mostly limited to (a) what is possible to
> back-port (well, obviously!), and (b) one version. So, for example,
> during the (to be) 0.26 development cycle, many fixes were
> backported to 0.25, but few to 0.24 (which may be more reflective
> of (a) than anything else).

I personally have backported fixed from master to the latest official
release. But never to the previous release.
Don't see the point, this is not a commercial enterprise...

If people want support, they can update to the latest version.

> With the pending release of 0.26, does this mean that it is likely
> that (with the occasional exception) that fixes in master will
> likely be back-ported only to 0.26 and not 0.25 (and likely never
> 0.24)?

I'd say that's exactly how it's going to be.

We had plan to maintain a backport branch, that includes all the
master backports that do not require a schema or protocol change... I
was supposed to do it, but lack of time (and will) made it not happen.
That 0.26 was supposed to be a short-cycle released didn't help. I see
0.26 mostly has a bug fix release and/or finishing features that were
incomplete in 0.25
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-dev

gjhurlbu at gmail

Jul 23, 2012, 6:53 PM

Post #3 of 28 (1517 views)
Permalink

Re: MythTV life-cycle support intentions [In reply to]

On Mon, Jul 23, 2012 at 6:14 PM, Jean-Yves Avenard <jyavenard [at] gmail> wrote:
> If people want support, they can update to the latest version.

Usually. Or they can live with it, or backport it themselves...
Sometimes it's nearly impossible to backport further back.

> We had plan to maintain a backport branch, that includes all the
> master backports that do not require a schema or protocol change... I
> was supposed to do it, but lack of time (and will) made it not happen.
> That 0.26 was supposed to be a short-cycle released didn't help. I see
> 0.26 mostly has a bug fix release and/or finishing features that were
> incomplete in 0.25

We could think about that again, but we haven't gotten there yet :)
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-dev

J.Pilk at tesco

Jul 24, 2012, 9:45 AM

Post #4 of 28 (1495 views)
Permalink

Re: MythTV life-cycle support intentions [In reply to]

On 24/07/12 02:53, Gavin Hurlbut wrote:
> On Mon, Jul 23, 2012 at 6:14 PM, Jean-Yves Avenard <jyavenard [at] gmail> wrote:
>> If people want support, they can update to the latest version.

I think it should be recognised that many people - and even some on the
mailing lists - don't want support; they want a system that will work
and won't cause domestic stress. That implies that a new release should
be fully tested /for its old features/ as well as the new. I'm not
convinced that that always happens. As things are, a mature fixes build
would probably be the best option for this group. Suggesting that they
should all switch asap to a new release is unrealistic. New problems
will surface as more of them gradually upgrade. I would hope that these
would still warrant attention from the devs, although I recognise the
allure of the bleeding edge :-)

John P

>
> Usually. Or they can live with it, or backport it themselves...
> Sometimes it's nearly impossible to backport further back.
>
>> We had plan to maintain a backport branch, that includes all the
>> master backports that do not require a schema or protocol change... I
>> was supposed to do it, but lack of time (and will) made it not happen.
>> That 0.26 was supposed to be a short-cycle released didn't help. I see
>> 0.26 mostly has a bug fix release and/or finishing features that were
>> incomplete in 0.25
>
> We could think about that again, but we haven't gotten there yet :)

_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-dev

adeffs.mythtv at gmail

Jul 24, 2012, 10:17 AM

Post #5 of 28 (1496 views)
Permalink

Re: MythTV life-cycle support intentions [In reply to]

On Tue, Jul 24, 2012 at 12:45 PM, John Pilkington <J.Pilk [at] tesco> wrote:
> On 24/07/12 02:53, Gavin Hurlbut wrote:
>> On Mon, Jul 23, 2012 at 6:14 PM, Jean-Yves Avenard <jyavenard [at] gmail>
>> wrote:
>>> If people want support, they can update to the latest version.
>
> I think it should be recognised that many people - and even some on the
> mailing lists - don't want support; they want a system that will work and
> won't cause domestic stress. That implies that a new release should be
> fully tested /for its old features/ as well as the new. I'm not convinced
> that that always happens. As things are, a mature fixes build would
> probably be the best option for this group. Suggesting that they should all
> switch asap to a new release is unrealistic. New problems will surface as
> more of them gradually upgrade. I would hope that these would still warrant
> attention from the devs, although I recognise the allure of the bleeding
> edge :-)

a lot of that is because most users are not willing to test during the
beta and release candidate period on a live system, so issues are not
found until more do run it. nature of the beast, and why the -fixes
branch exists.There is also initial hesitation after a release for
many to install it for fear of these bugs as well, but without more
people testing sometimes bugs take a long time to get discovered.
Again, I'm not really sure how to overcome that without the devs
having more test systems, something which is also difficult to expect.

If memory serves me correctly, the first few weeks after a major
release all the dev's are in new-bugs-found squashing mode as those
come in, before beginning back at added feature work for the next
release.

I'd say, it is generally the case that regressions don't occur often,
and they seem to be fixed as soon as a good bug report is submitted.
I'll add that sometimes getting that bug report requires some extra
help of the devs to the user that doesn't occur, but that may just
need a better wiki entry?

I do think that the problem is that regression bugs tend to show up in
big ways, like the current LiveTV bug, or the scheduler bug that was
causing the backend to freeze on people. But these are being
addressed, so it falls into the "warranted attention has been
provided" group.

BUT, that said, I don't see why support for more than a single older
version should be required. the big driving factor to updates is
hardware advances (VDPAU, CableCards, etc), so if someone with older
hardware is still running, say 0.24, I imagine at this point they're
pretty happy with how it works and the features it has, or they would
upgrade. Except for a few minor exceptions no loss of hardware support
has occurred that made a huge adverse affect on 99% of users, so even
those people could upgrade to 0.26 and all their hardware should still
work.

--
Steve
http://www.mythtv.org/wiki/User:Steveadeff
Before you ask, read the FAQ!
http://www.mythtv.org/wiki/Frequently_Asked_Questions
then search the Wiki, and this list,
http://www.gossamer-threads.com/lists/mythtv/
Mailinglist etiquette - http://www.mythtv.org/wiki/Mailing_List_etiquette
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-dev

brian at interlinx

Jul 24, 2012, 10:39 AM

Post #6 of 28 (1499 views)
Permalink

Re: MythTV life-cycle support intentions [In reply to]

On 12-07-24 01:17 PM, Steven Adeff wrote:
>
> a lot of that is because most users are not willing to test during the
> beta and release candidate period on a live system,

And I'd guess that's because downgrading an upgraded (i.e. to beta and
release candidate releases) Myth installation is so traumatic. If one
wants to endure trying to drop databases and restore them (which mysql
greenhorns are not going to be comfortable with) then a downgrade
immediately after an upgrade is at least doable, but you've recorded a
dozen programs already only to find that showstopper bug that you need
to downgrade because the wife is screaming mad at you.

Now what? Restore the pre-upgrade database and lose those 12
recordings? Do you think that's going to make her any happier?

If Myth provided +/-1 database compatibility so that one could upgrade
and downgrade as simply as installing/removing packages, I bet more
people would be willing to dip a toe in while the pool is still being
filled up instead of waiting until it's full.

b.

Attachments:

signature.asc (0.26 KB)

monkeypet at gmail

Jul 24, 2012, 12:52 PM

Post #7 of 28 (1487 views)
Permalink

Re: MythTV life-cycle support intentions [In reply to]

On Tue, Jul 24, 2012 at 10:39 AM, Brian J. Murrell <brian [at] interlinx>wrote:

> On 12-07-24 01:17 PM, Steven Adeff wrote:
> >
> > a lot of that is because most users are not willing to test during the
> > beta and release candidate period on a live system,
>
> And I'd guess that's because downgrading an upgraded (i.e. to beta and
> release candidate releases) Myth installation is so traumatic. If one
> wants to endure trying to drop databases and restore them (which mysql
> greenhorns are not going to be comfortable with) then a downgrade
> immediately after an upgrade is at least doable, but you've recorded a
> dozen programs already only to find that showstopper bug that you need
> to downgrade because the wife is screaming mad at you.
>
> Now what? Restore the pre-upgrade database and lose those 12
> recordings? Do you think that's going to make her any happier?
>
> If Myth provided +/-1 database compatibility so that one could upgrade
> and downgrade as simply as installing/removing packages, I bet more
> people would be willing to dip a toe in while the pool is still being
> filled up instead of waiting until it's full.
>

Yes, not being able to downgrade easily is a major bummer. I bet if it was
easier, please would be able to try it, then if it doesn't work, file a
bugreport and downgrade until the bug is fixed, then try again.

>
> b.
>
>
> _______________________________________________
> mythtv-dev mailing list
> mythtv-dev [at] mythtv
> http://www.mythtv.org/mailman/listinfo/mythtv-dev
>
>

J.Pilk at tesco

Jul 24, 2012, 1:40 PM

Post #8 of 28 (1492 views)
Permalink

Re: MythTV life-cycle support intentions [In reply to]

On 24/07/12 20:52, Monkey Pet wrote:
> On Tue, Jul 24, 2012 at 10:39 AM, Brian J. Murrell
> <brian [at] interlinx <mailto:brian [at] interlinx>> wrote:
>
> On 12-07-24 01:17 PM, Steven Adeff wrote:
> >
> > a lot of that is because most users are not willing to test
> during the
> > beta and release candidate period on a live system,
>
> And I'd guess that's because downgrading an upgraded (i.e. to beta and
> release candidate releases) Myth installation is so traumatic. If one
> wants to endure trying to drop databases and restore them (which mysql
> greenhorns are not going to be comfortable with) then a downgrade
> immediately after an upgrade is at least doable, but you've recorded a
> dozen programs already only to find that showstopper bug that you need
> to downgrade because the wife is screaming mad at you.
>
> Now what? Restore the pre-upgrade database and lose those 12
> recordings? Do you think that's going to make her any happier?
>
> If Myth provided +/-1 database compatibility so that one could upgrade
> and downgrade as simply as installing/removing packages, I bet more
> people would be willing to dip a toe in while the pool is still being
> filled up instead of waiting until it's full.
>
>
> Yes, not being able to downgrade easily is a major bummer. I bet if it
> was easier, please would be able to try it, then if it doesn't work,
> file a bugreport and downgrade until the bug is fixed, then try again.
>
>
> b.
>

If the only problem there is recovering recordings the 'native archive'
mode of MythArchive might be a starting point. It needs some TLC but
I've used it for 0.25 > 0.24. DVDs don't have to be involved.

_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-dev

brian at interlinx

Jul 24, 2012, 4:53 PM

Post #9 of 28 (1486 views)
Permalink

Re: MythTV life-cycle support intentions [In reply to]

On 12-07-24 04:40 PM, John Pilkington wrote:
>
> If the only problem there is recovering recordings the 'native archive'
> mode of MythArchive might be a starting point.

Automate the whole downgrading procedure so that it "mytharchives" the
recordings done since the upgrade, restores the pre-upgrade database and
then restores the mytharchived recordings and you might have some more
interest in beta/rc-testing.

Seriously.

Cheers,
b.

Attachments:

signature.asc (0.26 KB)

adeffs.mythtv at gmail

Jul 25, 2012, 9:39 AM

Post #10 of 28 (1477 views)
Permalink

Re: MythTV life-cycle support intentions [In reply to]

On Tue, Jul 24, 2012 at 7:53 PM, Brian J. Murrell <brian [at] interlinx> wrote:
> On 12-07-24 04:40 PM, John Pilkington wrote:
>>
>> If the only problem there is recovering recordings the 'native archive'
>> mode of MythArchive might be a starting point.
>
> Automate the whole downgrading procedure so that it "mytharchives" the
> recordings done since the upgrade, restores the pre-upgrade database and
> then restores the mytharchived recordings and you might have some more
> interest in beta/rc-testing.
>
> Seriously.
>
> Cheers,
> b.

My concern there would be if the recorded table changes due to the upgrade.

Is there a way to populate an existing table with data from another
table, ignoring any new fields in the source that do not exist in the
target?

--
Steve
http://www.mythtv.org/wiki/User:Steveadeff
Before you ask, read the FAQ!
http://www.mythtv.org/wiki/Frequently_Asked_Questions
then search the Wiki, and this list,
http://www.gossamer-threads.com/lists/mythtv/
Mailinglist etiquette - http://www.mythtv.org/wiki/Mailing_List_etiquette
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-dev

mtdean at thirdcontact

Aug 22, 2012, 2:15 PM

Post #11 of 28 (1246 views)
Permalink

Re: MythTV life-cycle support intentions [In reply to]

On 07/25/2012 12:39 PM, Steven Adeff wrote:
> On Tue, Jul 24, 2012 at 7:53 PM, Brian J. Murrell wrote:
>> On 12-07-24 04:40 PM, John Pilkington wrote:
>>> If the only problem there is recovering recordings the 'native archive'
>>> mode of MythArchive might be a starting point.
>> Automate the whole downgrading procedure so that it "mytharchives" the
>> recordings done since the upgrade, restores the pre-upgrade database and
>> then restores the mytharchived recordings and you might have some more
>> interest in beta/rc-testing.
>>
>> Seriously.
> My concern there would be if the recorded table changes due to the upgrade.
>
> Is there a way to populate an existing table with data from another
> table, ignoring any new fields in the source that do not exist in the
> target?
>

This is why the approved solution is to put any "not recorded by /this/
MythTV instance and database" videos into Video Library.

FWIW ( http://www.mythtv.org/wiki/Database_Backup_and_Restore ):

mythconverg_backup.pl

and put the resultant backup file somewhere safe. Then upgrade, record
a bunch of shows and find out hours/days/weeks/months later that the new
version completely destroys your favorite feature. So:

mythlink.pl --link /mnt/pretty --format '%Y%m%d-%H%i-%eH%ei-%T-%S'

then

mythconverg_restore.pl --drop_database --create_database \
--filename mythconverg-1214-20080626150513.sql.gz

and downgrade. Then, using the links--which are sorted by date/time,
you can get a good title/subtitle for each recording made after the
upgrade and move it to use that name and place it in the Video Library
directories, where it's available. Or, just use mythvidexport.py to
move the new recordings to Video Libray before you downgrade.

Note that when I'm working on my dev system, I always do at least one
restore to a previous (known-good, previous-release-version) database
backup each night and also create a new backup after updating listings.
It's actually not uncommon for me to do multiple (sometimes tens of)
backups/restores per night. I don't know of any way I can make it
easier for users (though I get the feeling that some users are "too
smart" to need the scripts we have, so maybe that's why so many think
it's difficult to backup/restore the MythTV database).

Mike
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-dev

brian at interlinx

Aug 22, 2012, 2:39 PM

Post #12 of 28 (1242 views)
Permalink

Re: MythTV life-cycle support intentions [In reply to]

On 12-08-22 05:15 PM, Michael T. Dean wrote:
>
> This is why the approved solution is to put any "not recorded by /this/
> MythTV instance and database" videos into Video Library.

With all due respect Mike, I've seen you up on this soapbox a number of
times in the last week or two and I cannot bite my tongue any more.

Having to flip back and forth between TV Recordings and Videos to find
and watch my TV recordings is just craziness. Things that are shown on
TV belong in TV Reordings and other things, like movies -- ripped from
the DVDs we buy, belong in Videos. As does stuff taken off of video
cameras, etc. -- you know, like, "videos".

b.

[1] and worse, asking my family to, after trying to teaching them to
flip back and forth -- all the while failing at answering questions
like: "but why are *some* TV shows in the Videos folder and how do I
know which ones I will find where, again?"

Attachments:

signature.asc (0.26 KB)

mtdean at thirdcontact

Aug 22, 2012, 3:31 PM

Post #13 of 28 (1242 views)
Permalink

Re: MythTV life-cycle support intentions [In reply to]

On 08/22/2012 05:39 PM, Brian J. Murrell wrote:
> On 12-08-22 05:15 PM, Michael T. Dean wrote:
>> This is why the approved solution is to put any "not recorded by /this/
>> MythTV instance and database" videos into Video Library.
> With all due respect Mike, I've seen you up on this soapbox a number of
> times in the last week or two and I cannot bite my tongue any more.
>
> Having to flip back and forth between TV Recordings and Videos to find
> and watch my TV recordings is just craziness. Things that are shown on
> TV belong in TV Reordings and other things, like movies -- ripped from
> the DVDs we buy, belong in Videos. As does stuff taken off of video
> cameras, etc. -- you know, like, "videos".
>
> b.
>
> [1] and worse, asking my family to, after trying to teaching them to
> flip back and forth -- all the while failing at answering questions
> like: "but why are *some* TV shows in the Videos folder and how do I
> know which ones I will find where, again?"

I suppose, then, that you never ever record any Movies? ("But why are
*some* movies in Watch Recordings and others in Video Library and how do
I know which ones I will find where, again?") For me, the origin and
type (TV or movies) of the video is really irrelevant. If I record
Stargate SG-1 and love it so much that I decide I want to see the
Stargate movies and buy the DVDs, I'm not going to keep the TV series in
Watch Recordings and the movies I ripped from DVD in Video Library--I'll
put it all together in the one location that allows me to add any video
and organize it myself.

I was describing the right approach for making sure you can watch
recordings made after you upgraded but before you decided to downgrade
instead of fixing the issue. If you actually plan to keep those
recordings--they're not just watch and delete shows--then you should
really put them in Video Library, along with all the other episodes of
that show. If you have other related recordings from before the
upgrade, move them to Video Library, too--even if you don't plan to keep
them--just to keep them together. (Video Library is designed for
managing large collections of video, unlike Watch Recordings, and you
can organize it how you like and use file names that are meaningful, so
that the content is always identifiable even if you lose the MythTV
database and ...)

Of course, making this argument is about like the Live TV argument.
Those who are unwilling to keep an open mind or who are too set in their
ways will just never see the benefits.

So the part you're not getting is that I'm not saying to just put random
things in Video Library--I'm saying put anything there that you plan to
keep. What I don't understand is why people seem to think that it makes
sense to segregate video content--why should you have to teach your
family to flip back and forth between "TV Recordings" and Videos to find
something? (Since I'm guessing that you don't have family meetings to
let everyone know which movies or TV you've bought on DVD and ripped and
which other ones you recorded, why would they know whether something
they're looking for was purchased and ripped or recorded?) I'm simply
saying to put virtually everything in Video Library, so all the
interesting video to watch is available in one location and your family
just goes into Video Library to find whatever they want (and navigates
the folders or uses the filters and the sort options to find what they
want).

Mike
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-dev

brian at interlinx

Aug 22, 2012, 4:36 PM

Post #14 of 28 (1240 views)
Permalink

Re: MythTV life-cycle support intentions [In reply to]

On 12-08-22 06:31 PM, Michael T. Dean wrote:
>
> I suppose, then, that you never ever record any Movies?

Actually, no, I don't. If I want to watch a movie, I'd rather see it
not-edited-for-television and commercialized. So I rent it.

> ("But why are
> *some* movies in Watch Recordings and others in Video Library and how do
> I know which ones I will find where, again?")

Doesn't happen here.

> For me, the origin and
> type (TV or movies) of the video is really irrelevant. If I record
> Stargate SG-1 and love it so much that I decide I want to see the
> Stargate movies and buy the DVDs, I'm not going to keep the TV series in
> Watch Recordings and the movies I ripped from DVD in Video Library--I'll
> put it all together in the one location that allows me to add any video
> and organize it myself.

In fact, the difference between TV Recordings and Videos is even more
subtle than that. It's mostly about "transientness" where Videos is for
stuff you want to keep and TV Recordings is for stuff you want to watch,
because it was shown, and then you delete it. But this transientness
directly correlates (movies shown on TV that you decide to archive,
aside -- but as I said, we don't do that here) between TV Recordings and
Videos.

But this correlation between location and transientness supports my
argument of craziness: it's unnatural to go looking for these transient
recordings in Videos.

> I was describing the right approach for making sure you can watch
> recordings

Which are most likely transient TV Recordings.

> made after you upgraded but before you decided to downgrade
> instead of fixing the issue. If you actually plan to keep those
> recordings--they're not just watch and delete shows--then you should
> really put them in Video Library,

Sure, but that's a strawman to the issue -- having to put transient
recordings that happened between upgrade and downgrade somewhere where
they are not expected.

> along with all the other episodes of
> that show.

But again, it's a strawman to start talking about the possibility that
these between upgrade and downgrade recordings *might* be desirable to
long-term archive in Videos. I'd posit that more times than not, they
don't qualify and are just transient recordings.

> If you have other related recordings from before the
> upgrade, move them to Video Library, too--even if you don't plan to keep
> them--just to keep them together. (Video Library is designed for
> managing large collections of video, unlike Watch Recordings,

Right. I'd suggest that a "collection" implies a desire for long-term
storage. Most TV Recordings probably don't qualify for the average
viewer/user. My TV Recordings set is quite large, almost none of which
I desire long-term storage of. In fact, quite a bit of it will be
deleted without even watching. This is because we record every new show
on -- September is gangbusters for Mythtv around here. We of course
cannot watch every new show, but we can wait out the first 3 months and
see what survives and what doesn't and purge what doesn't.

> and you
> can organize it how you like and use file names that are meaningful, so
> that the content is always identifiable even if you lose the MythTV
> database and ...)

Again, all strawman. Let's talk about the transient recordings you get
between upgrade and downgrade.

> So the part you're not getting is that I'm not saying to just put random
> things in Video Library--I'm saying put anything there that you plan to
> keep.

Sure. No argument from me. But I was addressing your point of putting
between-upgrade-and-downgrade recordings into the Video library as well
simply because they would not be considered recorded by /this/ MythTV
instance. That's why all of the rest of this archival-quality moving of
stuff to Videos is a strawman to this point.

Ultimately, this goes back to my point that if downgrading were painless
(including inserting between-upgrade-and-downgrade recordings back into
the downgraded database), you'd get a lot more people willing to test
pre-GA.

b.

Attachments:

signature.asc (0.26 KB)

mtdean at thirdcontact

Aug 22, 2012, 6:01 PM

Post #15 of 28 (1239 views)
Permalink

Re: MythTV life-cycle support intentions [In reply to]

On 08/22/2012 07:36 PM, Brian J. Murrell wrote:
> On 12-08-22 06:31 PM, Michael T. Dean wrote:
>> I suppose, then, that you never ever record any Movies?
> Actually, no, I don't. If I want to watch a movie, I'd rather see it
> not-edited-for-television and commercialized. So I rent it.
>
>> ("But why are
>> *some* movies in Watch Recordings and others in Video Library and how do
>> I know which ones I will find where, again?")
> Doesn't happen here.
>
>> For me, the origin and
>> type (TV or movies) of the video is really irrelevant. If I record
>> Stargate SG-1 and love it so much that I decide I want to see the
>> Stargate movies and buy the DVDs, I'm not going to keep the TV series in
>> Watch Recordings and the movies I ripped from DVD in Video Library--I'll
>> put it all together in the one location that allows me to add any video
>> and organize it myself.
> In fact, the difference between TV Recordings and Videos is even more
> subtle than that. It's mostly about "transientness" where Videos is for
> stuff you want to keep and TV Recordings is for stuff you want to watch,
> because it was shown, and then you delete it. But this transientness
> directly correlates (movies shown on TV that you decide to archive,
> aside -- but as I said, we don't do that here) between TV Recordings and
> Videos.
>
> But this correlation between location and transientness supports my
> argument of craziness: it's unnatural to go looking for these transient
> recordings in Videos.
>
>> I was describing the right approach for making sure you can watch
>> recordings
> Which are most likely transient TV Recordings.
>
>> made after you upgraded but before you decided to downgrade
>> instead of fixing the issue. If you actually plan to keep those
>> recordings--they're not just watch and delete shows--then you should
>> really put them in Video Library,
> Sure, but that's a strawman to the issue -- having to put transient
> recordings that happened between upgrade and downgrade somewhere where
> they are not expected.
>
>> along with all the other episodes of
>> that show.
> But again, it's a strawman to start talking about the possibility that
> these between upgrade and downgrade recordings *might* be desirable to
> long-term archive in Videos. I'd posit that more times than not, they
> don't qualify and are just transient recordings.
>
>> If you have other related recordings from before the
>> upgrade, move them to Video Library, too--even if you don't plan to keep
>> them--just to keep them together. (Video Library is designed for
>> managing large collections of video, unlike Watch Recordings,
> Right. I'd suggest that a "collection" implies a desire for long-term
> storage. Most TV Recordings probably don't qualify for the average
> viewer/user. My TV Recordings set is quite large, almost none of which
> I desire long-term storage of. In fact, quite a bit of it will be
> deleted without even watching. This is because we record every new show
> on -- September is gangbusters for Mythtv around here. We of course
> cannot watch every new show, but we can wait out the first 3 months and
> see what survives and what doesn't and purge what doesn't.
>
>> and you
>> can organize it how you like and use file names that are meaningful, so
>> that the content is always identifiable even if you lose the MythTV
>> database and ...)
> Again, all strawman. Let's talk about the transient recordings you get
> between upgrade and downgrade.

Call it a strawman or whatever.

I've /been/ saying in all of my discussion of using Video Library that
it's /the/ place for archival of videos--where you put videos to keep.
So you're completely agreeing with me, except about...

>> So the part you're not getting is that I'm not saying to just put random
>> things in Video Library--I'm saying put anything there that you plan to
>> keep.
> Sure. No argument from me. But I was addressing your point of putting
> between-upgrade-and-downgrade recordings into the Video library as well
> simply because they would not be considered recorded by /this/ MythTV
> instance. That's why all of the rest of this archival-quality moving of
> stuff to Videos is a strawman to this point.

the shows that were recorded when you tried to upgrade and failed to
make things work properly.

For this particular case, I'm saying you can just throw those recordings
into some temporary area in Video Library--since it's better than the
alternative of losing them or being "forced" to actually try to figure
out what's wrong and make the new version work. And, since they're
transient recordings, anyway, you'll watch and delete them in no time,
then that failed upgrade will fade from everyone's memory--along with
those transient recordings you've now deleted--right?

> Ultimately, this goes back to my point that if downgrading were painless
> (including inserting between-upgrade-and-downgrade recordings back into
> the downgraded database), you'd get a lot more people willing to test
> pre-GA.

It's not. It wouldn't be painless for us to make it painless (and
forever be stuck trying to keep all our future changes such that we
could support upgrades and downgrades)***. So the best we can offer,
currently, is "stick those recordings in Video Library until you watch
them."

Mike

*** Not to mention that if 0.26 supports easy downgrade to 0.25 and 0.25
supports easy downgrade to 0.24 and ..., users will think they can go
back to any version and up to any newer version at all just by rolling
back changes one by one. We have a hard enough time making sure that
database upgrades work properly--and convincing users that if they have
a failure, they need to restore the pre-upgrade backup (that they
invariably forget to create) before attempting the upgrade again. I
know I don't have the energy to try to support upgrades and downgrades
or "work with the old schema/data versions in the newer application
version" or ... The current approach is tiring enough for me. :)
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-dev

michael at thewatsonfamily

Aug 22, 2012, 6:13 PM

Post #16 of 28 (1242 views)
Permalink

Re: MythTV life-cycle support intentions [In reply to]

On 23/08/2012 9:36 AM, Brian J. Murrell wrote:
> Ultimately, this goes back to my point that if downgrading were painless
> (including inserting between-upgrade-and-downgrade recordings back into
> the downgraded database), you'd get a lot more people willing to test
> pre-GA.
>
> b.
>

Seems to me that, it would not be to difficult to write and
import/export script that either;

Exports all current recordings and relevant data since schema was
change (either automatically via date stored in database of when schema
was updated [if this data is even stored] or via a user entered date
Imports routine would ignore any new data not required/used by
previous schema

OR

Exports the entire database into say XML, so that import routine
from previous version can simply ignore data that it does not
recognize. IMHO this would provide a better backup, as it would be
"compatible" with any version of Myth, rather than current backup which
is only compatible with current versions or newer versions.

Regards,
Michael

_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-dev

ctreleaven at cogeco

Aug 22, 2012, 6:40 PM

Post #17 of 28 (1233 views)
Permalink

Re: MythTV life-cycle support intentions [In reply to]

At 11:13 AM +1000 8/23/12, Michael Watson wrote:
>On 23/08/2012 9:36 AM, Brian J. Murrell wrote:
>>Ultimately, this goes back to my point that if downgrading were painless
>>(including inserting between-upgrade-and-downgrade recordings back into
>>the downgraded database), you'd get a lot more people willing to test
>>pre-GA.
>
>Seems to me that, it would not be to difficult to write and
>import/export script that either;
>
> Exports all current recordings and relevant data since schema
>was change (either automatically via date stored in database of when
>schema was updated [if this data is even stored] or via a user
>entered date
> Imports routine would ignore any new data not required/used by
>previous schema
>
>OR
>
> Exports the entire database into say XML, so that import routine
>from previous version can simply ignore data that it does not
>recognize. IMHO this would provide a better backup, as it would be
>"compatible" with any version of Myth, rather than current backup
>which is only compatible with current versions or newer versions.

So here's what we do: every Myth user goes out and buys $5-10* of
tickets in their local mega-lottery and earmarks the tickets for
Myth. As soon as somebody wins, presto--we've got the funding to do
this and lots of other cool stuff.

Just don't let the Myth tickets get mixed up with your tickets! ;)

The only other plausible alternative is for you, Michael, or me,
Craig, to start coding up what you've described. And I'm pretty sure
it is not going to be me! ;(

Craig
*or local currency equivalent.
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-dev

michael at thewatsonfamily

Aug 22, 2012, 6:54 PM

Post #18 of 28 (1232 views)
Permalink

Re: MythTV life-cycle support intentions [In reply to]

On 23/08/2012 11:40 AM, Craig Treleaven wrote:
> At 11:13 AM +1000 8/23/12, Michael Watson wrote:
>> On 23/08/2012 9:36 AM, Brian J. Murrell wrote:
>>> Ultimately, this goes back to my point that if downgrading were
>>> painless
>>> (including inserting between-upgrade-and-downgrade recordings back into
>>> the downgraded database), you'd get a lot more people willing to test
>>> pre-GA.
>>
>> Seems to me that, it would not be to difficult to write and
>> import/export script that either;
>>
>> Exports all current recordings and relevant data since schema was
>> change (either automatically via date stored in database of when
>> schema was updated [if this data is even stored] or via a user
>> entered date
>> Imports routine would ignore any new data not required/used by
>> previous schema
>>
>> OR
>>
>> Exports the entire database into say XML, so that import routine
>> from previous version can simply ignore data that it does not
>> recognize. IMHO this would provide a better backup, as it would be
>> "compatible" with any version of Myth, rather than current backup
>> which is only compatible with current versions or newer versions.
>
> So here's what we do: every Myth user goes out and buys $5-10* of
> tickets in their local mega-lottery and earmarks the tickets for
> Myth. As soon as somebody wins, presto--we've got the funding to do
> this and lots of other cool stuff.
>
> Just don't let the Myth tickets get mixed up with your tickets! ;)
>
> The only other plausible alternative is for you, Michael, or me,
> Craig, to start coding up what you've described. And I'm pretty sure
> it is not going to be me! ;(
>
> Craig
> *or local currency equivalent.
Point me in the direction of where to find details of schema for 0.24,
0.25 and 0.26.
Im not a "real" coder, and DB's where never really my thing. But I
reckon I can give it a crack. I might be blind, stupid, or just crazy,
but it doesnt really sound difficult to me.

_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-dev

gary.buhrmaster at gmail

Aug 22, 2012, 6:58 PM

Post #19 of 28 (1235 views)
Permalink

Re: MythTV life-cycle support intentions [In reply to]

On Thu, Aug 23, 2012 at 1:13 AM, Michael Watson
<michael [at] thewatsonfamily> wrote:
....
> Seems to me that, it would not be to difficult to write and import/export
> script that either;
>
> Exports all current recordings and relevant data since schema was change
> (either automatically via date stored in database of when schema was updated
> [if this data is even stored] or via a user entered date
> Imports routine would ignore any new data not required/used by previous
> schema

In some specific cases, perhaps. But in other cases, the columns themselves
get renamed, modified (in a specific way), or re-normalized (into other tables).

Could one easily reverse some of those changes? Sure. Can one reverse
others? Not easily (if even possible(*)). As with much else, one is free to
create such a routine, and then closely follow the commit list and build
the reversal into your routine.

(btw, mysqldump already supports a --xml option, at least in recent versions.)

Gary

(*) A classic problem case is for tables where all rows where a column
has a value "1" the column is changed to "2", but any "2"s are left as is.
Which ones would need to be reversed?
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-dev

michael at thewatsonfamily

Aug 22, 2012, 7:12 PM

Post #20 of 28 (1234 views)
Permalink

Re: MythTV life-cycle support intentions [In reply to]

On 23/08/2012 11:58 AM, Gary Buhrmaster wrote:
> On Thu, Aug 23, 2012 at 1:13 AM, Michael Watson
> <michael [at] thewatsonfamily> wrote:
> ....
>> Seems to me that, it would not be to difficult to write and import/export
>> script that either;
>>
>> Exports all current recordings and relevant data since schema was change
>> (either automatically via date stored in database of when schema was updated
>> [if this data is even stored] or via a user entered date
>> Imports routine would ignore any new data not required/used by previous
>> schema
> In some specific cases, perhaps. But in other cases, the columns themselves
> get renamed, modified (in a specific way), or re-normalized (into other tables).
>
> Could one easily reverse some of those changes? Sure. Can one reverse
> others? Not easily (if even possible(*)). As with much else, one is free to
> create such a routine, and then closely follow the commit list and build
> the reversal into your routine.
>
> (btw, mysqldump already supports a --xml option, at least in recent versions.)
>
> Gary
>
> (*) A classic problem case is for tables where all rows where a column
> has a value "1" the column is changed to "2", but any "2"s are left as is.
> Which ones would need to be reversed?
>
For a rollback situation, I am thinking that it would only need to be
concerned with recorded, and (possibly) oldrecorded tables. I presume
this is the only relevent data needed to be downgraded/imported after
restoring backup from previous schema.. Music / Videos can be rescanned
easily, and less likely to changed greatly have "testing/evaluating"
newer version.

* Mind boggles as to why a 1 would become a 2, but a 2 would stay a 2.....

_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-dev

ctreleaven at cogeco

Aug 22, 2012, 7:17 PM

Post #21 of 28 (1233 views)
Permalink

Re: MythTV life-cycle support intentions [In reply to]

At 11:54 AM +1000 8/23/12, Michael Watson wrote:
>On 23/08/2012 11:40 AM, Craig Treleaven wrote:
>>At 11:13 AM +1000 8/23/12, Michael Watson wrote:
>>>On 23/08/2012 9:36 AM, Brian J. Murrell wrote:
>>>>Ultimately, this goes back to my point that if downgrading were painless
>>>>(including inserting between-upgrade-and-downgrade recordings back into
>>>>the downgraded database), you'd get a lot more people willing to test
>>>>pre-GA.
>>>
>>>Seems to me that, it would not be to difficult to write and
>>>import/export script that either;
>>>
>>> Exports all current recordings and relevant data since schema
>>>was change (either automatically via date stored in database of
>>>when schema was updated [if this data is even stored] or via a
>>>user entered date
>>> Imports routine would ignore any new data not required/used by
>>>previous schema
>>>
>>>OR
>>>
>>> Exports the entire database into say XML, so that import
>>>routine from previous version can simply ignore data that it does
>>>not recognize. IMHO this would provide a better backup, as it
>>>would be "compatible" with any version of Myth, rather than
>>>current backup which is only compatible with current versions or
>>>newer versions.
>>
>>So here's what we do: every Myth user goes out and buys $5-10* of
>>tickets in their local mega-lottery and earmarks the tickets for
>>Myth. As soon as somebody wins, presto--we've got the funding to
>>do this and lots of other cool stuff.
>>
>>Just don't let the Myth tickets get mixed up with your tickets! ;)
>>
>>The only other plausible alternative is for you, Michael, or me,
>>Craig, to start coding up what you've described. And I'm pretty
>>sure it is not going to be me! ;(
>>
>>Craig
>>*or local currency equivalent.
>Point me in the direction of where to find details of schema for
>0.24, 0.25 and 0.26.
>Im not a "real" coder, and DB's where never really my thing. But I
>reckon I can give it a crack. I might be blind, stupid, or just
>crazy, but it doesnt really sound difficult to me.

http://www.mythtv.org/wiki/Database_Schema

There is a single source code file contains all the schema changes
but I can't remember where to find it and couldn't locate it in a few
minutes of browsing.

Craig

_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-dev

michael at thewatsonfamily

Aug 22, 2012, 9:43 PM

Post #22 of 28 (1227 views)
Permalink

Re: MythTV life-cycle support intentions [In reply to]

On 23/08/2012 11:58 AM, Gary Buhrmaster wrote:
> On Thu, Aug 23, 2012 at 1:13 AM, Michael Watson
> <michael [at] thewatsonfamily> wrote:
> ....
>> Seems to me that, it would not be to difficult to write and import/export
>> script that either;
>>
>> Exports all current recordings and relevant data since schema was change
>> (either automatically via date stored in database of when schema was updated
>> [if this data is even stored] or via a user entered date
>> Imports routine would ignore any new data not required/used by previous
>> schema
> In some specific cases, perhaps. But in other cases, the columns themselves
> get renamed, modified (in a specific way), or re-normalized (into other tables).
>
> Could one easily reverse some of those changes? Sure. Can one reverse
> others? Not easily (if even possible(*)). As with much else, one is free to
> create such a routine, and then closely follow the commit list and build
> the reversal into your routine.
>
> (btw, mysqldump already supports a --xml option, at least in recent versions.)
>
> Gary
>
> (*) A classic problem case is for tables where all rows where a column
> has a value "1" the column is changed to "2", but any "2"s are left as is.
> Which ones would need to be reversed?
>
If rollback was to be supported, then it would be better to checked for
the merged "meanings" of these values in the code, rather than update
the database at upgrade time.

_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-dev

azmail at thezawackis

Aug 23, 2012, 8:56 AM

Post #23 of 28 (1217 views)
Permalink

Re: MythTV life-cycle support intentions [In reply to]

> On 08/22/2012 09:01 PM, Michael T. Dean wrote:
>> On 08/22/2012 07:36 PM, Brian J. Murrell wrote:
>> Ultimately, this goes back to my point that if downgrading were painless
>> (including inserting between-upgrade-and-downgrade recordings back into
>> the downgraded database), you'd get a lot more people willing to test
>> pre-GA.
>
> It's not. It wouldn't be painless for us to make it painless (and
> forever be stuck trying to keep all our future changes such that we
> could support upgrades and downgrades)***. So the best we can offer,
> currently, is "stick those recordings in Video Library until you watch
> them."
>

Perhaps my background colors my thinking (I am a developer,) but rolling
back is not a normal course of action. The idea that recordings that
were made by the "new" system are not listed as recorded by the "old"
system makes perfect sense. You rolled back the transaction, now the
system doesn't know anything about the recordings. I don't think it's
unnatural, and I don't think it would make sense to try to support it.
it should be a rare occasion, and you should be knowing what you are
getting into before you upgrade / rollback, and you should be prepared
for the results.

I agree with your sentiment, that if it was easy, then more people would
test the pre-GA code. Most of the people that are currently testing
pre-GA code probably fall into two camps:

1) Those that have a secondary MythTV system, where one MythTV is in
"production" and the other MythTV is a test system.

2) Those that do not have families that rely on the MythTV system for
their TV watching enjoyment.

I don't think Brian (or myself for that matter) falls into either of
these camps. When running pre-GA code, you have to be willing to accept
glitches as bugs are worked out. If MythTV fails to record the favorite
show of your family, your so-called WAF will fall dramatically. Yet
that is a real risk in Pre-GA code.

Anthony
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-dev

lsorense at csclub

Aug 23, 2012, 9:38 AM

Post #24 of 28 (1219 views)
Permalink

Re: MythTV life-cycle support intentions [In reply to]

On Thu, Aug 23, 2012 at 11:56:15AM -0400, Anthony Zawacki wrote:
> Perhaps my background colors my thinking (I am a developer,) but
> rolling back is not a normal course of action. The idea that
> recordings that were made by the "new" system are not listed as
> recorded by the "old" system makes perfect sense. You rolled back
> the transaction, now the system doesn't know anything about the
> recordings. I don't think it's unnatural, and I don't think it
> would make sense to try to support it. it should be a rare occasion,
> and you should be knowing what you are getting into before you
> upgrade / rollback, and you should be prepared for the results.

Of course not supporting that is what makes a lot of users not want to
test newer versions and then bugs are found right after a new release
comes out because it wasn't tested in that scenario.

Not sure how one would support it, but it would certainly increase the
potential pool of testers.

> I agree with your sentiment, that if it was easy, then more people
> would test the pre-GA code. Most of the people that are currently
> testing pre-GA code probably fall into two camps:
>
> 1) Those that have a secondary MythTV system, where one MythTV is
> in "production" and the other MythTV is a test system.
>
> 2) Those that do not have families that rely on the MythTV system
> for their TV watching enjoyment.
>
> I don't think Brian (or myself for that matter) falls into either of
> these camps. When running pre-GA code, you have to be willing to
> accept glitches as bugs are worked out. If MythTV fails to record
> the favorite show of your family, your so-called WAF will fall
> dramatically. Yet that is a real risk in Pre-GA code.

Yeah too risky for me to try. I sometimes think I need a second mythtv
box for testing, but that would require a lot of expensive tuner hardware.

--
Len Sorensen
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-dev

simon at koala

Aug 23, 2012, 12:54 PM

Post #25 of 28 (1213 views)
Permalink

Re: MythTV life-cycle support intentions [In reply to]

On 08/23/12 16:56, Anthony Zawacki wrote:
> Perhaps my background colors my thinking (I am a developer,) but rolling
> back is not a normal course of action.

if you were a ruby on rails developer you would think that rolling back
was completely normal. but in the context of mythtv the use-case is
pretty limited.
--
simon
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-dev

1 2

View All

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads