MythTV testing results

[usleepless at gmail.com]

Hans, Torfinn, List,

On 1/2/07, Hans Nieser <h.nieser at xs4all.nl> wrote:

<< snip >>

> 2007-01-02 12:44:41.012 Connection to backend server lost
> 2007-01-02 12:44:41.012 Connecting to backend server: 127.0.0.1:6543 (try
> 1 of 5)
> 2007-01-02 12:44:41.014 Using protocol version 30
> 2007-01-02 12:44:48.017 MythSocket(8726500:12): readStringList: Error,
> timeout (quick).
> 2007-01-02 12:44:48.018 MythSocket(8726500:-1): writeStringList: Error,
> invalid string list.
> 2007-01-02 12:44:48.018 MythSocket(8726500:-1): readStringList: Error,
> called with unconnected socket.
> 2007-01-02 12:44:48.018 Reconnection to backend server failed
> Mutex unlock failure: Operation not permitted

this is the same problem as Torfinn reported. i think it has to do
with the way ipc is done in mythtv ( ie: the problem is usleep() is
not guaranteed to do a context-switch ).

> I'm running both as root at the moment just to rule out any permission
> issues. Another thing that I noticed is that mythbackend reports "ERROR:
> no valid capture cards are defined in the database." even though I believe
> I have succesfully set one up using mythtv-setup, and I can see it defined
> in the mythconverg MySQL database in the capturecard table. It does seem
> to succesfully connect to the MySQL database though. Also note that I'm
> running everything (MySQL, mythbackend, mythtv) on the same machine.

i don't think you guys are doing anything wrong. i think the problem
is with the way mythtv is programmed ( poor ipc ).

i can understand why someone ( in this case Greg ) wants to start out
with the latest version. i was ( and still am ) curious if you guys
would have a much easier ride than i had because you based it of
mythtv-0.20, don't hate mysql as much as i do and are running it on
>6.0 only.

while i seem to be the only one running a mythbackend+mythfrontend on
freebsd, i would rather just install a port ( as long as it runs, and
doesn't rely on mysql ). the reason i didn't commit my personal branch
are: 1. lagging behind in version 2. don't want to maintain a branch.
inevatably, people will come with patches and requests, and knowing
myself i can not commit to such a task.

depending on other success/failure reports, i can imagine a couple of scenarios:

 - this port ( mythtv-0.20 ) is patched quick 'n' dirty by redefining
usleep() and a handfull(maybe more) of other patches ( i can be of
help, and would love to do so )
 -  i create diffs for my personal branch against 0.18-fixes and we!
try to apply them to 0.20 ( either the ipc-patches only, or the
ipc-patches and the pgsql patches ). this would be ideal.
 - my personal mythtv-0.18-fixes-pgsql-mythtv-ipc-done-right is
commited to the ports tree. it works for people with multimedia/pvrxxx
and should work for people with pvr250/350s soon as well. it will need
"port-polishing" since my installation evoluted(?).

it must be said that while we ( me and my gf ) are very happy with the
mythtv-system, it occasianally crashes. but now i think of it: it
never crashes on my freebsd6-desktop-system. it crashes on my xbox,
which is running on xebian. but the mythtv-installation on my xbox is
running of the the same personal branch of mythtv as my 4.11-server
and my 6.1-release-p10-desktop are running ( this also means that my
patches are freebsd/linux compatible ).

we hardly watch live-tv anymore. it is a blessing.

regards,

usleep