[vdr] Tuning failures for transponder-locked tuners (VDR 1.4.7)
I have a VDR box with three DVB-T tuners.. All cards are saa7146+tda10045 -based budget cards. I have forced the cards to specific transponders in channels.conf. Basicly VDR never has to switch transponders, all channels are always tuned. However, sometimes one of the cards looses sync and doesn't re-tune.. It's not always the same card, can be any of the three. The problem is that VDR doesn't recover from this. If there is a timed recording going on that jammed tuner, VDR keeps on restarting over and over again, which effectively ruins recordings on all other channels as well. VDR restarting doesn't solve the problem, the card still doesn't tune. I have tried killing VDR when the tuner is jammed, and then try tuning with tzap.. Tuning fails for the already tuned channel, but if I simply tune to another transponder and then back, it tunes fine. So apparently the problem is that VDR doesn't even try re-tuning because the tuners are locked to specific transponders in channels.conf.. I'm actually using VDR 1.4.7, I know it's old but otherwise it's working fine. Has there been any changes in this area in recent versions? So is it likely to fix my problem if I upgrade to latest developer version for example? -- Teemu Suikki http://www.z-power.fi/ ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Tuning failures for transponder-locked tuners (VDR 1.4.7)
Teemu, I had a similar problem with budget Freecom / WT-220U USB stick tuners. I usually had to swap multiplex/transponder to get them to re-tune reliably. I observed that if they lost tuning, vdr made them re-try (which I saw in the log) but eventually would bomb out if it couldn't tune, which is maybe what you're seeing? Originally I logged it as a DVB driver bug, but the maintainer said it was an application bug. I found the following, which requires you to patch/rebuild vdr from source. Basically it just adds a small delay to the tuning process, and it works 100% for me. I had to do this on 1.4.7 and carried it over in 1.6.0 also - so no, vanilla 1.6 won't help you. It would be good if something equivalent was in vanilla VDR but I suppose it slows some systems by a fraction of a second when tuning. Perhaps a budget card option? http://www.vdr-portal.de/board/thread.php?postid=639048 The actual patch is at http://tafe.unkelhaeusser.de/vdr/dvbdevice.c.patch HTH ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Tuning failures for transponder-locked tuners (VDR 1.4.7)
On 10/29/08 12:40, Richard F wrote: Teemu, I had a similar problem with budget Freecom / WT-220U USB stick tuners. I usually had to swap multiplex/transponder to get them to re-tune reliably. I observed that if they lost tuning, vdr made them re-try (which I saw in the log) but eventually would bomb out if it couldn't tune, which is maybe what you're seeing? Originally I logged it as a DVB driver bug, but the maintainer said it was an application bug. I found the following, which requires you to patch/rebuild vdr from source. Basically it just adds a small delay to the tuning process, and it works 100% for me. I had to do this on 1.4.7 and carried it over in 1.6.0 also - so no, vanilla 1.6 won't help you. It would be good if something equivalent was in vanilla VDR but I suppose it slows some systems by a fraction of a second when tuning. Perhaps a budget card option? http://www.vdr-portal.de/board/thread.php?postid=639048 The actual patch is at http://tafe.unkelhaeusser.de/vdr/dvbdevice.c.patch I'm afraid I don't quite see why the applications would need to do some arbitrary sleep here. If the driver requires this, why doesn't it do it by itself? Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] Antwort: Re: OT: VDR for grandparents
[EMAIL PROTECTED] schrieb am 26.10.2008 16:57:51: has anyone on this list any experience in setting up VDR for older people like grandparents? It would be nice, if she/he could share her/his experience or point me to information on the WWW. I have experience with second best thing after grandparents. A totally clueless user. Since I have setup VDR as the backend sitting near the dish, and added a MediaMVP box next to the TV set, she can use it, record stuff, delete recording, everything. We are using the Hauppauge MediaMVP together with the vdr-plugin-vompserver on the VDR system. Another vote for MediaMVP and vompserver. The user interface is IMO easier to operate than commercial PVRs such as the Humax, and the noisy recorder can be kept out of the living room. While I have not had experience with this myself, I do know a few users who've set up VDR for (grand)parents and wives. From the feedback I've heard, VDR works really well in those scenarios which I think says a lot! ;) I can second that. I set up a box for my brothers family almost 3 years ago and it still running with the ancient 1.3.24. The box is actually offline, 250km away and only needed some checks every few months at first. Now it's like a VW beatle: it runs, and runs, and runs ... He actually dont't care about the system setup, he doesn't even have the root password either ;-)) There seems to be some keys to success. 1.Chosing a stable(unfancy) plattform. I used an seemingly ancient PIII OEM(Siemens) plattform. These OEM systems are usually rock stable, quite quiet and relativly low power. With the stable TT-FF premium card there is also a stable plattform. Make sure that your system design is good (cooling, I/O attachment). Invest some time in the optical design (doesn't need to be fancy eigher) for WAF. Low WAF creates problems even while everything runs nicely ;-) 2.Limit yourself Only add the minimum set of plugins for doing the daily routines. Keep things as simple as possible. Sort the GUI to have the daily routines on the initial menu. Move special features into submenus to not bother the user with it. Use a stable distribution that is flexible enought for the task. I started with c't vdr distribution (Debian !) but hand tuned a lot of the distribution components for easy use and to fix some issues after some testing. Don't bother about latest versions. Once the system runs nicely only change what is broken or adding a needed feature. 3.testing, testing, testing Problem is not VDR and it's functions. Problem is to make the components working together in everydays tasks. You should use the system for the NOB-user by yourself for some time before delivery. Test the features and test it again after some weeks/months time. Crux is mostly the scripts and system setup beside VDR. Think about automated clean-up of log files and similar stuff. I had quite some fun with MySQL thrashing the HD and forgetting to delete the garbage. Some scripting beside VDR is also a pain, like vdrconvert and burn creating directories. In a single HD configuration the temp directories for those may end up in the video directory tree. But VDR don't like empty directories. So make shure scripts creating them also leaves a dummy file in it. Otherwise VDR cleans up the directory that burn/vdrconvert need for temporary data causing spurious fails of those plugins. regards Peter ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Tuning failures for transponder-locked tuners (VDR 1.4.7)
On Mittwoch, 29. Oktober 2008, Teemu Suikki wrote: I have a VDR box with three DVB-T tuners.. All cards are saa7146+tda10045 -based budget cards. [cut] I have tried killing VDR when the tuner is jammed, and then try tuning with tzap.. Tuning fails for the already tuned channel, but if I simply tune to another transponder and then back, it tunes fine. So apparently the problem is that VDR doesn't even try re-tuning because the tuners are locked to specific transponders in channels.conf.. 1. So for example using cardX. 2. This card gets tuned to channel C1 by VDR. Once it loses the lock and there is an ongoing recording VDR commits suicide and hopes the problem fixes magically (maybe vdr-launch-script reloads drivers ...) but it does not. 3. You kill VDR and run tzap C1 That also does not lock. But tzap C2 tzap C1 does make it lock. How should VDR know, it need to lock another frequency first to re-get a lock? This clearly is a driver/hw bug. And you can only fix it by modifying the driver. So you best report this to the linuxtv-dvb mailinglist and attach more info: exact used hardware, dmesg logs, ... Regards Matthias ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Tuning failures for transponder-locked tuners (VDR 1.4.7)
Richard F wrote:
Teemu,
I had a similar problem with budget Freecom / WT-220U USB stick tuners.
I usually had to swap multiplex/transponder to get them to re-tune reliably.
I observed that if they lost tuning, vdr made them re-try (which I saw in the
log)
but eventually would bomb out if it couldn't tune, which is maybe what you're
seeing?
Originally I logged it as a DVB driver bug, but the maintainer said it was an
application bug.
I found the following, which requires you to patch/rebuild vdr from source.
Basically it just adds a small delay to the tuning process, and it works 100%
for me.
I had to do this on 1.4.7 and carried it over in 1.6.0 also - so no, vanilla
1.6 won't help you.
It would be good if something equivalent was in vanilla VDR but I suppose it
slows
some systems by a fraction of a second when tuning.
Perhaps a budget card option?
http://www.vdr-portal.de/board/thread.php?postid=639048
The actual patch is at http://tafe.unkelhaeusser.de/vdr/dvbdevice.c.patch
If the .1s delay helps it's probably some kind of race, and if restarting
the app (ie close/open/tune sequence) does not make the device work it is
clearly a driver bug. Adding random delays to apps in order to work around
driver bugs is not the right solution.
Fixing the driver would be, but if that's not an option, you could add the
.1s delay to the open-demux path of the driver; that way only users of that
driver would suffer until it's fixed properly.
If the driver does recover after some time, you could do something like this
instead of the above patch:
int cDvbDevice::OpenFilter(u_short Pid, u_char Tid, u_char Mask)
{
const char *FileName = *cDvbName(DEV_DVB_DEMUX, CardIndex());
int f = open(FileName, O_RDWR | O_NONBLOCK);
+ if (f==-1) {
+ usleep(10);
+ f = open(FileName, O_RDWR | O_NONBLOCK);
+ }
if (f = 0) {
dmx_sct_filter_params sctFilterParams;
to limit the cost of the delays somewhat, but it won't work if the first
open call messes up the driver...
artur
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] [ANNOUNCE] fEPG 0.4.1
Hi, A new version of fEPG is now available at http://www.fepg.org Description --- fEPG is a plugin for VDR that provides a graphical way of viewing and navigating through EPG data. Almost all aspects of the user interface are configurable. Changes --- 2008-10-29: Version 0.4.1 - Fixed error in grid drawing code; 'No Info' entries were not always properly determined. - Key names are now being translated. - Added Italian translations (thanks to Diego Pierotto). - Added Spanish translations (thanks to Manuel Gomez). - Now only drawing the first line of an event name if row height is insufficient for two. - Selected event is now properly updated when the time changes. - Several minor cosmetic fixes. - Fixed prototype of function 'Darken'. - Cleaned up '#include's - Updated license information. Regards, Alex Lasnier ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
