Re: [vdr] SVDRP connection freezes

[Tony Houghton]

In <[EMAIL PROTECTED]>, Tony Houghton wrote:

> In <[EMAIL PROTECTED]>, Tony Houghton wrote:
> 
> > The problem is that the svdrp connection has a tendency to freeze.
> 
> [Snip]
> 
> > but it still happens very often when pressing the Red button to open the
> > progress bar.
> 
> [When playing a recording]
> 
> I've since noticed that when SVDRP freezes while the progress bar is on
> screen the clock of the current time shown under the bar stops counting,
> although playback continues. Perhaps the OSD is freezing as well as
> SVDRP?

It seems like it isn't specific to SVDRP anyway. I've rewritten boxstar
to use the remote plugin and it's still got the same problem: the
progress bar freezes, and VDR stops acting on keystrokes, but the video
carries on playing. I can "reset" it it by stopping and restarting xine,
which makes VDR go back to playing live TV; if I try to play the
recording again I find it has jumped forward by a large amount.

This is with VDR 1.4.1, vdr-xine 0.7.9 and xine-lib 1.1.2. I tried
upgrading to VDR 1.4.3 but that's a disaster, it crashes the DVB cards
as soon as Xine connects. vdr-xine is relatively old; I guess it needs
an overhaul, and it could even be the cause of the original problem. Is
there a newer "developer" version hidden away on a different site? The
problems might be peculiar to df_xine, otherwise surely someone else
using xine would have noticed by now, but I don't see how it could
affect VDR like that unless the problem is in xine-lib.

-- 
TH * http://www.realh.co.uk

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] SVDRP connection freezes

[Udo Richter]

Tony Houghton wrote:

[When playing a recording]

I've since noticed that when SVDRP freezes while the progress bar is on
screen the clock of the current time shown under the bar stops counting,
although playback continues. Perhaps the OSD is freezing as well as
SVDRP?


Its possible that the VDR main thread is frozen for some reason, this 
will also freeze SVDRP connections. However, the watchdog timer should 
react on such situations, provide that you've enabled it. Normally, 
nothing should freeze the main loop for more than a few seconds.


Cheers,

Udo

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] SVDRP connection freezes

[Tony Houghton]

In <[EMAIL PROTECTED]>, Tony Houghton wrote:

> The problem is that the svdrp connection has a tendency to freeze.

[Snip]

> but it still happens very often when pressing the Red button to open the
> progress bar.

[When playing a recording]

I've since noticed that when SVDRP freezes while the progress bar is on
screen the clock of the current time shown under the bar stops counting,
although playback continues. Perhaps the OSD is freezing as well as
SVDRP?

-- 
TH * http://www.realh.co.uk

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] SVDRP connection freezes

[Udo Richter]

Tony Houghton wrote:
If you want to rely on existing stuff, maybe you can use the remote 
plugin from Oliver Endriss for your needs - it supports tty control and 
telnet control.


That sounds like the best idea. If I wrote my own plugin I'd probably
just be effectively duplicating the telnet interface that's already
there. It's well-supported (including a Debian package) and I was
already using its input device functionality before for the Hauppauge
remote. It never occurred to me to look for its telnet interface.


The telnet interface is more than just a key-input device, it also 
displays a text replication of the OSD menus and standard dialogs. But 
you can redirect that to /dev/null of course.


Cheers,

Udo


___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] SVDRP connection freezes

[Tony Houghton]

In <[EMAIL PROTECTED]>, Udo Richter wrote:

> Holding the SVDRP connection for a long time is not a good idea, since 
> VDR can only keep one SVDRP connection open at the same time. Holding 
> the line permanently would block out other uses like VDRAdmin or 
> EPGSearch plugin.

ISTR reading about the one connection limitation, that's a good point.
If it weren't for the freezing problem SVDRP would have suited my needs
so far, but obviously it's an inadequate approach in the long term.

> If you don't want to open the connection dynamically, you can write a 
> simple plugin that forwards the key presses. This shouldn't be too 
> difficult, since cRemote::Put is thread-safe, so you can open a socket 
> and forward incoming key presses from a simple thread. You could even go 
> the next step and write a real boxstar-remote plugin for VDR.
> 
> If you want to rely on existing stuff, maybe you can use the remote 
> plugin from Oliver Endriss for your needs - it supports tty control and 
> telnet control.

That sounds like the best idea. If I wrote my own plugin I'd probably
just be effectively duplicating the telnet interface that's already
there. It's well-supported (including a Debian package) and I was
already using its input device functionality before for the Hauppauge
remote. It never occurred to me to look for its telnet interface.

-- 
TH * http://www.realh.co.uk

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] SVDRP connection freezes

[Udo Richter]

Tony Houghton wrote:

The problem is that the svdrp connection has a tendency to freeze. I
have to wait a few minutes for the socket to timeout at the system
level. VDR's SVDRP timeout is set to 0, but I don't think that's making
a difference. I think the reason other programs such as vdradmin work OK
is that they open and close the connection for every command, but that
approach is too sluggish for boxstar, which is supposed to be a
transparent, primary interface to controlling VDR.


Holding the SVDRP connection for a long time is not a good idea, since 
VDR can only keep one SVDRP connection open at the same time. Holding 
the line permanently would block out other uses like VDRAdmin or 
EPGSearch plugin.


If you don't want to open the connection dynamically, you can write a 
simple plugin that forwards the key presses. This shouldn't be too 
difficult, since cRemote::Put is thread-safe, so you can open a socket 
and forward incoming key presses from a simple thread. You could even go 
the next step and write a real boxstar-remote plugin for VDR.


If you want to rely on existing stuff, maybe you can use the remote 
plugin from Oliver Endriss for your needs - it supports tty control and 
telnet control.


About the original question why the socket freezes: I don't see an 
obvious reason why this happens. If the VDR side would freeze, this 
would lead to a watchdog timeout. Otherwise, if anything kills the 
connection, there is probably a "lost connection to SVDRP client" 
message in the syslog. You may want to add some debugging code there to 
investigate. (svdrp.c, line ~1594)


Cheers,

Udo

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

[vdr] SVDRP connection freezes

[Tony Houghton]

I'm writing an HTPC application called boxstar
, and its latest functionality is to
launch xine to watch VDR. The only way I could think of to be able to
use both boxstar and VDR with the same remote control was to have
boxstar always in charge of the remote and pass button presses on to VDR
via the HITK svdrp command.

The problem is that the svdrp connection has a tendency to freeze. I
have to wait a few minutes for the socket to timeout at the system
level. VDR's SVDRP timeout is set to 0, but I don't think that's making
a difference. I think the reason other programs such as vdradmin work OK
is that they open and close the connection for every command, but that
approach is too sluggish for boxstar, which is supposed to be a
transparent, primary interface to controlling VDR.

For some reason the problem was much worse before I used Python's
makefile() function, which is a sort of equivalent to C's fdopen() ie it
buffers the socket and provides some more convenient, higher level ways
to access it. Since using makefile() the problem has almost gone away,
but it still happens very often when pressing the Red button to open the
progress bar.

FWIW I'm using df_xine with a Matrox G450's TV-out. 

-- 
TH * http://www.realh.co.uk

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr