[vdr] VDR not starting if a plugin fails to start?
Hi, I have been running VDR as a daemon started via init script for some years now. I am currently using version 1.6.0-2. The problem is, that every now and then VDR doesn't start when I boot the server. The culprit seems to be lcdproc plugins, which for some reason cannot always connect to the LCDd daemon. In VDR's log it shows up like this: OK: Sep 18 16:31:49 vdrkone2 vdr: [4890] starting plugin: lcdproc Sep 18 16:31:49 vdrkone2 vdr: connection to LCDd at localhost:13666 established. Sep 18 16:31:49 vdrkone2 vdr: LCD output thread started (pid=4890), display size: 2x16 NOT OK: Sep 18 19:05:45 vdrkone2 vdr: [4876] starting plugin: lcdproc Sep 18 19:05:45 vdrkone2 vdr: [4876] stopping plugin: femon Sep 18 19:05:45 vdrkone2 vdr: [4876] stopping plugin: burn Now, the question is, does this really cause VDR to shut down? And if so, should VDR behave in some other way in such a case? Or is it just lcdproc plugin that causes such a behaviour? Is it possible for VDR to retry starting plugin which failed to start? -Petri ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR not starting if a plugin fails to start?
Diego Pierotto wrote: > Petri Helin ha scritto: >> Hi, >> >> I have been running VDR as a daemon started via init script for some >> years now. I am currently using version 1.6.0-2. The problem is, that >> every now and then VDR doesn't start when I boot the server. The culprit >> seems to be lcdproc plugins, which for some reason cannot always connect >> to the LCDd daemon. In VDR's log it shows up like this: >> >> OK: >> >> Sep 18 16:31:49 vdrkone2 vdr: [4890] starting plugin: lcdproc >> Sep 18 16:31:49 vdrkone2 vdr: connection to LCDd at localhost:13666 >> established. >> Sep 18 16:31:49 vdrkone2 vdr: LCD output thread started (pid=4890), >> display size: 2x16 >> >> NOT OK: >> >> Sep 18 19:05:45 vdrkone2 vdr: [4876] starting plugin: lcdproc >> Sep 18 19:05:45 vdrkone2 vdr: [4876] stopping plugin: femon >> Sep 18 19:05:45 vdrkone2 vdr: [4876] stopping plugin: burn >> >> Now, the question is, does this really cause VDR to shut down? And if >> so, should VDR behave in some other way in such a case? Or is it just >> lcdproc plugin that causes such a behaviour? Is it possible for VDR to >> retry starting plugin which failed to start? >> >> -Petri >> >> >> ___ >> vdr mailing list >> vdr@linuxtv.org >> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr >> >> > Hi, > what i now there is a patch inside Extension Patch that allow VDR to > start even if a plugin fails. > I don't remember which it's, just check inside the package. > > Diego Pierotto > I may have been a bit vague and unclear in what I wrote earlier. I did check the source code and noticed that if a plugin fails to start it really causes VDR to not start also. My aim really was to start some discussion on whether that should be changed. I myself think that VDR should start although some plugin fails to start. I'd hate to find out that some timed recording failed because the lcd display of the PC case malfunctioned. -Petri ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR not starting if a plugin fails to start?
Jouni Karvo wrote: > Petri Helin wrote: >> really causes VDR to not start also. My aim really was to start some >> discussion on whether that should be changed. I myself think that VDR >> should start although some plugin fails to start. I'd hate to find out >> that some timed recording failed because the lcd display of the PC case >> malfunctioned. >> >> > > Why not design plugins that start even if some non-fatal error happens? > To me it sounds natural that if > some non-recoverable error happens, the whole program stops. > I regularly use the a constant set of following set of plugins: burn, extrecmenu, epgsearch, femon, lcdproc, live, osdteletext, skinsoppalusikka, streamdev and xineliboutput. I cannot come up with any reason for any plugin besides xineliboutput being critical for my normal use. And VDR can run by itself quite well even without xineliboutput. So there really is no reason for VDR not to start if any of those plugins above fail to start. In fact I am already wondering why plugins are not hot-pluggable... -Petri ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR not starting if a plugin fails to start?
VDR User wrote: > I like that VDR won't load if a plugin failed. That means there was a > problem, and I should go fix it. Also, it's the plugins job to > continue on non-fatal errors, not VDR. How would VDR even know whats > a non-fatal error for a certain plugin? From VDR's perspective either > the plugin is working or it's not. > But why should even a fatal error (from plugin's perspective) cause VDR to not start? It should only cause the plugin not to be loaded. Of course plugins could also implement more intelligent initialization and try to deal with possible errors, but isn't it easier to just handle it in one place - at the VDR? If I think of the core VDR, I see its main function as recording TV-programmes. From that perspective it's not that big of a problem if it doesn't start properly due to a plugin not bevahing properly if I am sitting next to the PC and can fix or circumvent the problem. But since it will mostly record when I am not sitting next to it, I would prefer that it would still record the programme, no matter if all the plugins failed. -Petri ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR not starting if a plugin fails to start?
VDR User wrote: > I think it's a huge assumption (and incorrect one) to say the main > function of VDR is to record tv shows. I know many people who use it > for watching live tv, email notices, weather report, playing other > media something like an htpc, etc. Ok, let me rephrase it: for my purposes, the main task of VDR is to record TV programmes. I do use it for lots of other purposes also, but for me that is its main task. Some kind of an analogy could be drawn between Firefox and VDR: Although I use a lot of extensions with Firefox, I wouldn't want one that doesn't really behave to stop me using Firefox altogether. And before you ask, I don't know how Firefox reacts to a badly behaving extension ;) -Petri ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR not starting if a plugin fails to start?
Udo Richter wrote: > Petri Helin wrote: >> In fact I am already wondering why plugins are not >> hot-pluggable... > > They are, to some degree, by using the proxy plugin. The proxy plugin > can delay loading a plugin, and for some plugins it can unload a plugin > while VDR is running. It can also do the requested continue-on-error for > plugins. > Well that was nice news. Haven't heard about the proxy plugin before for some reason, but I will give it a shot and see what it is capable of. Thanks. -Petri ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] cannot compile most recent snapshot of vdr-xineliboutput
Diego Pierotto wrote: > Uwe Kiewel ha scritto: >> cc -O3 -pipe -Wall -fPIC -g -I/usr/local/include-c -D_GNU_SOURCE >> -DPLUGIN_NAME_I18N='"xineliboutput"' -D_REENTRANT -D_LARGEFILE_SOURCE >> -D_FILE_OFFSET_BITS=64 -DXINELIBOUTPUT_VERSION='"1.0.2"' >> -DHAVE_XRENDER=1 -DHAVE_XDPMS=1 -DHAVE_XINERAMA=1 -DHAVE_EXTRACTOR_H=1 >> -DUSE_ICONV=1 -Wall -I../../../include -I/usr/include/qt4 >> xine_input_vdr.c >> xine_input_vdr.c: In function 'resume_demuxer': >> xine_input_vdr.c:2363: error: 'xine_stream_t' has no member named >> 'demux_resume' >> make: *** [xine_input_vdr.o] Error 1 >> >> ___ >> vdr mailing list >> vdr@linuxtv.org >> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr >> >> > Hi, > now i tried to download last version 1.0.2 but it gives me the same error. > What i noticed is that if i revert the file xine_input_vdr.c as i wrote > before i can't see any xvdr icon in Xine. > > I'm running VDR with this option: > > ./vdr -P"xineliboutput --local=sxfe --video=xv --audio=oss --remote=none" > > Diego Pierotto > You might want to upgrade xine-lib (or even use xine-lib-1.2) to fix the compiling problem. -Petri ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] cannot compile most recent snapshot of vdr-xineliboutput
Uwe Kiewel wrote: > Petri Helin schrieb: >> Diego Pierotto wrote: >>> Uwe Kiewel ha scritto: >>>> cc -O3 -pipe -Wall -fPIC -g -I/usr/local/include-c -D_GNU_SOURCE >>>> -DPLUGIN_NAME_I18N='"xineliboutput"' -D_REENTRANT -D_LARGEFILE_SOURCE >>>> -D_FILE_OFFSET_BITS=64 -DXINELIBOUTPUT_VERSION='"1.0.2"' >>>> -DHAVE_XRENDER=1 -DHAVE_XDPMS=1 -DHAVE_XINERAMA=1 -DHAVE_EXTRACTOR_H=1 >>>> -DUSE_ICONV=1 -Wall -I../../../include -I/usr/include/qt4 >>>> xine_input_vdr.c >>>> xine_input_vdr.c: In function 'resume_demuxer': >>>> xine_input_vdr.c:2363: error: 'xine_stream_t' has no member named >>>> 'demux_resume' >>>> make: *** [xine_input_vdr.o] Error 1 >>>> >>>> ___ >>>> vdr mailing list >>>> vdr@linuxtv.org >>>> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr >>>> >>>> >>> Hi, >>> now i tried to download last version 1.0.2 but it gives me the same error. >>> What i noticed is that if i revert the file xine_input_vdr.c as i wrote >>> before i can't see any xvdr icon in Xine. >>> >>> I'm running VDR with this option: >>> >>> ./vdr -P"xineliboutput --local=sxfe --video=xv --audio=oss --remote=none" >>> >>> Diego Pierotto >>> >> You might want to upgrade xine-lib (or even use xine-lib-1.2) to fix the >> compiling problem. >> >> -Petri > > Now I tried the most recent version from Reinhard at > http://home.vrweb.de/~rnissl/ > > Now, it works. > Unless using vdr-xine, it could be a better option to use the hg version of either xine-lib or xine-lib-1.2 when using the newest release or the cvs version of xineliboutput. -Petri ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Problems building xine-lib on openSUSE 11.0 w/ gcc 4.3.1
On Tue, Oct 28, 2008 at 10:17 AM, Harald Milz <[EMAIL PROTECTED]> wrote: > On Wed, Oct 15, 2008 at 04:48:55PM +0100, Darren Salt wrote: >> Known problem. Use newer xine-lib (if you're using what I think that you're >> using, it's old and unsupported) and external ffmpeg. > > That sounds as if the vdr-xine plugin were outdated and should no longer be > used on recent distros. If this is so, this should be noted in the vdr-wiki > and one should use xineliboutput instead. Is that so? > How did you deduce that, when Darren said that you should upgrade your xine-lib? You might even jump to xine-lib 1.2 which already includes vdr-xine plugin. -Petri ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Problems building xine-lib on openSUSE 11.0 w/ gcc 4.3.1
On Tue, Oct 28, 2008 at 11:38 AM, Niels Wagenaar <[EMAIL PROTECTED]> wrote: > -Original message- > From: Goga777 <[EMAIL PROTECTED]> > Sent: Tue 28-10-2008 10:06 > To: vdr@linuxtv.org; > Subject: Re: [vdr] Problems building xine-lib on openSUSE 11.0 w/ gcc 4.3.1 > >> > -- SNIP -- >> > How did you deduce that, when Darren said that you should upgrade your >> > xine-lib? You might even jump to xine-lib 1.2 which already includes >> > vdr-xine plugin. >> >> does xine-lib 1.2 include vdr-pligin from Reinchard Nissl ? are you sure ? >> > > Last time I check, xine-lib 1.2 doesn't include the vdr-xine plugin. But, if > you use 1.2, you don't have to patch xine-lib anymore. > > Xine-lib 1.2 now includes the patches for Xine-Lib so that you connect to a > VDR system which is using the vdr-xine plugin. > Sorry, I put it very badly :( Of course xine-lib 1.2 doesn't include the whole vdr-xine plugin, but the VDR input plugin for xine-lib. -Petri ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] media player and a/52 sound.
On Mon, Nov 3, 2008 at 10:57 AM, JJussi <[EMAIL PROTECTED]> wrote: > Hi! > Could somebody enlight me why xine under vdr mediaplayer have problems with > ac3 sound? > I have file what I can play without problems directly with xine: > > xine: found demuxer plugin: matroska demux plugin > video discontinuity #1, type is 0, disc_off 0 > waiting for audio discontinuity #1 > audio discontinuity #1, type is 0, disc_off 0 > demux_matroska: Track 1, A_AC3 und > waiting for in_discontinuity update #1 > demux_matroska: Track 2, V_MPEG4/ISO/AVC eng > vpts adjusted with prebuffer to 24249 > load_plugins: plugin ffmpegvideo will be used for video streamtype 4d. > load_plugins: plugin a/52 will be used for audio streamtype 00. > > But if I select same file in VDR - [menu] - Media Player - Play file > Picture is ok, but only sound what I get is surround channel (background > noise). > > I have copied file '.xine/config' to '.xine/config_xineliboutput' with no > help. > > At plugins setup - xineliboutpu - audio I have set: > Speakers: Pass Through > Upmix stereo to 5.1: Yes > Rest of selections are no/off > > Connection from computer to amp is SPDIF > I assume that you use vdr-sxfe as the frontend for xineliboutput? What does its log output look like? Please set logging to verbose and post here (as attachments) the results. And the same with xine. -Petri ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] media player and a/52 sound.
JJussi wrote: >> I assume that you use vdr-sxfe as the frontend for xineliboutput? What >> does its log output look like? Please set logging to verbose and post >> here (as attachments) the results. And the same with xine. >> >> -Petri > > Hi! > That's right! vdr-sxfe is my front end. > Here is log files. > > Well, your logs didn't really reveal anything. I get the same entries when replaying a matroska file with AC3 audio and everything works just fine. Here are relevant parts of my settings, in case those might help you. config_xineliboutput: audio.driver:alsa audio.device.alsa_default_device:hw:0,1 audio.device.alsa_front_device:hw:0,1 audio.device.alsa_passthrough_device:plug:spdif:0 audio.device.alsa_surround40_device:plug:spdif:0 audio.device.alsa_surround51_device:hw:0,1 audio.output.speaker_arrangement:Pass Through audio.synchronization.slow_fast_audio:1 audio.synchronization.av_sync_method:resample audio.synchronization.resample_mode:off VDR's setup.conf: xineliboutput.Audio.Compression = 100 xineliboutput.Audio.Delay = 0 xineliboutput.Audio.Driver = alsa xineliboutput.Audio.Headphone = 0 xineliboutput.Audio.Port = default xineliboutput.Audio.SoftwareVolumeControl = 1 xineliboutput.Audio.Speakers = Pass Through xineliboutput.Audio.Surround = 0 xineliboutput.Audio.Upmix = 0 -Petri ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] xineliboutput not working
On Mon, Nov 3, 2008 at 9:27 PM, hudo kkow <[EMAIL PROTECTED]> wrote: > And why this >> (build with xine-lib 1.1.90, using xine-lib 1.1.15) if > I built xine-lib 1.2? > Do you have both xine-lib 1.2 and 1.1.15 installed? 1.1.90 means 1.2. -Petri ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] media player and a/52 sound.
JJussi wrote: > Base question/problem is.. Why vdr-xineliboutput don't work with xine > settings? (as I stated at start of this thread, with xine I don't have > problems with these files... Coping config file to setup_xineliboutput don't > solve problem.) > Most likely there is something else wrong. If I understood correctly, the problematic file has AC3 sound, but what exactly is it? Dolby digital 5.1? Does the same happen with all files containing AC3 sounds? Could you try with the samples found on this site (e.g. the 26MB Ambient Life): http://www.diatonis.com/downloads_dts_ac3.html What does your receiver say about the stream it is receiving? Does it recognize it as a DD track? -Petri ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] media player and a/52 sound.
JJussi wrote: > I would.. If I could.. When I try to download file, I get "403 Forbidden" > Even for this direct link? http://www.diatonis.com/downloads/diatonis_ac3_48k_soal.zip -Petri ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR on Fedora recommended window manager
On Sat, Nov 15, 2008 at 6:15 AM, Simon Baxter <[EMAIL PROTECTED]> wrote: > Hi > > I'm running VDR-1.6.0 and vdr-xine on my Fedora 6 box, and am moving into > Fedora 9. > Perhaps you could hold out for 11 days? Fedora 10 is due then. > I've always had problems with a lack of real understanding on window > managers, so have put up with GDM under Fedora 6, but Fedora 9 has some real > nasty "clever" stuff that just simply needs disabling. > What is this clever stuff? > Can anyone suggest a howto, or can guide me on how to circumvent this > entirely? Basically I need to: > > 1) auto log into 'vdruser' > 2) start xine > > That's it. Everything else is done behind the scenes, and I can handle. > > Can anyone help? > I apologize that I cannot give a simple howto for Fedore since I use Ubuntu myself, but I guess the same approach should work. What I did, was as follows: 1. Remove all Gnome related packages 2. Install slim (http://slim.berlios.de/index.php) 3. Install fluxbox (http://fluxbox.org/) Both of those can be found in Ubuntu repositories, but I used the git/cvs/svn/hg versions. Slim can be configured to do autologin with your favorite user and fluxbox in turn can be configured to start your favorite applications by modifying its startup file (http://fluxbox-wiki.org/index.php?title=Editing_the_startup_file). This is of course only one solution, but in my opinion it is easy and versatile enough. -Petri ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] xineliboutput sxfe / xxmc / via / EPIA ML6000 : great !
On Mon, Nov 24, 2008 at 11:11 AM, <[EMAIL PROTECTED]> wrote: > >> * diskless system : EPIA ML6000 / 600MHz, 512MB, diskless, 100Mbps > Ethernet, 12V power supply, no fan, no noise : 25W off the wall while > decoding video > > Blah, only one PCI slot. Where are proper low-power MB's with 2 or more PCI > slots for DVB-cards? Ever heard about PCI risers? Like this one: http://linitx.com/viewproduct.php?prodid=10568 Works splendidly with Epia boards. -Petri ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] New Video Decode and Presentation API from NVidia
On Mon, Nov 24, 2008 at 2:53 PM, Nicolas Huillard <[EMAIL PROTECTED]> wrote: > It seems that things are really moving, and VDR-HD may finally work with > cheap hardware by the time HD material is commonplace. > Well, in that case it is a good time for broadcasters to implement copy protection, chipset pairing in CAM etc... -Petri ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Where is the H.264 patch?
On Mon, Nov 24, 2008 at 9:44 PM, Tony Houghton <[EMAIL PROTECTED]> wrote: > On Fri, 21 Nov 2008 11:49:23 +0100 > jlacvdr <[EMAIL PROTECTED]> wrote: > >> to vdr-1.7.0, in attach file of this message : >> http://www.linuxtv.org/pipermail/vdr/2008-April/016513.html > > Is there a patch that will work with 1.6.0? It'll make things rather > easier if I can just patch the debian packages instead of completely > replacing them. > http://www.linuxtv.org/pipermail/vdr/2008-March/016227.html -Petri ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] xineliboutput OSD and playback problems
Antti Seppälä wrote: > > Reports about this pop-up occasionally so I'll try to clarify: > > You need a compositing window manager to see both the hud osd and > video at the same time. > > I recommend xcompmgr because it can run in parallel to your normal > window manager and serve the necessary compositing extensions as an > addition. Of the compositing managers I've tried it also seems to be > the fastest / least cpu intensive. > > So install xcompmgr and run: > xcompmgr -n& > > prior to starting vdr-sxfe --hud > > You'll need to setup xorg.conf so that compositing is enabled. IOW you > should have lines similar to following in you xorg.conf: > > Section "Extensions" > Option "Composite" "Enable" > EndSection > > Concerning your other display issues (opengl osd etc.) I'd recommend > trying without patched vdr and maybe latest version of xine-lib. > In addition to that I believe one needs to use Textured video instead of Overlay to get transparency working. -Petri ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Few more questions about xinelibout
On Thu, Dec 4, 2008 at 11:43 PM, Alex Betis <[EMAIL PROTECTED]> wrote: > Hi all, > > Few more questions about xinelibout. > I've run the frontend now as a separate task and looks like it doesn't crash > now except when I try to open a picture, I'll try to debug it later. > Perhaps your pictures a too big for xv? Try to reduce their size. > The questions are probably very simple: > - When I playback a file, how can I move back? When replaying a live stream > my "<" and ">" keys act as backward and forward buttons. In file playback > forward runs the movie forward indeed, but backward button slows the > playback until its fully stopped. This is a standard feature/restriction of many software players. You can jump backwards a given number of seconds, but a true rewind is not possible. > - Does deinterlacing settings from VDR menu apply also to movie playback? > Sometimes I can see effects of picture is not sync with the screen, I mean > that the picture is shown as its 2 halfs (top and bottom) that are moving in > very little difference. Thats mostly seen when the whole picture is moved. Sounds like tearing to me. Usually caused by difference in the output refresh rate and the video being played back, or just crappy drivers (like Intel with certain hardware combined with Textured video). -Petri ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Few more questions about xinelibout
On Fri, Dec 5, 2008 at 10:48 AM, Alex Betis <[EMAIL PROTECTED]> wrote: > On Fri, Dec 5, 2008 at 12:25 AM, Petri Helin <[EMAIL PROTECTED]> wrote: >> >> On Thu, Dec 4, 2008 at 11:43 PM, Alex Betis <[EMAIL PROTECTED]> wrote: >> > Hi all, >> > >> > Few more questions about xinelibout. >> > I've run the frontend now as a separate task and looks like it doesn't >> > crash >> > now except when I try to open a picture, I'll try to debug it later. >> > >> >> Perhaps your pictures a too big for xv? Try to reduce their size. > > I would expect the software to do it... You need to patch xine-lib to do that. But first I suggest you try out with smaller pictures to confirm the reason. What is the resolution of the pictures? >> >> >> > The questions are probably very simple: >> > - When I playback a file, how can I move back? When replaying a live >> > stream >> > my "<" and ">" keys act as backward and forward buttons. In file >> > playback >> > forward runs the movie forward indeed, but backward button slows the >> > playback until its fully stopped. >> >> This is a standard feature/restriction of many software players. You >> can jump backwards a given number of seconds, but a true rewind is not >> possible. > > Jump back is good enough, the question is how can I do it in xinelibout > frontend? See the README file under "Media player key bindings for video files": GreenJump 1 min back Yellow Jump 1 min forward 1, User8 Jump 20 s back 3, User9 Jump 20 s forward >> > - Does deinterlacing settings from VDR menu apply also to movie >> > playback? >> > Sometimes I can see effects of picture is not sync with the screen, I >> > mean >> > that the picture is shown as its 2 halfs (top and bottom) that are >> > moving in >> > very little difference. Thats mostly seen when the whole picture is >> > moved. >> >> Sounds like tearing to me. Usually caused by difference in the output >> refresh rate and the video being played back, or just crappy drivers >> (like Intel with certain hardware combined with Textured video). > > I was looking for the right word... tearing... > I have nVidia 177.82 driver. Again, mplayer has no such problem. Try xine-ui with the same file. If that works, compare files ~/.xine/config and ~/.xine/config_xineliboutput for any differences. -Petri ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr 1.7.4 & xineliboutput
Artem Makhutov wrote: > Hi, > > On Sat, Mar 07, 2009 at 12:22:11AM +0200, Lauri Tischler wrote: >> Artem Makhutov wrote: >> >>> Is some body working on getting xineliboutput to work vdr-1.7.4? >> Latest CVS works. > > I tried the lastest CVS, but it does not work for me. > Only the OSD is working. > > I am just getting a lot of this error messages: > > ar...@gandalf ~ $ vdr-sxfe --video=xv xvdr:tcp://192.168.10.2 > vdr-sxfe 1.0.4 (build with xine-lib 1.1.16, using xine-lib 1.1.16) > > Video driver: xv > VDR Server: xvdr:tcp://192.168.10.2 > > [6739] [vdr-fe]Detected 4 CPUs > [6739] [vdr-fe]Enabling multithreaded video decoding > > > Press Esc to exit > > [6739] [input_vdr] Connecting (control) to tcp://192.168.10.2:37890 ... > [6739] [input_vdr] Server greeting: VDR-1.7.4 xineliboutput-1.0.4 READY > [6739] [input_vdr] Connected (control) to tcp://192.168.10.2:37890 > [6739] [input_vdr] Connecting (data) to tcp://192.168.10.2:37890 ... > [6739] [input_vdr] Data stream connected (TCP) > xv_set_property: property=8, value=100 > xv_set_property: property=2, value=0 > xv_set_property: property=3, value=4096 > xv_set_property: property=5, value=0 > xv_set_property: property=4, value=4096 > xv_set_property: property=1, value=0 > [6753] [input_vdr] TCP: Buffer too small (8192 ; incoming frame 65550 bytes) > [6753] [input_vdr] TCP: Buffer too small (8192 ; incoming frame 1761883596 > bytes) > [6753] [input_vdr] TCP: Buffer too small (8192 ; incoming frame 2145345499 > bytes) > [6753] [input_vdr] TCP: Buffer too small (8192 ; incoming frame 1780906752 > bytes) > [...] > [6753] [input_vdr] TCP: Buffer too small (8192 ; incoming frame 504944419 > bytes) > [6753] [input_vdr] TCP: Buffer too small (8192 ; incoming frame 307106073 > bytes) > [6753] [input_vdr] TCP: Buffer too small (8192 ; incoming frame 793579809 > bytes) > [6753] [input_vdr] TCP: Buffer too small (8192 ; incoming frame 1734679773 > bytes) > Not multiplexed? 0xf6 > Not multiplexed? 0xbd > Speicherzugriffsfehler > There were some buffer related changes done in the cvs on 5th of March, so you could try with a version a bit older than that (cvs co -D 2009-03-04). -Petri ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] Where do you live and what kind of broadcast do you receive?
Hi, I have wondered for some time how broad has VDR spread and how is it really used. So, if people could post their location and the type of broadcast they are receiving, we could get some kind of understanding about the state of DVB (or ATSC) as it is now. Just a brief description, using myself as an example: Country: Finland Transmission: DVB-C Encoding: MPEG-2 for SD (tens of channels) and h.264 for HD (less than 10 channels) The main point is to get an idea of the standards used across the globe. I know that wiki etc give some idea, but you can never beat the first hand information. -Petri ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Best practices for running vdr-xine
On Wed, Apr 29, 2009 at 5:22 PM, Jan Ekholm wrote: > On Wednesday 29 April 2009 14:05:33 Pertti Kosunen wrote: >> Jan Ekholm wrote: >> > fine. Also the OSD isn't working making normal VDR use a hassle and I'm >> > forced to switch the the s-video side to see EPG, timers etc. >> >> "--primary" option to xineliboutput-plugin might help. > > I use the following: > > PLUGINS="-P\"xineliboutput --primary --local=none --remote=37890 -- > post=tvtime:method=Linear,cheap_mode=1,pulldown=0,use_progressive_frame_flag=1\"" > > So yeah, it's primary all right. > You said earlier that you use HTTP to connect with your frontend. The xineliboutput README states the following: Using with other media players (mplayer, vlc, ...) Primary device video and audio (without OSD or subtitles) can be streamed from plugin control port to almost any media player using http or rtsp. So, you might want to use a xine-based frontend (for example vdr-sxfe or xine-ui) with xvdr. -Petri ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Best practices for running vdr-xine
Lars Olsson wrote: > I am a happy VDR user since a couple of years ago. Before VDR, I used > Mythtv but switched due to its hardware requirements and bugs. > My VDR is an (very) old Duron 700 MHz with 1 Technotrend FF card and 1 > PVR 350 card. > It has been no problem recording two channels (SD) at a time and watch a > different recording trough FF card tv-out. FANTASTIC! > The VDR box is soon going to be replaced by a faster machine, but will > keep the current tv cards. > > The problem is now to find out how to setup VDR on my new computer. > Should I use > - FF-TVout? > - vdr-xine > - xine-liboutput? > > By just reading this thread, I can see that people has different favourites. > My personal fealing is that VDR is lacking recommendations / good > documentation on how to setup/configure "TV-out" in the best way, or at > least describe pros/cons for each alternative. Is this a point where > Mythtv beats VDR? I hope that I am wrong. > Or have I missed anything? > > regards, > baronen > That depends solely on your display device. If you use an "old style" CRT or something similar with an interlaced input, your FF-card will give you the best output. But if you have a progressive display with preferably a digital input you might want to use a software output device like vdr-xine or xineliboutput. Even with a reasonably slow system you can take advantage of vdpau with an nvidia card and have a perfect progressive output. There are graphic cards with both PCI and PCI-Express bus connection that you can acquire with a modest expense. -Petri ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR-1.7.7 & Video aspect ratios
On Mon, May 4, 2009 at 4:19 PM, Falk Spitzberg wrote: > > The OSD should adopt to the size of the video material. If that is > scaled to some non TV screen size, the OSD is scaled by the same factor. > Isn't that precisely what people would like to avoid? Since most of the material being broadcast is still SD, but more and more people have HD (Ready) displays, it would make sense to separate OSD and video size from each other. -Petri ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] vdr-webvideo 0.1.4
Antti Ajanki wrote: > New version of the Webvideo plugin is available at > http://users.tkk.fi/~aajanki/vdr/webvideo/ > Hi Antti, since it sounded such a nice plugin I decided to give it a try, but am still trying, because the installation it not what someone might call simple :) First of all, it installs the binaries under /usr/local/bin, but then it uses a hardcoded path of /usr/bin in several places. Secondly, it's incompatible with python 2.6, which I believe is the default version with recent distributions. Thirdly, it brings down the whole VDR if it cannot connect to the daemon. But, as I said, it sounded like a nice plugin so I am still working to get it running. -Petri ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] ExtRecMenu-Plugin 1.1
On Thu, May 28, 2009 at 1:10 AM, wrote: > > There is a patch, I don't know the name but it is included in the > ExtensionsPatch. Then you have the '0' to toggle the order. > It is included also in Liemikuutio patch: http://www.linuxtv.org/vdrwiki/index.php/Liemikuutio-patch It mentions this regarding the sort implementation: "Simple recordings sorting by wal...@vdrportal" -Petri ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] ExtRecMenu-Plugin 1.1
On Wed, May 27, 2009 at 5:54 PM, Carsten Koch wrote: > I like the ExtRecMenu plugin very much. > > In particular, I love the fact that it shows me the length > of my recordings and that it allows me to display recordings > in alphabetical (and chronological) order. > > There have been no new releases for almost 2 years now. > There is also a test version of version 1.2: http://www.vdrportal.de/board/thread.php?threadid=75295&threadview=0&hilight=&hilightuser=0&page=1 You could try it out. -Petri ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdrconvert-vdr-1.7.0+
hu_emulator wrote: > Thank you for your help. Replaced vdr2dvd.sh with your, renamed to > vdr2dvd.sh, rebooted. But still getting the following error: > ---> new File: > '/video0/iso/tmp/vdr2dvd/9137/%Day_the_Earth_Stood_Still_(All_Day)_/VDRSYNC.vTpfbc/001[1].mpa' > What version of Project-X are you using? Are you able to demux the recording with Project-X manually? You might want to update to 0.90.4.00.b30 from cvs if you are running a older version. With that version you could also give a go to the new version of the burn plugin, which should be compatible with vdr's new TS recordings: http://www.vdr-portal.de/board/thread.php?threadid=87788&threadview=0&hilight=&hilightuser=0&page=1 -Petri ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Replay Problems with Extension HD
On Mon, Sep 7, 2009 at 6:57 PM, VDR User wrote: > > I'd suggest posting to the mailing list or both as VDR Portal caters > 99% to people who speak german and isn't much help for the very large > english-speaking-only VDR community. > I wouldn't say the english-speaking-only VD community is that large: At least if you look at the registered users: http://www.cadsoft.de/cgi-bin/vdr-counter.pl?action=statist Perhaps you meant the great non-german-speaking community, who communicate in English? ;) -Petri ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Replay Problems with Extension HD
VDR User wrote: On Mon, Sep 7, 2009 at 9:14 AM, Petri Helin wrote: On Mon, Sep 7, 2009 at 6:57 PM, VDR User wrote: Perhaps you meant the great non-german-speaking community, who communicate in English? ;) Nope, I mean english-speaking-only. Like the other user pointed out, many many people are using various howto's and IRC for their VDR info, and never find their way here & other places. I can't count how many times people have said they've never even looked at the MANUAL, README, and so on. Ok, so what do you suggest us that belong to neither german-speaking nor english-speaking-only communities should do? Or would it be acceptable for the english-speaking-only community to accept those other-than-english-speaking as well? I mean, where are you all hiding? :) This might be a good time to bring forward things that might not have been discussed on this list. Like if there were patches/plugins etc lying around that the other-than-english-speaking community might be unaware of. -Petri ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Problems compiling xine-lib-1.2 for vdr-xine
Simon Baxter wrote: > I'm using ffmpeg svn revision 29766 Any ideas? You must have picked up that revision number from a wrong place, since the current revision is 20199. libavcodec/avcodec.h is the file where you should look for the missing member definition. Also make sure that the headers for that revision are the only ones installed. Most likely you are not using correct headers. btw... --with-external-ffmpeg is deprecated in xine-lib 1.2 since it uses external ffmpeg by default. -Petri ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Problems compiling xine-lib-1.2 for vdr-xine
Simon Baxter wrote: Simon Baxter wrote: > I'm using ffmpeg svn revision 29766 Any ideas? You must have picked up that revision number from a wrong place, since the current revision is 20199. libavcodec/avcodec.h is the file where you should look for the missing member definition. Also make sure that the headers for that revision are the only ones installed. Most likely you are not using correct headers. I pulled ffmpeg from: svn checkout svn://svn.mplayerhq.hu/ffmpeg/trunk ffmpeg which told me revision 29766 is this wrong? You can check the revision with "svn info". I guess that 29766 is actually the revision of libswscale. /usr/src/development/ffmpeg/libavcodec/avcodec.h _does define_ int ticks_per_frame; Perhaps I am using the wrong headers - how do I link to these? You should install the headers (well, doing "make install" should do that). Look for avcodec.h under /usr/local/include and check the contents of that file. Also make sure that there is only one such file. To do that, you could clear all ffmpeg headers and re-install the current ones. -Petri ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] Restricting a particular dvb card from tuning to channels with a selected modulation
Hi, I have an USB DVB-C card (Reddo dvb-c, actually a relabelled Tongshi box), which works very well with the current Linux driver excluding channels with QAM-256 modulation. Would it be easy to check FE_CAN_QAM_256 in vdr before trying to use a device to tune to a particular channel? In such a case I could deactivate FE_CAN_QAM_256 in the drivers. I am using VDR 1.7.9, if it makes a difference. Of course at the moment the proper solution would be to modify the channels.conf to se a preselected card to tune to a particular channel, but in this case there are two drawbacks with it. 1) I have more than one card that I can use for QAM-256 channels and would like to use them all, and 2) channels woth QAM-256 are also encrypted and I have yet to figure out how to set both the CA code and the number of the card in the "Conditional access" parameter in the channels.conf. Actually now that I think of it... How about separating the explicit card selection and conditional access by introducing a new paremeter in the channels.conf that could be used to preselect the card(s) that can tune to the selected channel? -Petri ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Restricting a particular dvb card from tuning to channels with a selected modulation
On Thu, Oct 29, 2009 at 10:13 AM, Klaus Schmidinger wrote: > On 10/28/09 23:15, Petri Helin wrote: >> Hi, >> >> I have an USB DVB-C card (Reddo dvb-c, actually a relabelled Tongshi >> box), which works very well with the current Linux driver excluding >> channels with QAM-256 modulation. Would it be easy to check >> FE_CAN_QAM_256 in vdr before trying to use a device to tune to a >> particular channel? In such a case I could deactivate FE_CAN_QAM_256 in >> the drivers. I am using VDR 1.7.9, if it makes a difference. > > Checking the frontend capabilities is certainly the right thing to do, > and I will see that this gets implemented. > > Klaus > Thanks! -Petri ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] rewind recordings doesn't work with xineliboutput and vdr 1.7.10
On 12/29/2009 09:32 PM, Gerald Dachs wrote: Hello, if I try to rewind a recording, I can see the movie going fast backwards, but if I stop rewinding, the movie continues from the moment I started the rewinding. This doesn't happen with xine-ui and the xine-plugin and with xbmc using the streamdev-plugin, so I believe it is a xineliboutput problem. I use a cvs snapshot from today and vdr 1.7.10 on Ubuntu 9.10, xinelib 1.2 with vdpau patch r285 and durchflieger cropping patch. I posted this already on the xineliboutput-user ML, but this list seems to be dead. Gerald It should work for old PES recordings, I think. The changelog reveals that backward trickspeed is not yet even expected to work: http://xineliboutput.cvs.sourceforge.net/viewvc/xineliboutput/vdr-xineliboutput/device.c?sortby=date&view=log (see revision 1.81: forward trick speeds should now work. Backward trickspeeds won't work yet) -Petri ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] xine vdpau not working?
On Sat, Jan 9, 2010 at 1:25 AM, Simon Baxter wrote: > I'm using xine-lib-1.2 and patching with xine-lib-1.2-vdpau-r286.diff which There is no need to do such thing, since there already exists a repository which contains vdpau: xine-lib/xine-lib-1.2-vdpau You can use it as follows: hg clone http://hg.debian.org/hg/xine-lib/xine-lib-1.2-vdpau Otherwise, just pay attention to the messages you get when configuring/compiling xine-lib. -Petri ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Channel wrapping in live-tv
On Mon, Jan 11, 2010 at 9:36 PM, Ville Skyttä wrote: > On Monday 11 January 2010, Matti Lehtimäki wrote: >> Hi, >> >> One small feature I find is missing from vdr is to have the possibility >> to go from the last channel to the first channel and vice versa when >> changing channel to next/previous channel in live-tv mode. This is the >> normal behaviour in most TVs. So I made a small patch for vdr-1.7.11 >> (can be applied also to vdr-1.6.0) to make this possible with a menu >> option to enable/disable the feature. Would it be possible to have this >> feature included in future releases of vdr? > > I haven't tested the patch, but it sounds useful to me. I wonder if it's > really necessary to make this configurable though - why not just go ahead and > do the wrap-around unconditionally? VDR has more than enough config options > already... > Well, I for one would prefer to current behaviour over wrapping. -Petri ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.11
On 01/12/2010 10:11 PM, VDR User wrote: On Mon, Jan 11, 2010 at 11:41 PM, Theunis Potgieter wrote: 2010/1/11 Klaus Schmidinger: On 01/11/10 15:33, Rolf Ahrenberg wrote: On Mon, 11 Jan 2010, Theunis Potgieter wrote: Hi Klaus, any plans on including vdr-1.7.9-pluginparam.patch for pvrinput plugin? http://drseltsam.device.name/vdr/pvr/src/pvrinput This seems to create an input device of Plugin Type. I guess the vdr-iptv plugin also creates something similar. Both are using the same patch. I'd like to see also this patch (or similar feature) merged into official vdr sources. This is very high on my TODO list ;-) Klaus Great News! :) Hopefully the truecolor osd upgrade is high on the list as well. ;) As well as checking the frontend capabilities ;) -Petri ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] A few things about DVB subtitles
Hi, Although the support for DVB subtitles is more than satisfactory at the moment, I still have a few things I'd like see handled in a better way: 1. Pausing. At the monet the subtitles will disappear like in a live view - meaning that VDR seems to adhere the life time assignened to a subtitle image though the replay has been paused, causing the subtitles to disappear. 2. Backward jumping. When I jump backward, for example for 20 seconds, it will take quite a long time until the first subtitle is shown. Quite a many times this will end up in a rush of subtitles being presented very very quickly until the normal flow is reached. For us living and dealing with subtitled broadcasts this is a "major" issue. Which means that if these things could be fixed, VDR would be much more user friendly. I don't know where this behaviour originates, but I use xineliboutput as the output device. -Petri ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR with DD5.1 output over xineliboutput possible
On Thu, Jan 14, 2010 at 5:07 PM, Matthias Fechner wrote: > Hi, > > really no one is using DD5.1 over HDMI and can help me here? > > Bye, > Matthias > Can't really make sense of your original post regarding your audio set up, but I guess your problem has nothing to do with xineliboutput per se. Have you got the DD pass through to work with any other application? Anyway, for configuring and testing your set up I recommend that you read this: http://alsa.opensrc.org/index.php/DigitalOut -Petri ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] xine-plugin and vdpau
On Sat, Jan 23, 2010 at 11:59 AM, Jussi J wrote: > Hi! > I have "nVidia Corporation G96 [GeForce 9400 GT] (rev a1)" what is VDPAU > capable. I have loaded xine-plugin and try to use vdr-sxfe in vdpau mode, > but no success.. AFAIK xine-plugin normally refers to vdr-xine, but I think you mean xineliboutput, since you also mention vdr-sxfe. > > Any ideas where problem lies? Check the following: 1. Make sure you have a xine-lib which supports vdpau. Since you seem to be using xine-lib 1.2, it might be best to get the current hg in case you haven't yet. 2. Make sure you have everything installed from nvidia drivers pov. The simplest choice is to install manually the driver which nvidia provides on their web page. But if you use a distribution package, make sure you install the vdpau library as well. 3. Check that you have configured xineliboutput with vdpau enabled. If you do all of the above steps properly, you should have no problems with vdpau. -Petri ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] xine-plugin and vdpau
On Sun, Jan 24, 2010 at 7:44 PM, Stefan Taferner wrote:
> Am Samstag 23 Januar 2010 21:59:10 schrieb Jussi J:
>> Sorry.. My fault.. It's vdr-plugin-xine.. :-)
>> Anyway, now I can use it thru vdr-sxfe (but not using xine-ui; but that's
>> not relevant)
>
> You need a patched version of the xine library, and xine-ui must use it,
> in order to get the VDR driver in xine.
>
The VDR plugin for xine ("vdr", used by vdr-xine) is included with
xine-lib 1.2, if that's what you mean. But I still don't understand
the configuration of the original poster, where he states that he is
using vdr-xine's xine plugin with vdr-sxfe. That just doesn't make any
sense. Using vdr-sxfe with xineliboutput's "xvdr" plugin for xine or
xine-ui with "vdr" plugin would be much more sensible.
-Petri
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] epgsearch compile problem
On Mon, Feb 1, 2010 at 12:53 PM, Pertti Kosunen
wrote:
> g++ -march=native -O2 -pipe -fPIC -c -DCONFDIR=\"/etc/vdr\"
> -D__KERNEL_STRICT_NAMES -DUSE_LIEMIEXT -DUSE_MCLI -DUSE_TTXTSUBS
> -D_GNU_SOURCE -DSENDMAIL='"/usr/sbin/sendmail"'
> -DPLUGIN_NAME_I18N='"epgsearch"' -DHAVE_PCREPOSIX -I/usr/include
> -I/usr/include conflictcheck.c
> In file included from uservars.h:34,
> from confdloader.c:28:
> varparser.h:50: error: ISO C++ forbids declaration of ‘cCommand’ with no
> type
> varparser.h:50: error: expected ‘;’ before ‘*’ token
> varparser.h: In constructor ‘cVarParser::cVarParser()’:
> varparser.h:53: error: class ‘cVarParser’ does not have any field named
> ‘cmd’
> g++ -march=native -O2 -pipe -fPIC -c -DCONFDIR=\"/etc/vdr\"
> -D__KERNEL_STRICT_NAMES -DUSE_LIEMIEXT -DUSE_MCLI -DUSE_TTXTSUBS
> -D_GNU_SOURCE -DSENDMAIL='"/usr/sbin/sendmail"'
> -DPLUGIN_NAME_I18N='"epgsearch"' -DHAVE_PCREPOSIX -I/usr/include
> -I/usr/include conflictcheck_thread.c
> make: *** [confdloader.o] Error 1
> make: *** Waiting for unfinished jobs
>
>
> varparser.h:50-53:
> cCommand* cmd;
> string cmdArgs;
>
> cVarParser() : cmd(NULL) {}
>
>
> Tested vdr-epgsearch-0.9.25_beta14 & 15 + VDR 1.7.12 @ Gentoo amd64
>
I am pretty sute that's due to the following change:
- The files "commands.conf" and "reccmd.conf" can now contain nested lists of
commands. See vdr.5 for information about the new file format.
I guess the epgsearch and similar plugins need to adapt to the new
command list implementation.
-Petri
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] A few things about DVB subtitles
On 01/26/2010 06:28 PM, Rolf Ahrenberg wrote: On Wed, 13 Jan 2010, Petri Helin wrote: 1. Pausing. At the monet the subtitles will disappear like in a live view - meaning that VDR seems to adhere the life time assignened to a subtitle image though the replay has been paused, causing the subtitles to disappear. The attached patch should handle this - in a way. Ofcourse, the elapsed time of shown subtitle should be stored when paused and re-set after the replaying has started again. But it would complicate the patch and I don't see any real-life benefits for it. BR, -- rofa Thanks. But with a quick test with VDR 1.7.11 I could not get the subtitles to stay visible. They still disappear after their lifetime has been spent. -Petri ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] A few things about DVB subtitles
On Wed, Feb 3, 2010 at 10:12 AM, Rolf Ahrenberg wrote: > On Wed, 3 Feb 2010, Petri Helin wrote: > >> Thanks. But with a quick test with VDR 1.7.11 I could not get the >> subtitles to stay visible. They still disappear after their lifetime has >> been spent. > > Well, it worked with my FF card. :) If you're using xineliboutput, make sure > you're also using VDR as subtitles decoder. > Yes, I am using xineliboutput and also VDR as the subtitles decoder. -Petri ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] XBMC and vdr
On 02/05/2010 04:16 PM, martinez wrote: To the best of my knowledge XBMC can only be compiled for xbox1 It is always best not to rely on flawed knowledge, but try to find out the truth instead: http://xbmc.org/about/ -Petri ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] A few things about DVB subtitles
On 02/08/2010 12:50 AM, Rolf Ahrenberg wrote: On Wed, 3 Feb 2010, Petri Helin wrote: Yes, I am using xineliboutput and also VDR as the subtitles decoder. Ok. I've just added a patch into xineliboutput's cvs and it should fix this (preparing for next vdr release) - at least it did in my quick tests. And it truly does. :) Thank you! -Petri ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] xineliboutput and libextractor3
On 02/22/2010 11:25 AM, Stefan Wagner wrote: after update to libextractor3 (debian sid) xineliboutput will not compile: tools/playlist.c: In member function 'virtual void cID3Scanner::Action()': tools/playlist.c:172: error: 'EXTRACTOR_ExtractorList' was not declared in this scope tools/playlist.c:172: error: 'plugins' was not declared in this scope tools/playlist.c:173: error: 'EXTRACTOR_KeywordList' was not declared in this scope tools/playlist.c:173: error: 'md_list' was not declared in this scope tools/playlist.c:174: error: 'EXTRACTOR_loadDefaultLibraries' was not declared in this scope tools/playlist.c:175: error: 'EXTRACTOR_getKeywords' was not declared in this scope tools/playlist.c:178: error: 'EXTRACTOR_getKeywordTypeAsString' was not declared in this scope tools/playlist.c:190: error: 'EXTRACTOR_freeKeywords' was not declared in this scope tools/playlist.c:191: error: 'EXTRACTOR_removeAll' was not declared in this scope make[1]: *** [tools/playlist.o] Error 1 make[1]: Leaving directory `/usr/src/vdr-plugins/xineliboutput/vdr-xineliboutput' make: *** [common-build-arch] Error 2 is there a patch aviable? stefan I believe that the "libextractor3" contains version 0.6 of libextractor. There is a patch for that, though I have not tested it and cannot confirm whether it works or not. You can find it here: http://www.vdrportal.de/board/thread.php?threadid=93447 -Petri ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] 10 Year Anniversary of VDR
On 02/19/2010 06:09 PM, Klaus Schmidinger wrote: It has been exactly 10 years since version 0.01 of VDR (originally named "OSM" - On Screen Menu) was released. I want to use the occasion to thank everybody who has contributed to VDR, but also those who simply use VDR in their every day life. I for one couldn't imagine watching tv without VDR any more. Special thanks go to the people running the VDR-Portal (www.vdr-portal.de). Originally I intended to release version 2.0 of VDR at the 10th anniversary, but as ever so often, I ran out of time. But I'm still on it - stability comes before deadlines ;-) I hope you don't think I'm blowing my own horn here, I just didn't want the date to pass by without a remark... Klaus It was a kind of a revelation to come upon VDR years ago, when I first met this great piece of software. It revealed that the change from analog to digital TV was not just for the worse, but in many ways for the better as well. So thank you Klaus for your great work (not forgetting others contributing) for letting as enjoy the best digital TV software there is. And bringing about a hobby that has consumed more hours than I care to count... And I don't mean the time spent watching TV :) -Petri ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Restricting a particular dvb card from tuning to channels with a selected modulation
On 04/05/2010 12:57 PM, Klaus Schmidinger wrote:
On 05.04.2010 00:55, Teemu Rantanen wrote:
Hi,
There's a new version of the patch implemented as a plugin. It seems to
work, but there are few things to notice:
- Plugin does not cache which devices are Reddo devices, instead it
probes sysfs every time QAM256 channel is being tuned into (on any
device). It would be nice if cDeviceHook added a mechanism for a hook to
store context for each device. Hooking into device probe (like full
feature card plugin does) would be much nicer way, but it would
interfere with other plugins which need the same mechanism.
The proper way of doing this is to check the modulation types
in cDvbDevice::ProvidesTransponder(), as in the attached patch (which will
be part of VDR 1.7.15). If the "reddo" driver doesn't set the FE_CAN_QAM_256
flag correctly, it needs to be fixed there.
I used your patch as an example and created a simple test patch for
dvb-c (I think yours is for dvb-s(2) only) in order to test the
approach. I also disabled FE_CAN_QAM256 from the driver. After that VDR
no longer used Reddo for QAM256 channels as expected. The approach is
very limited: It disables QAM256 for the every TDA10023 frontend, not
just for Reddo's, and it doesn't make VDR to prefer Reddo for non QAM256
channels, which would make sense in order to keep QAM256 channels
available as much as possible. The patches are inline below:
--- dvbdevice.c.orig 2010-02-21 19:10:35.0 +0200
+++ dvbdevice.c 2010-04-05 17:20:06.080525344 +0300
@@ -872,8 +872,12 @@
{
if (!ProvidesSource(Channel->Source()))
return false; // doesn't provide source
- if (!cSource::IsSat(Channel->Source()))
+ if (!cSource::IsSat(Channel->Source())) {
+ cDvbTransponderParameters dtp(Channel->Parameters());
+ if (dtp.Modulation() == QAM_256 && !(frontendInfo.caps &
FE_CAN_QAM_256))
+return false;
return DeviceHooksProvidesTransponder(Channel); // source is
sufficient for non sat
+ }
cDvbTransponderParameters dtp(Channel->Parameters());
if (frontendType == SYS_DVBS && dtp.System() == SYS_DVBS2)
return false; // requires modulation system which frontend
doesn't provide
--- v4l-dvb/linux/drivers/media/dvb/frontends/tda10023.c.orig
2010-04-05 15:28:22.605844128 +0300
+++ v4l-dvb/linux/drivers/media/dvb/frontends/tda10023.c 2010-04-05
15:27:54.934343796 +0300
@@ -553,7 +553,7 @@
#endif
.caps = 0x400 | //FE_CAN_QAM_4
FE_CAN_QAM_16 | FE_CAN_QAM_32 | FE_CAN_QAM_64 |
- FE_CAN_QAM_128 | FE_CAN_QAM_256 |
+ FE_CAN_QAM_128 | //FE_CAN_QAM_256 |
FE_CAN_FEC_AUTO
},
-Petri
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Ubuntu 10.04 + vdr-plugin-xineliboutput + vdr-1.7.10
Hi! I know this is not directly this lists problem.. But probably right people read this list. I just upgraded to ubuntu 10.04 and run problem with vdr-plugin-xineliboutput package. It depency says that vdr-abi-1.6.debian is required and I'm using vdr-1.7.10. Is there something what I could tweak to get around this problem? -- JJussi I would say that you are doing something that you should not... either mixing packages from several repositories or mixing packages with self-built vdr. If you have compiled vdr 1.7.10 from the source, do the same with xineliboutput (but please note that the current cvs no more supports vdr < 1.7.11). If you have installed 1.7.10 from some third-party repository, use its package for xineliboutput as well, if possible. If not possible, switch to a repository that offers both. Perhaps yavdr's repository could suite you well? -Petri ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Ubuntu 10.04 + vdr-plugin-xineliboutput + vdr-1.7.10
On Mon, May 24, 2010 at 7:33 AM, JJussi wrote: > 23.5.2010 23:23, Petri Helin kirjoitti: >> >>> Hi! >>> I know this is not directly this lists problem.. But probably right >>> people read this list. >>> >>> I just upgraded to ubuntu 10.04 and run problem with >>> vdr-plugin-xineliboutput package. It depency says that vdr-abi-1.6.debian is >>> required and I'm using vdr-1.7.10. >>> Is there something what I could tweak to get around this problem? >>> >>> >>> -- >>> JJussi >>> >>> >> >> I would say that you are doing something that you should not... either >> mixing packages from several repositories or mixing packages with self-built >> vdr. If you have compiled vdr 1.7.10 from the source, do the same with >> xineliboutput (but please note that the current cvs no more supports vdr < >> 1.7.11). If you have installed 1.7.10 from some third-party repository, use >> its package for xineliboutput as well, if possible. If not possible, switch >> to a repository that offers both. Perhaps yavdr's repository could suite you >> well? > > System where I started was Ubuntu 9.04 + "deb > http://ppa.launchpad.net/the-vdr-team/vdr-ubuntu-karmic/ubuntu karmic main" > from where I got that vdr-1.7.10 -package. > Now when I allowed system to upgrade it self to 10.04 (lucid-version), there > is no "lucid" directory in "ppa.launchpad.net/the-vdr-team", so I still use > that 'karmic'-directory from there. > > Hmm.. Yes, you are right.. Lucid gives me > "vdr-plugin-xineliboutput-1.0.4+cvs20091016.1108" what is older version than > ppa.launchpad.net, what provides > "vdr-plugin-xineliboutput_1.0.4+cvs20091013.1200-7tvt1_amd64.deb".. > But because it (lucid) has been compiled later, system selects it. > > -- > > JJussi > > Perhaps this ppa might fit your needs: https://launchpad.net/~yavdr/+archive/testing-vdr There is vdr 1.7.14 and also xineliboutput 1.0.6+cvs20100521.1550-2yavdr1. -Petri ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] Multiple tuners and reception error recovery without emergency exit
Hi,
I was wondering whether what I experienced yesterday is really the way
VDR functions at the moment. I have two tuner cards, one in pci slot
and another connected via usb. While VDR was running I disconnected
the antenna cable from the pci card in order to connect it to a hd
cable ready set-top box. This resulted in a 0 sized recording due to
VDR not switching the tuner to the one still connected to the antenna.
You can see this in the following log entries:
Aug 28 17:31:56 vdrkone2 vdr: [1282] frontend 0/0 provides DVB-C
("VLSI VES1820 DVB-C")
Aug 28 17:31:56 vdrkone2 vdr: [1282] frontend 1/0 provides DVB-C
("Philips TDA10023 DVB-C")
Aug 28 17:31:56 vdrkone2 vdr: [1344] tuner on frontend 0/0 thread
started (pid=1282, tid=1344)
Aug 28 18:36:30 vdrkone2 vdr: [1344] frontend 0/0 lost lock on channel 1, tp 274
Aug 28 18:36:32 vdrkone2 vdr: [1344] frontend 0/0 timed out while
tuning to channel 1, tp 274
Aug 28 18:37:26 vdrkone2 vdr: [1344] frontend 0/0 timed out while
tuning to channel 1, tp 274
Aug 28 18:37:53 vdrkone2 vdr: [1344] frontend 0/0 timed out while
tuning to channel 1, tp 274
Aug 28 18:38:11 vdrkone2 vdr: [1344] frontend 0/0 timed out while
tuning to channel 7, tp 274
Aug 28 18:39:14 vdrkone2 vdr: [1344] frontend 0/0 timed out while
tuning to channel 7, tp 274
...
Aug 28 21:55:00 vdrkone2 vdr: [1282] switching device 1 to channel 7
Aug 28 21:55:00 vdrkone2 vdr: [1282] timer 1 (7 2155-2351 'Tapaus
Wilson (K15)') start
Aug 28 21:55:00 vdrkone2 vdr: [1282] Title: 'Tapaus Wilson (K15)'
Subtitle: '(null)'
Aug 28 21:55:00 vdrkone2 vdr: [1282] record
/data/video/Tapaus_Wilson_(K15)/2010-08-28.21.55.7-0.rec
Aug 28 21:55:00 vdrkone2 vdr: [1282] creating directory
/data/video/Tapaus_Wilson_(K15)
Aug 28 21:55:01 vdrkone2 vdr: [1344] frontend 0/0 timed out while
tuning to channel 7, tp 274
Aug 28 21:55:13 vdrkone2 vdr: [1282] creating directory
/data/video/Tapaus_Wilson_(K15)/2010-08-28.21.55.7-0.rec
Aug 28 21:55:13 vdrkone2 vdr: [1282] recording to
'/data/video/Tapaus_Wilson_(K15)/2010-08-28.21.55.7-0.rec/1.ts'
Aug 28 21:55:13 vdrkone2 vdr: [5921] recording thread started
(pid=1282, tid=5921)
Aug 28 21:55:14 vdrkone2 vdr: [1348] channel 2 (TV2) event La
28.08.2010 21:55-22:05 'Urheiluruutu' status 4
Aug 28 21:55:14 vdrkone2 vdr: [1282] max. latency time 14 seconds
Aug 28 21:55:44 vdrkone2 vdr: [5921] ERROR: video data stream broken
Aug 28 21:55:44 vdrkone2 vdr: [5921] emergency exit request ignored
according to setup
Aug 28 21:56:04 vdrkone2 vdr: [1344] frontend 0/0 timed out while
tuning to channel 7, tp 274
As you can see, I have turned the emergency exit off, but I'd have
thought that VDR would have been able to try the other tuner without
emergency exit being activated. However, this does not seem to be the
case. Is there any reason for that?
-Petri
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] ProjectX and burn plugin
On 8/16/06, Gavin Hamill <[EMAIL PROTECTED]> wrote: I'm posting this here for the lack of a better place. The ProjectX home page is a German-only forum, and as I don't speak German, that leaves me a little stuck. You might as well try your luck at the ProjectX forum. Although most of the messages there are german, at least I have always gotten an answer in english if the question was in english. dvb.matt responds quite rapidly so I recommend you try it out. -Petri ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Recordings sorting
On 11/14/06, Martin Prochnow <[EMAIL PROTECTED]> wrote: Hi, > problem with the recording menu that pops up annoyingly after end of recording playback this is a feature ;-) > and sometimes in channel switching. and this is a bug. But nobody else complained about it until yet. Are there any other users using my plugin and streamdev together? Greets Martin Hi, I have used those two together and seen the feature (which I actually like quite a bit), but not the bug. -Petri ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] Utf8-patch experiences, anyone?
Hi, I have been experimenting with increasing the resolution of the OSD with xineliboutput with at least some kind of success (see http://img79.imageshack.us/my.php?image=hdosdrx4.png and try to not get bothered about the other "images" you are forced to see, this was the first image sharing site I came across). Now there are some problems that have come up with the HD OSD. Font rendering and the way fonts and OSD are used by plugins are the main distractions. I bumped in to this Utf8-patch (http://www.vdr-wiki.de/wiki/index.php/Utf8-patch) which looks promising, but failed to find any more information than what is provided in the german wiki. And the latest adaptation is for VDR 1.4.0. Is the someone out there using this patch and could share his experiences? Maybe someone has adapted it to the current version of VDR... -Petri ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.5.0
Klaus Schmidinger wrote: VDR developer version 1.5.0 is now available at ftp://ftp.cadsoft.de/vdr/Developer/vdr-1.5.0.tar.bz2 A 'diff' against the latest stable version is available at ftp://ftp.cadsoft.de/vdr/Developer/vdr-1.4.5-1.5.0.diff WARNING: This is a *developer* version. Even though *I* use it in my productive environment, I strongly recommend that you only use it under controlled conditions and for testing and debugging. This version focuses mainly on improvements in CAM handling. The highlights are: - Improved CAM menu and reset handling. - Automatic selection of suitable CAM in a system with several CAMs that claim to decrypt a given channel. - Decrypting of several channels on the same transponder (if the CAM is able to do this). The changes since version 1.4.5: - The CAM handling has been refactored. Instead of a cCiHandler per device there is now an abstract cCiAdapter and a cCamSlot. This allows each slot to be accessed individually. - The general 15 seconds workaround time before opening the CAM menu has been removed. If the CAM menu doesn't open within a timeout, the enter menu command is now sent again. - If a CAM is reset or pulled and reinserted, it now automatically starts decrypting the current channel again. - The Setup/CAM menu now dynamically refreshes its items and displays whether a CAM is present or ready. The 'Reset' function no longer leaves the menu. - The CAM menu will now be openend when pressing the Ok key on a slot entry. - The CAM menu now stays within the current menu context and doesn't close and reopen the menu every time an option is selected. - When an encrypted channel is switched to for the first time, VDR now checks explicitly whether a CAM can actually decrypt that channel. If there is more than one CAM in the system that claims to be able to decrypt the channel, they are all tried in turn. To make this possible, an encrypted channel needs to be received in Transfer Mode when it is switched to for the first time, so that VDR can determine whether the TS packets are actually decrypted. Once a channel is known to be decrypted by a particular CAM, the next time it is switched to it will be shown in normal live viewing mode. - A cDevice now automatically detaches all cReceiver objects that receive PIDs that can't be decrypted with the current CAM. A plugin that attaches a cReceiver to a device should therefore watch the receiver's IsAttached() function to see if it is still attached to the device. - The cReceiver constructor no longer takes an 'int Ca' as its first parameter, but rather a 'tChannelID ChannelID'. This is necessary for the device to be able to determine which CAM a particular channel can be decrypted with. If the channel is known to be unencrypted, or a plugin doesn't want to provide the channel id for other reasons, an invalid tChannelID() can be given. - The cThread::Start() function now waits until a previous incarnation of this thread has actually stopped. Before this it could happen that a thread's Cancel(-1) function was called and immediately after that it was started again, but the Start() function still found it to be 'active'. - The parameter NeedsDetachReceivers in cDevice::GetDevice(const cChannel *Channel, ...) has been removed. A call to this function will automatically detach all receivers from the device if it returns a non-NULL pointer. - The cTimeMs class now accepts an initial timeout value in its constructor. - A CAM is now explicitly instructed to stop decrypting when switching away from an encrypted channel. - If the CAM in use can decrypt several channels at the same time, VDR can now make use if this capability. Whether or not a CAM can decrypt more than one channel is determined by sending it an initial empty QUERY command and testing whether it replies to it. - Ca values in the range 0...F in channels.conf can still be used to assign a channel to a particular device, but this will no longer work with encrypted channels because without valid CA ids VDR can't decide which CAM slot to use. However, since VDR now automatically determines which CAM can decrypt which channel, setting fixed channel/device relations should no longer be necessary. KNOWN BUG - PLEASE HELP DEBUGGING: Start VDR with only one FF DVB card and an attached CI with a CAM. Switch to an encrypted channel for the first time, the channel is shown in Transfer Mode. Wait for at least 10 seconds, so that VDR will mark the CAM as "able to decrypt this channel". Now switch to the same channel again (by selecting it from the Channels menu or typing in its number), and the screen goes black. VDR is now receiving the channel in normal live mode (no Transfer Mode). Apparently there is a problem with switching to live mode after using Transfer Mode. The problem goes away if you switch to a channel on a different transponder and then back to the original one.
Re: [vdr] [ANNOUNCE] VDR developer version 1.5.0
Klaus Schmidinger wrote: Looks like the CAM is recognized all right. Please enable the lines static bool DumpTPDUDataTransfer = false; static bool DebugProtocol = false; static bool DumpPolls = false; static bool DumpDateTime = false; in ci.c by changing them to 'true' and compile/run VDR again, redirecting stderr into a file, as in ./vdr 2> ci.txt Then send me the resulting output after trying to switch to an encrypted channel. Attached. -Petri ci.txt.gz Description: application/gzip ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.5.0
Klaus Schmidinger wrote:
Petri Helin wrote:
...
BTW: I have been patching the device.c in 1.4.* series so that my other
card, TT budget DVB-C v1.0, is always preferred for FTA channel
recordings. Otherwise the precious CAM could be wasted in an FTA
recording. I understood that you are planning on restructuring the
priority model in 1.5.*. Have you taken in consideration the situation
with budget-only environment with one or more CIs?
Please try the attached patch and let me know if it works
as expected.
Klaus
Unfortunately it didn't work as (at least I) expected. What I am looking
for is as follows
- card 1 (with CI) is tuned to channel A
- card 2 (without CI) is tuned to channel B
- channels A and B are on on different transponders
- a recording is about to start on channel A
- VDR chooses card 2 and tunes it to channel A in order to actuate the
recording
Currently I have achieved this with the attached patch.
-Petri
--- vdr-1.4.4/device.c.orig 2006-09-03 13:13:25.0 +0300
+++ vdr-1.4.4/device.c 2006-12-11 20:46:13.0 +0200
@@ -292,11 +292,11 @@
// to their individual severity, where the one listed first will make the most
// difference, because it results in the most significant bit of the result.
uint imp = 0;
+ imp <<= 8; imp |= min(max(device[i]->ProvidesCa(Channel), 0), 0xFF); // use the device that provides the lowest number of conditional access methods
imp <<= 1; imp |= !device[i]->Receiving() || ndr; // use receiving devices if we don't need to detach existing receivers
imp <<= 1; imp |= device[i]->Receiving(); // avoid devices that are receiving
imp <<= 1; imp |= device[i] == cTransferControl::ReceiverDevice();// avoid the Transfer Mode receiver device
imp <<= 8; imp |= min(max(device[i]->Priority() + MAXPRIORITY, 0), 0xFF); // use the device with the lowest priority (+MAXPRIORITY to assure that values -99..99 can be used)
- imp <<= 8; imp |= min(max(device[i]->ProvidesCa(Channel), 0), 0xFF); // use the device that provides the lowest number of conditional access methods
imp <<= 1; imp |= device[i]->IsPrimaryDevice(); // avoid the primary device
imp <<= 1; imp |= device[i]->HasDecoder();// avoid full featured cards
if (imp < Impact) {
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.5.0
Klaus Schmidinger wrote: Petri Helin wrote: Klaus Schmidinger wrote: Looks like the CAM is recognized all right. Please enable the lines static bool DumpTPDUDataTransfer = false; static bool DebugProtocol = false; static bool DumpPolls = false; static bool DumpDateTime = false; in ci.c by changing them to 'true' and compile/run VDR again, redirecting stderr into a file, as in ./vdr 2> ci.txt Then send me the resulting output after trying to switch to an encrypted channel. Attached. Everything looks fine, the CaPmt is sent to the CAM and the communication with the CAM is stable. It should work. Can you please do the same with VDR 1.4 and send me the result of that, too? Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr Here you are. -Petri ci-1.4.4.txt.gz Description: application/gzip ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.5.0
Klaus Schmidinger wrote: Petri Helin wrote: Klaus Schmidinger wrote: Petri Helin wrote: Klaus Schmidinger wrote: Looks like the CAM is recognized all right. Please enable the lines static bool DumpTPDUDataTransfer = false; static bool DebugProtocol = false; static bool DumpPolls = false; static bool DumpDateTime = false; in ci.c by changing them to 'true' and compile/run VDR again, redirecting stderr into a file, as in ./vdr 2> ci.txt Then send me the resulting output after trying to switch to an encrypted channel. Attached. Everything looks fine, the CaPmt is sent to the CAM and the communication with the CAM is stable. It should work. Can you please do the same with VDR 1.4 and send me the result of that, too? ... Here you are. Ah, now I see the difference: 3: ==> Ca Pmt 4 --> 00 01 A0 2F 01 90 02 00 03 9F 80 32 26 03 01 35 01 00 07 01 09 04 0B 00 E0 68 02 02 06 00 00 04 02 AE 00 00 04 02 AF 00 00 04 02 AC 00 00 04 02 AD 00 00 Slot 1: ==> Ca Pmt (3) 3 3 1: --> 00 01 A0 10 01 90 02 00 03 9F 80 32 07 03 00 00 01 00 01 03 For some reason VDR 1.4.4 sends the CA descriptors in the CaPmt, while VDR 1.5.0 doesn't. Please post the channels.conf entry for the channel you are trying to tune to. Also, just to make sure: are you using plain vanilla VDR 1.5.0 or are there any patches involved? Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr Here are the channels that VDR 1.5.0 cannot tune to: Canal+ Mix;Telenor:266000:C0M128:C:6900:518:686=nor,687=fin,684=sve,685=dan:581:1:309:0:9:0 Canal+ Film 1;Telenor:266000:C0M128:C:6900:512:650=sve,651=dan,652=nor,653=fin;654=eng:576:1:301:0:9:0 Canal+ Film 2;Telenor:266000:C0M128:C:6900:515:682=nor,683=fin,680=sve,681=dan;679=eng:579:1:308:0:9:0 Canal+ Film 3;Telenor:314000:C0M128:C:6900:518:664=sve,665=dan,666=nor,667=fin;668=eng:577:1:3307:0:19:0 Canal+ HD;Telenor:33:C0M256:C:6900:512:640;641=eng:580:1:3306:0:22:0 Canal+ Sport 1;Telenor:266000:C0M128:C:6900:514:670=fin:577:1:305:0:9:0 Canal+ Sport 2;Telenor:314000:C0M128:C:6900:519:672=sve,673=dan,674=nor,675=fin:578:1:3308:0:19:0 My 1.5.0 is unpatched, but 1.4.4 has been patched with liemikuutio-patch and patches needed for ttxtsubs- and subtitles-plugins. -Petri ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.5.0
Klaus Schmidinger wrote: Petri Helin wrote: Klaus Schmidinger wrote: Petri Helin wrote: Klaus Schmidinger wrote: Petri Helin wrote: Klaus Schmidinger wrote: Looks like the CAM is recognized all right. Please enable the lines static bool DumpTPDUDataTransfer = false; static bool DebugProtocol = false; static bool DumpPolls = false; static bool DumpDateTime = false; in ci.c by changing them to 'true' and compile/run VDR again, redirecting stderr into a file, as in ./vdr 2> ci.txt Then send me the resulting output after trying to switch to an encrypted channel. Attached. Everything looks fine, the CaPmt is sent to the CAM and the communication with the CAM is stable. It should work. Can you please do the same with VDR 1.4 and send me the result of that, too? ... Here you are. Ah, now I see the difference: 3: ==> Ca Pmt 4 --> 00 01 A0 2F 01 90 02 00 03 9F 80 32 26 03 01 35 01 00 07 01 09 04 0B 00 E0 68 02 02 06 00 00 04 02 AE 00 00 04 02 AF 00 00 04 02 AC 00 00 04 02 AD 00 00 Slot 1: ==> Ca Pmt (3) 3 3 1: --> 00 01 A0 10 01 90 02 00 03 9F 80 32 07 03 00 00 01 00 01 03 For some reason VDR 1.4.4 sends the CA descriptors in the CaPmt, while VDR 1.5.0 doesn't. Please post the channels.conf entry for the channel you are trying to tune to. Also, just to make sure: are you using plain vanilla VDR 1.5.0 or are there any patches involved? Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr Here are the channels that VDR 1.5.0 cannot tune to: Canal+ Mix;Telenor:266000:C0M128:C:6900:518:686=nor,687=fin,684=sve,685=dan:581:1:309:0:9:0 Canal+ Film 1;Telenor:266000:C0M128:C:6900:512:650=sve,651=dan,652=nor,653=fin;654=eng:576:1:301:0:9:0 Canal+ Film 2;Telenor:266000:C0M128:C:6900:515:682=nor,683=fin,680=sve,681=dan;679=eng:579:1:308:0:9:0 Canal+ Film 3;Telenor:314000:C0M128:C:6900:518:664=sve,665=dan,666=nor,667=fin;668=eng:577:1:3307:0:19:0 Canal+ HD;Telenor:33:C0M256:C:6900:512:640;641=eng:580:1:3306:0:22:0 Canal+ Sport 1;Telenor:266000:C0M128:C:6900:514:670=fin:577:1:305:0:9:0 Canal+ Sport 2;Telenor:314000:C0M128:C:6900:519:672=sve,673=dan,674=nor,675=fin:578:1:3308:0:19:0 Ah, just as I thought. Please set the CA parameter of these channels to 0 (FTA) and tune to them again. VDR should automatically insert the correct CA values then. From the HISTORY: - Ca values in the range 0...F in channels.conf can still be used to assign a channel to a particular device, but this will no longer work with encrypted channels because without valid CA ids VDR can't decide which CAM slot to use. However, since VDR now automatically determines which CAM can decrypt which channel, setting fixed channel/device relations should no longer be necessary. Klaus Oh, should have read that HISTORY more carefully, though it still not clear to me, after reading that part of HISTORY, that i should change the channels.conf file. Maybe that could be impressed in a way that would make it clear, even for me? But anyway, now it works, though only for one channel at time as stated in the vdr's log. Is that a hardware specific restriction? Thanks for helping out. -Petri ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.5.0
Klaus Schmidinger wrote: Petri Helin wrote: But anyway, now it works, though only for one channel at time as stated in the vdr's log. Is that a hardware specific restriction? Your CAM doesn't respond to the QUERY that VDR sends to it. So VDR can't ask the CAM whether it is able to decrypt a certain channel (in addition to others it is already decrypting). So it's a hard-/firmware restriction of your CAM. The only CAM I have here that actually can decrypt more than one channel is the Alphacrypt with firmware revision 3.09. Is it possible to override the query and just try to decrypt two channels? -Petri ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] OSD-Resolution
Rene Hertell wrote:
Hi Guys,
I remember that someone had some kind of patch for increasing the
OSD-resoluion in VDR. I just can't find that post that mentioned about
that...
Could anyone post a link to that site that had that patch.. I would like
to try that out :-)
Regards,
René
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
The patches are here: http://www.netholic.com/viewtopic.php?t=1622
Unfortunately, if you do not speak Finnish, it might a bit hard to
follow that thread
What comes to VDR, you just need to change the defines for MAXOSDHEIGHT
and -WIDTH in config.h (this is against 1.4.3-4):
--- config.h.orig 2006-10-28 02:30:20.0 +0300
+++ config.h2006-10-28 00:14:11.0 +0300
@@ -41,9 +41,9 @@
#define MAXLIFETIME 99
#define MINOSDWIDTH 480
-#define MAXOSDWIDTH 672
+#define MAXOSDWIDTH 1280
#define MINOSDHEIGHT 324
-#define MAXOSDHEIGHT 567
+#define MAXOSDHEIGHT 720
#define MaxFileName 256
#define MaxSkinName 16
In order to increase the resolution of the OSD you should use
xineliboutput-plugin and patch it like this (patch will most likely be
broken because it is inline):
--- osd.c.orig 2006-10-30 02:37:03.0 +0200
+++ osd.c 2006-10-30 03:46:49.0 +0200
@@ -155,7 +155,12 @@
m_Device = Device;
m_Shown = false;
- CmdSize(m_Device, 0, 720, 576);
+
+ if(Setup.OSDWidth + (2*Setup.OSDLeft) > 720 || Setup.OSDHeight +
(2*Setup.OSDTop) > 576) {
+CmdSize(m_Device, 0, Setup.OSDWidth + (2*Setup.OSDLeft),
Setup.OSDHeight + (2*Setup.OSDTop));
+ } else {
+CmdSize(m_Device, 0, 720, 576);
+ }
}
cXinelibOsd::~cXinelibOsd()
@@ -182,11 +187,11 @@
if(Result == oeOk)
m_Shown = false;
- if(Left() + Width() > 720 || Top() + Height() > 576) {
+ if(2*Left() + Width() > 720 || 2*Top() + Height() > 576) {
LOGDBG("Detected HD OSD, size > %dx%d, using setup values %dx%d",
- Left() + Width(), Top() + Height(),
- Setup.OSDWidth, Setup.OSDHeight);
-CmdSize(m_Device, 0, Setup.OSDWidth, Setup.OSDHeight);
+ 2*Left() + Width(), 2*Top() + Height(),
+ Setup.OSDWidth + (2*Setup.OSDLeft), Setup.OSDHeight +
(2*Setup.OSDTop));
+CmdSize(m_Device, 0, Setup.OSDWidth + (2*Setup.OSDLeft),
Setup.OSDHeight + (2*Setup.OSDTop));
} else {
CmdSize(m_Device, 0, 720, 576);
}
After that you should change the resolution via VDR's setup menu. Note
that menu plugins are not really compatible with the larger resolution,
like for example the ttxtsubs plugin unless you make some changes in to
them. Here is an example fix for the ttxtsubs plugin:
--- ttxtsubsdisplay.c.orig 2006-10-28 02:22:29.0 +0300
+++ ttxtsubsdisplay.c 2006-10-28 02:23:42.0 +0300
@@ -332,13 +332,13 @@
enum {
SCREENLEFT = 0,
- SCREENRIGHT = 719,
+ SCREENRIGHT = 1280,
SCREENTOP = 150,
- SCREENBOTTOM = 575,
+ SCREENBOTTOM = 720,
SIDEMARGIN = 125,
- BOTNORM = 540,
- BOTLETTERBOX = 482,
+ BOTNORM = 640,
+ BOTLETTERBOX = 520,
ROWINCR = 43,
ROWH = 34,
-Petri
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] xineliboutput - DVB-C - No sound
JJussi wrote: Hi to everybody! I have strange sound problem... I have VDR machine with 3x Terratec Cinergy (mark 3) DVB-C cards, xineliboutput settings are "local=none, remote=37890". If I connect with "vdr-sxfe xvdr://htpc --audio=alsa" at some other computer (at network) everything works fine and I can hear audio of tv-broadcast.. BUT, if I do same "vdr-sxfe xvdr://htpc --audio=alsa" at my HTPC (that machine what have those DVB-C cards and it's connected to LCD-TV and 5.1 amp.) I get no sound what ever (no front, rear or surround) from tv-broadcast.. HOWEVER, if I select "Menu - Media Player - Play file" and select some AVI, MPEG, MP3, OGG or DVD... I get sound... Same problem exists if I try to play Recorded tv-show... So, have somebody some ideas why can't get (broadcast) sound at local machine, but sound works at remote machines... You might not have the correct decoder installed. Check with "xine --list-plugins" and see under "Audio decoders" whether they contain different set of decoders on local and remote hosts. -Petri ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] xineliboutput - DVB-C - No sound
JJussi wrote: On Sunday, 22. Aprilta 2007 18:23, Petri Helin wrote: You might not have the correct decoder installed. Check with "xine --list-plugins" and see under "Audio decoders" whether they contain different set of decoders on local and remote hosts. Maybe.. At machine where sound works list is: -Audio decoder: gsm610, mad, ffmpegaudio, mpc, nsf, dvaudio, flacdec, realadec, vorbis, a/52, pcm. And at not working machine it's: -Audio decoder: gsm610, ffmpegaudio, speex, realadec, nsf, dvaudio, flacdec, vorbis, a/52, faad, pcm, qta, dts, win32a. which of, it is: mad, mpc realadec Hmm.. Maybe I have to test.. If I can figure out from where those codecs come.. mad is the decoder you need. How to obtain it depends on the distribution you are using and the method how xine has been installed. Typically it is libmad and libmad-dev or libmad0 and libmad0-dev packages you should be looking for. -Petri ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Best settings..
JJussi wrote: Hi! I have very simple and still hard question.. At vdr pluging setup - xineliboutput - Video. Post processing (ffmpeg) and Deinterlaceing. What ARE best values (to select) when you have HD LCD (via DVI) as TV and enough CPU power (Intel Core 2 Duo) to use. I think that I'm not only one who thinks that there is too many choices.. ;-) There is a simple answer: the one that pleases your eyes the most... AFAIK ffmpeg post processing is for mpeg4 only. What comes to deinterlacing, I'd suggest to use tvtime with any greedy algorithm or TomsMoComp, disable cheap mode and use full framerate. My experience is that TomsMoComp or Greedy2Frame are needed for sports whereas other types of programs are not that demanding. Unfortunately none of the deinterlacing methods is perfect and they all produce some jagginess, especially with football in 16:9 aspect. -Petri ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Problem with multiple audio channels and DVB subtitles in recordings (YLE Teema)
On 5/12/07, Ville Aakko <[EMAIL PROTECTED]> wrote: Hi! I've had problems with two episodes of a documentary series about drugs and the human brain running on Finnish YLE Teema (originally a French documentary by ARTE France NOVAPROD OWL). The audio channels are labeled wrongly in the recordings (there is the original French commentary / dubbed interviews and one with Finnish commentary / original interviews), but more importantly, subtitles are not replayed in the recordings! I've had no problems with DVB subtitles on other recordings I've made. You might want to check with ProjectX that there really is a DVB subtitle stream in the recording. I have also experienced problems when a recording contains both ttxt- and DVB-subtitles (for example Canal+ HD). Both subtitles try to get to the OSD and as a result none of them is shown. As a side effect I cannot bring the menu on either in such a case. But I gather this is not the case with your problem? So, maybe start with ProjectX and let us know what you find? -Petri ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Re: Problem with multiple audio channels and DVB subtitles in recordings (YLE Teema)
Pekka Virtanen wrote: On 5/14/07, Arthur Konovalov <[EMAIL PROTECTED]> wrote: Ville Aakko wrote: > Wathing the program in real-time has no problems, there I can see the > subtitles without problems. Only the recordings have problems. I have similar issue with YLE1 and YLE2. Sometimes subtitles saved, sometimes not. ProjectX shows same: no subtitles- no DVB stream. And vice versa. The problem is most likely caused by the fact that the PIDs for subtitles are different than at the time the recording started. Current implementation doesn't detect if PIDs change during recording. As a workaround you can set your time e.g. 1 minute after the program has begun. Since the subtitle pids are always the same (at least I think they are on Finnish channels: Finnish subtitles can be found from 1027 for TV1, 2027 for TV2, 3027 for FST, 4027 for Teema and 5027 for Extra), would it be hard to add a possibility to fix the pids per channel? Maybe through setup. -Petri ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Re: Problem with multiple audio channels and DVB subtitles in recordings (YLE Teema)
Rolf Ahrenberg wrote: On Mon, 14 May 2007, Petri Helin wrote: Since the subtitle pids are always the same (at least I think they are on Finnish channels: Finnish subtitles can be found from 1027 for TV1, 2027 for TV2, 3027 for FST, 4027 for Teema and 5027 for Extra), would it be hard to add a possibility to fix the pids per channel? Maybe through setup. I've done and using (and sent to Klaus) two patches (spids & remux) that detects automatically changes in subtitle pids as it's done nowadays with audio pids and records all available subtitle tracks. I don't see any benefits using fixed pids... Of course that is the preferred way to go. I was just thinking "a quick fix" type of solution... Also all OSD opening problems should be fixed hopefully in the latest versions of my subtitles patches. Sorry, cannot remember the exact version, but atleast vdr-1.5.2-subtitles-0.5.0.diff should contain the fix. I'll have to check which patches I have applied and come back to this if the latest ones still have the OSD opening problem. -Petri ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Best settings..
Anssi Hannula wrote: Lauri Tischler wrote: Anssi Hannula wrote: JJussi wrote: Hi! I have very simple and still hard question.. At vdr pluging setup - xineliboutput - Video. Post processing (ffmpeg) and Deinterlaceing. What ARE best values (to select) when you have HD LCD (via DVI) as TV and enough CPU power (Intel Core 2 Duo) to use. I think that I'm not only one who thinks that there is too many choices.. ;-) I use vdr-sxfe with "--video=xv --aspect=16:9 --post tvtime:method=Greedy2Frame,cheap_mode=0,pulldown=0,use_progressive_frame_flag=1". Is there a document somewhere which explains all switches in above command ? I think they are shown somewhere in xine gui, but quoting from xine-lib source: PARAM_ITEM( POST_PARAM_TYPE_INT, method, enum_methods, 0, 0, 0, "deinterlace method" ) PARAM_ITEM( POST_PARAM_TYPE_BOOL, enabled, NULL, 0, 1, 0, "enable/disable" ) PARAM_ITEM( POST_PARAM_TYPE_INT, pulldown, enum_pulldown, 0, 0, 0, "pulldown algorithm" ) PARAM_ITEM( POST_PARAM_TYPE_INT, framerate_mode, enum_framerate, 0, 0, 0, "framerate output mode" ) PARAM_ITEM( POST_PARAM_TYPE_BOOL, judder_correction, NULL, 0, 1, 0, "make frames evenly spaced for film mode (24 fps)" ) PARAM_ITEM( POST_PARAM_TYPE_BOOL, use_progressive_frame_flag, NULL, 0, 1, 0, "disable deinterlacing when progressive_frame flag is set" ) PARAM_ITEM( POST_PARAM_TYPE_BOOL, chroma_filter, NULL, 0, 1, 0, "apply chroma filter after deinterlacing" ) PARAM_ITEM( POST_PARAM_TYPE_BOOL, cheap_mode, NULL, 0, 1, 0, "skip image format conversion - cheaper but not 100% correct" ) And in a bit more detail, also from the source: Advanced tvtime/deinterlacer plugin with pulldown detection This plugin aims to provide deinterlacing mechanisms comparable to high quality progressive DVD players and so called line-doublers, for use with computer monitors, projectors and other progressive display devices. Parameters: Method: Select deinterlacing method/algorithm to use, see below for explanation of each method. Enabled: Enable/disable the plugin. Pulldown: Choose the 2-3 pulldown detection algorithm. 24 FPS films that have being converted to NTSC can be detected and intelligently reconstructed to their original (non-interlaced) frames. Framerate_mode: Selecting 'full' will deinterlace every field to an unique frame for television quality and beyond. This feature will effetively double the frame rate, improving smoothness. Note, however, that full 59.94 FPS is not possible with plain 2.4 Linux kernel (that use a timer interrupt frequency of 100Hz). Newer RedHat and 2.6 kernels use higher HZ settings (512 and 1000, respectively) and should work fine. Judder_correction: Once 2-3 pulldown is enabled and a film material is detected, it is possible to reduce the frame rate to original rate used (24 FPS). This will make the frames evenly spaced in time, matching the speed they were shot and eliminating the judder effect. Use_progressive_frame_flag: Well mastered MPEG2 streams uses a flag to indicate progressive material. This setting control whether we trust this flag or not (some rare and buggy mpeg2 streams set it wrong). Chroma_filter: DVD/MPEG2 use an interlaced image format that has a very poor vertical chroma resolution. Upsampling the chroma for purposes of deinterlacing may cause some artifacts to occur (eg. color stripes). Use this option to blur the chroma vertically after deinterlacing to remove the artifacts. Warning: cpu intensive. Cheap_mode: This will skip the expensive YV12->YUY2 image conversion, tricking tvtime/dscaler routines like if they were still handling YUY2 images. Of course, this is not correct, not all pixels will be evaluated by the algorithms to decide the regions to deinterlace and chroma will be processed separately. Nevertheless, it allows people with not so fast systems to try deinterlace algorithms, in a tradeoff between quality and cpu usage. One conclusion is that Judder_correction and Pulldown are useless for PAL material. Use_progressive_frame_flag is also quite futile with DVB material, but some DVDs might benefit from it. -Petri ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Re: Problem with multiple audio channels and DVB subtitles in recordings (YLE Teema)
Rolf Ahrenberg wrote: I've done and using (and sent to Klaus) two patches (spids & remux) that detects automatically changes in subtitle pids as it's done nowadays with audio pids and records all available subtitle tracks. I don't see any benefits using fixed pids... So, I should just remove the part regarding remux.c from vdr-1.5.2-subtitles-0.5.0-and-ttxtsubs-0.0.5.diff patch to test these patches with 1.5.2, or do you have a matching subtitles&ttxtsubs patch to be used with the remux patch already? -Petri ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Re: Problem with multiple audio channels and DVB subtitles in recordings (YLE Teema)
Rolf Ahrenberg wrote: On Mon, 14 May 2007, Petri Helin wrote: So, I should just remove the part regarding remux.c from vdr-1.5.2-subtitles-0.5.0-and-ttxtsubs-0.0.5.diff patch to test these patches with 1.5.2, or do you have a matching subtitles&ttxtsubs patch to be used with the remux patch already? Yes, you shouldn't need the remux.c and menu.c hunks anymore. The spids Hmm. It looks like menu.c needs to be patched? menu.c: In constructor ‘cRecordControl::cRecordControl(cDevice*, cTimer*, bool)’: menu.c:3846: error: no matching function for call to ‘cRecorder::cRecorder(char*&, tChannelID, int, int, const int*, const int*, const int*)’ recorder.h:32: note: candidates are: cRecorder::cRecorder(const char*, tChannelID, int, int, const int*, const int*, const int*, cTtxtSubsRecorderBase*) recorder.h:22: note: cRecorder::cRecorder(const cRecorder&) make: *** [menu.o] Error 1 -Petri ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Re: Problem with multiple audio channels and DVB subtitles in recordings (YLE Teema)
Rolf Ahrenberg wrote: On Tue, 15 May 2007, Petri Helin wrote: Rolf Ahrenberg wrote: Yes, you shouldn't need the remux.c and menu.c hunks anymore. The spids Hmm. It looks like menu.c needs to be patched? Sorry about the misinformation. I don't use ttxtsubs, so I didn't check the combined patch. No problem, just wanted to be sure I didn't miss something. I have briefly tested the remux and spids patches and found one major problem. Somehow the "voice subtitling" or "audio subtitling" or "spoken subtitling" (whatever the correct naming might be) which is used on YLE's channels, is not correctly recognized. Normally there is the actual spoken language + dutch in the audio selection list, but with these patches I always end up with three options: 1, 2 and 33. In addition entries like this started to appear to the log: "switching to pre 1.3.19 Dolby Digital compatibility mode" and I've never seen them before. -Petri ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] MPlayer plug-in..
JJussi wrote: Hi! (to everybody) I have "problem" with vdr-mplayer -plug-in... 1. It don't play files.. IF I start pure MPlayer it can play all video files what I have.. 2. some how plug-in have problem to see symbol links and (some of) files.. That number one is annoying... Where I can configure file extensions what it shows.. To select *.* so it's me who decides what I want to play.. And why it cannot play files what normal Mplayer can? What are parameters what are sent to mplayer when plug-in starts it? Just a few days ago you asked about xineliboutput... why would you want to use mplayer plugin with xineliboutput? -Petri ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] MPlayer plug-in..
JJussi wrote: On Thursday, 17. Mayta 2007 13:21, Petri Helin wrote: Just a few days ago you asked about xineliboutput... why would you want to use mplayer plugin with xineliboutput? Yes, vdr-sxfe (xineliboutput) is my frontend what shows content of my htpc.. TV programs and video/music files. There IS (in menu) "Media Player - Play File" but 1. it shows only few files (.mpg,.avi) and cannot configure to see other extensions 2. when try to play HD content (720p) avi, sometimes it crash.. SO, then there is mplayer what plays what ever (almost) what I give it... BUT if that vdr-mplayer plug-in don't work, then I have to close my vdr-sxfe and start mplayer (or kmplayer).. OK, I can do it.. But rest of this household don't.. So It would be easier that you can choose from menu what you want to watch.. That's why! Hmm, the media player built into xineliboutput plays back files with the following suffix: Audio: mpa, mp2, mp3, mpega, flac, ac3, ogg, ogm, au, aud, wma, asf, wav, spx, ra Video: avi, mpv, vob, vdr, mpg, mpeg, mp4, asf, wmv, mov, ts, pes, xvid, divx, fli, dv, dat, mkv, rm, iso Image: jpg, jpeg, gif, tiff, bmp, mng, png If there are still some file types that should be added, please let me know. I've played several 720p videos with the media player and it has never crashed. What are the versions of xine-lib and xineliboutput you are using? Are you using binary packages or have you compiled them yourself? There should be no need to use mplayer with xineliboutput. -Petri ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] MPlayer plug-in..
Pertti Kosunen wrote: Petri Helin wrote: Hmm, the media player built into xineliboutput plays back files with the following suffix: What subtitle types are supported? I think sub, srt, txt and ssa are supported but I do not use subtitles so I do not know how well that reflects the real life. I have though tested that at least type sub should work. -Petri ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] MPlayer plug-in..
JJussi wrote: On Thursday, 17. Mayta 2007 18:42, Petri Helin wrote: Audio: mpa, mp2, mp3, mpega, flac, ac3, ogg, ogm, au, aud, wma, asf, wav, spx, ra Video: avi, mpv, vob, vdr, mpg, mpeg, mp4, asf, wmv, mov, ts, pes, xvid, divx, fli, dv, dat, mkv, rm, iso Image: jpg, jpeg, gif, tiff, bmp, mng, png Would be nice if you could set (at /etc/vdr/setup.conf-file) parameter like: mediaplayer.filemask=* (or something like that) so it shows all files.. This could be a good idea... But to my problem files, I have quite much files from Topfield 5100 (DBV-C recorder). Extensioin is .rec... mplayer says: Playing 4D-# 2007-01-16.rec. TS file format detected. VIDEO MPEG2(pid=512) AUDIO MPA(pid=650) NO SUBS (yet)! PROGRAM N. 65 VIDEO: MPEG2 704x576 (aspect 2) 25.000 fps 5000.0 kbps (625.0 kbyte/s) and shows it fine.. EVEN I rename file extension to .mpg or .mpeg (so mediaplayer can list it) it cannot show it.. Nor can vdr-mplayer plug-in.. Can you play the file with xine-ui? At least try it with --verbose=3 (i.e. xine --verbose=3 "4D-# 2007-01-16.rec"). I've played several 720p videos with the media player and it has never crashed. What are the versions of xine-lib and xineliboutput you are using? Are you using binary packages or have you compiled them yourself? xine-lib: 1.1.4-r2 (gentoo amd64; compiled) xineliboutput: 1.0.0_rc1 (gentoo amd64; compiled) Would it be possible to upgrade to xine-lib 1.1.6 and maybe to xineliboutput cvs? There should be no need to use mplayer with xineliboutput. Then why it cannot play that 4D-# 2007-01-16.rec file.. ;-) I hope we'll find that out :) Although Anssi already pointed out one reason to use mplayer-plugin... -Petri ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] Timers not starting
Hi, I have encountered a new problem which I have not seen before: I have missed timers without any obvious reason. All these timers were set to the same channel and this partivular channel differs from others in the sense that I have set the xmltv2vdr to update its epg. But I have also had successful timers on that channels so xmltv2vdr shoould not cause this problem. As I said, I have not found any obvious reason, but will still attach a bit of the log showing how the timer for the 15th episode of "Heroes" was set but never started to record. But in the mean time recordings on other channels started just fine. I am using vdr 1.5.2 patched with liemikuutio-, MainMenuHooks-, subtitles- and ttxtsub-patches. The version of the epgsearch-plugin is 0.9.21. Hopefully someone could help me out with this one... -Petri May 16 19:57:00 ... timer 23 (4 1957-2210 'Ep�miellytt�v� totuus') start May 16 19:57:00 ... record /video/Ep�miellytt�v�_totuus/2007-05-16.19.57.50.99.rec May 16 19:57:04 ... recording to '/video/Ep�miellytt�v�_totuus/2007-05-16.19.57.50.99.rec/001.vdr' May 16 19:57:04 ... recording thread started (pid=4767, tid=5034) ... May 16 21:27:01 ... timer 22 (2 2127-0030 'Jalkapallon UEFA-cup') start May 16 21:27:01 ... record /video/Jalkapallon_UEFA-cup/2007-05-16.21.27.50.99.rec May 16 21:27:01 ... recording to '/video/Jalkapallon_UEFA-cup/2007-05-16.21.27.50.99.rec/001.vdr' May 16 21:27:01 ... recording thread started (pid=4767, tid=6077) ... May 16 21:28:24 ... timer 1 (12 2257-2355 'Heroes: 15. jakso: Run!~Ke 16.05.2007-23:00') set to no event ... May 16 21:28:28 ... timer 1 (12 2257-2355 'Heroes: 15. jakso: Run!~Ke 16.05.2007-23:00') set to event Ke 16.05.2007 23:00-23:45 'Heroes: 15. jakso: Run!' ... May 16 21:30:24 ... stopping recording due to modification of channel 2 May 16 21:30:24 ... recording thread ended (pid=4767, tid=6077) May 16 21:30:24 ... timer 22 (2 2127-0030 'Jalkapallon UEFA-cup') stop May 16 21:30:25 ... timer 22 (2 2127-0030 'Jalkapallon UEFA-cup') start May 16 21:30:25 ... record /video/Jalkapallon_UEFA-cup/2007-05-16.21.27.50.99.rec May 16 21:30:25 ... ttxtsubs: Selected language not found, just recording first teletext pid found. May 16 21:30:25 ... recording to '/video/Jalkapallon_UEFA-cup/2007-05-16.21.27.50.99.rec/002.vdr' May 16 21:30:25 ... recording thread started (pid=4767, tid=6125) May 16 21:46:34 ... recording to '/video/Ep�miellytt�v�_totuus/2007-05-16.19.57.50.99.rec/002.vdr' ... May 16 22:10:00 ... recording thread ended (pid=4767, tid=5034) May 16 22:10:00 ... timer 23 (4 1957-2210 'Ep�miellytt�v� totuus') stop May 16 22:11:29 ... deleting timer 23 (4 1957-2210 'Ep�miellytt�v� totuus') ... May 16 22:31:43 ... stopping recording due to modification of channel 2 May 16 22:31:43 ... recording thread ended (pid=4767, tid=6125) May 16 22:31:43 ... timer 22 (2 2127-0030 'Jalkapallon UEFA-cup') stop May 16 22:31:43 ... timer 22 (2 2127-0030 'Jalkapallon UEFA-cup') start May 16 22:31:43 ... record /video/Jalkapallon_UEFA-cup/2007-05-16.21.27.50.99.rec May 16 22:31:44 ... recording to '/video/Jalkapallon_UEFA-cup/2007-05-16.21.27.50.99.rec/003.vdr' May 16 22:31:44 ... recording thread started (pid=4767, tid=6745) May 16 22:40:24 ... stopping recording due to modification of channel 2 May 16 22:40:24 ... recording thread ended (pid=4767, tid=6745) May 16 22:40:24 ... timer 22 (2 2127-0030 'Jalkapallon UEFA-cup') stop May 16 22:40:24 ... timer 22 (2 2127-0030 'Jalkapallon UEFA-cup') start May 16 22:40:24 ... record /video/Jalkapallon_UEFA-cup/2007-05-16.21.27.50.99.rec May 16 22:40:24 ... recording to '/video/Jalkapallon_UEFA-cup/2007-05-16.21.27.50.99.rec/004.vdr' May 16 22:40:24 ... recording thread started (pid=4767, tid=6842) ... May 16 23:39:28 ... recording to '/video/Jalkapallon_UEFA-cup/2007-05-16.21.27.50.99.rec/005.vdr' May 16 23:53:00 ... EPGSearch: search timer update started May 16 23:53:00 ... EPGSearch: search timer update finished May 16 23:56:04 ... deleting timer 1 (12 2257-2355 'Heroes: 15. jakso: Run!~Ke 16.05.2007-23:00') ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Timers not starting
Klaus Schmidinger wrote: How many DVB devices does your system have? Are you sure there was one free when that timer should have been recorded? What was the priority of that timer? I'm afraid you've shortened your log a little too much, so I can't see the information on which device the individual timers did record. I have two budget cards. One of them was recording, but the other one should have been available. I use always the default priority (50). I have now attached a longer log, hope that will provide more info. -Petri May 16 19:52:52 x vdr: [4865] receiver on device 1 thread started (pid=4767, tid=4865) May 16 19:52:52 x vdr: [4868] TS buffer on device 1 thread started (pid=4767, tid=4868) May 16 19:52:52 x vdr: [4767] timer 1 (12 2257-2355 'Heroes: 15. jakso: Run!~Ke 16.05.2007-23:00') set to event Ke 16.05.2007 23:00-23:45 'Heroes: 15. jakso: Run!' May 16 19:52:52 x vdr: [4767] timer 2 (12 2057-2310 'Merijalkaväen mies') set to event Pe 18.05.2007 21:00-23:00 'Merijalkaväen mies' May 16 19:52:52 x vdr: [4767] timer 3 (12 2257-2355 'Heroes: 16. jakso: Unexpected~Ke 23.05.2007-23:00') set to event Ke 23.05.2007 23:00-23:45 'Heroes: 16. jakso: Unexpected' May 16 19:52:52 x vdr: [4767] timer 4 (2 1032-1133 'Meren salaisuudet~To 17.05.2007-10:35') set to event To 17.05.2007 10:35-11:24 'Meren salaisuudet' May 16 19:52:53 x vdr: [4774] changing pids of channel 1 from 512+512:650=fin:2321 to 512+512:650=fin,652=dut:2321 May 16 19:52:53 x vdr: [4807] ttxtsubs: Service Information read: timeout! May 16 19:52:53 x vdr: [4864] setting audio track to 1 (0) May 16 19:52:53 x vdr: [4767] timer 5 (7 1958-2036 'Monty Pythonin lentävä sirkus~Pe 18.05.2007-20:01') set to event Pe 18.05.2007 20:01-20:26 'Monty Pythonin lentävä sirkus' May 16 19:52:53 x vdr: [4767] timer 6 (1 1843-1944 'Avara luonto: Haikaran matkassa') set to event La 19.05.2007 18:45-19:34 'Avara luonto: Haikaran matkassa' May 16 19:52:53 x vdr: [4807] ttxtsubs: Wanted subtitle language(s) not found on channel, available languages: May 16 19:52:53 x vdr: [4807] ttxtsubs: 100: fin (Initial Page (The teletext start page, not a subtitles page!)) May 16 19:52:53 x vdr: [4770] video directory scanner thread ended (pid=4767, tid=4770) May 16 19:52:53 x vdr: [4769] video directory scanner thread ended (pid=4767, tid=4769) May 16 19:52:53 x vdr: [4767] timer 7 (5 2252- 'Twin Peaks~La 19.05.2007-22:55') set to event La 19.05.2007 22:55-23:50 'Twin Peaks' May 16 19:52:53 x vdr: [4767] timer 8 (12 2057-2350 'München') set to event Pe 25.05.2007 21:00-23:40 'München' May 16 19:52:53 x vdr: [4767] timer 9 (12 2337-0250 'King Kong') set to event Pe 25.05.2007 23:40-02:40 'King Kong' May 16 19:52:53 x vdr: [4767] timer 10 (12 2057-2320 'Brokeback Mountain') set to event La 26.05.2007 21:00-23:10 'Brokeback Mountain' May 16 19:52:53 x vdr: [4767] timer 11 (10 0238-0320 'Entourage: 3. kausi, 1. jakso: Aquamom~Ma 21.05.2007-02:40') set to event Ma 21.05.2007 02:40-03:10 'Entourage: 3. kausi, 1. jakso: Aquamom' May 16 19:52:53 x vdr: [4767] timer 12 (10 0238-0320 'Entourage: 3. kausi, 2. jakso: One Day in the Valley~Ti 22.05.2007-02:40') set to event Ti 22.05.2007 02:40-03:10 'Entourage: 3. kausi, 2. jakso: One Day in the Valley' May 16 19:52:53 x vdr: [4774] changing pids of channel 2 from 513+513:660=fin:2321 to 513+513:660=eng:2321 May 16 19:52:53 x vdr: [4807] ttxtsubs: Wanted subtitle language(s) not found on channel, available languages: May 16 19:52:53 x vdr: [4767] timer 13 (10 0253-0335 'Entourage: 3. kausi, 3. jakso: Dominated~Ke 23.05.2007-02:55') set to event Ke 23.05.2007 02:55-03:25 'Entourage: 3. kausi, 3. jakso: Dominated' May 16 19:52:53 x vdr: [4807] ttxtsubs: 100: fin (Initial Page (The teletext start page, not a subtitles page!)) May 16 19:52:53 x vdr: [4767] timer 14 (10 0238-0320 'Entourage: 3. kausi, 4. jakso: Guys and Doll~To 24.05.2007-02:40') set to event To 24.05.2007 02:40-03:10 'Entourage: 3. kausi, 4. jakso: Guys and Doll' May 16 19:52:53 x vdr: [4767] timer 15 (10 0238-0320 'Entourage: 5. jakso: Crash and Burn~Pe 25.05.2007-02:40') set to event Pe 25.05.2007 02:40-03:10 'Entourage: 5. jakso: Crash and Burn' May 16 19:52:53 x vdr: [4807] ttxtsubs: Wanted subtitle language(s) not found on channel, available languages: May 16 19:52:53 x vdr: [4767] timer 16 (10 0233-0315 'Entourage: 6. jakso: Three's Company~La 26.05.2007-02:35') set to event La 26.05.2007 02:35-03:05 'Entourage: 6. jakso: Three's Company' May 16 19:52:53 x vdr: [4807] ttxtsubs: 100: fin (Initial Page (The teletext start page, not a subtitles page!)) May 16 19:52:53 x vdr: [4767] timer 17 (10 0258-0345 'Entourage: 7. jakso: Strange Days~Su 27.05.2007-03:00') set to event Su 27.05.2007 03:00-03:35 'Entourage: 7. jakso: Strange Days' May 16 19:52:53 x vdr: [4767] timer 19 (10 0228-0310 'Entourage: 8. jakso: The Release~Ma 28.05.2007-02:30') set to event Ma 28.05.2007 02:30
Re: [vdr] Timers not starting
Klaus Schmidinger wrote:
How many DVB devices does your system have?
Are you sure there was one free when that timer should have been recorded?
What was the priority of that timer?
I tried to recreate the situation by disabling the decrypting for the
subscription channels. The channel the recording was supposed the take
place on is encrypted and I though that maybe the decrypting didn't work
for some reason and therefore the channel was unavailable. I just tested
this and got the following log entries:
May 18 02:02:56 x vdr: [32337] EPGSearch: timer thread started
(pid=32258, tid=32337)
May 18 02:02:57 x vdr: [32258] connect from 127.0.0.1, port 39440 - accepted
May 18 02:02:57 x vdr: [32258] timer 25 (11 0205-0215 'Magnum .44') added
May 18 02:02:57 x vdr: [32258] closing SVDRP connection
May 18 02:02:57 x vdr: [32337] EPGSearch: timer thread ended (pid=32258,
tid=32337)
May 18 02:03:02 x vdr: [32258] timer 25 (11 0205-0215 'Magnum .44') set
to event Pe 18.05.2007 01:20-03:20 'Magnum .44'
May 18 02:04:03 x vdr: [32258] switching device 3 to channel 11
So vdr tried to change to the channel, but couldn't, and therefore the
recording could be started. Shouldn't this create some entries in the
log? Like "unable to start recording" or something?
After that I tried to manually wswitch to the channel and got these log
entries (these entries follow immediately the ones above):
May 18 02:06:52 x vdr: [32258] switching to channel 11
May 18 02:06:52 x vdr: [32334] transfer thread ended (pid=32258, tid=32334)
May 18 02:06:52 x vdr: [32258] buffer stats: 87608 (4%) used
May 18 02:06:52 x vdr: [32258] info: Kanava ei ole käytettävissä!
May 18 02:06:57 x vdr: [32258] info: Kanavan vaihtaminen ei mahdollista!
May 18 02:07:02 x vdr: [32258] switching to channel 1
May 18 02:07:02 x vdr: [32258] buffer stats: 0 (0%) used
May 18 02:07:02 x vdr: [32397] transfer thread started (pid=32258,
tid=32397)
May 18 02:07:02 x vdr: [32258] buffer stats: 0 (0%) used
May 18 02:07:02 x vdr: [32258] max. latency time 10 seconds
May 18 02:07:02 x vdr: [32258] switching to channel 11
May 18 02:07:02 x vdr: [32397] transfer thread ended (pid=32258, tid=32397)
May 18 02:07:02 x vdr: [32258] buffer stats: 0 (0%) used
May 18 02:07:02 x vdr: [32258] info: Kanava ei ole käytettävissä!
May 18 02:07:02 x vdr: [32258] connect from 127.0.0.1, port 60450 - accepted
May 18 02:07:02 x vdr: [32258] closing SVDRP connection
May 18 02:07:06 x vdr: [32258] info: VPS-tallennus on alkamassa!
May 18 02:07:13 x vdr: [32258] switching to channel 1
May 18 02:07:13 x vdr: [32258] buffer stats: 0 (0%) used
May 18 02:07:13 x vdr: [32400] transfer thread started (pid=32258,
tid=32400)
May 18 02:07:13 x vdr: [32258] buffer stats: 0 (0%) used
May 18 02:07:15 x vdr: [32400] setting audio track to 1 (0)
So now there is additional entries telling that the channel is not
available ("Kanava ei ole käytettävissä!"). But what is that strange
entry about VPS recording staring ("VPS-tallennus on alkamassa!")? I
didn't create a VPS timer...
-Petri
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] MPlayer plug-in..
JJussi wrote: > LOG SECTION [messages] '19:44:24: xine: found demuxer plugin: Elementary MPEG stream demux plugin' '19:44:24: xine: found input plugin : file input plugin' '19:44:24: xine: couldn't find demux for >4D.rec<' '19:44:23: xine: found input plugin : file input plugin' Well, it does look like that xine cannot play back Topfield recordings without defining the demuxer explicitly. This can be done either by adding string "#demux:mpeg-ts" to the filename or by changing the extension of the file from ".rec" to ".ts". Could you try the latter approach with xineliboutput's media player? -Petri ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Timers not starting
Klaus Schmidinger wrote:
On 05/18/07 01:24, Petri Helin wrote:
So now there is additional entries telling that the channel is not
available ("Kanava ei ole käytettävissä!"). But what is that strange
entry about VPS recording staring ("VPS-tallennus on alkamassa!")? I
didn't create a VPS timer...
The "Upcoming VPS recording!" message is probably actually wrong, since
your timer doesn't use VPS. Originally switching to the transponder early
was only done for VPS recordings, but beginning with version 1.4.0-3 this
is also done for non-VPS timers, so that the EPG data is up-to-date when
the timer actually starts. I'll change the message accordingly, so in your
case it should just say "Upcoming recording".
As for the actual problem: I assume you're using a heavily patched version
of VDR. Can you try to recreate the situation with an unpatched VDR?
And please switch the OSD language to English while doing so, so that I can
understand the log messages ;-)
Sorry about the OSD language, should have known better...
Anyways, I am fairly confident that the problem is not with VDR per se,
but with the decryption failing (there seems to be something wrong with
my smartcard or my subscription). But an improvement I'd like to see in
VDR would be some sort of loud and clear alert about "Unable to start
recording xxx" or something like that to the OSD so that the user could
try to fix the problem manually. And maybe an option to do something in
case a recording cannot be started because VDR cannot tune to the channel.
-Petri
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] cFemonOsd::Show() cannot open frontend device
Alasdair Campbell wrote: When trialing vdr-femon-1.1.0 with vdr-xineliboutput-1.0.0_rc1 I ... Any advice gladly received! Try the current versions? Femon 1.1.4: http://www.saunalahti.fi/~rahrenbe/vdr/femon/ Xineliboutput 1.0.0rc2: http://phivdr.dyndns.org/vdr/vdr-xineliboutput/ -Petri ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] record plug-in..
JJussi wrote: Hi! Is there (somewhere) or is easy to produce plug-in what would save (record) all what you are watching live? Something like last 30 - 60 minutes?!? That way you could always rewind backward and that would remove that gap (of time) what now exists when you press "pause" (at least I have "problem"; when I press pause button, it takes over 10 seconds before it's actually pausing live stream) Not a plugin but does exactly what you are asking for - the livebuffer patch: http://home.vrweb.de/~bergwinkl.thomas/ -Petri ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] record plug-in..
On 5/25/07, JJussi <[EMAIL PROTECTED]> wrote: On Thursday, 24. Mayta 2007 23:15, Petri Helin wrote: > Not a plugin but does exactly what you are asking for - the livebuffer > patch: http://home.vrweb.de/~bergwinkl.thomas/ OK, now I have to move using non-gentoo version of vdr.. ;-) You cannot "include" extra patches to gentoo compile process.. Atleast not easily.. It might be included in the bigpatch and that should be available through Gentoo portage. -Petri ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Burning DVB (non-Teletext) subtitles to the video prior to editing and transcoding
Samuli Seppänen wrote: > I did not find anything definite about this subject from LinuxTV wiki, > mailing list archives or google, so here it comes. Please point me to a > previous thread if there is one - I did check the mailinglist archives for > the last 12 months or so. > > Ok, so I'm using VDR as the software for my dedicated VDR box - see > http://users.utu.fi/sjsepp/gentoo_vdr/gentoo_vdr.html for more information. > There are some recordings that I like to archive. The process which I use > currently is like this: > > 1. Fix / demultiplex the recordings with ProjectX > 2. Multiplex the recordings with mplex > 3. Edit and transcode the videos (to xvid) with Avidemux > > Now this works just fine for those recordings that don't have separate > subtitles. Here in Finland we do have separate subtitles on some channels. > The subtitles are not s.c. teletext subtitles, but "normal" dvb subtitles. > VDR can record these just fine and ProjectX can extract them as well. The > files ProjectX creates for the subtitles are .sup and .sup.IFO. I tried > selecting the subtitle export format in ProjectX, but it did not seem to have > any effect - I guess it's only valid for teletext subtitles. The DVB > subtitles don't seem to be that well supported, so I can't edit the > recordings at all unless I want to break the timings in the subtitle files. > > So I was thinking of a couple of approaches: > > - Convert the subtitles to some other (bitmap) format (dvd subtitles, for > example) which is better supported and which the editing software (avidemux) > can understand > - Converting the subtitles as above plus streaming them IN the video stream > with vlc (I guess this is possible?) > - Burning the subtitles into the video stream prior to editing and > transcoding with avidemux - this is what I'd prefer > > Could someone point me to the right direction - I don't really care how to > get to my goal, as long as I get there. > > All guides I've found make use of Windows programs, which do work in Wine at > least to a degree. I'd rather do this 100% natively in Linux, as I haven't > got any Windows boxes around. > > Best regards to all, > > Samuli Seppänen > What you could do is take a recent enough ProjectX cvs which has support for exporting dvb-subtitles in Vobsub format. Then just demux the video, audio and subtitles with projectx, encode video and audio with your preferred method and combine video, audio and subtitles in to a Matroska envelope. To get the right subtitles in right format, ensure that your ProjectX.ini file contains these definitions (PageId=1 makes sure you select the finnish subtitles in case there are more than one subtitle stream present): SubtitlePanel.PageId.Value=1 SubtitlePanel.SubpictureColorModel=YLE SubtitlePanel.SubtitleExportFormat=SUP SubtitlePanel.exportAsVobSub=1 And, since you speak finnish, I'd point you to www.linuxtv.fi, which contains relevant information in finnish (e.g. http://www.linuxtv.fi/viewtopic.php?t=2283) -Petri ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Breaking sound at playback
JJussi wrote: > Hi! > > This question is directed more to Finnish DBV/VDR gurus... > > I have problem with YLE recordings. When watching "live" proadcast, sound is > just right but when watch same program as recoded, sound is breaking, picture > is fine, but sound have short gaps.. Like when there is not enougth CPU power > to decode it. > IF I play that file directly with xine sound is fine.. No problem. > > During watching, when sound start breaking, if I "jump" few second backward > sound is fine for a while, but then start breaking again. > > So this problem is only with YLE recordings, other channels are fine always. > > I have tried to change almost everyhting at xineliboutput and replay > settings, > nothing helps. This is not version related (atleast not vdr version). > Do you use identical configurations for xine-ui and xineliboutput? I mean the ones in your ~/.xine directory. What are those like? Do you use vdr-sxfe, vdr-fbfe or local frontend with xineliboutput? Have you tried other frontends like VLC or mplayer? Have you tried increasing the output of vdr-sxfe (or your frontend of choice)? What versions of xine-lib and xineliboutput are you using? How do you start the frontend, VDR and other players you have tested? Do you for example always use the same audio driver? Please try to gather all the necessary information... that way it is easier for others to help you. -Petri ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Breaking sound at playback
On 7/22/07, JJussi <[EMAIL PROTECTED]> wrote:
>
> > Have you tried increasing the output of vdr-sxfe (or your frontend of
> > choice)?
>
> Mixer settings or frontends volume settings don't make any difference.. EVEN
> it sounds like (the sound/gaps) it's "overdriving" the sound. Is audio
> compressed or not, no different.
>
> > How do you start the frontend, VDR and other players you have tested? Do
> > you for example always use the same audio driver?
>
With output I meant verbose debugging information... ;)
> Command what I use to start frontend.. There is no different on sound even I
> use --audio= parameter
>
> /usr/bin/vdr-sxfe --lirc=/dev/lircd --fullscreen --video=xv --syslog
> --aspect=16:9 --rtp
> xvdr://localhost
>
Could you try without the "---rtp" option, so that it would use local
pipe instead? And perhaps try the other transport options too ("--tcp"
and "--udp"). And add "--verbose" to the command to get more detailed
information.
-Petri
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] New shutdown procedure not working as expected
Hi,
It seems that the new shutdown procedure introduced for versions 1.5.x
is (at least for me) not working as expected. The problem is that it
does not recognize correctly whether VDR was started manually or not. In
fact it thinks every time that it has been started manually. I traced
the problem to the SystemExec call in
cShutdownHandler::CallShutdownCommand where Setup.NextWakeupTime is
updated only if the SystemExec call returns 0. i changed it to accept
all values greater or equal to 0 and now Setup.NextWakeupTime gets
updated properly. Can some explain me why 0 is expected?
Here is the patch that I came up with:
--- shutdown.c.orig 2007-08-02 00:14:49.0 +0300
+++ shutdown.c 2007-08-02 00:15:10.0 +0300
@@ -126,7 +126,7 @@
time_t Delta = WakeupTime ? WakeupTime - time(NULL) : 0;
cString cmd = cString::sprintf("%s %ld %ld %d \"%s\" %d",
shutdownCommand, WakeupTime, Delta, Channel, *strescape(File, "\"$"),
UserShutdown);
isyslog("executing '%s'", *cmd);
- if (SystemExec(cmd, true) == 0)
+ if (SystemExec(cmd, true) >= 0)
Setup.NextWakeupTime = WakeupTime; // Remember this wakeup time
for comparison on reboot
}
-Petri
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] 1.4.7 and xineliboutput issues
On 8/3/07, mike lewis <[EMAIL PROTECTED]> wrote:
>
> So.. What can I do to debug whats going on and why??
>
First of all you'd need to tell us the version of xineliboutput you
are using and the way you use/start xineliboutput. Which frontend do
you use (remote or local), what parameters do you give to
xineliboutput, what settings have you set and so on. Also information
about cpu load and used hardware could be useful.
I use remote frontend (vdr-sxfe) and start it like this in a script:
STARTTIME=`date +%Y%m%d_%H%M`
vdr-sxfe --reconnect --fullscreen --audio=alsa --video=xv
--display=0.0 --verbose xvdr://127.0.0.1 2>
/var/log/vdr/vdr-sxfe_err_${STARTTIME}.log 1>
/var/log/vdr/vdr-sxfe_${STARTTIME}.log &
That way I have always a log of what's happened.
-Petri
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] New shutdown procedure not working as expected
Udo Richter wrote: > Petri Helin wrote: >> I traced the problem to the SystemExec call in >> cShutdownHandler::CallShutdownCommand where Setup.NextWakeupTime is >> updated only if the SystemExec call returns 0. i changed it to accept >> all values greater or equal to 0 and now Setup.NextWakeupTime gets >> updated properly. Can some explain me why 0 is expected? > > SystemExec called with true as second parameter should only return -1 in > case of an error (logged to syslog) or the status of waitpid() in case > of success. (see thread.c) Since the direct child instantly does > exit(0), I assumed that status should also be 0. > > On the other hand, the man page of waitpid mentions lots of macros to > inspect the status return of waitpid. Maybe checking on these helps here. > It seems to me that VDR still fails writing the NextWakeupTime every now and then, even after I made the change described earlier. Do you have suggestions on how to shutdown properly in order to get the NextWakeupTime written to setup.conf? I run VDR as a daemon and shut it down in shutdown script by calling start-stop-daemon (I use Ubuntu Feisty). -Petri ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] New shutdown procedure not working as expected
Udo Richter wrote: > > In any case, try dumping the return value to syslog, I would really like > to know what additional flag is set on the return value. > I got 6, 9 and 11 when I did some debugging earlier. -Petri ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] New shutdown procedure not working as expected
Udo Richter wrote: > Petri Helin wrote: >> Udo Richter wrote: >>> In any case, try dumping the return value to syslog, I would really like >>> to know what additional flag is set on the return value. >>> >> I got 6, 9 and 11 when I did some debugging earlier. > > I *think* that these are kill signals received by the child process. > Which is strange, as the child does an exit immediately. (Unless you're > somewhere between 1.5.1 and 1.5.3 - this changed in 1.5.4) > > 6 is SIGABRT, 11 is SIGSEGV and 9 is SIGKILL. > > I use version 1.5.6. I tested with my normal shutdown script and with a script that just does an "exit 0". No difference there. Can the script itself have any influence on the return value? -Petri ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] EPG - info - length
JJussi wrote: > Hi! > > Have anybody noticed, but atleast here in Finland, EPG information (the text > what tells f.ex. what tells about movie) is so long that it's "cut short" > from middle of world, most of time. > Is because the string in VDR what holds that information is too short or...? > IIRC they put the information in wrong field. For some obscure reason they use the short event descriptor for the main part of the event description when they should be using the extended event descriptor. the only way to fix that is to complain to the source (read Digita and broadcast companies). Or use an external epg input like xmltv. -Petri ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Mid range CPU choice
On 8/21/07, covert covert <[EMAIL PROTECTED]> wrote: > On 8/21/07, Nicolas Huillard <[EMAIL PROTECTED]> wrote: > > There are lots of EPIA mobos (Mini-ITX for factor) with fanless CPUs > > around. With these, you get only one PCI slot, but everything is > > integrated on the motherboard. > > Using a good laptop-like power block (efficient and fanless), you can > > have a really silent setup (one slow fan for the whole system). > > > > At least 2 PCI slots is a must. I want 2 x DVB-S, 1 x DVB-T, 1 x > Analog TV. I plan to do this with 1 all in one card and a single > Skystar2 for the second DVB-S tuner. > You can use two PCI cards with VIA mobos by using a PCI riser with two slots. I had such a solution with two DVB-C cards. But if you want crunch and muscle, VIA is definitely not the way to go. For Intel side I can share you the information that E4*-series is better in the way that they allow you to use multiplier 6, which results with standard fsb to 1200MHz when idling. For example E6300 will idle at 1600 MHz. But you should also take care when choosing the motherboard, because undervolting is the most efficient way to reduce heat and some mobos (namely all Asrocks) do not allow undervolting. -Petri ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] H.264 updates for VDR-1.5.9
Reinhard Nissl wrote: > Hi, > > the attached vdr-1.5.9-h264.patch adds H.264 support to VDR's remuxer. > The changes to earlier releases are: > > - H264::cParser has been enhanced to provide information for > H264::cContext::GetFramesPerSec() and therefore outsourced > into separate files. > - cVideoRepacker generates Access Unit Delimiters in case they > are not part of the stream. Should this patch make it possible to record H.264 encoded stream? I have applied the patch and can see in the channels menu that Canal+ HD Film uses H.264 codec, but I can not record the channel (nor watch it...). -Petri ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
