Hi,
I'm using vdr-1.6 and xineliboutput from cvs. I'm using it with freevo and vdr is controlled through xine-ui/vdr-sxfe by stdin. For instance I send "hitk Up" to vdr-sxfe or "EventUp" to xine-ui. Every so often when i change between channels xine-ui/vdr-sxfe stops displaying video+osd. I have to quit it and start it again. (but commands are still sent to vdr, if i press "up" 2 times while xine-ui/vdr-sxfe has stopped displaying anything, I can see vdr receiving the "up" events)
I haven't tried to reverse patches, or to reproduce it without using stdin (--stdctl/--slave). Before I do so, I'm just asking if anybody has encountered this issue already.
Cheers.
syrius.ml@no-log.org wrote:
Hi,
I'm using vdr-1.6 and xineliboutput from cvs. I'm using it with freevo and vdr is controlled through xine-ui/vdr-sxfe by stdin. For instance I send "hitk Up" to vdr-sxfe or "EventUp" to xine-ui. Every so often when i change between channels xine-ui/vdr-sxfe stops displaying video+osd. I have to quit it and start it again. (but commands are still sent to vdr, if i press "up" 2 times while xine-ui/vdr-sxfe has stopped displaying anything, I can see vdr receiving the "up" events)
I haven't tried to reverse patches, or to reproduce it without using stdin (--stdctl/--slave). Before I do so, I'm just asking if anybody has encountered this issue already.
Cheers.
For a temporary solution you could revert file xine_input_vdr.c to version 1.127:
cvs update -C -r 1.127 xine_input_vdr.c
It has been reported to cure the kind of behaviour you have been experiencing.
-Petri
syrius.ml@no-log.org wrote:
Hi,
I'm using vdr-1.6 and xineliboutput from cvs. I'm using it with freevo and vdr is controlled through xine-ui/vdr-sxfe by stdin. For instance I send "hitk Up" to vdr-sxfe or "EventUp" to xine-ui.
Can you tell me more on how this works? Are you running a standard freevo rpm, or built from source? How does the xineliboutput work with freevo, is there any HOWTO? How is this stdin key mapping working?
Thanks Simon
"Simon Baxter" linuxtv@nzbaxters.com writes:
syrius.ml@no-log.org wrote:
Hi,
I'm using vdr-1.6 and xineliboutput from cvs. I'm using it with freevo and vdr is controlled through xine-ui/vdr-sxfe by stdin. For instance I send "hitk Up" to vdr-sxfe or "EventUp" to xine-ui.
Can you tell me more on how this works? Are you running a standard freevo rpm, or built from source? How does the xineliboutput work with freevo, is there any HOWTO?
I'm using freevo-1.x from svn. I'm using debian and ubuntu. I'm installing kaa and freevo in /usr/local/stow and using stow to make it available through the standard paths. (cd /usr/src/kaa; python setup.py install --prefix /usr/local/stow/kaa; cd /usr/local/stow; stow kaa; ldconfig; cd /usr/src/freevo; python setup.py install --prefix /usr/local/stow/free; cd /usr/local/stow; stow free)
I then install vdrpylib (although i don't use it) And I use a modified freevo-vdr plugin. (but i can't remember where to get it)
How is this stdin key mapping working?
The freevo-vdr plugin catches and maps freevo events to vdr actions that it passes through stdin. (vdr can be controlled through xine when you use vdr or xineliboutput)
Sorry my english is not helping this evening. Just run xine --stdctl 'xvdr://url/...#need_stuff' and type 'eventup' (or vdr-sxfe --slave with 'hitk up')
Anyway if you're are interested i can give you the modified plugin i'm using.
I'm using freevo-1.x from svn. I'm using debian and ubuntu. I'm installing kaa and freevo in /usr/local/stow and using stow to make it available through the standard paths. (cd /usr/src/kaa; python setup.py install --prefix /usr/local/stow/kaa; cd /usr/local/stow; stow kaa; ldconfig; cd /usr/src/freevo; python setup.py install --prefix /usr/local/stow/free; cd /usr/local/stow; stow free)
I then install vdrpylib (although i don't use it) And I use a modified freevo-vdr plugin. (but i can't remember where to get it)
How is this stdin key mapping working?
The freevo-vdr plugin catches and maps freevo events to vdr actions that it passes through stdin. (vdr can be controlled through xine when you use vdr or xineliboutput)
Sorry my english is not helping this evening. Just run xine --stdctl 'xvdr://url/...#need_stuff' and type 'eventup' (or vdr-sxfe --slave with 'hitk up')
Anyway if you're are interested i can give you the modified plugin i'm using.
Sounds interesting - I've been looking at reskinning my vdr box. Have been using vdr natively with vdr-xine - but need plugins for dvd, mp3, mplayer etc to get features I need. Also the OSD is quite limited and looking a bit dated :)
If you could share your modified plugin - that'd be great
"Simon Baxter" linuxtv@nzbaxters.com writes:
If you could share your modified plugin - that'd be great
If I recall correctly it was based on freevo-vdr-0.5. I copy the 2 files in /usr/local/stow/freevo-1.x/lib/python2.5/site-packages/freevo/plugins/ and I use this in my local_conf.py: plugin.activate('vdr_interface') plugin.activate('vdrtv', level=5) VDR_VIEWER_PLUGIN='sxfe' #VDR_VIEWER_PLUGIN='xine' VDR_USE_SVDRP=0 VDR_SVDRP_HOST='telly' VDR_SVDRP_PORT=2001 VDR_SVDRP_ALWAYSCLOSE=0 #VDR_XINE_FIFO_PATH='xvdr:tcp://telly:37890#nocache;demux:mpeg_block' VDR_XINE_FIFO_PATH='xvdr://telly:37890'
It's a bit hackish, I haven't taken the time make it clearer and cleaner.
--
Petri Helin phelin@googlemail.com writes:
For a temporary solution you could revert file xine_input_vdr.c to version 1.127:
cvs update -C -r 1.127 xine_input_vdr.c
It has been reported to cure the kind of behaviour you have been experiencing.
I'll do that. Cheers.
Petri Helin phelin@googlemail.com writes:
For a temporary solution you could revert file xine_input_vdr.c to version 1.127:
cvs update -C -r 1.127 xine_input_vdr.c
It has been reported to cure the kind of behaviour you have been experiencing.
btw, vdr-sxfe is also affected.
syrius.ml@no-log.org wrote:
Petri Helin phelin@googlemail.com writes:
For a temporary solution you could revert file xine_input_vdr.c to version 1.127:
cvs update -C -r 1.127 xine_input_vdr.c
It has been reported to cure the kind of behaviour you have been experiencing.
btw, vdr-sxfe is also affected.
Reverting xine_input_vdr.c, recompiling (make plugins) and reinstalling vdr-sxfe should fix that.
-Petri
Petri Helin phelin@googlemail.com writes:
cvs update -C -r 1.127 xine_input_vdr.c
It has been reported to cure the kind of behaviour you have been experiencing.
btw, vdr-sxfe is also affected.
Reverting xine_input_vdr.c, recompiling (make plugins) and reinstalling vdr-sxfe should fix that.
That's exactly what i did. /usr/src/vdr/vdr-1.6.0/PLUGINS/src/xineliboutput $ ls -lht |head -n 6 total 5.8M -rwxrwxr-x 1 laurent laurent 211K May 3 00:04 xineplug_inp_xvdr.so -rw-rw-r-- 1 laurent laurent 249K May 3 00:04 xine_input_vdr.o drwxrwxr-x 2 laurent laurent 48 May 3 00:04 CVS -rw-rw-r-- 1 laurent laurent 187K May 3 00:04 xine_input_vdr.c drwxrwxr-x 3 laurent laurent 4.0K May 1 12:28 po
but vdr-sxfe wasn't recompiled. it seems there's no dependency to xine_input_vdr.c
syrius.ml@no-log.org wrote:
but vdr-sxfe wasn't recompiled. it seems there's no dependency to xine_input_vdr.c
You may have to run "make clean-plugins".
( cd /usr/src/vdr-1.6.0-1/ make clean-plugins make plugins
cd /usr/src/vdr-1.6.0-1/PLUGINS/src/xineliboutput-1.0.0 make install
cp /usr/src/vdr-1.6.0-1/PLUGINS/lib/libvdr-xineliboutput.so.1.6.0 \ /usr/lib/vdr/plugins/ cp /usr/src/vdr-1.6.0-1/PLUGINS/lib/libxineliboutput-sxfe.so.1.0.0 \ /usr/lib/vdr/plugins/ )
Pertti Kosunen pertti.kosunen@pp.nic.fi writes:
syrius.ml@no-log.org wrote:
but vdr-sxfe wasn't recompiled. it seems there's no dependency to xine_input_vdr.c
You may have to run "make clean-plugins".
what I meant is that it does not seem vdr-sxfe depends on xine_input_vdr.c And the modification made to xine_input_vdr.c won't affect vdr-sxfe. And it can be verified by removing xine_input_vdr.{c,o} vdr-sxfe and running make vdr-sxfe
syrius.ml@no-log.org wrote:
Pertti Kosunen pertti.kosunen@pp.nic.fi writes:
syrius.ml@no-log.org wrote:
but vdr-sxfe wasn't recompiled. it seems there's no dependency to xine_input_vdr.c
You may have to run "make clean-plugins".
what I meant is that it does not seem vdr-sxfe depends on xine_input_vdr.c And the modification made to xine_input_vdr.c won't affect vdr-sxfe. And it can be verified by removing xine_input_vdr.{c,o} vdr-sxfe and running make vdr-sxfe
It will affect in a sense since xine_input_vdr.c is used when building xineplug_inp_xvdr.so (the xine VDR input plugin) which in turn is used whether you use vdr-sxfe or xine-ui. So, the important thing is to replace the xine plugin after recompile, which is done by make install.
Are you saying that you still see the same behaviour when using vdr-sxfe? Even if you recompile and replace the xine plugin?
-Petri
Petri Helin phelin@googlemail.com writes:
It will affect in a sense since xine_input_vdr.c is used when building xineplug_inp_xvdr.so (the xine VDR input plugin) which in turn is used whether you use vdr-sxfe or xine-ui. So, the important thing is to replace the xine plugin after recompile, which is done by make install.
ok, I was thinking only xine-ui was using the plugin.
Are you saying that you still see the same behaviour when using vdr-sxfe? Even if you recompile and replace the xine plugin?
Don't know, I haven't tried :) Going to try right now
Reverting xine_input_vdr.c breaks the OSD scaling.
cu
Edgar (gimli) Hucek
Petri Helin schrieb:
syrius.ml@no-log.org wrote:
Petri Helin phelin@googlemail.com writes:
For a temporary solution you could revert file xine_input_vdr.c to version 1.127:
cvs update -C -r 1.127 xine_input_vdr.c
It has been reported to cure the kind of behaviour you have been experiencing.
btw, vdr-sxfe is also affected.
Reverting xine_input_vdr.c, recompiling (make plugins) and reinstalling vdr-sxfe should fix that.
-Petri
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
gimli wrote:
Reverting xine_input_vdr.c breaks the OSD scaling.
cu
Edgar (gimli) Hucek
Could you elaborate a bit? What settings do you have, what is the resolution of the video when it happens, what are the exact symptoms you are experiencing and so on... I myself have not yet experienced any breakage.
But still, reverting was meant as a temporary solution, not a permanent one.
-Petri
Screen resolution is 1920x1080 for HDTV. When is switch from an SDTV channel to an HDTV channel the OSD is way to small. Looks there is no scalling to the larger resolution.
cu
Edgar (gimli) Hucek
Petri Helin schrieb:
gimli wrote:
Reverting xine_input_vdr.c breaks the OSD scaling.
cu
Edgar (gimli) Hucek
Could you elaborate a bit? What settings do you have, what is the resolution of the video when it happens, what are the exact symptoms you are experiencing and so on... I myself have not yet experienced any breakage.
But still, reverting was meant as a temporary solution, not a permanent one.
-Petri
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
gimli wrote:
Screen resolution is 1920x1080 for HDTV. When is switch from an SDTV channel to an HDTV channel the OSD is way to small. Looks there is no scalling to the larger resolution.
Yes, that's an unfortunate side effect. You could try reverting several other files also, namely setup_menu.c, osd.c, config.c, config.h, menu.c and xine_frontend_main.c to April the 13th, but I cannot promise it'll work. The other alternative is to wait until the issue gets solved properly.
-Petri
gimli wrote:
Screen resolution is 1920x1080 for HDTV. When is switch from an SDTV channel to an HDTV channel the OSD is way to small. Looks there is no scalling to the larger resolution.
You might want to give the cvs a go now. There should be a proper fix in place and no more reverting is needed.
-Petri
Petri Helin phelin@googlemail.com writes:
gimli wrote:
Screen resolution is 1920x1080 for HDTV. When is switch from an SDTV channel to an HDTV channel the OSD is way to small. Looks there is no scalling to the larger resolution.
You might want to give the cvs a go now. There should be a proper fix in place and no more reverting is needed.
Seems ok. Although, I still have issues with OSD and channels broadcasting "small" video streams (for instance, ITV2 @28.2E => 544x576) In that case OSD is bigger than screen and I miss a bit on the right.
The behavior is different whether I use vdr-sxfe or xine-ui
With xine-ui OSD is always out of the screen, whatever the video/osd settings. (xine-ui is run in full screen (800x600), setting the aspect ratio or the screen size, using pp/expandi don't change a thing)
With vdr-sxfe, I have to set xineliboutput.Video.SwScale to 1
It might be the expected behavior, I don't mind using vdr-sxfe and SwScale. (i just need to resolve some issues with my alsa setup)
Thanks.
xinelibout settings are: xineliboutput.OSD.AlphaCorrection = 0 xineliboutput.OSD.AlphaCorrectionAbs = 30 xineliboutput.OSD.Downscale = 1 xineliboutput.OSD.ExtSubSize = -1 xineliboutput.OSD.HideMainMenu = 0 xineliboutput.OSD.LayersVisible = 4 xineliboutput.OSD.Prescale = 1 xineliboutput.OSD.Scaling = 1 xineliboutput.OSD.UnscaledAlways = 0 xineliboutput.OSD.UnscaledLowRes = 0 xineliboutput.OSD.UnscaledOpaque = 0 xineliboutput.Video.AspectRatio = 2 xineliboutput.Video.AutoCrop = 0 xineliboutput.Video.AutoCrop.AutoDetect = 1 xineliboutput.Video.AutoCrop.DetectSubs = 1 xineliboutput.Video.AutoCrop.FixedSize = 1 xineliboutput.Video.AutoCrop.SoftStart = 1 xineliboutput.Video.Brightness = -1 xineliboutput.Video.Contrast = -1 xineliboutput.Video.Deinterlace = none xineliboutput.Video.DeinterlaceOptions = method=Linear,cheap_mode=1,pulldown=none,framerate_mode=full,judder_correction=1,use_progressive_frame_flag=1,chroma_filter=0,enabled=1 xineliboutput.Video.HUE = -1 xineliboutput.Video.IBPTrickSpeed = 0 xineliboutput.Video.MaxTrickSpeed = 12 xineliboutput.Video.Overscan = 0 xineliboutput.Video.Saturation = -1 xineliboutput.Video.SwScale = 1 xineliboutput.Video.SwScale.Aspect = 0 xineliboutput.Video.SwScale.Downscale = 0 xineliboutput.Video.SwScale.Height = 576 xineliboutput.Video.SwScale.Resize = 1 xineliboutput.Video.SwScale.Width = 720
-
gimli -
Pertti Kosunen -
Petri Helin -
Simon Baxter -
syrius.ml＠no-log.org