[vdr] problem in remux.c
Hi Klaus, I just wanted to make you aware of http://www.vdr-portal.de/board16-video-disk-recorder/board8-vdr-grundlagen/p1046411-vdr-coredump-und-speicherverletzungen-beim-umschalten/#post1046411 It is about a problem in remux.c Joerg ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] digitenne disturbance, poor reception or mistake in descrambling?
cedric.dew...@telfort.nl wrote: | I have setup vdr to receive and decode digitenne. I have used the following | manuals: | https://wiki.archlinux.org/index.php/VDR | https://wiki.archlinux.org/index.php/Digitenne | | | Sometimes i see some disturbance in the received image. I wonder if this | is due to poor reception, or by a problem of the decoding of the scrambled | channels. NED1, NED2 and NED3 are not scrambled, so if you get disturbances on those channels, you probably have poor reception. | Does vdr keep statistics of the reception quality? Is there any way I can | get diagnostics of the sc plugin? You can view the signal quality with the femon plugin, although not all DVB-T drivers report proper signal levels. It also shows whether a channel is encrypted or not (CA). The sc plugin will write messages to one of the log files in /var/log/. -- Dick ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Patch: Eliminate duplicate events when using xmltv2vdr
On 14.10.2011 16:25, Timo Eskola wrote: Hi, I started to use xmltv2vdr for some channels with poor EPG data. I do not want to use xmltv2vdr for all channels so I modified xmltv2vdr.pl http://xmltv2vdr.pl script to clear only the channels which will be grabbed with xmltv. The result was multiple EPG events for some programs. I found 2 issues in VDR code that caused this. 1. CLRE for a channel does not always clear all events. I compared CLRE for clearing all channels and noticed that it also clears events in timers. The patch will add this to CLRE for a channel. Adopted for version 1.7.23. 2. Second problem was that for some reason there are small differences in events times in EPG and xmltv. The patch find events close to the current event during EPG scan. I don't see why you are adding 'Duration / 2' here. The call to GetEventAround(StartTime + Around) that you have introduced in your patch searches for the event closest to the middle of the event in question. Shouldn't you look for an event closest to the *start* of the given event? That would obsolete the new 'Around' parameter and the actual call could simply be GetEventAround(StartTime) What I don't like about this whole thing is that it totally defeats the purpose of the eventsHashStartTime hash table, which has been introduced to make this lookup faster. I'm afraid I can't accept this patch because of this. Klaus Now I have proper program data from EPG and xmltv. http://www.tolleri.net/vdr/vdr/vdr-1.7.21-clre-epgscan.patch Maybe Klaus can have a look if the changes can be implemented in VDR. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
