[vdr] dropping broken PES packet

[Vidar Tyldum]

After upgrading to 1.7.21 I have started having these issues where the
picture freezes on the frontend from time to time. It can last from 30
seconds to several minutes. Looking at the log I see these errors repeating
themselves:
vdr-sxfe[9003]: [9014] [demux_vdr] ts2es: payload not PES ?
vdr-sxfe[9003]: [9014] [demux_vdr] ts2es: dropping broken PES packet

VDR itself is not logging anything particular when this happens, despite
being at loglevel 3.

I tried just streaming to VLC and the same thing happends, which means it's
nota frontend issue. I cannot open the OSD when the problem is 'active'.

If the watchdog is enabled it will cause a restart of VDR.

If the picture comes back before the watchdog kicks inn I get:
vdr-sxfe[31073]: [3] [demux_vdr] New PTS: 7275023756 (VIDEO)

Any ideas on how to proceed to debug this?

Source is DVB-C, 1.7.17 was my previous version where I did not have this
issue. Using precompiled packages from
http://ppa.launchpad.net/yavdr/stable-vdr/ubuntu


-- 
Vidar Tyldum
  vi...@tyldum.com   PGP: 0x3110AA98

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

[vdr] Unable to record 2 dvb-t channels

[Marc]

Hi,

I use vdr (1.7.21) with xvdr (git version). I can't record 2 channels,
vdr start the recording but the file is empty and after 30 seconds, vdr
throws an emergency exit :
Nov 25 12:18:34 myhost vdr: [12866] recording thread started (pid=10925,
tid=12866)
Nov 25 12:18:34 myhost vdr: [10949] XVDR: Recordings state changed (6)
Nov 25 12:18:34 myhost vdr: [10949] XVDR: Requesting clients to reload
recordings list
Nov 25 12:19:05 myhost vdr: [12866] ERROR: video data stream broken
Nov 25 12:19:05 myhost vdr: [12866] emergency exit request ignored
according to setup

When I try to watch these streams with xineliboutput, the stream starts
only after 30 seconds and I have only the sound :
[19021] [input_vdr]  OSDCMD
[19021] [input_vdr]  OSDCMD
[19021] [input_vdr]  OSDCMD
[19021] [input_vdr]  DISCARD 114940568 61162
[19022] [demux_vdr] input->read_block() was interrupted
[19021] [input_vdr]  STILL 0
[19022] [input_vdr]   DISCARD 114940568 61162
[19022] [input_vdr] wait_stream_sync: discard_index 114940568 != curpos
114869128 ! (diff 71440)
[19022] [input_vdr] wait_stream_sync: streams synced at 114940568/114940568
[19021] [input_vdr]  LIVE 0
[19022] [input_vdr]   BLANK
prebuffer=14400 pts
[19021] [input_vdr]  STILL 0
vdpau_set_property: property=0, value=0
vo_vdpau: deinterlace: none
[19022] [input_vdr] wait_fifos_empty: video 0, audio 0
prebuffer=2000 pts
prebuffer=14400 pts
[19021] [input_vdr]  STILL 0
[19021] [input_vdr]  LIVE 1
prebuffer=14400 pts
[19021] [input_vdr]  TRICKSPEED 1
[19021] [input_vdr]  STILL 0
[19022] [demux_vdr] PAT: program changed, flushing demuxer
[19022] [demux_vdr] PMT changed, resetting demuxer
[19022] [demux_vdr] New PTS: 7327138046 (AUDIO)
[19022] [demux_vdr] audio stream changed:  -> 0301
*** The stream  doesn't start
[19021] [input_vdr]  OSDCMD
[19021] [input_vdr]  OSDCMD
*** After 30 seconds, the audio start but no picture

