Mailing List Archive: MythTV: Dev

Interesting Comparison

1 2 3

View All

Index | Next | Previous | View Threaded

mythtv at zacglen

Mar 3, 2006, 12:44 AM

Post #1 of 54 (4917 views)
Permalink

Interesting Comparison

I have just completed my web-based equivalent of MythTV.

The only things missing at this stage are all the extras (which
I can hardly see myself using since I have a computer) like phone,
browser, etc.

It is interesting to make a comparison.
MythTV has about 112,792 lines of code.
My implementation has about 1731 lines of Perl.

Additionally, my implementation has the following features:

- the only interface is via browser (which I didn't have to write)
- there is no database, only plain text files
- there is no XML
- it is fast
- it is highly configurable with all configuration in plain files
- the recording format can be whatever anyone chooses

Some of the implementation details which have helped keep it simple are:

- Hardware contention is only resolved at record time.
I use a simple lockfile containing pid and priority.
When a conflict occurs a lower priority job can preempt running job.
Or a higher priority job will lock out a lower priority job, but
it will still possibly run for a reduced duration.
At scheduling time there is absolutely no possibility of conflict.

- Instead of XML the program guide information is in simple
column-delimited format, with first line being the column definitions.
Times are in UTC. That is all that is needed.

- All configuration data is simple "name = value" expressions.
But to allow 1:n relationships I simply look for plural names.
So that "guides = fta-%Y%m%d other-%Y%m%d", for example,
generates a Perl array.
Wont work for foreign languages but I reckon it would have
been simpler for the whole world to convert to English rather
that have every programmer die in agony anyhow.

I intend to add a few more features, mainly with respect to the automated
recording selection plus some alternate tv guide sources.

KISS to all you MythTV developers.

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

myth-mail at matt-sam

Mar 3, 2006, 12:52 AM

Post #2 of 54 (4821 views)
Permalink

Re: Interesting Comparison [In reply to]

On Fri, 03 Mar 2006 19:44:22 +1100, <mythtv [at] zacglen> wrote:

> I have just completed my web-based equivalent of MythTV.
>
> It is interesting to make a comparison.
> MythTV has about 112,792 lines of code.
> My implementation has about 1731 lines of Perl.
>
> KISS to all you MythTV developers.

Wow - You showed them!

You're my new geek hero. Congratulations.

How about you contribute to the project or start your own? Either way
your post contributes nothing to the list other than flame-bait.
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

cpinkham at bc2va

Mar 3, 2006, 1:21 AM

Post #3 of 54 (4819 views)
Permalink

Re: Interesting Comparison [In reply to]

> I have just completed my web-based equivalent of MythTV.

I've just completed my soap-box derby equivalent of a Lamborghini.

> The only things missing at this stage are all the extras (which
> I can hardly see myself using since I have a computer) like phone,
> browser, etc.

The only things missing at this stage are all the extras (which I
can hardly see myself using since I ride the bus) like an engine,
comfortable seats, etc..

> It is interesting to make a comparison.
> MythTV has about 112,792 lines of code.
> My implementation has about 1731 lines of Perl.

It is interesting to make a comparison.
A Lamborghini has a few thousand bolts and weighs over a ton.
My soap-box derby car has a few dozen nails and weighs in just under
120 pounds.

> Additionally, my implementation has the following features:
>
> - the only interface is via browser (which I didn't have to write)
> - there is no database, only plain text files
> - there is no XML
> - it is fast
> - it is highly configurable with all configuration in plain files
> - the recording format can be whatever anyone chooses

Additionally my implemtation has the following features:

- It's cheap (cause I don't have any money)
- It's easy to drive (cause I have no clue what that pole sticking
out of the floor with the numbers and the letter 'R' in an H
pattern is for).
- It is fast (going down big hills that are straigth and don't have
any bumps)
- I get to wear a cool helmet while I drive.
- It's a convertible (this is why I want the helmet)
- Tires are cheaper since I have a few old lawnmowers rusting out
in the back yard.
- The stearing wheel is also made from an old tire, so it doubles
as a spare and a steering wheel.
- It doesn't use any gas at all.
- I don't have to worry about getting the doors dinged when I take
it to the playground with me.

> Some of the implementation details which have helped keep it simple are:
>
> - Hardware contention is only resolved at record time.
> I use a simple lockfile containing pid and priority.
> When a conflict occurs a lower priority job can preempt running job.
> Or a higher priority job will lock out a lower priority job, but
> it will still possibly run for a reduced duration.
> At scheduling time there is absolutely no possibility of conflict.
>
> - Instead of XML the program guide information is in simple
> column-delimited format, with first line being the column definitions.
> Times are in UTC. That is all that is needed.
>
> - All configuration data is simple "name = value" expressions.
> But to allow 1:n relationships I simply look for plural names.
> So that "guides = fta-%Y%m%d other-%Y%m%d", for example,
> generates a Perl array.
> Wont work for foreign languages but I reckon it would have
> been simpler for the whole world to convert to English rather
> that have every programmer die in agony anyhow.

Some of the implementation details which have helped keep it simple are:

- I got the wood from an old crate I found on the side of the road
the other day.
- My side-business repairing lawnmowers has left me with a huge number
of spare wheels so I never have to spend any money.
- Use of nails instead of bolts helped save me time because I didn't
have to turn any nuts with a wrench, I just hit the suckers with
a hammer and they went right in.
- I didn't have to spend any money an an alarm system because nobody
in their right mind would steal my ride.

> I intend to add a few more features, mainly with respect to the automated
> recording selection plus some alternate tv guide sources.

I intend to add a few more features, mainly with respect to the overall
safety and roadworthiness of the vehicle. I think that if I cut a big
enough hole in the floorboard, I can put my feet out through the hold
to both provide additional braking while trying to stop and useful
acceleration while going downhill. I am going to add spinners to my
wheels made out of some old lawnmower blades trimmed down and sharpened
up.

> KISS to all you MythTV developers.

KISS to all you losers who fly by me on the interstate.
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

mythtv at zacglen

Mar 3, 2006, 1:32 AM

Post #4 of 54 (4818 views)
Permalink

Re: Interesting Comparison [In reply to]

>> I have just completed my web-based equivalent of MythTV.
>
>I've just completed my soap-box derby equivalent of a Lamborghini.
>

I never claimed to be creating a Lamborghini.
And I don't think MythTV developers have made such a claim either.
They definitely haven't made one.

>> The only things missing at this stage are all the extras (which
>> I can hardly see myself using since I have a computer) like phone,
>> browser, etc.
>
>The only things missing at this stage are all the extras (which I
>can hardly see myself using since I ride the bus) like an engine,
>comfortable seats, etc..

They are not extras, you fool.

>
>> It is interesting to make a comparison.
>> MythTV has about 112,792 lines of code.
>> My implementation has about 1731 lines of Perl.
>
>It is interesting to make a comparison.
>A Lamborghini has a few thousand bolts and weighs over a ton.

Really? Mine doesn't.

>My soap-box derby car has a few dozen nails and weighs in just under
>120 pounds.

Are you alluding to the current MythTV?

>
>> Additionally, my implementation has the following features:
>>
>
>> - the only interface is via browser (which I didn't have to write)
>> - there is no database, only plain text files
>> - there is no XML
>> - it is fast
>> - it is highly configurable with all configuration in plain files
>> - the recording format can be whatever anyone chooses
>
>Additionally my implemtation has the following features:
>
> - It's cheap (cause I don't have any money)

Must be because of your attitide.

> - It's easy to drive (cause I have no clue what that pole sticking
> out of the floor with the numbers and the letter 'R' in an H
> pattern is for).

You should get an education!

> - It is fast (going down big hills that are straigth and don't have
> any bumps)

Pity it doesn't go uphill like mine.

> - I get to wear a cool helmet while I drive.
> - It's a convertible (this is why I want the helmet)
> - Tires are cheaper since I have a few old lawnmowers rusting out
> in the back yard.
So you aren't much good at keeping lawnmowers in working order?

> - The stearing wheel is also made from an old tire, so it doubles
> as a spare and a steering wheel.
> - It doesn't use any gas at all.
> - I don't have to worry about getting the doors dinged when I take
> it to the playground with me.
>
>> Some of the implementation details which have helped keep it simple are:
>>
>
>> - Hardware contention is only resolved at record time.
>> I use a simple lockfile containing pid and priority.
>> When a conflict occurs a lower priority job can preempt running job.
>> Or a higher priority job will lock out a lower priority job, but
>> it will still possibly run for a reduced duration.
>> At scheduling time there is absolutely no possibility of conflict.
>>
>
>> - Instead of XML the program guide information is in simple
>> column-delimited format, with first line being the column definitions.
>> Times are in UTC. That is all that is needed.
>>
>
>> - All configuration data is simple "name = value" expressions.
>> But to allow 1:n relationships I simply look for plural names.
>> So that "guides = fta-%Y%m%d other-%Y%m%d", for example,
>> generates a Perl array.
>> Wont work for foreign languages but I reckon it would have
>> been simpler for the whole world to convert to English rather
>> that have every programmer die in agony anyhow.
>
>Some of the implementation details which have helped keep it simple are:
>
> - I got the wood from an old crate I found on the side of the road
> the other day.

Oh, so then re-using existing software is a bad thing?

> - My side-business repairing lawnmowers has left me with a huge number
> of spare wheels so I never have to spend any money.

You side-business isn't very successful. Else you wouldn't have so
many broken ones lying around!

> - Use of nails instead of bolts helped save me time because I didn't
> have to turn any nuts with a wrench, I just hit the suckers with
> a hammer and they went right in.

Nails are often provide vasty superior adhesion than screws.
Ask any builder.
BTW where do you think the "screw loose" saying came from?

> - I didn't have to spend any money an an alarm system because nobody
> in their right mind would steal my ride.

Great analogy!

>
>> I intend to add a few more features, mainly with respect to the automated
>> recording selection plus some alternate tv guide sources.
>
>I intend to add a few more features, mainly with respect to the overall
>safety and roadworthiness of the vehicle. I think that if I cut a big
>enough hole in the floorboard, I can put my feet out through the hold
>to both provide additional braking while trying to stop and useful
>acceleration while going downhill. I am going to add spinners to my
>wheels made out of some old lawnmower blades trimmed down and sharpened
>up.
>
>> KISS to all you MythTV developers.
>
>KISS to all you losers who fly by me on the interstate.
>

You wit is only exceeded by your irrelevance.

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

abostock at gmail

Mar 3, 2006, 1:47 AM

Post #5 of 54 (4819 views)
Permalink

Re: Interesting Comparison [In reply to]

No idea what the point of starting this thread was but at least reading
Chris Pinkham's reply did crack me up :)

Ash.

