Hi,
I'm pleased to announce Valentine's release 0.7.7:
http://home.vr-web.de/~rnissl/vdr-xine-0.7.7.tgz
2006-02-14: Version 0.7.7
- Updated MANUAL (thanks to Ville Skyttä for supplying the patch). - Added Dutch translation (thanks to Maarten Wisse for supplying the patch). - Fixed auto primary device functionality concerning ActualDevice (thanks to Luca Olivetti for reporting this issue). - Shutting down cOsdProvider when vdr-xine is nolonger primary device to fix an issue where the new primary device doesn't register it's own cOsdProvider instance. - Fixed cXineDevice::SetDigitalAudioDevice() for radio channels with multiple audio tracks (e. g. RADIO INT2). These tracks are not related to each other and therefore syncing these tracks by PTS is impossible and causes huge delays otherwise. - Adopted cXineDevice::GrabImage() to VDR-1.3.38 (based on a patch of Darren Salt). - Fixed some issues with FIFO_DIR containing spaces (thanks to Darren Salt for supplying the patch). - Fixed some warnings about strict-aliasing issues when compiling with gcc-4.1 (thanks to Ville Skyttä for reporting this issue). - Added two new command line arguments (-X / -Y) to change the default image size for GrabImage(). Internally, they are predefined as -X 720 and -Y 576. - Dropped the Audio-Mode setup option for VDR >= 1.3.18 as VDR's audio menu and PlayPes() took over sending just a single audio stream to the output device. - Fixed implementation of cXineDevice::Clear(), which speeds up jumping back and forth in recordings. A stresstest showed that from time to time a deadlock happened in libasound (ALSA) when xine is opening the audio device. You may experience a problem too if you stay on the GREEN button at the beginning of a recording. On my system it caused segfaults, asserts and deadlocks while xine is opening the ALSA audio device. I'd be glad if someone could fix this issue. Anyway, I hope that this change partitially fixes the delay on some systems which happened when switching to trickspeed modes while replaying a recording. - Added support for VDR's new info key. - Tried to get xine's ffmpeg decoder to work with vdr-xine, but failed. - Had xine CVS take over a couple of my xine patches. - Tuned xine-lib's startcode scanner in libmpeg2. - Adapted vdr-xine to VDR-1.4.41 changed detection of transfer mode. - Adapted vdr-xine to VDR-1.4.42 changed cDevice::PlayAudio(). - Replaced noSignal*.pes with noSignal*.mpg. vdr-xine will complain about a missing noSignal.mpg. Just copy the new files from the source directory to the mentioned location as mentioned in INSTALL. - Changed buffering completely. When VDR switches to a channel, xine starts replaying at 12.5 % of normal speed. Then vdr-xine monitors the stream's PTS values and compares them to the value which xine reports. The difference between VDR's and xine's value makes up the currently gained buffer. When the buffer reaches the configured size then xine switches to 100 % speed. ATTENTION: this change requires you to reduce the configured prebuffer in vdr-xine's setup page to about 8 frames! - Updated MANUAL and INSTALL accordingly.
For this release I suggest the following xine sources:
http://home.vr-web.de/~rnissl/xine-lib-cvs-20060212215500.tar.bz2 http://home.vr-web.de/~rnissl/xine-ui-cvs-20060212215500.tar.bz2
Highly recommended is the following patch:
http://home.vr-web.de/~rnissl/vdr-1.3.42-dvbplayer6.patch http://home.vr-web.de/~rnissl/vdr-1.2.6-dvbplayer5.patch
For details about the patch see:
http://home.vr-web.de/~rnissl/vdr-patches-README.txt
Enjoy.
Bye.
Highly recommended is the following patch:
May I ask why this hasn't been incorporated into VDR yet?
-- Jaroslaw Swierczynski swiergot@gmail.com www.archlinux.org | www.juvepoland.com
Hi,
Jaroslaw Swierczynski wrote:
Highly recommended is the following patch:
May I ask why this hasn't been incorporated into VDR yet?
Actually, this is a hack, which is only necessary for editing old or foreign recordings (old means: taken with VDR < 1.3.26).
Part of the patch which is concerning radio channels with multiple audio tracks is already on Klaus' input queue ;-)
Bye.
Hello,
don't know why xine-ui don't compil here :
source='mediamarks.c' object='mediamarks.lo' libtool=yes \ depfile='.deps/mediamarks.Plo' tmpdepfile='.deps/mediamarks.TPlo' \ depmode=gcc3 /bin/sh ../../../depcomp \ /bin/sh ../../../libtool --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I../../.. -I../../.. -I../../.. -I../../../src -I../../../src -I../../../src/common -I../../../src/common -I../../../src/xitk/xine-toolkit -I../../../src/xitk/xine-toolkit -I/usr/local/include -I../../../src/xitk -I/usr/local/include -DNDEBUG -Wall -D_FILE_OFFSET_BITS=64 -O3 -fomit-frame-pointer -fexpensive-optimizations -fschedule-insns2 -fno-strict-aliasing -ffast-math -funroll-loops -finline-functions -Wpointer-arith -Wnested-externs -Wcast-align -Wchar-subscripts -Wmissing-declarations -Wmissing-prototypes -O2 -pipe -march=k8 -c -o mediamarks.lo `test -f 'mediamarks.c' || echo './'`mediamarks.c gcc -DHAVE_CONFIG_H -I. -I. -I../../.. -I../../.. -I../../.. -I../../../src -I../../../src -I../../../src/common -I../../../src/common -I../../../src/xitk/xine-toolkit -I../../../src/xitk/xine-toolkit -I/usr/local/include -I../../../src/xitk -I/usr/local/include -DNDEBUG -Wall -D_FILE_OFFSET_BITS=64 -O3 -fomit-frame-pointer -fexpensive-optimizations -fschedule-insns2 -fno-strict-aliasing -ffast-math -funroll-loops -finline-functions -Wpointer-arith -Wnested-externs -Wcast-align -Wchar-subscripts -Wmissing-declarations -Wmissing-prototypes -O2 -pipe -march=k8 -c mediamarks.c -MT mediamarks.lo -MD -MP -MF .deps/mediamarks.TPlo -fPIC -DPIC -o .libs/mediamarks.o In file included from ../../../src/xitk/common.h:40, from mediamarks.c:37: ../../../src/xitk/kbindings.h:214: error: `XINE_EVENT_VDR_INFO' undeclared here (not in a function) ../../../src/xitk/kbindings.h:220: error: enumerator value for `ACTID_EVENT_VDR_INFO' not integer constant mediamarks.c: In function `parse_m3u': mediamarks.c:454: warning: passing arg 2 of `getline' from incompatible pointer type mediamarks.c:457: warning: passing arg 2 of `getline' from incompatible pointer type make[5]: *** [mediamarks.lo] Error 1
Hi,
Gregoire Favre wrote:
don't know why xine-ui don't compil here :
source='mediamarks.c' object='mediamarks.lo' libtool=yes \ depfile='.deps/mediamarks.Plo' tmpdepfile='.deps/mediamarks.TPlo' \ depmode=gcc3 /bin/sh ../../../depcomp \ /bin/sh ../../../libtool --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I../../.. -I../../.. -I../../.. -I../../../src -I../../../src -I../../../src/common -I../../../src/common -I../../../src/xitk/xine-toolkit -I../../../src/xitk/xine-toolkit -I/usr/local/include -I../../../src/xitk -I/usr/local/include -DNDEBUG -Wall -D_FILE_OFFSET_BITS=64 -O3 -fomit-frame-pointer -fexpensive-optimizations -fschedule-insns2 -fno-strict-aliasing -ffast-math -funroll-loops -finline-functions -Wpointer-arith -Wnested-externs -Wcast-align -Wchar-subscripts -Wmissing-declarations -Wmissing-prototypes -O2 -pipe -march=k8 -c -o mediamarks.lo `test -f 'mediamarks.c' || echo './'`mediamarks.c gcc -DHAVE_CONFIG_H -I. -I. -I../../.. -I../../.. -I../../.. -I../../../src -I../../../src -I../../../src/common -I../../../src/common -I../../../src/xitk/xine-toolkit -I../../../src/xitk/xine-toolkit -I/usr/local/include -I../../../src/xitk -I/usr/local/include -DNDEBUG -Wall -D_FILE_OFFSET_BITS=64 -O3 -fomit-frame-pointer -fexpensive-optimizations -fschedule-insns2 -fno-strict-aliasing -ffast-math -funroll-loops -finline-functions -Wpointer-arith -Wnested-externs -Wcast-align -Wchar-subscripts -Wmissing-declarations -Wmissing-prototypes -O2 -pipe -march=k8 -c mediamarks.c -MT mediamarks.lo -MD -MP -MF .deps/mediamarks.TPlo -fPIC -DPIC -o .libs/mediamarks.o In file included from ../../../src/xitk/common.h:40, from mediamarks.c:37: ../../../src/xitk/kbindings.h:214: error: `XINE_EVENT_VDR_INFO' undeclared here (not in a function) ../../../src/xitk/kbindings.h:220: error: enumerator value for `ACTID_EVENT_VDR_INFO' not integer constant mediamarks.c: In function `parse_m3u': mediamarks.c:454: warning: passing arg 2 of `getline' from incompatible pointer type mediamarks.c:457: warning: passing arg 2 of `getline' from incompatible pointer type make[5]: *** [mediamarks.lo] Error 1
It seems as if there is an old xine.h around, which doesn't define XINE_EVENT_VDR_INFO.
Bye.
I demand that Reinhard Nissl may or may not have written...
[snip]
- Had xine CVS take over a couple of my xine patches.
... at the expense of not providing patches for *release* versions of xine-lib :-\
I've disabled the version checking so that I can continue to use xine-lib 1.0.3. Updated .debs are being made available.
[snip]
Hi,
Reinhard Nissl wrote:
For this release I suggest the following xine sources:
http://home.vr-web.de/~rnissl/xine-lib-cvs-20060212215500.tar.bz2 http://home.vr-web.de/~rnissl/xine-ui-cvs-20060212215500.tar.bz2
In case that xine-lib cannot be installed (chcon gives an error), please have a look at the following link:
http://85.25.132.30/board/thread.php?postid=425675#post425675
Bye.
El 15/02/2006, a las 0:15, Reinhard Nissl escribió:
For this release I suggest the following xine sources: http://home.vr-web.de/~rnissl/xine-lib-cvs-20060212215500.tar.bz2 http://home.vr-web.de/~rnissl/xine-ui-cvs-20060212215500.tar.bz2
In case that xine-lib cannot be installed (chcon gives an error), please have a look at the following link:
http://85.25.132.30/board/thread.php?postid=425675#post425675
Error 404!
/board/thread.php File Not Found!
On Wed, Feb 15, 2006 at 02:18:28PM +0100, Luis Palacios wrote:
El 15/02/2006, a las 0:15, Reinhard Nissl escribió:
For this release I suggest the following xine sources: http://home.vr-web.de/~rnissl/xine-lib-cvs-20060212215500.tar.bz2 http://home.vr-web.de/~rnissl/xine-ui-cvs-20060212215500.tar.bz2
In case that xine-lib cannot be installed (chcon gives an error), please have a look at the following link:
http://85.25.132.30/board/thread.php?postid=425675#post425675
Anyway, the patch is really small, I can include it here :)
On Tue, Feb 14, 2006 at 09:39:49PM +0100, Reinhard Nissl wrote:
Hi,
I'm pleased to announce Valentine's release 0.7.7:
http://home.vr-web.de/~rnissl/vdr-xine-0.7.7.tgz
Hello,
finaly all is compiled :)
Are you able to edit mark with this combinaison ?
I can't, neither with xxmv, nor xv nor xshm.
Any idea on what I do wrong ?
Thank you very much,
Hello,
On Wed, 15 Feb 2006 00:29:15 +0100 Gregoire Favre gregoire.favre@gmail.com wrote:
| On Tue, Feb 14, 2006 at 09:39:49PM +0100, Reinhard Nissl wrote: | > Hi, | > | > I'm pleased to announce Valentine's release 0.7.7: | > | > http://home.vr-web.de/~rnissl/vdr-xine-0.7.7.tgz | | Hello, | | finaly all is compiled :) | | Are you able to edit mark with this combinaison ? | | I can't, neither with xxmv, nor xv nor xshm. | | Any idea on what I do wrong ? | | Thank you very much, | --
Hello,
Well, i seem to have the same problem : I can use/edit the marks , but if i move the marks using "4" and "6" , picture is not updated, which makes editing quite difficult.
Thanks,
Philippe
VDR 1.3.42 client, Xine + Streamdev plugin / VDR 1.3.42 server 1 FF DVB-S, Streamdev-server plugin
I demand that Philippe Gramoullé may or may not have written...
[snip]
Well, I seem to have the same problem: I can use/edit the marks, but if I move the marks using "4" and "6", picture is not updated, which makes editing quite difficult.
<AOL>. I've reverted to 0.7.6 for now.
Hi,
Philippe Gramoullé wrote:
| On Tue, Feb 14, 2006 at 09:39:49PM +0100, Reinhard Nissl wrote: | > Hi, | > | > I'm pleased to announce Valentine's release 0.7.7: | > | > http://home.vr-web.de/~rnissl/vdr-xine-0.7.7.tgz | | Hello, | | finaly all is compiled :) | | Are you able to edit mark with this combinaison ? | | I can't, neither with xxmv, nor xv nor xshm. | | Any idea on what I do wrong ?
Well, i seem to have the same problem : I can use/edit the marks , but if i move the marks using "4" and "6" , picture is not updated, which makes editing quite difficult.
You are right, it doesn't work anymore ;-(
I simply forgot to test editing cutting marks. While I try to get this fixed soon in 0.7.8, would you please continue to test 0.7.7 and report any further issues?
Bye.
On Wed, Feb 15, 2006 at 08:34:44PM +0100, Reinhard Nissl wrote:
I simply forgot to test editing cutting marks. While I try to get this fixed soon in 0.7.8, would you please continue to test 0.7.7 and report any further issues?
Not really a bug : you had announced that 0.n.m will strech the OSD regarding zoom function, but at leat here, it doesn't...
Is it still planned ?
Thank you,
Hi,
Gregoire Favre wrote:
I simply forgot to test editing cutting marks. While I try to get this fixed soon in 0.7.8, would you please continue to test 0.7.7 and report any further issues?
Not really a bug : you had announced that 0.n.m will strech the OSD regarding zoom function, but at leat here, it doesn't...
Is it still planned ?
I had planned more things for 0.7.7 but I didn't want to delay the release further. The changes in VDR made the release necessary so I just put in the most relevant changes.
Let's see when I find some time to implement the requested functionality.
Bye.
Hi,
Reinhard Nissl wrote:
Well, i seem to have the same problem : I can use/edit the marks , but if i move the marks using "4" and "6" , picture is not updated, which makes editing quite difficult.
You are right, it doesn't work anymore ;-(
The problem is that xine doesn't show the first I frame after a Clear(). Clear() was modified in 0.7.7 as mentioned in HISTORY, so that's the main cause why editing cutting marks doesn't work in plain 0.7.7.
While developing for a "real" fix, one can avoid this issue by applying the attach patch which has vdr-xine send still images twice to xine.
Bye.
Hello Reinhard,
On Wed, 15 Feb 2006 20:51:12 +0100 Reinhard Nissl rnissl@gmx.de wrote:
| The problem is that xine doesn't show the first I frame after a Clear(). | Clear() was modified in 0.7.7 as mentioned in HISTORY, so that's the | main cause why editing cutting marks doesn't work in plain 0.7.7. | | While developing for a "real" fix, one can avoid this issue by applying | the attach patch which has vdr-xine send still images twice to xine.
Thanks for the patch, i can edit cutting marks just fine right now.
Philippe
I demand that Reinhard Nissl may or may not have written...
Reinhard Nissl wrote:
Well, i seem to have the same problem : I can use/edit the marks , but if i move the marks using "4" and "6" , picture is not updated, which makes editing quite difficult.
You are right, it doesn't work anymore ;-(
The problem is that xine doesn't show the first I frame after a Clear(). Clear() was modified in 0.7.7 as mentioned in HISTORY, so that's the main cause why editing cutting marks doesn't work in plain 0.7.7.
While developing for a "real" fix, one can avoid this issue by applying the attach patch which has vdr-xine send still images twice to xine.
Works here. Building and uploading...
On Wed, Feb 15, 2006 at 08:51:12PM +0100, Reinhard Nissl wrote:
The problem is that xine doesn't show the first I frame after a Clear(). Clear() was modified in 0.7.7 as mentioned in HISTORY, so that's the main cause why editing cutting marks doesn't work in plain 0.7.7.
While developing for a "real" fix, one can avoid this issue by applying the attach patch which has vdr-xine send still images twice to xine.
Works also great here !!!
Thank you very much for this quick fix :)
Hello Reinhard,
On Wed, 15 Feb 2006 20:34:44 +0100 Reinhard Nissl rnissl@gmx.de wrote:
| You are right, it doesn't work anymore ;-( | | I simply forgot to test editing cutting marks. While I try to get this | fixed soon in 0.7.8, would you please continue to test 0.7.7 and report | any further issues?
Sure. Well this not directly related to 0.7.7 but following another post where you suggested to use :
http://home.vr-web.de/~rnissl/xine-lib-cvs-20060212215500.tar.bz2 http://home.vr-web.de/~rnissl/xine-ui-cvs-20060212215500.tar.bz2
Well, on my Debian/Sid x86 with gcc version 4.0.3 20060212 (prerelease) (Debian 4.0.2-9), i couldn't compile xine-lib, problem in xine-lib/src/libffmpeg/libavcodec/i386/dsputil_mmx.c
More detailed output here : http://pastebin.com/555896
I was able to get around this issue by using latest xine-lib CVS
Thanks,
Philippe
Hi Reinhard,
I'm pleased to announce Valentine's release 0.7.7:
http://home.vr-web.de/~rnissl/vdr-xine-0.7.7.tgz
......
Do you have any plans about integrating the network ability of the xine plugin ? With 0.7.6 there was only a small difference between these versions, unfortunately you have change some things in the connection area, so it's not so easy anymore to apply this patch.
Hi,
Helmut Auer wrote:
I'm pleased to announce Valentine's release 0.7.7:
http://home.vr-web.de/~rnissl/vdr-xine-0.7.7.tgzDo you have any plans about integrating the network ability of the xine plugin ? With 0.7.6 there was only a small difference between these versions, unfortunately you have change some things in the connection area, so it's not so easy anymore to apply this patch.
When the network patch was first released, I was just about to change the buffering and I wanted to do that before taking over the network patch.
As this buffering changes are now done in 0.7.7 I'm ready to take over the network patch and modify it to use just a single port on server side and just two TCP connections instead of four. This are my plans for 0.8.0.
But due to the bug(s) in 0.7.7, I'll first release 0.7.8.
Bye.
Hi
Do you have any plans about integrating the network ability of the xine plugin ? With 0.7.6 there was only a small difference between these versions, unfortunately you have change some things in the connection area, so it's not so easy anymore to apply this patch.
When the network patch was first released, I was just about to change the buffering and I wanted to do that before taking over the network patch.
As this buffering changes are now done in 0.7.7 I'm ready to take over the network patch and modify it to use just a single port on server side and just two TCP connections instead of four. This are my plans for 0.8.0.
But due to the bug(s) in 0.7.7, I'll first release 0.7.8.
Thanks for the info ! That's good news :-)
Reinhard Nissl rnissl@gmx.de writes:
Hi,
As this buffering changes are now done in 0.7.7 I'm ready to take over the network patch and modify it to use just a single port on server side and just two TCP connections instead of four. This are my plans for 0.8.0.
But due to the bug(s) in 0.7.7, I'll first release 0.7.8.
\o/ That's good news :) Would it be possible to have it handling more than one client ? (sorry i've no idea of the implications and limitations)
Cheers
Hi first of thanks alot for a great plugin. I have found that I must restart vdr at least 2 times to get a stable run of vdr with your plugin. I am using cvs "fbxine" I am using vdr-1.3.42 and vdr-1.3.41 and vdr-1.3.37 OS debain, with 2.6.15.3 kernel
I start xine with this script:
matroxset -f /dev/fb0 -m 5 matroxset -f /dev/fb1 -m 2 matroxset -f /dev/fb1 -o 1 2 fbset -fb /dev/fb1 "1024x768-60" -depth 16 -laced true while true do /usr/bin/fbxine --stdctl --deinterlace -V DirectFB -A alsa vdr:/tmp/vdr-xine/stream#demux:mpeg_pes$ sleep 10
I start vdr with this script:
PLUGINS -P'xine -r' -P'remote -i /dev/input/event3' &
So what happens is that I start it, it runs say for about 10 minutes. Then I loose video but audio is still playing. At that point I still have remote control response to change channels even though no video. I have to stop vdr and restart it. But not fbxine its still running. Then I restart vdr and get stable continuous play. Thanks ----- Original Message ----- From: "Reinhard Nissl" rnissl@gmx.de To: "Klaus Schmidinger's VDR" vdr@linuxtv.org Sent: Tuesday, February 14, 2006 3:39 PM Subject: [vdr] [ANNOUNCE] vdr-xine-0.7.7 plugin
Hi,
I'm pleased to announce Valentine's release 0.7.7:
http://home.vr-web.de/~rnissl/vdr-xine-0.7.7.tgz2006-02-14: Version 0.7.7
- Updated MANUAL (thanks to Ville Skyttä for supplying the patch).
- Added Dutch translation (thanks to Maarten Wisse for supplying the patch).
- Fixed auto primary device functionality concerning ActualDevice (thanks to Luca Olivetti for reporting this issue).
- Shutting down cOsdProvider when vdr-xine is nolonger primary device to fix an issue where the new primary device doesn't register it's own cOsdProvider instance.
- Fixed cXineDevice::SetDigitalAudioDevice() for radio channels with multiple audio tracks (e. g. RADIO INT2). These tracks are not related to each other and therefore syncing these tracks by PTS is impossible and causes huge delays otherwise.
- Adopted cXineDevice::GrabImage() to VDR-1.3.38 (based on a patch of Darren Salt).
- Fixed some issues with FIFO_DIR containing spaces (thanks to Darren Salt for supplying the patch).
- Fixed some warnings about strict-aliasing issues when compiling with gcc-4.1 (thanks to Ville Skyttä for reporting this issue).
- Added two new command line arguments (-X / -Y) to change the default image size for GrabImage(). Internally, they are predefined as -X 720 and -Y 576.
- Dropped the Audio-Mode setup option for VDR >= 1.3.18 as VDR's audio menu and PlayPes() took over sending just a single audio stream to the output device.
- Fixed implementation of cXineDevice::Clear(), which speeds up jumping back and forth in recordings. A stresstest showed that from time to time a deadlock happened in libasound (ALSA) when xine is opening the audio device. You may experience a problem too if you stay on the GREEN button at the beginning of a recording. On my system it caused segfaults, asserts and deadlocks while xine is opening the ALSA audio device. I'd be glad if someone could fix this issue. Anyway, I hope that this change partitially fixes the delay on some systems which happened when switching to trickspeed modes while replaying a recording.
- Added support for VDR's new info key.
- Tried to get xine's ffmpeg decoder to work with vdr-xine, but failed.
- Had xine CVS take over a couple of my xine patches.
- Tuned xine-lib's startcode scanner in libmpeg2.
- Adapted vdr-xine to VDR-1.4.41 changed detection of transfer mode.
- Adapted vdr-xine to VDR-1.4.42 changed cDevice::PlayAudio().
- Replaced noSignal*.pes with noSignal*.mpg. vdr-xine will complain about a missing noSignal.mpg. Just copy the new files from the source directory to the mentioned location as mentioned in INSTALL.
- Changed buffering completely. When VDR switches to a channel, xine starts replaying at 12.5 % of normal speed. Then vdr-xine monitors the stream's PTS values and compares them to the value which xine reports. The difference between VDR's and xine's value makes up the currently gained buffer. When the buffer reaches the configured size then xine switches to 100 % speed. ATTENTION: this change requires you to reduce the configured prebuffer in vdr-xine's setup page to about 8 frames!
- Updated MANUAL and INSTALL accordingly.
For this release I suggest the following xine sources:
http://home.vr-web.de/~rnissl/xine-lib-cvs-20060212215500.tar.bz2 http://home.vr-web.de/~rnissl/xine-ui-cvs-20060212215500.tar.bz2
Highly recommended is the following patch:
http://home.vr-web.de/~rnissl/vdr-1.3.42-dvbplayer6.patch http://home.vr-web.de/~rnissl/vdr-1.2.6-dvbplayer5.patch
For details about the patch see:
http://home.vr-web.de/~rnissl/vdr-patches-README.txt
Enjoy.
Bye.
Dipl.-Inform. (FH) Reinhard Nissl mailto:rnissl@gmx.de
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Hi,
Hu-Emulator wrote:
Hi first of thanks alot for a great plugin. I have found that I must restart vdr at least 2 times to get a stable run of vdr with your plugin. I am using cvs "fbxine" I am using vdr-1.3.42 and vdr-1.3.41 and vdr-1.3.37 OS debain, with 2.6.15.3 kernel
I start xine with this script:
matroxset -f /dev/fb0 -m 5 matroxset -f /dev/fb1 -m 2 matroxset -f /dev/fb1 -o 1 2 fbset -fb /dev/fb1 "1024x768-60" -depth 16 -laced true while true do /usr/bin/fbxine --stdctl --deinterlace -V DirectFB -A alsa vdr:/tmp/vdr-xine/stream#demux:mpeg_pes$ sleep 10
I start vdr with this script:
PLUGINS -P'xine -r' -P'remote -i /dev/input/event3' &
So what happens is that I start it, it runs say for about 10 minutes. Then I loose video but audio is still playing. At that point I still have remote control response to change channels even though no video. I have to stop vdr and restart it. But not fbxine its still running. Then I restart vdr and get stable continuous play.
Hhm, I've no idea why this issue happens after about 10 minutes and vanishes when you restart VDR.
Please try to find something useful in the logs of VDR (e. g. /var/log/messages) and run fbxine with --verbose=2. Of cause you have to redirect stdout/stderr of fbxine to a file in order to get a log from fbxine while console is taken over by directfb.
BTW: nice to hear that xine's directfb driver works with a matrox card.
Bye.
Off topic: I can get hdtv on nimiq 82 but I get 1 main picuture and 2 side pictures usinb fbxine and your newest xine-0.7.7 plugins. Question should I be compiling with osd scaling? My tv aspic ration is 16:9. Thanks ----- Original Message ----- From: "Reinhard Nissl" rnissl@gmx.de To: "VDR Mailing List" vdr@linuxtv.org Sent: Thursday, February 16, 2006 4:17 PM Subject: Re: [vdr] vdr-xine-0.7.7 plugin--Restart always need--then becomesstable
Hi,
Hu-Emulator wrote:
Hi first of thanks alot for a great plugin. I have found that I must restart vdr at least 2 times to get a stable run of vdr with your plugin. I am using cvs "fbxine" I am using vdr-1.3.42 and vdr-1.3.41 and vdr-1.3.37 OS debain, with 2.6.15.3 kernel
I start xine with this script:
matroxset -f /dev/fb0 -m 5 matroxset -f /dev/fb1 -m 2 matroxset -f /dev/fb1 -o 1 2 fbset -fb /dev/fb1 "1024x768-60" -depth 16 -laced true while true do /usr/bin/fbxine --stdctl --deinterlace -V DirectFB -A alsa vdr:/tmp/vdr-xine/stream#demux:mpeg_pes$ sleep 10
I start vdr with this script:
PLUGINS -P'xine -r' -P'remote -i /dev/input/event3' &
So what happens is that I start it, it runs say for about 10 minutes. Then I loose video but audio is still playing. At that point I still have remote control response to change channels even though no video. I have to stop vdr and restart it. But not fbxine its still running. Then I restart vdr and get stable continuous play.
Hhm, I've no idea why this issue happens after about 10 minutes and vanishes when you restart VDR.
Please try to find something useful in the logs of VDR (e. g. /var/log/messages) and run fbxine with --verbose=2. Of cause you have to redirect stdout/stderr of fbxine to a file in order to get a log from fbxine while console is taken over by directfb.
BTW: nice to hear that xine's directfb driver works with a matrox card.
Bye.
Dipl.-Inform. (FH) Reinhard Nissl mailto:rnissl@gmx.de
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Hi,
Hu-Emulator wrote:
I can get hdtv on nimiq 82 but I get 1 main picuture and 2 side pictures usinb fbxine and your newest xine-0.7.7 plugins. Question should I be compiling with osd scaling? My tv aspic ration is 16:9. Thanks
I don't know what you mean. Can you provide a photo?
I don't know an option to not compile in osd scaling. I'd say, it's always compiled in, but you may want to enable or disable it at runtime through the config menus.
Bye.
-
Darren Salt -
Gregoire Favre -
Helmut Auer -
Hu-Emulator -
Jaroslaw Swierczynski -
Klaus Schmidinger -
Luis Palacios -
Philippe Gramoullé -
Reinhard Nissl -
syrius.ml＠no-log.org