MythTV and PVR500 (was: Possible FreeBSD port?)

[usleepless at gmail.com]

John, List,

On 12/22/06, John-Mark Gurney <gurney_j at resnet.uoregon.edu> wrote:
> usleepless at gmail.com wrote this message on Wed, Dec 20, 2006 at 22:40 +0100:
> > because i am still running on a 4.11 server, the mythbackend needed to
> > run on 4.11. i soon discovered that mythtv had strange ipc, so i
> > compiled it against linux-threads ( had to rebuild QT with
> > linux-threads as well ). i remember it helped a little, but not
> > enough.
> >
> > i stumbled upon all the busy-wait-loops:
> >
> > "
> >  while(!condition)
> >        usleep(50);
> > "
> >
> > this is probably the reason why i needed linux-threads. but there is a
> > catch: linux-usleep guarantees a context-switch, while freebsd doesn't
> > ( didn't ? ).
> >
> > my first solution was to redefine usleep in mythcontext.h, to force a
> > context-switch. this produced a working mythtv-install. later on, i
> > removed all busy-wait-loops because they are just plain stupid.
>
> Why not use sched_yield(2)?  I forget if it's in 4.x, but I'm pretty
> sure just yield is in 4.x...  That will force a context switch...

in the end i did. i tried a couple of different redefines of usleep
combined with sched_yield, pthread_yield, the qt-variant etc. i don't
remember exactly which i used in the end, but i can look it up if it
becomes relevant.

while redefining usleep, i started logging all usleep's ( which are
also context-switches ). the amount of usleeps was so mind-boggling i
decided to try to get rid of most of them.  some i replaced with
QWaitConditions, other i eliminated by changing a module to an
event-driven model instead of .... welll.... i don't know how to call
it. microprocessor-c-style might be the closest i can think of ( think
PIC/atmel style c-code )

anyways, i am very happy that a discussion is going on about fbsd-mm,
mythtv and how to get on par mm-wise with other systems.

i hope things "spin up" in the sense that if we have a "just works"
mythtv-port, someone somewhere will decide "now is the time for adding
dvb or whatever".

although i am sticking to my own
0.18-fixes-postgresql-usleepless-mythtv for the moment, in the end the
best thing for me would be to run the standard mythtv-port tool and
participate in the normal upgrade cycle. but because of personal
wackyness i refuse to install mysql.

i am willing to spend some time on this, for example with my
experience with compiling v4l2 stuff for freebsd, i would be happy to
extend the bktr driver to do the same. but it would like to be paired
up with a buddy who is actually using bktr-cards who can test and
debug a little as well. any takers?

for example, we could define relatively small goals: make the
bktr-driver run with mplayer through v4l2 or make the bktr-driver run
with a linux-tv-viewing app which is currently not supported ( kdetv?
). just implement the minimal subset to make it work, and from there
take on another app and eventually mythtv.

let's feed this thread, keep it alive.

regards,

usleep