Segfault when Attempting Playback of a Recording

[skd5aner <skd5aner@…>]

I have a recording that causes a segfault on the frontend the moment it begins playback. I've attached the backtrace and log (-v playback).

The recording was made from an HD-PVR connected to an STB. The Channels are changed on the STB via firewire and the channel changing scripts provided with myth. I have been able to watch other recordings via the HD-PVR, even of this program (obviously not this particular recording/episode), without a problem.

I'm running .22-fixes (r22954)

mythfrontend --version Please include all output in bug reports. MythTV Version : 22954 MythTV Branch : branches/release-0-22-fixes Network Protocol : 50 Library API : 0.22.20091023-1 QT Version : 4.5.2 Options compiled in:

linux debug using_oss using_alsa using_pulse using_backend using_directfb using_dvb using_firewire using_frontend using_hdhomerun using_hdpvr using_iptv using_ivtv using_joystick_menu using_lirc using_mheg using_opengl_video using_opengl_vsync using_qtwebkit using_v4l using_x11 using_xrandr using_xv using_bindings_perl using_bindings_python using_opengl using_vdpau using_ffmpeg_threads using_libavc_5_3 using_live using_mheg

Please let me know if there's any additional information I can provide which would help troubleshoot this.

[skd5aner <skd5aner@…>]

gdb output of segfault

[skd5aner <skd5aner@…>]

mythfrontend log with -v playback

[skd5aner <skd5aner@…>]

Some additional info:

I have a theory on the "cause" of the segfault. The recording is from an HD-PVR attached to my STB via component. The channels on the STB are changed via firewire and the 3250 channel changing script. When the STB changes channels, many times it takes several seconds for the video to "stabilize" and show the video properly (especially when changing from a channel with one resolution to a different resolution i.e., 720p --> 1080i). I've been able to get around this by adding a 5 second sleep to the channel changing script, which gives it enough time for the STB to stabilize the signal before the HD-PVR start to record. I believe there are other tickets out there related to signal monitor capabilities for the HD-PVR which will probably eventually solve these issues.

However - the intent of the ticket is to show that mythfrotend will segfault if trying to play a corrupted clip like this, rather than exiting playback gracefully.

I still have the recording around to test if necessary. Thanks!

[danielk]

Looks like an ffmpeg bug, if this doesn't cause the same problem with ffplay please reply on the mythtv-dev mailing list.

[skd5aner <skd5aner@…>]

I just wanted to report back and let you know that after upgrading to .23-fixes yesterday, these recordings play back properly, and no longer produce a segfault. There is still an obvious "glitch" at the start of the recording, but now myth handles it and continues to play.

This appears to be fixed.