I'm writing an HTPC application called boxstar http://boxstar.sourceforge.net, 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.
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
In 4546AC19.6090409@gmx.de, 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.
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
In 20061030230920.GA19352@realh.co.uk, 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?
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
In 20061101003953.GA25848@realh.co.uk, Tony Houghton wrote:
In 20061030230920.GA19352@realh.co.uk, 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.
-
Tony Houghton -
Udo Richter