On 03/03/06, mythtv [at] zacglen <mythtv [at] zacglen> wrote:
>
> >> I have just completed my web-based equivalent of MythTV.
> >
> >I've just completed my soap-box derby equivalent of a Lamborghini.
> >
>
> I never claimed to be creating a Lamborghini.
> And I don't think MythTV developers have made such a claim either.
> They definitely haven't made one.
>
> >> The only things missing at this stage are all the extras (which
> >> I can hardly see myself using since I have a computer) like phone,
> >> browser, etc.
> >
> >The only things missing at this stage are all the extras (which I
> >can hardly see myself using since I ride the bus) like an engine,
> >comfortable seats, etc..
>
> They are not extras, you fool.
>
> >
> >> It is interesting to make a comparison.
> >> MythTV has about 112,792 lines of code.
> >> My implementation has about 1731 lines of Perl.
> >
> >It is interesting to make a comparison.
> >A Lamborghini has a few thousand bolts and weighs over a ton.
>
> Really? Mine doesn't.
>
> >My soap-box derby car has a few dozen nails and weighs in just under
> >120 pounds.
>
> Are you alluding to the current MythTV?
>
> >
> >> Additionally, my implementation has the following features:
> >>
> >
> >> - the only interface is via browser (which I didn't have to write)
> >> - there is no database, only plain text files
> >> - there is no XML
> >> - it is fast
> >> - it is highly configurable with all configuration in plain files
> >> - the recording format can be whatever anyone chooses
> >
> >Additionally my implemtation has the following features:
> >
> > - It's cheap (cause I don't have any money)
>
> Must be because of your attitide.
>
> > - It's easy to drive (cause I have no clue what that pole sticking
> > out of the floor with the numbers and the letter 'R' in an H
> > pattern is for).
>
> You should get an education!
>
> > - It is fast (going down big hills that are straigth and don't have
> > any bumps)
>
> Pity it doesn't go uphill like mine.
>
> > - I get to wear a cool helmet while I drive.
> > - It's a convertible (this is why I want the helmet)
> > - Tires are cheaper since I have a few old lawnmowers rusting out
> > in the back yard.
> So you aren't much good at keeping lawnmowers in working order?
>
> > - The stearing wheel is also made from an old tire, so it doubles
> > as a spare and a steering wheel.
> > - It doesn't use any gas at all.
> > - I don't have to worry about getting the doors dinged when I take
> > it to the playground with me.
> >
> >> Some of the implementation details which have helped keep it simple
> are:
> >>
> >
> >> - Hardware contention is only resolved at record time.
> >> I use a simple lockfile containing pid and priority.
> >> When a conflict occurs a lower priority job can preempt running
> job.
> >> Or a higher priority job will lock out a lower priority job, but
> >> it will still possibly run for a reduced duration.
> >> At scheduling time there is absolutely no possibility of
> conflict.
> >>
> >
> >> - Instead of XML the program guide information is in simple
> >> column-delimited format, with first line being the column
> definitions.
> >> Times are in UTC. That is all that is needed.
> >>
> >
> >> - All configuration data is simple "name = value" expressions.
> >> But to allow 1:n relationships I simply look for plural names.
> >> So that "guides = fta-%Y%m%d other-%Y%m%d", for example,
> >> generates a Perl array.
> >> Wont work for foreign languages but I reckon it would have
> >> been simpler for the whole world to convert to English rather
> >> that have every programmer die in agony anyhow.
> >
> >Some of the implementation details which have helped keep it simple are:
> >
> > - I got the wood from an old crate I found on the side of the road
> > the other day.
>
> Oh, so then re-using existing software is a bad thing?
>
> > - My side-business repairing lawnmowers has left me with a huge
> number
> > of spare wheels so I never have to spend any money.
>
> You side-business isn't very successful. Else you wouldn't have so
> many broken ones lying around!
>
> > - Use of nails instead of bolts helped save me time because I didn't
> > have to turn any nuts with a wrench, I just hit the suckers with
> > a hammer and they went right in.
>
> Nails are often provide vasty superior adhesion than screws.
> Ask any builder.
> BTW where do you think the "screw loose" saying came from?
>
> > - I didn't have to spend any money an an alarm system because nobody
> > in their right mind would steal my ride.
>
> Great analogy!
>
> >
> >> I intend to add a few more features, mainly with respect to the
> automated
> >> recording selection plus some alternate tv guide sources.
> >
> >I intend to add a few more features, mainly with respect to the overall
> >safety and roadworthiness of the vehicle. I think that if I cut a big
> >enough hole in the floorboard, I can put my feet out through the hold
> >to both provide additional braking while trying to stop and useful
> >acceleration while going downhill. I am going to add spinners to my
> >wheels made out of some old lawnmower blades trimmed down and sharpened
> >up.
> >
> >> KISS to all you MythTV developers.
> >
> >KISS to all you losers who fly by me on the interstate.
> >
>
> You wit is only exceeded by your irrelevance.
>
> _______________________________________________
> mythtv-dev mailing list
> mythtv-dev [at] mythtv
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
>

mythtv at zacglen

Mar 3, 2006, 2:03 AM

Post #6 of 54 (4820 views)
Permalink

Re: Interesting Comparison [In reply to]

>No idea what the point of starting this thread was but at least reading
>Chris Pinkham's reply did crack me up :)
>

The point is that MythTV is bloated bug-ridden software which
mostly just duplicates the functionality of a browser.

Do the math - 112,792 lines vs a probable 3000 lines of Perl.

Do the experiment - try developing a Perl/whatever version and see how far you
get, how long it takes, and what the result is like.

I have taken the trouble to do the experiment.
The results are impressive.

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

zartzartzart+mythtv-dev at gmail

Mar 3, 2006, 2:10 AM

Post #7 of 54 (4818 views)
Permalink

Re: Interesting Comparison [In reply to]

Are you saying you actually implemented OSD, XvMC acceleration,
VIA XvMC acceleration, LiveTV (with pause, etc.)
in... perl? Or is that in the normal feature set of a browser?

I'm impressed if the answer to any of those questions is yes,
though I don't think it is...?

On 3/3/06, mythtv [at] zacglen <mythtv [at] zacglen> wrote:
>
> >No idea what the point of starting this thread was but at least reading
> >Chris Pinkham's reply did crack me up :)
> >
>
> The point is that MythTV is bloated bug-ridden software which
> mostly just duplicates the functionality of a browser.
>
> Do the math - 112,792 lines vs a probable 3000 lines of Perl.
>
> Do the experiment - try developing a Perl/whatever version and see how far
> you
> get, how long it takes, and what the result is like.
>
> I have taken the trouble to do the experiment.
> The results are impressive.
>
> _______________________________________________
> mythtv-dev mailing list
> mythtv-dev [at] mythtv
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
>

mythtv at zacglen

Mar 3, 2006, 2:17 AM

Post #8 of 54 (4817 views)
Permalink

Re: Interesting Comparison [In reply to]

>Are you saying you actually implemented OSD, XvMC acceleration,
>VIA XvMC acceleration, LiveTV (with pause, etc.)
>in... perl? Or is that in the normal feature set of a browser?

OSD is not a feature of a browser.
But OSD is a feature of mplayer, for example.
Mplayer is existing software that can be reused.

XvMC is a feature of X11 - so I don't know what on
earth you are on about.

