[vdr] found the problem (in xineliboutput) Re: vdr-sxfe segfaults when listening to radiochannles (vdr-1.7.9/1.7.12)
Hi folks,
The segfault was introduced in xineliboutput's cvs between 28.01.2010
and 29.01.2010
The following change produces it:
--- xine_input_vdr.c.old2010-02-13 14:13:48.670894516 +0100
+++ xine_input_vdr.c2010-02-13 14:13:56.246141788 +0100
@@ -4,7 +4,7 @@
* See the main source file 'xineliboutput.c' for copyright information and
* how to reach the author.
*
- * $Id: xine_input_vdr.c,v 1.289 2010/01/18 20:39:36 phintuka Exp $
+ * $Id: xine_input_vdr.c,v 1.291 2010/01/28 11:50:07 phintuka Exp $
*
*/
@@ -62,6 +62,7 @@
#include xine/adjustable_scr.h
#include xine/osd_manager.h
+#include xine/xvdr_metronom.h
#include xine_input_vdr.h
#include xine_input_vdr_net.h
@@ -127,7 +128,7 @@
# include linux/unistd.h /* syscall(__NR_gettid) */
#endif
-static const char module_revision[] = $Id: xine_input_vdr.c,v 1.289
2010/01/18 20:39:36 phintuka Exp $;
+static const char module_revision[] = $Id: xine_input_vdr.c,v 1.291
2010/01/28 11:50:07 phintuka Exp $;
static const char log_module_input_vdr[] = [input_vdr] ;
#define LOG_MODULENAME log_module_input_vdr
#define SysLogLeveliSysLogLevel
@@ -313,6 +314,9 @@
uint8_t hd_stream : 1;/* true if current stream is HD */
uint8_t sw_volume_control : 1;
+ /* metronom */
+ xvdr_metronom_t*metronom;
+
/* SCR */
adjustable_scr_t *scr;
int speed_before_pause;
@@ -1813,7 +1817,7 @@
this-class-xine-config-update_num(this-class-xine-config,
video.output.xv_deinterlace_method,
method = 0 ? method : 0);
- xine_set_param(this-stream, XINE_PARAM_VO_DEINTERLACE, method ? 1 : 0);
+ xine_set_param(this-stream, XINE_PARAM_VO_DEINTERLACE, !!method);
return 0;
}
@@ -1935,7 +1939,7 @@
return 0;
}
-static int set_playback_speed(vdr_input_plugin_t *this, int speed)
+static int set_trick_speed(vdr_input_plugin_t *this, int speed, int backwards)
{
/* speed:
0 - show each abs(n)'th frame (drop other frames)
@@ -1955,6 +1959,8 @@
return -2;
}
+ this-metronom-set_trickspeed(this-metronom, backwards ? speed : 0);
+
if(speed 1 || speed -1) {
reset_scr_tuning(this, -1);
this-is_trickspeed = 1;
@@ -1981,6 +1987,11 @@
return 0;
}
+static int reset_trick_speed(vdr_input_plugin_t *this)
+{
+ return set_trick_speed(this, 1, 0);
+}
+
static void send_meta_info(vdr_input_plugin_t *this)
{
if(this-slave_stream) {
@@ -2263,10 +2274,10 @@
xine_usec_sleep(50*1000);
/* keep our own demux happy while playing another stream */
- set_playback_speed(this, 1);
+ reset_trick_speed(this);
this-live_mode = 1;
set_live_mode(this, 0);
- set_playback_speed(this, 1);
+ reset_trick_speed(this);
reset_scr_tuning(this, this-speed_before_pause =
XINE_FINE_SPEED_NORMAL);
this-slave_stream-metronom-set_option(this-slave_stream-metronom,
METRONOM_PREBUFFER, 9);
@@ -2902,7 +2913,7 @@
} else if(!strncasecmp(cmd, TRICKSPEED , 11)) {
err = (1 == sscanf(cmd+11, %d, tmp32)) ?
- set_playback_speed(this, tmp32) :
+ set_trick_speed(this, tmp32, !!strstr(cmd+13, Back)) :
CONTROL_PARAM_ERROR;
} else if(!strncasecmp(cmd, STILL , 6)) {
@@ -2938,13 +2949,13 @@
} else if(!strncasecmp(cmd, MASTER , 7)) {
if(1 == sscanf(cmd+7, %d, tmp32))
- this-fixed_scr = tmp32 ? 1 : 0;
+ this-fixed_scr = !!tmp32;
else
err = CONTROL_PARAM_ERROR;
} else if(!strncasecmp(cmd, VOLUME , 7)) {
if(1 == sscanf(cmd+7, %d, tmp32)) {
- int sw = strstr(cmd, SW) ? 1 : 0;
+ int sw = !!strstr(cmd, SW);
if(!sw) {
xine_set_param(stream, XINE_PARAM_AUDIO_VOLUME, tmp32);
xine_set_param(stream, XINE_PARAM_AUDIO_MUTE, tmp32=0 ? 1 : 0);
@@ -2994,7 +3005,7 @@
} else if(!strncasecmp(cmd, AUDIOSTREAM , 12)) {
if(!this-slave_stream) {
#if 0
- int ac3 = strncmp(cmd+12, AC3, 3) ? 0 : 1;
+ int ac3 = !strncmp(cmd+12, AC3, 3);
if(1 == sscanf(cmd+12 + 4*ac3, %d, tmp32)) {
pthread_mutex_lock(this-lock);
this-audio_stream_id = tmp32;
@@ -3016,7 +3027,7 @@
int old_ch = _x_get_spu_channel(stream);
int max_ch = xine_get_stream_info(stream,
XINE_STREAM_INFO_MAX_SPU_CHANNEL);
int ch = old_ch;
-int ch_auto = strstr(cmd+10, auto) ? 1 : 0;
+int ch_auto = !!strstr(cmd+10, auto);
int is_dvd = 0;
if (this-slave_stream this-slave_stream-input_plugin) {
@@ -4512,7 +4523,7 @@
flush_all_fifos (this, 0);
- set_playback_speed(this, 1);
+ reset_trick_speed(this);
this-live_mode = 0;
reset_scr_tuning(this, XINE_FINE_SPEED_NORMAL);
this-stream-emergency_brake = 1;
@@ -4697,7 +4708,7 @@
this-control_running = 0;
- local = this-funcs.push_input_write ? 1 : 0;
+ local = !!this-funcs.push_input_write;
[vdr] Channel not available - vdr 1.7.12 + streamdev
Hi I'm using vdr 1712 + patched cvs streamdev + xbmc pvr-testing2. While watching some dvb channels on xbmc I can see in vdr log strange logs as Feb 13 15:40:55 arvdr vdr: [2154] switching to channel 22 Feb 13 15:40:55 arvdr vdr: [2154] info: Channel not available! really I can watch this channel on xbms without any problem more details is here http://pastebin.com/m1378ef32 Goga ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] vdr 1.7.12 - TS continuity error
Hi I have vdr 1712 + vdr-xine 093 during of watching regular mpeg2 channels sometimes the sound is disappeared and in the logs I can see Feb 13 21:31:06 arvdr logger: fixing sound card drift by 1352 pts Feb 13 21:31:07 arvdr logger: 200 frames delivered, 0 frames skipped, 4 frames discarded Feb 13 21:38:17 arvdr vdr: [2884] TS continuity error (2) Feb 13 21:38:17 arvdr vdr: [2884] TS continuity error (6) Feb 13 21:38:17 arvdr vdr: [2884] TS continuity error (8) Feb 13 21:38:17 arvdr vdr: [2884] TS continuity error (4) Feb 13 21:38:17 arvdr vdr: [2884] TS continuity error (0) Feb 13 21:38:17 arvdr vdr: [2884] TS continuity error (2) Feb 13 21:38:17 arvdr vdr: [2884] TS continuity error (0) Feb 13 21:38:17 arvdr vdr: [2884] 3 cRepacker messages suppressed Feb 13 21:38:17 arvdr vdr: [2884] cAudioRepacker(0xC0): skipped 572 bytes while syncing on next audio frame Feb 13 21:38:17 arvdr vdr: [2884] TS continuity error (6) Feb 13 21:38:17 arvdr vdr: [2884] TS continuity error (10) Feb 13 21:38:17 arvdr logger: pcm_hw.c: snd_pcm_hw_delay() SNDRV_PCM_IOCTL_DELAY failed. Feb 13 21:38:17 arvdr logger: fixing sound card drift by 2413 pts Feb 13 21:38:17 arvdr logger: pcm_hw.c: snd_pcm_hw_delay() SNDRV_PCM_IOCTL_DELAY failed. Feb 13 21:38:17 arvdr logger: pcm_hw.c: snd_pcm_hw_delay() SNDRV_PCM_IOCTL_DELAY failed. Feb 13 21:38:18 arvdr logger: fixing sound card drift by 1956 pts Feb 13 21:38:19 arvdr logger: fixing sound card drift by 1466 pts Feb 13 21:38:29 arvdr logger: pcm_hw.c: snd_pcm_hw_delay() SNDRV_PCM_IOCTL_DELAY failed. Feb 13 21:38:29 arvdr logger: fixing sound card drift by 1250 pts Feb 13 21:38:29 arvdr logger: pcm_hw.c: snd_pcm_hw_delay() SNDRV_PCM_IOCTL_DELAY failed. Feb 13 21:38:35 arvdr logger: pcm_hw.c: snd_pcm_hw_delay() SNDRV_PCM_IOCTL_DELAY failed. Feb 13 21:39:16 arvdr last message repeated 2 times Feb 13 21:39:16 arvdr logger: fixing sound card drift by 1293 pts the full log here's http://pastebin.com/m413ba15d ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] [ANNOUNCE] Bandwidth limiting patch for FF cards (VDR-1.6)
Hi list, One of the known problems of the FF-DVB cards is the bandwidth limitation, that is addressed by the full-ts-mod for example. However, there are still enough FF cards out there that are not and wont ever be modded, and these cards tend to produce broken recordings on high bandwidth channels. I've written an experimental patch to avoid this by limiting the total bandwidth of the DVB card for recording and playback. In case that the bandwidth exceeds the allowed maximum, the playback gets reduced to I-frame only, audio only or complete suspend. Recording is not limited. The patch is still fresh and not well tested, so its only recommended for experimenting. Also, there's only a VDR-1.6 patch now, VDR-1.7 needs a rewrite for TS, and will follow later. For first experiments, set Setup - DVB - FF DVB Bandwidth Limit (kbit) to something around 14000-15000. Get it: http://www.udo-richter.de/vdr/patches.en.html#bandwidthlimit Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] Bandwidth limiting patch for FF cards (VDR-1.6)
Why not just use ttpci-bwlimit.diff to patch the driver? There is also a
patch floating around that lets you select what to block.
On 2/13/2010 1:15 PM, Udo Richter wrote:
Hi list,
One of the known problems of the FF-DVB cards is the bandwidth
limitation, that is addressed by the full-ts-mod for example. However,
there are still enough FF cards out there that are not and wont ever be
modded, and these cards tend to produce broken recordings on high
bandwidth channels.
I've written an experimental patch to avoid this by limiting the total
bandwidth of the DVB card for recording and playback. In case that the
bandwidth exceeds the allowed maximum, the playback gets reduced to
I-frame only, audio only or complete suspend. Recording is not limited.
The patch is still fresh and not well tested, so its only recommended
for experimenting. Also, there's only a VDR-1.6 patch now, VDR-1.7 needs
a rewrite for TS, and will follow later. For first experiments, set
Setup - DVB - FF DVB Bandwidth Limit (kbit) to something around
14000-15000.
Get it:
http://www.udo-richter.de/vdr/patches.en.html#bandwidthlimit
Cheers,
Udo
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
diff -ruN v4l-dvb.orig/linux/drivers/media/dvb/ttpci/av7110.c
v4l-dvb/linux/drivers/media/dvb/ttpci/av7110.c
--- v4l-dvb.orig/linux/drivers/media/dvb/ttpci/av7110.c 2009-09-07
16:09:09.0 -0400
+++ v4l-dvb/linux/drivers/media/dvb/ttpci/av7110.c 2009-09-07
15:13:48.0 -0400
@@ -817,7 +817,7 @@
return 0;
if (dvbdmxfilter-type == DMX_TYPE_SEC) {
- if (hw_sections) {
+ if (hw_sections ((dvbdmxfeed-pid = 0x122
dvbdmxfeed-pid = 0x176) || (dvbdmxfeed-pid = 0x21 dvbdmxfeed-pid =
0x64))) {
buf[4] = (dvbdmxfilter-filter.filter_value[0] 8) |
dvbdmxfilter-maskandmode[0];
for (i = 3; i 18; i++)
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] runvr extreme with different lirc device?
What's the proper way to configure a different lirc socket path with runvdr-extreme? Eg. I need to pass --lirc=/var/run/lirc/lircd to VDR, as this is the new default lirc socket path with lirc 0.8.6. -- -Tor ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
