Hi,
I've just got around to upgrading xine-lib so that I could try out version 0.7.3 of the xine output plugin. So far, I have not managed to get any sort of OSD with this new version.
:-(
I have also got an LCD module attached and that reacts almost instantly to keypresses for the menu, etc. but I see no OSD on either my TV or monitor. With version 0.7.2, the OSD appears after maybe 2-4 s after a keypress (even thought the LCD module updates much quicker).
I have been messing about with various xine options trying to improve my TV-out quality and I'm sure that the OSD was much more responsive when I first tried 0.7.2!
Are there any major changes in drawing the OSD between the two versions that I may be affecting? I've seen mentions that the new version if more stable for some and that it is much more responsive to keypresses.
On another point, is it possible to get xine to reconnect to vdr if it restarts? At the moment, I have a loop which runs xine continuously but I have to poke 'q' to restart xine if vdr restarts!
Cheers,
Laz
I demand that Laurence Abbott may or may not have written...
I've just got around to upgrading xine-lib so that I could try out version 0.7.3 of the xine output plugin. So far, I have not managed to get any sort of OSD with this new version.
:-(
Works for me, although I've yet to test CVS HEAD. I was going to do so yesterday, but a failed PSU fan put paid to that. (The PSU has been replaced now and that computer is up and running again; thoughts on the viability of replacing the fan in the old one, anybody?)
You could try using the xine-1_0 branch (as of yesterday - a lot of stuff has been merged from HEAD today, ready for 1.0.1). You'll need to change the plugin version number in the patch fom 16 to 15 (look for PLUGIN_INPUT); memory says that there should be one reject and that it's trivially fixable.
[snip]
On another point, is it possible to get xine to reconnect to vdr if it restarts? At the moment, I have a loop which runs xine continuously but I have to poke 'q' to restart xine if vdr restarts!
If it's the only item in the playlist then clicking on the 'play' button should be sufficient (with gxine, it is); other than that, I doubt it - you've hit end-of-stream :-)
Hi,
Laurence Abbott wrote:
I've just got around to upgrading xine-lib so that I could try out version 0.7.3 of the xine output plugin. So far, I have not managed to get any sort of OSD with this new version.
:-(
I have also got an LCD module attached and that reacts almost instantly to keypresses for the menu, etc. but I see no OSD on either my TV or monitor. With version 0.7.2, the OSD appears after maybe 2-4 s after a keypress (even thought the LCD module updates much quicker).
Should this be a nptl issue? Did you turn off nptl (export LD_ASSUME_KERNEL=2.4.1)?
I have been messing about with various xine options trying to improve my TV-out quality and I'm sure that the OSD was much more responsive when I first tried 0.7.2!
Do you get messages like:
vdr: osdflush: n: 1, 7.5
when you run xine with --verbose=2?
Are there any major changes in drawing the OSD between the two versions that I may be affecting? I've seen mentions that the new version if more stable for some and that it is much more responsive to keypresses.
I've changed the implementation of osd_flush in input_vdr to not cause high CPU load. There is now a xine_usleep() of 5000 ms in the wait loop. The above numbers indicate 1 loop interation and a total wait time of 7.5 ms until the OSD got flushed by xine.
On another point, is it possible to get xine to reconnect to vdr if it restarts? At the moment, I have a loop which runs xine continuously but I have to poke 'q' to restart xine if vdr restarts!
Try xine's -pq option. This makes xine exit when the stream is done, e. g. when VDR shuts down. Then wait a little bit until VDR is up again and then start xine again.
A working solution is to have too scripts that restart each programme.
For VDR one should remove /tmp/vdr-xine in runvdr when VDR exits. Then wait 2 seconds and kill xine too in the case it hasn't exited by itself.
The script for xine waits 5 seconds and tests whether /tmp/vdr-xine/stream exists and starts xine then. Otherwise it goes on with waiting and testing.
Bye.
I demand that Reinhard Nissl may or may not have written...
Laurence Abbott wrote:
I've just got around to upgrading xine-lib so that I could try out version 0.7.3 of the xine output plugin. So far, I have not managed to get any sort of OSD with this new version.
:-(
I have also got an LCD module attached and that reacts almost instantly to keypresses for the menu, etc. but I see no OSD on either my TV or monitor. With version 0.7.2, the OSD appears after maybe 2-4 s after a keypress (even thought the LCD module updates much quicker).
Should this be a nptl issue?
FWIW, I've seen some failures wrt display of the playback mode; apart from that, though, it seems fine here.
Did you turn off nptl (export LD_ASSUME_KERNEL=2.4.1)?
Users of my VDR package can edit /etc/default/vdr then restart vdr to do this ;-)
[snip]
On Wed, 2005-04-20 at 20:15 +0200, Reinhard Nissl wrote:
I have also got an LCD module attached and that reacts almost instantly to keypresses for the menu, etc. but I see no OSD on either my TV or monitor. With version 0.7.2, the OSD appears after maybe 2-4 s after a keypress (even thought the LCD module updates much quicker).
Should this be a nptl issue? Did you turn off nptl (export LD_ASSUME_KERNEL=2.4.1)?
I am already doing so to disable NPTL for vdr. Is it worth trying it for xine as well?
I have been messing about with various xine options trying to improve my TV-out quality and I'm sure that the OSD was much more responsive when I first tried 0.7.2!
Do you get messages like:
vdr: osdflush: n: 1, 7.5
when you run xine with --verbose=2?
I haven't really had a chance to do any proper testing yet but I'll check it out later, hopefully.
Are there any major changes in drawing the OSD between the two versions that I may be affecting? I've seen mentions that the new version if more stable for some and that it is much more responsive to keypresses.
I've changed the implementation of osd_flush in input_vdr to not cause high CPU load. There is now a xine_usleep() of 5000 ms in the wait loop. The above numbers indicate 1 loop interation and a total wait time of 7.5 ms until the OSD got flushed by xine.
On another point, is it possible to get xine to reconnect to vdr if it restarts? At the moment, I have a loop which runs xine continuously but I have to poke 'q' to restart xine if vdr restarts!
Try xine's -pq option. This makes xine exit when the stream is done, e. g. when VDR shuts down. Then wait a little bit until VDR is up again and then start xine again.
Ahhh...that sounds like what I want. I'll give that a go...
A working solution is to have too scripts that restart each programme.
For VDR one should remove /tmp/vdr-xine in runvdr when VDR exits. Then wait 2 seconds and kill xine too in the case it hasn't exited by itself.
The script for xine waits 5 seconds and tests whether /tmp/vdr-xine/stream exists and starts xine then. Otherwise it goes on with waiting and testing.
...in combination with this. I never thought of getting my vdr script to remove the directory.
Cheers,
Laz
On Wed, 2005-04-20 at 18:51 +0100, Darren Salt wrote:
I demand that Laurence Abbott may or may not have written...
I've just got around to upgrading xine-lib so that I could try out version 0.7.3 of the xine output plugin. So far, I have not managed to get any sort of OSD with this new version.
:-(
Works for me, although I've yet to test CVS HEAD. I was going to do so yesterday, but a failed PSU fan put paid to that. (The PSU has been replaced now and that computer is up and running again; thoughts on the viability of replacing the fan in the old one, anybody?)
You could try using the xine-1_0 branch (as of yesterday - a lot of stuff has been merged from HEAD today, ready for 1.0.1). You'll need to change the plugin version number in the patch fom 16 to 15 (look for PLUGIN_INPUT); memory says that there should be one reject and that it's trivially fixable.
Hmmm...could be something to do with this. Originally, I had a xine-lib 1.0-1vdr6.xvmc deb installed, which included both vdr and Via Unichrome patches, and vdr-xine-0.7.2 was very responsive. vdr-xine-0.7.3 wouldn't build against this version so I upgraded to xine-lib cvs from 18/4/05. Now vdr-xine-0.7.2 is a bit sluggish (ca. 1 s delay for OSD to appear or react). vdr-xine-0.7.3 now builds but I get no OSD!
Darren: do your libxine1 packages include supoprt for Via Unichrome xxmc output? I _think_ this is in current xine-lib cvs. If it does, I can just grab your packages and, hopefully, things will 'just work'!
;-)
[snip]
On another point, is it possible to get xine to reconnect to vdr if it restarts? At the moment, I have a loop which runs xine continuously but I have to poke 'q' to restart xine if vdr restarts!
If it's the only item in the playlist then clicking on the 'play' button should be sufficient (with gxine, it is); other than that, I doubt it - you've hit end-of-stream :-)
The -pq options have been suggested, i.e. quit after play has stopped, and also getting my vdr startup script to remove /tmp/vdr-xine on a restart so that the 'file' disappears and play stops.
Cheers,
Laz
Hi,
Laurence Abbott wrote:
Hmmm...could be something to do with this. Originally, I had a xine-lib 1.0-1vdr6.xvmc deb installed, which included both vdr and Via Unichrome patches, and vdr-xine-0.7.2 was very responsive. vdr-xine-0.7.3 wouldn't build against this version so I upgraded to xine-lib cvs from 18/4/05. Now vdr-xine-0.7.2 is a bit sluggish (ca. 1 s delay for OSD to appear or react). vdr-xine-0.7.3 now builds but I get no OSD!
Well, the xine version on my homepage runs successfully with vdr-xine-0.7.3 on my EPIA MII-6000E with xxmc enabled.
Bye.
Hi,
Laurence Abbott wrote:
I have also got an LCD module attached and that reacts almost instantly to keypresses for the menu, etc. but I see no OSD on either my TV or monitor. With version 0.7.2, the OSD appears after maybe 2-4 s after a keypress (even thought the LCD module updates much quicker).
Should this be a nptl issue? Did you turn off nptl (export LD_ASSUME_KERNEL=2.4.1)?
I am already doing so to disable NPTL for vdr. Is it worth trying it for xine as well?
Hhm, on my EPIA board, I've compiled gentoo without support for NPTL. On my SuSE 9.2 system, I have no gfx board that would support xxmc.
Bye.
I demand that Laurence Abbott may or may not have written...
[snip]
Darren: do your libxine1 packages include supoprt for Via Unichrome xxmc output? I _think_ this is in current xine-lib cvs. If it does, I can just grab your packages and, hopefully, things will 'just work'!
No. Download the source, install libxvmc-dev and/or libxvmcw-dev, rebuild - the resulting libxine1 should have XxMC support.
(OTOH, you may want to wait: I'm preparing 1.0-1vdr9...)
[snip]
On Thu, 2005-04-21 at 21:54 +0100, Darren Salt wrote:
I demand that Laurence Abbott may or may not have written...
[snip]
Darren: do your libxine1 packages include supoprt for Via Unichrome xxmc output? I _think_ this is in current xine-lib cvs. If it does, I can just grab your packages and, hopefully, things will 'just work'!
No. Download the source, install libxvmc-dev and/or libxvmcw-dev, rebuild - the resulting libxine1 should have XxMC support.
(OTOH, you may want to wait: I'm preparing 1.0-1vdr9...)
That's what I was hoping you'd say! I did toy with the idea of grabbing the relevant bits and building myself a deb but if you are going to do it!
;-)
Any idea how long that will be? I can stick with xine-0.7.2 for the time being.
Cheers,
Laz
I demand that Laurence Abbott may or may not have written...
On Thu, 2005-04-21 at 21:54 +0100, Darren Salt wrote:
I demand that Laurence Abbott may or may not have written... [snip]
Darren: do your libxine1 packages include supoprt for Via Unichrome xxmc output? I _think_ this is in current xine-lib cvs. If it does, I can just grab your packages and, hopefully, things will 'just work'!
No. Download the source, install libxvmc-dev and/or libxvmcw-dev, rebuild
- the resulting libxine1 should have XxMC support.
(OTOH, you may want to wait: I'm preparing 1.0-1vdr9...)
That's what I was hoping you'd say! I did toy with the idea of grabbing the relevant bits and building myself a deb but if you are going to do it!
You still need to do that. I plan to wait until xorg source appears in testing (etch, not sarge), at which point, according to the sources file in Henning Glawe's unichrome repository, I'll only need to add libxvmcw to my repository - I'd rather not add both that and a patched xfree86...
Anyway, the main reason for -1vdr9 (which is now available) is here: URL:http://xinehq.de/index.php/security/XSA-2004-8
On Fri, Apr 22, 2005 at 07:35:14PM +0100, Darren Salt wrote:
That's what I was hoping you'd say! I did toy with the idea of grabbing the relevant bits and building myself a deb but if you are going to do it!
You still need to do that. I plan to wait until xorg source appears in testing (etch, not sarge), at which point, according to the sources file in Henning Glawe's unichrome repository, I'll only need to add libxvmcw to my repository - I'd rather not add both that and a patched xfree86...
even that would not be necessairy when xorg is included in debian: xvmcw is include in xorg
Anyway, the main reason for -1vdr9 (which is now available) is here: URL:http://xinehq.de/index.php/security/XSA-2004-8
If I have time, I'll update my packages this weekend ;)
-
Darren Salt -
Henning Glawe -
Laurence Abbott -
Reinhard Nissl