LiveTV is just playing back a recored video.
Nothing special at all. You can pause a recorded video
with the pause button on most players.

>
>I'm impressed if the answer to any of those questions is yes,
>though I don't think it is...?

Interesting questions.

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

mythtv at zacglen

Mar 3, 2006, 2:21 AM

Post #9 of 54 (4804 views)
Permalink

Re: Interesting Comparison [In reply to]

>> I have just completed my web-based equivalent of MythTV.
>put up or shut up?

Where would you like it?

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

mythdev at penyball

Mar 3, 2006, 2:22 AM

Post #10 of 54 (4801 views)
Permalink

Re: Interesting Comparison [In reply to]

> I have just completed my web-based equivalent of MythTV.
put up or shut up?
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

zartzartzart+mythtv-dev at gmail

Mar 3, 2006, 2:27 AM

Post #11 of 54 (4808 views)
Permalink

Re: Interesting Comparison [In reply to]

>OSD is not a feature of a browser.
>But OSD is a feature of mplayer, for example.
>Mplayer is existing software that can be reused.

Does mplayer let you skip between channels?
Or at least choose another channel while watching one?
Can it display info about the current show in its OSD?

I know XvMC is a feature of X11 - but I meant taking advantage of the
feature (Though mplayer would use it of course)

>LiveTV is just playing back a recored video.
>Nothing special at all. You can pause a recorded video
>with the pause button on most players.
Pausing was just an example. What about closed caption support,
tele text support?
But here you _might_ have a point. Maybe support for this should be
implemented in mplayer instead of making mythtv (the tv watching part)
I guess that's why the myth developers uses libraries - so they don't
have to reinvent the wheel all the time.

On 3/3/06, mythtv [at] zacglen <mythtv [at] zacglen> wrote:
>
> >Are you saying you actually implemented OSD, XvMC acceleration,
> >VIA XvMC acceleration, LiveTV (with pause, etc.)
> >in... perl? Or is that in the normal feature set of a browser?
>
> OSD is not a feature of a browser.
> But OSD is a feature of mplayer, for example.
> Mplayer is existing software that can be reused.
>
> XvMC is a feature of X11 - so I don't know what on
> earth you are on about.
>
> LiveTV is just playing back a recored video.
> Nothing special at all. You can pause a recorded video
> with the pause button on most players.
>
> >
> >I'm impressed if the answer to any of those questions is yes,
> >though I don't think it is...?
>
> Interesting questions.
>
> _______________________________________________
> mythtv-dev mailing list
> mythtv-dev [at] mythtv
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
>

cardboil at gmail

Mar 3, 2006, 2:36 AM

Post #12 of 54 (4814 views)
Permalink

Re: Interesting Comparison [In reply to]

On 3/3/06, mythtv [at] zacglen <mythtv [at] zacglen> wrote:
>
> >No idea what the point of starting this thread was but at least reading
> >Chris Pinkham's reply did crack me up :)
> >
>
> The point is that MythTV is bloated bug-ridden software which
> mostly just duplicates the functionality of a browser.
>
> Do the math - 112,792 lines vs a probable 3000 lines of Perl.
>
>
>
Obviously, mythtv [at] zacgle is a pain in the ass.