An example with an other channel of the same provider (France Television
Group, the 2 wrecked channels are from the same provider):
[19021] [input_vdr]  OSDCMD
[19021] [input_vdr]  OSDCMD
[19021] [input_vdr]  OSDCMD
[19021] [input_vdr]  DISCARD 56596648 30119
[19022] [demux_vdr] input->read_block() was interrupted
[19021] [input_vdr]  STILL 0
[19021] [input_vdr]  LIVE 0
prebuffer=14400 pts
[19021] [input_vdr]  STILL 0
vdpau_set_property: property=0, value=0
vo_vdpau: deinterlace: none
[19022] [input_vdr]   DISCARD 56596648 30119
[19022] [input_vdr] wait_stream_sync: streams synced at 56596648/56596648
[19022] [input_vdr]   BLANK
[19022] [input_vdr] wait_fifos_empty: video 0, audio 0
prebuffer=2000 pts
prebuffer=14400 pts
[19021] [input_vdr]  STILL 0
[19021] [input_vdr]  LIVE 1
prebuffer=14400 pts
[19021] [input_vdr]  TRICKSPEED 1
[19021] [input_vdr]  STILL 0
[19022] [demux_vdr] PAT: program changed, flushing demuxer
[19022] [demux_vdr] PMT changed, resetting demuxer
[19022] [demux_vdr] New PTS: 6415996599 (VIDEO)
[19022] [demux_vdr] audio stream changed:  -> 0341
[19021] [input_vdr]  HDMODE 1
[19021] [input_vdr] WARNING: xine-engine setting
"engine.buffers.video_num_frames":22 is too small for some HD channels
vdpau_set_property: property=0, value=1
vo_vdpau: deinterlace: temporal_spatial
Broken NAL, skip it.
ffmpeg_audio_dec: increasing buffer to 98304 to avoid overflow.
Allocate 4 reference frames
Create decoder: vdp_device: 1, profile: 8, res: 1920x1080
vo_vdpau: deinterlace: temporal
vo_vdpau: set_scaling_level=0
vo_vdpau: enabled features: inverse_telecine=1
vo_vdpau: disable noise reduction.
vo_vdpau: disable sharpness.
vo_vdpau: vdpau_update_csc: hue=0.00, saturation=1.00,
contrast=1.00, brightness=0.00, color_standard=1 studio_levels=0
vo_vdpau: skip_chroma = 0
vo_vdpau: background_color = 0
[19021] [input_vdr]  OSDCMD
[19021] [input_vdr]  OSDCMD

Regards,

Marc.

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] dropping broken PES packet

[Vidar Tyldum]

I forced a core dump and did a backtrace on VDR when the problem occurred:
(gdb) bt
#0  0xb77ec424 in __kernel_vsyscall ()
#1  0xb77a30b9 in __lll_lock_wait () from /lib/i386-linux-gnu/libpthread.so.0
#2  0xb779e54b in _L_lock_791 () from /lib/i386-linux-gnu/libpthread.so.0
#3  0xb779e371 in pthread_mutex_lock () from /lib/i386-linux-gnu/libpthread.so.0
#4  0x0811da32 in cMutex::Lock() ()
#5  0xb5df6928 in Lock (this=0xb0d7ffc8) at ../../../include/vdr/thread.h:91
#6  cLogger::Down (this=0xb0d7ffc8) at cam.c:407
#7  0xb5dfaf39 in cCam::Stop (this=0xb0d456a8) at cam.c:2315
#8  0xb5dfb04e in cCam::Tune (this=0xb0d456a8, channel=0xb0d5229c) at cam.c:2284
#9  0xb5e00e47 in cScDvbDevice::SetChannelDevice (this=0xb42a9da0,
Channel=0xb0d5229c, LiveView=false) at device-tmpl.c:184
#10 0x080ac537 in cDevice::SetChannel(cChannel const*, bool) ()
#11 0x080ac881 in cDevice::SwitchChannel(cChannel const*, bool) ()
#12 0x080beae0 in cEITScanner::Process() ()
#13 0x0812a3c8 in main ()

Is the problem CAM related?

Den 25.11.2011 12:23, skrev Vidar Tyldum:
> After upgrading to 1.7.21 I have started having these issues where the
> picture freezes on the frontend from time to time. It can last from 30
> seconds to several minutes. Looking at the log I see these errors repeating
> themselves:
> vdr-sxfe[9003]: [9014] [demux_vdr] ts2es: payload not PES ?
> vdr-sxfe[9003]: [9014] [demux_vdr] ts2es: dropping broken PES packet
> 
> VDR itself is not logging anything particular when this happens, despite
> being at loglevel 3.
> 
> I tried just streaming to VLC and the same thing happends, which means it's
> nota frontend issue. I cannot open the OSD when the problem is 'active'.
> 
> If the watchdog is enabled it will cause a restart of VDR.
> 
> If the picture comes back before the watchdog kicks inn I get:
> vdr-sxfe[31073]: [3] [demux_vdr] New PTS: 7275023756 (VIDEO)
> 
> Any ideas on how to proceed to debug this?
> 
> Source is DVB-C, 1.7.17 was my previous version where I did not have this
> issue. Using precompiled packages from
> http://ppa.launchpad.net/yavdr/stable-vdr/ubuntu
> 
> 


-- 
Vidar Tyldum
  vi...@tyldum.com   PGP: 0x3110AA98

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr