Okay, I went back and did some research on my problem
and I bring it to the group again.
Freevo 1.5.4 (compiled from source)
DirectFB 0.9.24 (from source)
mmpython 0.4.9
pygame 1.7.1
fbxine 0.99.4
df_xine from DirectFB Extras 0.9.23
Patches to Freevo python files to add detection of
df_xine in setup.py and circumvent version checking in
xine.py (df_xine does not report a version number, -v
is used to set verbosity of output).
Debian 3.0, dist-upgraded to Sarge
Kernel 2.4.27 (from source, with AMD K7 optimizations)
This is an 'X-less' box. It all runs from the command
line
Matrox G400 Max DH card, running TV-Out from the
second head
Did I miss anything?
Okay. The main problem is Freevo cannot control
df_xine or fbxine when playing back DVDs. After a bit
of fiddling, I've narrowed this down to an issue with
DirectFB, because:
* DVD playback with df_xine or fbxine is unresponsive
* Video playback with mplayer (used for everything but
DVDs) responds to mplayer's key commands, but not
necessarily Freevo's key commands.
* Audio playback (mplayer) always responds to Freevo's
key commands
For example, right now Freevo's volume bindings are
'n' for decrease and 'm' for increase. If I play back
audio in mplayer (which uses OSS/ALSA, not DirectFB)
then n/m control volume. However, if I play back video
in mplayer (DVD Title or video file), n/m no longer
control volume, but '/' and '*' (mplayer's default
volume keys) on the keypad do. I believe this works
because mplayer will still respond to it's keyboard
commands when run with the -slave switch. df_xine and
fbxine ignore the keyboard and only listen to stdin
when run with --stdctl.
I can only conclude that video playback through
DirectFB is somehow blocking the stdin commands from
Freevo. I'm very suspicious of the 'virtual terminal'
stuff that DFB is supposed to do. If a child app runs
in a virtual terminal, will Freevo be able to
communicate with it? However, no combination of
'no-vt-switch' and 'no-vt-switching' in the directfbrc
file seems to make any difference.
Interesting to me, if I run df_xine with --stdctl over
telnet, when DirectFB fires up it reports the line:
(*) Direct/Thread: Running 'VT Switcher' (CRITICAL,
1093)...
Freevo also reports this line whenever the DirectFB
system initalizes.
But if I run fbxine with --stdctl (the only way it
will run from telnet), that line does NOT appear. In
both cases, all lines in directfbrc that deal with the
VT are commented out.
For what it's worth:
If Freevo starts fbxine, the terminal that appears
behind the video output is active: I can type things
into the command line and get responses, even as the
DVD plays back. This leads me to think Freevo has lost
the keyboard.
The above may also be the case with df_xine, but
df_xine does not show any of the terminal behind the
video when played back on the monitor, and blanks the
terminal monitor completely when played back on the
TV-Out.
Both df_xine and fbxine work fine outside of Freevo
when run normally (without the --stdctl command). They
respond to all keyboard commands. Both fbxine and
df_xine do not show a terminal behind the video in
this case. If df_xine is run with --layer=0 for
TV-Out, the terminal monitor remains black.
If I run fbxine with --stdctl from the terminal, I can
control it via stdin. I can also see my input and
fbxine's output because the terminal appears 'behind'
the DVD playback. However, when I quit fbxine, the
output remains until I press a key. Then all output is
instantly restored exactly as it was before running
fbxine (fbxine is running in a DFB virtual terminal?).
If I run df_xine with --stdctl from the terminal, I
can _not_ see any part of the terminal 'behind' the
video playback on the monitor. It also does _not_
respond to stdin commands.
If I run df_xine with --stdctl and --layer=0 (to force
it to TV-Out), the terminal monitor is blanked and the
video is output to the TV. However as above, it does
not respond to stdin commands.
If I run df_xine or fbxine with --stdctl from a telnet
session, they will respond to stdin commands sent over
the telnet session.
In all cases where df_xine or fbxine become
unresponsive from inside Freevo, if I terminate the
process manually (via Telnet), Freevo pops back up
once the child process ends. So I can assume Freevo is
working correctly, waiting for the child process to
end. There's just some kind of disconnect between the
keyboard and/or Freevo and/or the child process when
DirectFB is running.
Anyone have any clues they can offer? Even just a
nudge in the right direction? I'd love to whip this,
because otherwise my Freevo box is ready for
prime-time in the living room. I don't have a TV-Tuner
card yet, but I do have the webserver, recordserver
and tv_grab working near perfectly (so I can browse
the guide and set up recordings, just not view or
record anything).
I'd be happy to provide any debug logs (Freevo and
child-app) that may be needed.
Surely there are other G400 DH/DirectFB Freevoers out
there who have a working setup?
Thanks in advance.
James
Panorama City, CA USA
__________________________________
Yahoo! for Good - Make a difference this year.
http://brand.yahoo.com/cybergivingweek2005/
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Freevo-users mailing list
Freevo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freevo-users