I am little curious about some points he raised (however idiotic his choice
of words may have been). Theoretically speaking, if one were to start with
a clean slate, do some of this guy's suggestions make sense? What I was
able to gather from this and the other thread (
http://www.gossamer-threads.com/lists/mythtv/dev/185962) are:

(Note: I am not making any judgements on technology choices and I am not
even qualified to do so; I'm just asking for the sake of my own learning.)

1. Use a browser as the UI framework instead of QT
2. Use files instead of database for settings and guide/recording data
3. He says something about "the recording format can be whatever anyone
chooses" -- not sure what he means

And, of course, he seems to prefer Perl but that's a religious war I don't
care about.

I'd be curious to hear what the devs think about this, just as an
intellectual exercise.

mythtv at zacglen

Mar 3, 2006, 2:43 AM

Post #13 of 54 (4813 views)
Permalink

Re: Interesting Comparison [In reply to]

>
>Does mplayer let you skip between channels?
>Or at least choose another channel while watching one?

Why would you choose another channel while you are watching one?
Wouldn't that mean that you aren't watching that one?

But I think I know what you are getting at.
Yes, the Perl scripts will preempt a current recording.
There would be a couple of seconds worth of interruption however.

But normally you wouldn't want to be browsing channels
becaused the whole point of a pvr is to eliminate the crap
and preserve what you really want to watch.

>
>Can it display info about the current show in its OSD?
>

That depends on the player you use.
My version doesn't dictate anything, you can specify the player
depending on hardware. For example, I have a DXR3 card which does
all the MPEG2 decoding in hardware.

So in my config file for certain recording hardware I can add:

play = "mplayer -ao oss:/dev/em8300_ma-0 -vo dxr3 -monitoraspect 5:4 -fixed-vo $FILES"

If you arrange to put detailed program information in subtitle
(using corresponding "record = xxxxx ${TITLE} xxxx ${DESCRIPTION} xxxx" config)
then you have your osd program information.

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

bob.green at logicacmg

Mar 3, 2006, 2:44 AM

Post #14 of 54 (4801 views)
Permalink

Re: Interesting Comparison [In reply to]

Okay, its head above the parapet time! Guys, guys, what's going on here?
Isn't this how wars start? Whatever happened to reasoned debate; to the
freedom to express an opinion without being shot down in flames. So,
someone has a new tool that he thinks is the dog's wotsits - how is that
a Bad Thing(tm). Do none of you programmers out there not remember what
its like to write some code that you think is great and you end up
boring all your friends with the details. Anyway I digress; my view (for
what it's worth) is that we should be openminded about any new
developments, large or small that in any way overlap MythTv's raison
d'etre. We can't believe that we have a monopoly on good ideas. As soon
as we stop looking outward, we end up with a product that is in danger
of becoming stale. Give this guy a chance. We might hate his offering,
we might like it - who knows, but whatever we do, we should encourage
this sort of thing rather than flame it. For those of you who remember
life before Linux, remember what happened to Andrew Tannenbaum of Minix
fame. He absolutely flamed Linus Torvalds and his software when he
announced version 0.11 of Linux and within a couple of months he and his
(up to then) thriving operating system had been consigned to obscurity.

Oh well, I'll stop ranting now, I guess I've made my point - the
stupidest idea is one that is never voiced for fear of it being
ridiculed.

Time for a lie down in a quiet room, I think :-)

-Bob

Bob Green
Rapid Software Infrastructure Manager
LogicaCMG
Office : (+44) 117 901 7550
Mobile : (+44 788 798 3072)
Fax (+44 1454 620 527)
www.logicacmg.com <blocked::http://www.logicacmg.com/>

________________________________

From: mythtv-dev-bounces [at] mythtv
[mailto:mythtv-dev-bounces [at] mythtv] On Behalf Of Lasse Nisted
Sent: 03 March 2006 10:11
To: Development of mythtv
Subject: Re: [mythtv] Interesting Comparison

Are you saying you actually implemented OSD, XvMC acceleration,
VIA XvMC acceleration, LiveTV (with pause, etc.)
in... perl? Or is that in the normal feature set of a browser?

I'm impressed if the answer to any of those questions is yes,
though I don't think it is...?

On 3/3/06, mythtv [at] zacglen < mythtv [at] zacglen
<mailto:mythtv [at] zacglen> > wrote:

>No idea what the point of starting this thread was but at least
reading
>Chris Pinkham's reply did crack me up :)
>

The point is that MythTV is bloated bug-ridden software which
mostly just duplicates the functionality of a browser.

Do the math - 112,792 lines vs a probable 3000 lines of Perl.

Do the experiment - try developing a Perl/whatever version and
see how far you
get, how long it takes, and what the result is like.

I have taken the trouble to do the experiment.
The results are impressive.

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

This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.

zartzartzart+mythtv-dev at gmail

Mar 3, 2006, 2:51 AM

Post #15 of 54 (4821 views)
Permalink

Re: Interesting Comparison [In reply to]

You bring up some valid questions. I would like to hear others opinions
also.

On 3/3/06, cardboil <cardboil [at] gmail> wrote:
>
> On 3/3/06, mythtv [at] zacglen <mythtv [at] zacglen> wrote:
>
> > >No idea what the point of starting this thread was but at least reading
> > >Chris Pinkham's reply did crack me up :)
> > >
> >
> > The point is that MythTV is bloated bug-ridden software which
> > mostly just duplicates the functionality of a browser.
> >
> > Do the math - 112,792 lines vs a probable 3000 lines of Perl.
> >
> >
> >
> Obviously, mythtv [at] zacgle is a pain in the ass.
>
> I am little curious about some points he raised (however idiotic his
> choice of words may have been). Theoretically speaking, if one were to
> start with a clean slate, do some of this guy's suggestions make sense?
> What I was able to gather from this and the other thread (
> http://www.gossamer-threads.com/lists/mythtv/dev/185962) are:
>
> (Note: I am not making any judgements on technology choices and I am not
> even qualified to do so; I'm just asking for the sake of my own learning.)
>
> 1. Use a browser as the UI framework instead of QT
>
Would save a lot of time for a simple solution. But what about fading menus,
simple navigation with remote control, _very_ flexible layout.
And _very_ flexible data reading - in lists like those in mythvideo not all
data has to be loaded at once. First when the user scrolls it's loaded.
I know all of this (i think) could be done in a browser. But that would
require either
extensive use of javascripting, flash or something like that.

So what would the benefits be in the end?

2. Use files instead of database for settings and guide/recording data
>

This I think is a stupid idea. Databases are for holding large amount of
data,
and allowing easy access to those. I don't see any reason why not to use
them.
Normal formatted files would require implementing a lot of extra routines
for accessing
data the right way. Which is just what the database does for you...

3. He says something about "the recording format can be whatever anyone
> chooses" -- not sure what he means
>

Dunno either.

- Lasse

mythtv at zacglen

Mar 3, 2006, 2:58 AM

Post #16 of 54 (4826 views)
Permalink

Re: Interesting Comparison [In reply to]

>Okay, its head above the parapet time! Guys, guys, what's going on here?
>Isn't this how wars start? Whatever happened to reasoned debate; to the
>freedom to express an opinion without being shot down in flames. So,
>someone has a new tool that he thinks is the dog's wotsits - how is that
>a Bad Thing(tm). Do none of you programmers out there not remember what
>its like to write some code that you think is great and you end up
>boring all your friends with the details. Anyway I digress; my view (for
>what it's worth) is that we should be openminded about any new
>developments, large or small that in any way overlap MythTv's raison
>d'etre. We can't believe that we have a monopoly on good ideas. As soon
>as we stop looking outward, we end up with a product that is in danger
>of becoming stale. Give this guy a chance. We might hate his offering,
>we might like it - who knows, but whatever we do, we should encourage
>this sort of thing rather than flame it. For those of you who remember
>life before Linux, remember what happened to Andrew Tannenbaum of Minix
>fame. He absolutely flamed Linus Torvalds and his software when he
>announced version 0.11 of Linux and within a couple of months he and his
>(up to then) thriving operating system had been consigned to obscurity.
>
>Oh well, I'll stop ranting now, I guess I've made my point - the
>stupidest idea is one that is never voiced for fear of it being
>ridiculed.
>
>Time for a lie down in a quiet room, I think :-)
>

That sounds reasonable to me.

My software isn't supposed to be particularly fantastic.
It is only supposed to work as I want it.

I was faced with a choice - dive into MythTV software and try and figure
out why it was consuming all of my cpu. And, based on my belief that
it was doing software decoding regardless of what I wanted, and also given
that it was recording in a format which wasn't useful for me, I decided
it would probably be more satisfactory to create my own.

Besides, I am not particularly interested in doing any scheduling
on my TV screen - there are so many computers in my house that it
seems plain silly to have to use a clunky IR control with clunky fonts
on a lowish resolution TV screen.

Besides, it is just as easy to plonk my laptop on the coffee table
which just happens to be somewhere in fron of my TV.

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

zartzartzart+mythtv-dev at gmail

Mar 3, 2006, 3:02 AM

Post #17 of 54 (4810 views)
Permalink

Re: Interesting Comparison [In reply to]

You are correct and I am sorry.

As an excuse I just didn't like him calling his perl script a
``web-based equivalent of MythTV'' -- It lacks many (important)
featurures. And those some of those features are the exact
reason why this is not written in perl, and why it's not just
~1700 lines of code.

But his ideas should not just be flamed. And of course a
big bloated bug infested code-base should be avoided.

- Lasse

On 3/3/06, Green, Bob <bob.green [at] logicacmg> wrote:
>
> Okay, its head above the parapet time! Guys, guys, what's going on here?
> Isn't this how wars start? Whatever happened to reasoned debate; to the
> freedom to express an opinion without being shot down in flames. So, someone
> has a new tool that he thinks is the dog's wotsits - how is that a Bad
> Thing(tm). Do none of you programmers out there not remember what its like
> to write some code that you think is great and you end up boring all your
> friends with the details. Anyway I digress; my view (for what it's worth) is
> that we should be openminded about any new developments, large or small that
> in any way overlap MythTv's raison d'etre. We can't believe that we have a
> monopoly on good ideas. As soon as we stop looking outward, we end up with a
> product that is in danger of becoming stale. Give this guy a chance. We
> might hate his offering, we might like it - who knows, but whatever we do,
> we should encourage this sort of thing rather than flame it. For those of
> you who remember life before Linux, remember what happened to Andrew
> Tannenbaum of Minix fame. He absolutely flamed Linus Torvalds and his
> software when he announced version 0.11 of Linux and within a couple of
> months he and his (up to then) thriving operating system had been consigned
> to obscurity.
>
> Oh well, I'll stop ranting now, I guess I've made my point - the stupidest
> idea is one that is never voiced for fear of it being ridiculed.
>
> Time for a lie down in a quiet room, I think :-)
>
> -Bob
>
> *Bob Green*
> Rapid Software Infrastructure Manager
> *LogicaCMG*
> Office : (+44) 117 901 7550
> Mobile : (+44 788 798 3072)
> Fax (+44 1454 620 527)
> www.logicacmg.com
>
>
> ------------------------------
> *From:* mythtv-dev-bounces [at] mythtv [mailto:
> mythtv-dev-bounces [at] mythtv] *On Behalf Of *Lasse Nisted
> *Sent:* 03 March 2006 10:11
> *To:* Development of mythtv
> *Subject:* Re: [mythtv] Interesting Comparison
>
> Are you saying you actually implemented OSD, XvMC acceleration,
> VIA XvMC acceleration, LiveTV (with pause, etc.)
> in... perl? Or is that in the normal feature set of a browser?
>
> I'm impressed if the answer to any of those questions is yes,
> though I don't think it is...?
>
> On 3/3/06, mythtv [at] zacglen < mythtv [at] zacglen> wrote:
>
> > >No idea what the point of starting this thread was but at least reading
>
> >Chris Pinkham's reply did crack me up :)
> >
>
> The point is that MythTV is bloated bug-ridden software which
> mostly just duplicates the functionality of a browser.
>
> Do the math - 112,792 lines vs a probable 3000 lines of Perl.
>
> Do the experiment - try developing a Perl/whatever version and see how far
> you
> get, how long it takes, and what the result is like.
>
> I have taken the trouble to do the experiment.
> The results are impressive.
>
> _______________________________________________
> mythtv-dev mailing list
> mythtv-dev [at] mythtv
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
>
>
>
> This e-mail and any attachment is for authorised use by the intended
> recipient(s) only. It may contain proprietary material, confidential
> information and/or be subject to legal privilege. It should not be copied,
> disclosed to, retained or used by, any other party. If you are not an
> intended recipient then please promptly delete this e-mail and any
> attachment and all copies and inform the sender. Thank you.
>
> _______________________________________________
> mythtv-dev mailing list
> mythtv-dev [at] mythtv
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
>
>
>

mythtv at zacglen

Mar 3, 2006, 3:13 AM

Post #18 of 54 (4816 views)
Permalink

Re: Interesting Comparison [In reply to]

>Would save a lot of time for a simple solution. But what about fading menus
>,
>simple navigation with remote control, _very_ flexible layout.

Simple navigation is possible with a browser. You just have to get
the tabbing order right.

>And _very_ flexible data reading - in lists like those in mythvideo not all
>dataof has to be loaded at once. First when the user scrolls it's loaded.

To load the program guide (current time, and 24 hours plus and minus)
only takes a second. Mainly because there is no XML.
Add XML and you are talking slower times because you have to bear with
XML telling you that "23" is an "integer" or something ridiculous.

>I know all of this (i think) could be done in a browser. But that would
>require either
>extensive use of javascripting, flash or something like that.

There is sone Javascript in my implementation.
Mainly to update main window when program detail popup schedules
something, and to popup certain windows when required.

>
>So what would the benefits be in the end?
>

Simplicity?

>
>
>2. Use files instead of database for settings and guide/recording data
>>
>
>This I think is a stupid idea. Databases are for holding large amount of
>data,
>and allowing easy access to those. I don't see any reason why not to use
>them.
>Normal formatted files would require implementing a lot of extra routines
>for accessing
>data the right way. Which is just what the database does for you...

You can easily tie Perl hashes (used extensively in my implementation)
to a database - without changing anything whatsoever (nearly).
But I have found it unnecessary.

My data structure:

pvr.conf - main config, points to hardware.conf's, has paths etc
fta.conf - hardware config
austar.conf - hardware config
eg. "record=cmd"
"otherthings=whatever"
channel/* - channel details
eg "hardwares=fta.3 austar.325" - ties 'em together
"priority=5"
queue/* - scheduled recordings

In most cases the primary key which links everything together
is channel+utctimestamp. And if there are multiple hardware sources
for the same program then they will all get recorded/scheduled
but soemthing miught possible get preempted of course.

>
>3. He says something about "the recording format can be whatever anyone
>> chooses" -- not sure what he means
>>
>
>Dunno either.
>

If I want MJPEG in avi then that is what I get.
If I want something in NippleVideo then that is also what I get.
Because the recording program is specified in hardware config.
It is always an external program. It is always totally independent
of the PVR.

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

zartzartzart+mythtv-dev at gmail

Mar 3, 2006, 3:25 AM

Post #19 of 54 (4820 views)
Permalink

Re: Interesting Comparison [In reply to]

As a program-guide-integrated recording box your solution is fine(AFAIK).
-- and it can be kept simple.

And in fact I think it could be a nice tool for people wanting just what you
want.

But I still don't see mythtv being coded with its full feature set in some
very
simple way. But I'm getting the feeling that's not what you wanted to prove
either,
so... I'll just shut up.

- Lasse

On 3/3/06, mythtv [at] zacglen <mythtv [at] zacglen> wrote:
>
> >Would save a lot of time for a simple solution. But what about fading
> menus
> >,
> >simple navigation with remote control, _very_ flexible layout.
>
> Simple navigation is possible with a browser. You just have to get
> the tabbing order right.
>
> >And _very_ flexible data reading - in lists like those in mythvideo not
> all
> >dataof has to be loaded at once. First when the user scrolls it's
> loaded.
>
> To load the program guide (current time, and 24 hours plus and minus)
> only takes a second. Mainly because there is no XML.
> Add XML and you are talking slower times because you have to bear with
> XML telling you that "23" is an "integer" or something ridiculous.
>
> >I know all of this (i think) could be done in a browser. But that would
> >require either
> >extensive use of javascripting, flash or something like that.
>
> There is sone Javascript in my implementation.
> Mainly to update main window when program detail popup schedules
> something, and to popup certain windows when required.
>
> >
> >So what would the benefits be in the end?
> >
>
> Simplicity?
>
> >
> >
> >2. Use files instead of database for settings and guide/recording data
> >>
> >
> >This I think is a stupid idea. Databases are for holding large amount of
> >data,
> >and allowing easy access to those. I don't see any reason why not to use
> >them.
> >Normal formatted files would require implementing a lot of extra routines
> >for accessing
> >data the right way. Which is just what the database does for you...
>
> You can easily tie Perl hashes (used extensively in my implementation)
> to a database - without changing anything whatsoever (nearly).
> But I have found it unnecessary.
>
> My data structure:
>
> pvr.conf - main config, points to hardware.conf's, has
> paths etc
> fta.conf - hardware config
> austar.conf - hardware config
> eg. "record=cmd"
> "otherthings=whatever"
> channel/* - channel details
> eg "hardwares=fta.3 austar.325" - ties 'em
> together
> "priority=5"
> queue/* - scheduled recordings
>
> In most cases the primary key which links everything together
> is channel+utctimestamp. And if there are multiple hardware sources
> for the same program then they will all get recorded/scheduled
> but soemthing miught possible get preempted of course.
>
> >
> >3. He says something about "the recording format can be whatever anyone
> >> chooses" -- not sure what he means
> >>
> >
> >Dunno either.
> >
>
> If I want MJPEG in avi then that is what I get.
> If I want something in NippleVideo then that is also what I get.
> Because the recording program is specified in hardware config.
> It is always an external program. It is always totally independent
> of the PVR.
>
> _______________________________________________
> mythtv-dev mailing list
> mythtv-dev [at] mythtv
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
>

mjw at woogie

Mar 3, 2006, 3:31 AM

Post #20 of 54 (4811 views)
Permalink

Re: Interesting Comparison [In reply to]

mythtv [at] zacglen wrote:

>I have just completed my web-based equivalent of MythTV.
>
>
Under what license are you releasing the code? Where is the information
on where I can download it?

Mike

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

setimike at gmail

Mar 3, 2006, 4:18 AM

Post #21 of 54 (4801 views)
Permalink

Re: Interesting Comparison [In reply to]

On 3/3/06, Lasse Nisted <zartzartzart+mythtv-dev [at] gmail> wrote:
>
> You bring up some valid questions. I would like to hear others opinions also.
> On 3/3/06, cardboil <cardboil [at] gmail > wrote:
> > 2. Use files instead of database for settings and guide/recording data
>
> This I think is a stupid idea. Databases are for holding large amount of data,
> and allowing easy access to those. I don't see any reason why not to use them.
> Normal formatted files would require implementing a lot of extra routines for accessing
> data the right way. Which is just what the database does for you...

I agree 100% using databases for holding information like the program
guide, but what about configuration? I would really like to ssh in to
change some settings, such as which software is being used to playback
dvds. My TV is great for watching videos but sucks for reading
computer text, not to mention I would then have to dig out and hook up
a keyboard to that computer.

I guess X forwarding should work for me to change those settings
remotely, but I like command line tools.

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

dag at newtech

Mar 3, 2006, 4:42 AM

Post #22 of 54 (4811 views)
Permalink

Re: Interesting Comparison [In reply to]

> Simple navigation is possible with a browser. You just have to get
> the tabbing order right.
>
> >And _very_ flexible data reading - in lists like those in mythvideo not all
> >dataof has to be loaded at once. First when the user scrolls it's loaded.
>
> To load the program guide (current time, and 24 hours plus and minus)
> only takes a second. Mainly because there is no XML.
> Add XML and you are talking slower times because you have to bear with
> XML telling you that "23" is an "integer" or something ridiculous.

You are probably right about XML.
Thought about this myself as I also have problems with Myth and
communicating with the developers (well not all of them ;-) ) thus
considering brewing my own.
The problem with a textfile for setup is that to implement a front/backend
solution both probably need some access to this file and you get the problem
of accessing that data. The database solution solves that problem nicely.

My humble opinions on Myth are the following:
1. The back/frontend idea is good
2. I would prefer different programs instead of a "allinone" solution.
That is:
- Backend's doing DVB reception, reading a file, doing Firewire etc.
All these creating a MPEG stream
- Frontends for putting a file on disk (recording), showing the file on a
display etc.
Accepting aa MPEG stream
- One scheduler connecting the above together and not only one to one but
also
one to many, which would be good for watching LIveTV and getting near
instant
channelsurfing capabilities
- One program gathering program info
- And so on
3. The themeability of Myth is _A Good Thing_ as it makes it more appealing
also
to non techies.
4. The logic of the UI could be seriously rethought though. Now it needs far
too many
different buttons. Should be more like a Nokia phone...
5. And I still think that there are too many places where Myth breaks if not
used
in perfect conditions. The current problems with MySQL 5.x is an indication
of
deeper logical problems. Handling/surviving "not perfect" MPEG files is
another
(Can probably be attributed tothe ffmpeg library though).

> There is sone Javascript in my implementation.
> Mainly to update main window when program detail popup schedules
> something, and to popup certain windows when required.

I am not that convinced about the browser idea as I would like even more
displays like VDR, with the OSD on top of the current picture. This is also
almost a requirement for

> Simplicity?

Yep, that is a good thing. But we still need/like functionality too.

Best

Dag

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

zartzartzart+mythtv-dev at gmail

Mar 3, 2006, 4:59 AM

Post #23 of 54 (4825 views)
Permalink

Re: Interesting Comparison [In reply to]

Command line editing can easily be accomplished with something like the
mysql client.

mysql -uuser -ppassword mythconverg
: describe settings;
: select data from settings;
etc.

But one might find vim/emacs/nano/... easier. But I would argue that if
you're
the type who wants to do command like editing, then mysql client isn't that
hard.

With relations for configuration files mythtv doesn't need to come up with
yet another
configuration file format :)

On 3/3/06, Mike <setimike [at] gmail> wrote:
>
> On 3/3/06, Lasse Nisted <zartzartzart+mythtv-dev [at] gmail> wrote:
> >
> > You bring up some valid questions. I would like to hear others opinions
> also.
> > On 3/3/06, cardboil <cardboil [at] gmail > wrote:
> > > 2. Use files instead of database for settings and guide/recording
> data
> >
> > This I think is a stupid idea. Databases are for holding large amount
> of data,
> > and allowing easy access to those. I don't see any reason why not to use
> them.
> > Normal formatted files would require implementing a lot of extra
> routines for accessing
> > data the right way. Which is just what the database does for you...
>
> I agree 100% using databases for holding information like the program
> guide, but what about configuration? I would really like to ssh in to
> change some settings, such as which software is being used to playback
> dvds. My TV is great for watching videos but sucks for reading
> computer text, not to mention I would then have to dig out and hook up
> a keyboard to that computer.
>
> I guess X forwarding should work for me to change those settings
> remotely, but I like command line tools.
>
> --Mike
> _______________________________________________
> mythtv-dev mailing list
> mythtv-dev [at] mythtv
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
>

mythtv at zacglen

Mar 3, 2006, 5:04 AM

Post #24 of 54 (4807 views)
Permalink

Re: Interesting Comparison [In reply to]

>
>You are probably right about XML.
>Thought about this myself as I also have problems with Myth and
>
>communicating with the developers (well not all of them ;-) ) thus
>considering brewing my own.
>The problem with a textfile for setup is that to implement a front/backend
>solution both probably need some access to this file and you get the problem
>of accessing that data. The database solution solves that problem nicely.

Accessing modifiable data isn't really a big problem.
In my case it is only the queue files that need modification.
In which case a simple prioritised locking scheme works fine (using flock
or fcntl or whatever). The only trick necessary is to use dual lock
files, and to fork a child process to unlock the temporary lock
file as soon as the parent process has commenced the flock os the]
main queue file. Sounds complicated but it really is a simple, cheap
and reliable operation

>
>My humble opinions on Myth are the following:
>1. The back/frontend idea is good
>2. I would prefer different programs instead of a "allinone" solution.
> That is:
>
> - Backend's doing DVB reception, reading a file, doing Firewire etc.
> All these creating a MPEG stream

There isn't even a need for a so-called backend.
My solution simply uses standard atd scheduler (albeit it has been slightly
modified wrt to niceness, and even SCHED_FIFO if you want).
So there is no backend whatsoever.
Jobs are created, and contention is eliminated through a simpler
wrapper script when jobs run.

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

dag at newtech

Mar 3, 2006, 5:21 AM

Post #25 of 54 (4829 views)
Permalink

Re: Interesting Comparison [In reply to]

>
> Accessing modifiable data isn't really a big problem.
> In my case it is only the queue files that need modification.
> In which case a simple prioritised locking scheme works fine (using flock
> or fcntl or whatever). The only trick necessary is to use dual lock
> files, and to fork a child process to unlock the temporary lock
> file as soon as the parent process has commenced the flock os the]
> main queue file. Sounds complicated but it really is a simple, cheap
> and reliable operation

Well, it is if you have to create your own networking protocol.
Haven't considered yet how much info really is needed on the client
side though. Guess you at least need to access it for updating settings
from the frontend .

> >2. I would prefer different programs instead of a "allinone" solution.
> > That is:
> >
> > - Backend's doing DVB reception, reading a file, doing Firewire etc.
> > All these creating a MPEG stream
>
> There isn't even a need for a so-called backend.
> My solution simply uses standard atd scheduler (albeit it has been slightly
> modified wrt to niceness, and even SCHED_FIFO if you want).
> So there is no backend whatsoever.
> Jobs are created, and contention is eliminated through a simpler
> wrapper script when jobs run.

I think you misunderstood me here. My backend would be more like a
"format converter" that makes a MPEG stream out of everything.

The Myth backend in my solution would be the scheduler, which would
stand on it's own as a process, possibly as you say just a simple atd (like)
thing.

My suggested architecture is actually "copied" from the EMC Networker
backup solution, where it works very well. The other inspiration is UNIX.

I find Myth to be more like a solution programmed with Windows rules
instead of my preferred UNIX rules.

Best
Dag

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

1 2 3

View All

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads