Opened 15 years ago
Closed 15 years ago
#6716 closed defect (fixed)
frontend crashing when watching /certain/ recordings
Reported by: | 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)
Change History (16)
Changed 15 years ago by
Attachment: | mythlogs.zip added |
---|
comment:2 Changed 15 years ago by
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 15 years ago by
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 15 years ago by
Milestone: | unknown → 0.22 |
---|---|
Owner: | changed from Isaac Richards to Janne Grunau |
Status: | new → accepted |
Version: | unknown → head |
comment:5 Changed 15 years ago by
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 15 years ago by
Attachment: | myth_log_gglap added |
---|
Changed 15 years ago by
Attachment: | myth_log_mythfe2 added |
---|
Changed 15 years ago by
Attachment: | gdb_mythfe2 added |
---|
Changed 15 years ago by
Attachment: | gdb_gglap_profile_patch2 added |
---|
comment:6 Changed 15 years ago by
comment:7 Changed 15 years ago by
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
gdb