[mythtv] Request: MythHelp

[usleepless at gmail.com]

List, Allan,

On 2/7/07, Allan Stirling <Dibblahmythml0015 at pendor.org> wrote:
> usleepless at gmail.com wrote:
> > it wouldn't be so bad if you guys actually knew proper database design and
> ipc.
> >
> > a lousy database is used,
> > with a lousy schema. threads are created to work around the problems
> > that arise. ipc is done
> ...
>
> >
> > i refrained myself from contributing due to this "attitude". i know i
> > am not alone on this one.
> >
>
> ask yourself how this "attitude" is helpful.

it is very much so. it depends on one's goals. my goal was to run
mythtv on the infrastructure i already had ( freebsd server,
postgresql db ).

so i put my time into achieving that goal.
 - i developed a driver for the pvr150/500 cards based of the
pvr250-driver for freebsd. it is in the ports tree now (
multimedia/pvrxxx ).
 - i removed all silly query.size() calls, as per the qt-docs, and
translated faulty sql so it now runs on postgresql, together with the
other databases that server ehhh "serves".
 - i made mythtv run on fbsd 4.x and 6.x. this is when i encountered
the silly ipc. removed almost all of it.

so there you go, i achieved my goal. gf is happy. i am happy. why
would i spent time convincing "hostile" developers of changed that
need to be made? by the way: this heavily modified mythtv-0.18-fixes
compiles and runs fine on the penguin as well ( xbox debian, ubuntu ).
even better.

this december my fellow freebsd users wanted to port mythtv. when they
did not succeed, i offered my mythtv-expertise and made it work:
  http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/108667

although these are little patches, i took me quite some time to find
out why it wouldn't work.

it's not that i do not contribute, i choose to contribute elsewhere
because of the hostility and the clinging on the cancer that calls
itself a rdbms.

in the meantime i continue to use the 0.18-fixes-postgresql i am
running. no need to upgrade yet. it has been made clear to me on this
very list that considering multi-db-compatibility is "out of the
question" in a rather "hostile" way.

well running mysql on my systems is "out of the question" as well.
multi-db-compatibility would have helped identifiyng "hickup" problems
you are encountering ( oh, hickups don't occur when running on
postgresql/mssql. then you would know where to look. ).

although i don't supply patches, i supplied this list with a
scheduler-query-optimization/normalization. next time, i'll refrain
from that too because it is indeed pointless.

regards,

usleep