Opened 10 years ago

Closed 10 years ago

#6716 closed defect (fixed)

frontend crashing when watching /certain/ recordings

Reported by: gareth.glaccum@… Owned by: Janne Grunau
Priority: minor Milestone: 0.22
Component: MythTV - General Version: head
Severity: medium Keywords: mythfrontend crash
Cc: Ticket locked: no

Description

Whilst investigating, this appears to only affect my 32bit clients This is using trunk, version 20856

Master backend is F11 (64bit), running trunk, 3x DVB-T capture cards (not frontend) Slave backend is F10 (64bit), running trunk, 1x DVB-S capture card (is main frontend)

Two clients both 32bit, 1 running F10, 1 running F11, all at trunk, same revision

As far as I can tell from testing: Any recording can be viewed on the slave backend. (F10, trunk, 64bit)

Any DVB-S recording can be viewed on the 32bit clients, (either F10 or F11 client) Only some DVB-T recordings can be views on the 32bit clients. It would seem that no recording from BBC Three, or BBC can be. Some can from Dave, (it seems to maybe be the quality of the recording?)

Effect is immediate after selecting the recording from the watch recordings, and results in a SEGFAULT. Not thoroughly tested, but appears to be the same when watching liveTV

I was going to send in a gdb trace when recompiled with debug, but the problem doesn't exist. When compiled with release (after previous test), the problem is still there, but when running under gdb, the program hangs instead of crashes (at normal crash point). Have recompiled with profile, and mythfrontend is still crashing, so attached files are from profile.

Attachments (8)

gdb.txt (28.8 KB) - added by gareth.glaccum@… 10 years ago.
gdb
myth.log (5.1 KB) - added by garet 10 years ago.
mythlogs.zip (57.1 KB) - added by Tim Jordan <tim@…> 10 years ago.
gdb_gglap (11.9 KB) - added by anonymous 10 years ago.
myth_log_gglap (15.7 KB) - added by anonymous 10 years ago.
myth_log_mythfe2 (8.8 KB) - added by anonymous 10 years ago.
gdb_mythfe2 (8.2 KB) - added by anonymous 10 years ago.
gdb_gglap_profile_patch2 (10.7 KB) - added by anonymous 10 years ago.

Download all attachments as: .zip

Change History (16)

Changed 10 years ago by gareth.glaccum@…

Attachment: gdb.txt added

gdb

Changed 10 years ago by garet

Attachment: myth.log added

comment:1 Changed 10 years ago by Tim Jordan <tim@…>

seeing the same issue, attaching -v all logs and backtrace

Changed 10 years ago by Tim Jordan <tim@…>

Attachment: mythlogs.zip added

comment:2 Changed 10 years ago by Tim Jordan <tim@…>

Tried 20806 same problem. Reverted back to 20796 and seems to work fine, so I guess this is related to the ffmpeg.

comment:3 Changed 10 years ago by gareth.glaccum@…

I can confirm that works for me too with the file which was causing the error.

I have since had the same crash appear on a 64bit system running F10 with the latest trunk, on a different recording. Reverting that machine to 20796 also allowed that recording to be viewed.

comment:4 Changed 10 years ago by Janne Grunau

Milestone: unknown0.22
Owner: changed from Isaac Richards to Janne Grunau
Status: newaccepted
Version: unknownhead

comment:5 Changed 10 years ago by anonymous

Janne? supplied a patch, unfortunately this did not fix the problem. I have attached gdb_mythfe2 and myth_log_mythfe2 which were debug compiled versions of trunk 20958 with the patch. This took out X, for some reason at the same time (restarted X) I only applied the patch to the frontend, I assume that this was enough (different machine to the backend) Also supplied gdb_gglap and myth_log_gglap, which are a profile compilation/crash on a different machine. This is with the patch in place on 20958

Changed 10 years ago by anonymous

Attachment: gdb_gglap added

Changed 10 years ago by anonymous

Attachment: myth_log_gglap added

Changed 10 years ago by anonymous

Attachment: myth_log_mythfe2 added

Changed 10 years ago by anonymous

Attachment: gdb_mythfe2 added

Changed 10 years ago by anonymous

Attachment: gdb_gglap_profile_patch2 added

comment:6 Changed 10 years ago by Janne Grunau

(In [20961]) be more cautious when to create a new AVPacket in mpegts_push_section

syncs the mpegts demuxers a little bit more to the upstream version and fixes parsing bug introduced in [20811].

Might fixes Refs #6716 and Refs #6729

comment:7 Changed 10 years ago by anonymous

I reckon you might have cracked it. With the latest trunk (revn#20969), the recording that I was using as a 'known problem' is playing on one of the 32bit machines I have. I currently have not recompiled the others (they take a while), but if you haven't heard to the contrary in 24 hours /I/ consider this fixed on the systems I have tested on. Regards, Gareth

comment:8 Changed 10 years ago by Janne Grunau

Resolution: fixed
Status: acceptedclosed

fixed by [20961]

Note: See TracTickets for help on using tickets.