vdr

vdr@linuxtv.org

2 participants
6731 discussions

[Fwd: Re: [vdr] Patch: dxr3plugin OSD don't turn pink]
by anthony hornby 31 Mar '05

31 Mar '05

Hi Ville, finally got around to trying out the Fedora 3 rpms - they work well - thanks :-) Still have the odd problem with 1.3.17 where I have to select a channel press "switch" then select it again ( from the "what's on now" menu only - oddly) and then press switch again to get it to change channel. Any suggestions on how to track down what might be causing this? I have had this problem with all versions of vdr post 1.3.12 - it is not related to your rpms. Also saw the fix for the pink OSD - I modified the vdr-dxr3 src rpm from you to incorporate this patch, rebuilt it and it works well - great, that's one major annoyance for me fixed. Thanks again for the rpms and all the great work. Regards Anthony. On Thu, 2005-03-31 at 00:16 +0300, Ville Skyttä wrote: > On Wed, 2005-03-30 at 13:48 퍭㐱ꫭ詰骧૨뗠ⶵ꜡秛梶᢬ posting is a patch which fixes the odd problem making > > the osd > > turn pink after returning from mplayer or after hardware-reset of the > > dxr3-card. > > I posted this fix in a german-vdr-forum a couple of months ago and it > > works for other users there, too. I haven't found the time to post it > > here (other users hadn't either:) )... so, > > here it is. > > Yep, works for me too, thanks. > > However, the patch gave me the creeps, so I dug a little deeper. I > found that the only thing needed to fix the pink OSD here was to comment > out the "m_users[i] == 0" test in AddColor() and unconditionally setting > m_changed to true there, or to set it to true in GetIndex() when the > color was found. Both of those were still ugly. Then I noticed that > the counters in m_users were not being reset to zero when they IMO > should have been, and came up with the attached patch which I think > would be more appropriate. (Also applied to the vdr-dxr3-0-2 branch in > CVS.) > > With this one applied, I no longer get pink OSD after returning from the > MPlayer plugin. But after "Reset DXR3", the OSD is still momentarily > pink immediately after; things return to normal when the OSD is > hidden/shown again. > > Reviews/testing welcome... > _______________________________________________ > vdr mailing list > vdr(a)linuxtv.org > http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

1 0

Re: Re: [vdr] vdr-xine: what's wrong with this piece of code--
by peter_weber69 31 Mar '05

31 Mar '05

> >>>peter_weber69 wrote: > >>> > >>>bin aus den Osterferien zurück [...] > >> > >>Das Schnittmarken-Problem ist nach meinem Patch an VDR nicht mehr > > > > [scorchio] > > > > Was that meant to be private? > Yes, it was. Sorry! I'm sorry too, it was my silly mistake peter Benachrichtigung bei E-Mail Empfang! - http://mail.lycos.de/app/lycosinside/setupLI.exe

1 0

scanning frequencies for analogtv
by Helmut Kodritsch 30 Mar '05

30 Mar '05

hi, i want to use my analog TV card (bt78) with help of the analogtv-plugin based on a c't-vdrdevel1.3.23 machine. Is there any tool out to scan analog frequencies? tia Helmut

1 0

How to get a notification of a completed transponder scan?
by Luca Olivetti 30 Mar '05

30 Mar '05

Currently both the channelscan and the actuator plugin offer an option to scan a complete satellite by tuning to each transponder and then waiting for 10 seconds. Is it possible to get a notification when all of the transponder data has been received? (I's assume it'd take less than 10 seconds, so a complete satellite scan should be noticeably faster). TIA -- - Yo también quiero una Europa libre de Patentes de Software - - I want a Software Patents Free Europe too! And you? - --------------------------------------------------------------- EuropeSwPatentFree - http://EuropeSwPatentFree.hispalinux.es

2 18

vdr-xine: is this code thread safe?
by Reinhard Nissl 30 Mar '05

30 Mar '05

Hi, while facing deadlocks in xine I've written an emulation of an recursive mutex, as xine cannot use non posix extensions to be portable. The code below seems to work but are there any errors left? What happens if the thread owning the lock is cancelled? Feel free to send me your improvements. Thanks! /* * xine_rmutex - xine's recursive mutex emulation */ struct xine_rmutex_s { pthread_mutex_t access_rmutex; pthread_cond_t unlock_cond; int lock_count; pthread_t lock_owner; }; typedef struct xine_rmutex_s xine_rmutex_t; int _x_rmutex_init(xine_rmutex_t *rmutex); int _x_rmutex_lock(xine_rmutex_t *rmutex); int _x_rmutex_timedlock(xine_rmutex_t *rmutex, int ms_to_time_out); int _x_rmutex_unlock(xine_rmutex_t *rmutex); int _x_rmutex_destroy(xine_rmutex_t *rmutex); #include "assert.h" int _x_rmutex_init(xine_rmutex_t *rmutex) { pthread_mutex_init(&rmutex->access_rmutex, 0); pthread_cond_init(&rmutex->unlock_cond, 0); rmutex->lock_count = 0; return 0; } int _x_rmutex_lock(xine_rmutex_t *rmutex) { return _x_rmutex_timedlock(rmutex, -1); } int _x_rmutex_timedlock(xine_rmutex_t *rmutex, int ms_to_time_out) { int r = 0; struct timespec abstime; { struct timeval now; gettimeofday(&now, 0); abstime.tv_sec = now.tv_sec + ms_to_time_out / 1000; abstime.tv_nsec = now.tv_usec * 1000 + (ms_to_time_out % 1000) * 1e6; if (abstime.tv_nsec > 1e9) { abstime.tv_nsec -= 1e9; abstime.tv_sec++; } } pthread_mutex_lock(&rmutex->access_rmutex); assert(rmutex->lock_count >= 0); while (0 == r && rmutex->lock_count > 0 && !pthread_equal(rmutex->lock_owner, pthread_self())) { if (ms_to_time_out < 0) pthread_cond_wait(&rmutex->unlock_cond, &rmutex->access_rmutex); else r = pthread_cond_timedwait(&rmutex->unlock_cond, &rmutex->access_rmutex, &abstime); } if (0 == r) { rmutex->lock_owner = pthread_self(); rmutex->lock_count++; } pthread_mutex_unlock(&rmutex->access_rmutex); return r; } int _x_rmutex_unlock(xine_rmutex_t *rmutex) { int r = 0; pthread_mutex_lock(&rmutex->access_rmutex); assert(rmutex->lock_count > 0); assert(pthread_equal(rmutex->lock_owner, pthread_self())); rmutex->lock_count--; if (rmutex->lock_count == 0) pthread_cond_broadcast(&rmutex->unlock_cond); pthread_mutex_unlock(&rmutex->access_rmutex); return r; } int _x_rmutex_destroy(xine_rmutex_t *rmutex) { pthread_cond_destroy(&rmutex->unlock_cond); pthread_mutex_destroy(&rmutex->access_rmutex); return 0; } Bye. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:rnissl@gmx.de

1 0

Re: Re: [vdr] vdr-xine: what's wrong with this piece of code-- threadingissue?
by peter_weber69 30 Mar '05

30 Mar '05

> Von :: Reinhard Nissl <rnissl(a)gmx.de> > An :: Klaus Schmidinger's VDR <vdr(a)linuxtv.org> > Betreff: Re: [vdr] vdr-xine: what's wrong with this piece of code-- threadingissue? > Datum: Fri, 25 Mar 2005 23:54:43 +0100 > <pre>Hi, > Rantanen Teemu wrote: > >>This typically happens when moving cutting marks, and I'm > >>investigating this already. > >> > >>Expect it for 0.8.0, but the next release will still be 0.7.3. > > > > Looking forward to both 0.8.0 and 0.7.3 ... > > > > In my experience the most problems I've had are starting/ending > > recording, and all rewinds. At these points may happen that xine > > disconnects. Not very often but sometimes. When xine disconnects VDR > > will "play" the recording really fast and it's minutes past the place > > when xine reconnects. I've had no problems with cutting marks... > Please apply the attached patch to vdr-1.3.23 and tell me, whether there > is any improvement. At least there was one for me ;-) > Bye. > -- > Dipl.-Inform. (FH) Reinhard Nissl > mailto:rnissl@gmx.de > </pre><pre>_______________________________________________ > vdr mailing list > vdr(a)linuxtv.org > <a href=http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr>http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr</a></pre> Hi Reinhard, bin aus den Osterferien zurück, diesen Patch werde ich heute Abend auch testen, bin schon neugierig. Besteht Dein Problem mit Schnittmarken noch, oder ist dies mit Teemu und dem deadlock fix gelöst? lg Peter Benachrichtigung bei E-Mail Empfang! - http://mail.lycos.de/app/lycosinside/setupLI.exe

