Re: [vdr] Re: VDR 1.5.x + streamdev issue
On Tuesday 15 May 2007 10:33:21 Sebastian Frei wrote: > Am Dienstag, 15. Mai 2007 09:47:27 schrieb alexw: > > Hi, > > > > I am using VDR 1.5.2 in a streamdev only environment. With the vanilla > > CVS version of streamdev I am receiving a channel picture after every 2 > > channel switches. I did a bug report and schmirl did post a quick fix. > > Unfortunately it is not 100% perfect and time to time the picture does > > not pop up on the screen. Is anyone else experiencing such behavior? > > > > Mantis bug tracking system: > > http://www.vdr-developer.org/mantisbt/view.php?id=255 > > > > Cheers, > > > > Alex > > Hello, > > I have exactly the same problem. I'll try the client/device.c fix this > evening. > > S. > > ___ > vdr mailing list > vdr@linuxtv.org > http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr The client fix is a first step but it seems not to solve the complete issue. Sometimes the streamdev-client is not able to get the requested pid from the server. See logs: Good call with picture: ** AWK: SetPid, Pid=3521, Type=5, On=1, used=1 ** AWK: SetPid: no data connection -> OpenDvr() ** AWK: OpenDvrInt ** AWK: CloseDvrInt(): Closing DVR connection (ClientSocket.CloseDvr();DELETENULL(m_TSBuffer);) ** AWK: cStreamdevDevice::OpenDvrInt(): Connecting ... ++ AWK: SOCKET: SetPid call ** AWK: FIX: res=1 ** AWK: SetPid, Pid=3641, Type=6, On=1, used=1 ++ AWK: SOCKET: SetPid call ** AWK: FIX: res=1 === 1 ** AWK: OpenDvrInt ** AWK: cStreamdevDevice::OpenDvrInt(): DVR connection already open When a black screen occurs. ** AWK: SetPid, Pid=3521, Type=5, On=0, used=0 ++ AWK: SOCKET: SetPid call ** AWK: FIX: res=1 ** AWK: SetPid, Pid=3641, Type=6, On=0, used=0 ++ AWK: SOCKET: SetPid call ** AWK: FIX: res=1 ** AWK: CloseDvr ** AWK: CloseDvrInt(): Closing DVR connection (ClientSocket.CloseDvr();DELETENULL(m_TSBuffer);) ** AWK: SetPid, Pid=3522, Type=5, On=1, used=1 ** AWK: SetPid: no data connection -> OpenDvr() ** AWK: OpenDvrInt ** AWK: CloseDvrInt(): Closing DVR connection (ClientSocket.CloseDvr();DELETENULL(m_TSBuffer);) ** AWK: cStreamdevDevice::OpenDvrInt(): Connecting ... ++ AWK: SOCKET: SetPid call ++ AWK: SOCKET: Streamdev: Pid 3522 not available from 192.168.100.1:43654 ** AWK: FIX: res=0 ** AWK: SetPid: 0 pids left -> CloseDvr() ** AWK: CloseDvrInt(): Closing DVR connection (ClientSocket.CloseDvr();DELETENULL(m_TSBuffer);) ** AWK: SetPid, Pid=3522, Type=5, On=0, used=0 ++ AWK: SOCKET: SetPid call ++ AWK: SOCKET: Streamdev: Pid 3522 not available from 192.168.100.1:43654 ** AWK: FIX: res=0 ** AWK: SetPid: 0 pids left -> CloseDvr() ** AWK: CloseDvrInt(): Closing DVR connection (ClientSocket.CloseDvr();DELETENULL(m_TSBuffer);) ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] record plug-in..
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.. -- JJussi ___ 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] Xineliboutput: can achieve similar to softdevice's mgatv option?
On Tue, 2007-05-22 at 23:27 +0100, Alasdair Campbell wrote: > On 21/04/07, Petri Hintukainen <[EMAIL PROTECTED]> wrote: > > 2) "unscaled OSD": OSD and video are mixed by hardware using either > > colorkeying (no opacity) or hardware RGBA layer. OSD and video can be of > > different size and OSD can be blended outside of video frame. OSD size > > is constant (fbdev primary layer size, most likely 720x576). > > > > Xine-lib directfb driver supports method 2) for only some hardware with > > ARGB blending capacity. For the rest method 1) is used. > > > > I have experimental patch to support colorkeying mode when hardware does > > not support separate ARGB OSD layer, I just need to adjust it for recent > > xine-libs. > > I was wondering if you'd had a look at the patch you mentioned. I'd > happily lose osd opacity in favour of a consistant look to my vdr > experience - maybe others would too. I actually struggle to read some > of the text with low resolution channels. Yes, patch against xine-lib 1.1.6 is available from http://phivdr.dyndns.org/xine-lib/directfb/ - Petri ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] record plug-in..
On Freitag, 25. Mai 2007, JJussi 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.. Have a look at this describing how you can easily add own patches to the vdr ebuild: http://www.linuxtv.org/vdrwiki/index.php/Gentoo_VDR_own_patches Matthias PS: I think bigpatch has livebuffer included. -- Matthias Schwarzott (zzam) ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Feature requests
On 05/24/07 20:23, Pasi Juppo wrote:
> How about Klaus: do you see these features in a way that they get
> implemented in v1.5 -branch or maybe even in v1.4 -branch?
Version 1.4 is stable, so there won't be any such changes there.
In version 1.5 I'll lock at the various suggestions, patches, requests
as time permits...
Klaus
>>
>>> Date: Wed, 16 May 2007 20:06:35 +0300
>>> From: [EMAIL PROTECTED]
>>> To: vdr@linuxtv.org
>>> Subject: [vdr] Feature requests
>>>
>>> Hi,
>>>
>>> There are couple of annoying problems in vdr (v1.4.4 at least but most
>>> likely also in never ones):
>>>
>>> 1) If there is data stream problems in a channel VDR initiates emergency
>>> exit. This can be a temporary situation and gets fixed in few seconds to
>>> minutes.
>>>
>>> To solve this: change to other channel and infor user via OSD ("Channel
>>> not available" or something similar)
>>>
>>> 2) If there is no data comming from the channel (e.g. new decrypting
>>> card that needs to be updated first before it is ready to be used or for
>>> some reason the key is not available) VDR initiates emergency exit.
>>> Unnecessary action and user can do shutdown action if this is really a
>>> problem.
>>>
>>> To solve this: do not initiate emergency exit but show message in OSD
>>> ("Channel not available").
>>>
>>> Basically every unnecessary exit should be avoided because it does not
>>> provide any advantage to the user - just the opposite. Problems should
>>> be informed to the user and let user decide what to do in case of long
>>> lasting problem such as missing data stream.
>>>
>>>
>>> Minor feature that would be nice:
>>>
>>> 3) If there is a problem like crash with VDR and a timed recording did
>>> not get recorded VDR simply deletes the timer without notifying user. Of
>>> course the timer as such is useless but it would be nice to see that
>>> this and this recording was not done at all, was not started in time or
>>> was not recorded fully. This way the program can be re-recorded if/when
>>> it is broadcasted again.
>>>
>>> And if this information can be asked from VDR then epgsearch or other
>>> plugins can try to find missed programs again automatically.
>>>
>>> Br, Pasi
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR: Mantis bug tracking and a forum
Hi Steffen Barszus wrote: > bugtracking is for sure a nice tool, but for vdr alone i don't see the > use of it. Often its one of the components which is making problems (a > plugin/patch) and these are on thousend different locations (vdrportal Perhaps using Launchpad would be an idea then? It can be taught about projects and products, so you could have a vdr project with various products registered underneath it (ie vdr and all the components), then bugs can all be tracked in one place and easily moved from the vdr product to another component. It's kinda a shame that so much work goes into the VDR community, but it's spread around the place and hard to keep track of. Hosting code branches on Launchpad (or at least mirroring them there), keeping bugs there and so on, would be very useful, imho. Cheers, -- Chris Jones [EMAIL PROTECTED] www.tenshu.net ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Xineliboutput: can achieve similar to softdevice's mgatv option?
On 25/05/07, Petri Hintukainen <[EMAIL PROTECTED]> wrote: Yes, patch against xine-lib 1.1.6 is available from http://phivdr.dyndns.org/xine-lib/directfb/ Thanks so much for that! I'll be able to try it over the weekend and I'll let you know how I get on. many thanks -- A l a s d a i r C a m p b e l l r a g a w u @ g m a i l . c o m ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] record plug-in..
On Friday, 25. Mayta 2007 10:33, Petri Helin wrote: > It might be included in the bigpatch and that should be available > through Gentoo portage. Yes, it was.. BTW, I found "bug"... IF you define (at setup) your OSD to it's maximum size (+vertical and horisontal place to 5) AND you use --fullscreen parameter at vdr-sxfe.. Every time when you try to access OSD you get "30156 Segmentation fault /usr/bin/vdr-sxfe --audio=alsa:default --lirc=/dev/lircd --fullscreen --video=xv --syslog --aspect=16:9" OK, if you don't say --fullscreen you can open OSD and fix those values.. -- JJussi ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] Lightning destroyed my 4 DVB-S cards, what should I replace them with?
I had 1 FF and 2 budget cards in one PC, 1 FF card in the other. All 4 were destroyed by lightning this morning during a thunderstorm. What are the best cards to replace them with? In an earlier post, Klaus wrote that he is working on HDTV support and that he is using a TT-budget S2-3200. Would that be a good model to replace my 2 budget cards with? Does the driver work reliably now? Is there a supported FF HDTV card? If no, would the TT-premium S-2300 be the best choice? Should I still buy a FF card at all or does xine or softdevice work just as reliably by now? Thanks for any hints! :-) Carsten. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Lightning destroyed my 4 DVB-S cards, what should I replace them with?
Depends on what your needs are. Aside of that though, OUCH! I would be pissed if lightening took out my dvb card! Sorry to hear your bad luck! ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Lightning destroyed my 4 DVB-S cards, what should I replace them with?
On 25 May 2007, at 22:29, Carsten Koch wrote: Should I still buy a FF card at all or does xine or softdevice work just as reliably by now? Softdevice can give you really smooth fully interlaced SDTV output using a matrox G450 or G550 card, if your processor is fast enough. I'm using a pentium M at 1.733 MHz on an Aopen i915Ga-HFS and the processor runs at just below 40% CPU utilisation with passive cooling most of the time (the fan only starts when compiling etc). This setup might be sufficient for an HDTV setup in the future, by adding a PCIE gfx card, but it's hard to tell in advance. A full features card still uses much less CPU however, and can automatically reclock the output based on the timing of the input DVB stream. If you're not replacing any other component at this time I'd stick with FF cards, and then swap hardware when HDTV F solutions pop up in the future, or when the requirements are better know for proper 'soft' playback of HDTV content. -- Torgeir Veimo [EMAIL PROTECTED] ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
