MythTV (was: Possible FreeBSD port?)

[Stephen Hocking]

On 12/20/06, usleepless at gmail.com <usleepless at gmail.com> wrote:
>
> Stephen,
>
> On 12/20/06, Stephen Hocking < stephen.hocking at gmail.com> wrote:
> > On 12/20/06, usleepless at gmail.com <usleepless at gmail.com> wrote:
> > >
> > >
> > > i did not make a port, but i am willing to help. but if people are
> > > interested in a 0.18-fixes-postgresql-heavily-modified port of mythtv,
> > > let me know. if there is enough interest we might pull it off.
> > >
> > > but i got the impression of the list that only the most recent version
> > > of mythtv is worth aiming for ( i have no need to go to .19 or .20 )
> >
> >
> >
> > I think that you're probably right as regards the versions, but have you
>
> > thought of pushing your patches back to the maintainers
> > of MythTV?
> >
> >     Stephen
>
> thank you for asking.
>
> are you subscribed to any of the mythtv lists? i am.



Yup, certainly am. There's a few outstanding bugs that bother me (backend
crashes
after transcode when another program is being watched).


they don't want to talk about changes to the database-layer: they
> don't think the database is important and would rather have nothing to
> do with sql. when i proposed to make mythtv cross-database-compatible
> ( mysql, postgresql, mssql etc ), they responded with "we might move
> to a embedded db like firebird"?. shutting off postgresql totally.



Yeah, I can vaguely recall some of the debate on the lists. It's a shame -
I try & write code so that it's as portable as possible, with  appropriate
abstraction layers, which dates from the time I used to port stuff from
BSD over to uPort V/AT (286 SVR2).

furthermore, the interprocess-communication in mythtv is horrific,
> mostly busy wait loops, which makes a context-switching-hell.
> unfortunatly mythtv developers lack essential db and ipc skills. the
> abstraction is pretty good though.



What were they smoking? Surely a simple select(2) would be good enough?

they are hunting ghosts too: in the mailing lists "hickups" are
> discussed regulary: they are fiddling with process priorities between
> frontend and database/backend. at the same time they throw immense
> queries to the db which could be so much more efficient with a proper
> datamodel.



Yes, I've seen the recommendations about putting the DB on a separate
spindle
to the recordings.

for my own install, i implented a "settings cache" even before they
> did! before this, every setting was queried from the db _everytime_ it
> was used (ie: roundtrips all the time ).



Yeah, it's not likely that you'll be changing things on a another session
when you're currently active.


> i am under the impression that most of the changes in .19 and .20 are
> digital-broadcast-specific. this is of no interest to me: i am running
> on 2 pvr500s.


I'm all digital, and as far as I'm aware, there's no settled kernel API for
DVB-T cards (or video really, in general) for FBSD.

    Stephen