3 3

[ANNOUNCE] vdr-osdteletext-0.5-pre1
by Marcel Wiesweg 30 Mar '05

30 Mar '05

Hi, thanks to the work of Udo Richter I may announce you a preview version of the osdteletext plugin. This version features an extensive rewrite of the display code. This makes the display substantially faster and offers a clean architecture for future development. Additionally, it aims at strict adherence to the standard. Such a rewrite offers many ways for new bugs, so this is a preview release and any bug reports are welcome. The new version is available from: http://www.wiesweg-online.de/linux/vdr/vdr-osdteletext-0.5-pre1.tgz Marcel

4 9

HDTV -> mpeg4
by Grégoire Favre 30 Mar '05

30 Mar '05

Hello, just done a small try to convert an Euro1080 FTA preview to mpeg4, with a bitrate of 2500 with mencoder : quality was very bad... Anyone already converted (and keeping the resolution) HDTV with a perfect quality to mpeg4 ? I would be interested in the parameters... -- Grégoire Favre ___________________________________________________________________ http://magma.epfl.ch/Gregoire.Favre mailto:Gregoire.Favre@gmail.com

11 23

RE: [vdr] Update for NTSC problem
by Vladimir Shved 30 Mar '05

30 Mar '05

If you look inside of insmod.sh script, you'll see whats loaded and unloaded, I actually had to comment out some modules to keep it cleaner, like modules for USB DVB devices, etc. I think your primary concern right now is to make sure that your built-in DVB kernel modules are unloaded first, then you can worry about loading new ones. > -----Original Message----- > From: vdr-bounces(a)linuxtv.org [mailto:vdr-bounces@linuxtv.org] On Behalf > Of Andrey Vlassov > Sent: Tuesday, March 29, 2005 12:05 PM > To: Klaus Schmidinger's VDR > Subject: Re: [vdr] Update for NTSC problem > > Vladimir, > > I normally unload/load drivers before starting VDR but I never checked > that all drivers have been unloaded. > > I don't have full list drivers which related to DVB-S card to check what > modules should be unloaded. I guess that if I will check list of modules > which loaded with "./insmod.sh load" I should have this list. > > Do you think that this list should be correct and I will not miss any > important module? > > Andy

2 1

RE: [vdr] Re: xineplayer and vdr-xine-plugin
by Rantanen Teemu 30 Mar '05

30 Mar '05

Lucian Muresan wrote: > You might consider trying df_xine from DirectFB-extra if > DirectFB supports your graphics card on the client side. > Another possibility to avoid X would be softdevice with > DirectFB output... ...or you can use (networked) xine with dxr3 output and build a really low-price diskless vdr-terminal... Teemu

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

vdr