[mythtv] Interesting Comparison

[Lasse Nisted]

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.com.au <mythtv at zacglen.com.au> 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.org
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mythtv.org/pipermail/mythtv-dev/attachments/20060303/d65bf17b/attachment.htm