Opened 16 years ago

Closed 15 years ago

#4635 closed defect (duplicate)

Mythfrontend segfault switching tuner cards

Reported by: brtab Owned by: Isaac Richards
Priority: minor Milestone: 0.22
Component: mythtv Version: head
Severity: medium Keywords: segfault channel change
Cc: Ticket locked: no


While investigating a problem in cycling through the tuner cards using the 'Y' key on version 15741 mythfrontend segfaults. Below is information on the current card setup. B1 is the primary back end and B2 is the slave back end.

Here is the cardinput table: mysql> select cardinputid,cardid,displayname,preference,recpriority from cardinput order by cardid;

| cardinputid | cardid | displayname | preference | recpriority | 1 1 B1A1T1 0 0, 2 2 B1A2T1 0 0, 8 3 B2A1T1 0 0, 3 4 B1HD0 0 0, 4 5 B1DVB0 0 0, 5 6 B1HD1 0 0, 9 7 B2A2T1 0 0, 6 8 B1A3T1 0 0, 7 9 B1A4T1 0 0

B1A{1,2,3,4}T1 are PVR-250 installed in primary back end B1HD{0,1} are the tuners from an HDHomerun on the ethernet configured in the primary back end B1DVB0 is a pcHDTV5500 installed in primary back end B2A{1,2}T1 are the tuners from a PVR-500 installed in a slave back end

With no recordings or other front ends running I am expecting to see the card B1A4T1 come up initially then B1A1T1, B1A2T1, B2A1T1, B1HD0, etc. The "Avoid conflicts between live TV and scheduled shows" is set as well as the "Allow live TV to move scheduled shows". It used to work so that the "Y" key selected the tuners down the table in cardid order since that is how the tuners were entered.

But what is seen instead is this order: B1A4T1, B1HD0 and then B1A1T1, B1HD0. These last two are cycled between from then on. Exiting and restarting livetv restarts this cycle again. If there is another front end that is already using B1A4T1 the sequence starts at B1A3T1, cycles to B1HD0, and then loops on B1A1T1 and B1HD0. If there are recordings on B1A1T1, B1A2T1, and a front end on B1A4T1 the sequence starts at B1A3T1, cycles to B1HD0, and then loops on B2A1T1 and B1HD0.

When I entered the tuners in mythtv-setup there was no additional setup done such as input groups or jockeying with priorities.

Continuing to cycle through these cards results in the segfault. The above configuration information was posted to the user list to see if I have failed to configure something else that is needed or if this is the behavior that others are seeing as well.

Attachments (4)

gdb.txt (41.4 KB) - added by brtab 16 years ago.
gdb backtrace
mythfrontend.log (1.5 KB) - added by brtab 16 years ago.
mythfrontend log file
gdb.2.txt (28.3 KB) - added by dstrang@… 16 years ago.
gdb.txt - 0.21-fixes rev.16183
crash.txt (127.8 KB) - added by dstrang@… 16 years ago.
mythfrontend -v most - 0.21-fixes rev.16183

Download all attachments as: .zip

Change History (15)

Changed 16 years ago by brtab

Attachment: gdb.txt added

gdb backtrace

Changed 16 years ago by brtab

Attachment: mythfrontend.log added

mythfrontend log file

comment:1 Changed 16 years ago by brtab

This problem has been further refined to a single PVR-250 and a single HDHomerun tuner configured on a single master back end. The previously reported inconsistent cycling through the tuner cards may be attributed to some keybinding changes that were implemented in an earlier version. The keybinding settings have since been adjusted on the system and now results in proper cycling through the tuner card entries as expected, ie., the last tuner entered in mythtv-setup is the first tuner chosen. The 'Y' key then cycles to the first tuner, then the second, then the first, and so on.

The start channels are valid for the specific cards as has been suggested as something to check in a user list post.

comment:2 Changed 16 years ago by anonymous

Some additional information on this is the problem is not specific to the HDHomerun. Substituting a pcHDTV-5500 using the DVB drivers results in the same frontend segfault. Using two or more PVR-250s and the frontend does not segfault cycling through them.

comment:3 Changed 16 years ago by stuartm

Milestone: unknown0.21

comment:4 Changed 16 years ago by paulh

Just a shot in the dark. I'm wondering if you have a bad font because the bt shows the segfault is in the freetype library. If you change the OSD to one that uses a different font does that change anything?

comment:5 Changed 16 years ago by dstrang@…

I also have this crash; however - I'm not 100% certain it's the tuner. If I'm using DVB-S, and switch to an 8VSB OTA station on a diff tuner - it doesn't seem to crash, tho swiching back to a DVB-S, or HDHomeRun input - will cause it to crash... I also get get random crashes when I attempt to watch SOME recorded shows via Media Library -> Watch Recordings. The crashes are never 100%, mine actually bomb me right out of gnome, and I have to re-login. Eventually I always CAN change inputs (it starts on an 8VSB channel on my air2pc ota card, and switches to a DVB-S channel, or a QAM channel on my HDHomeRun) but it takes about 4 tries.

I'm testing 0.21-fixes, rev 16183.

Here are my configure options:

./configure --prefix=/usr --enable-dvb --disable-dbox2 --disable-joystick-menu --enable-hdhomerun --enable-opengl-vsync --enable-opengl-video --enable-mmx

I'm using OpenGL as my painter.

Changed 16 years ago by dstrang@…

Attachment: gdb.2.txt added

gdb.txt - 0.21-fixes rev.16183

Changed 16 years ago by dstrang@…

Attachment: crash.txt added

mythfrontend -v most - 0.21-fixes rev.16183

comment:6 Changed 16 years ago by danielk

dstrang, when you remove the "--enable-opengl-vsync --enable-opengl-video" experimental ./configure options, which are known to cause segfaults, does it still crash?

comment:7 Changed 16 years ago by danielk

Status: newinfoneeded_new

comment:8 Changed 16 years ago by dstrang@…

danielk -

No, I wasn't able to crash it all when I removed those options...

comment:9 Changed 16 years ago by danielk

Milestone: 0.210.22
Status: infoneeded_newnew

Moving this to 0.22. It's a real problem, but the problems are in portions of MythTV which we've disabled by default in MythTV because they are segfault prone.

comment:10 Changed 16 years ago by anonymous

danielk -

This appears to be a problem with just the --enable-opengl-video option; it remains stable with --enable-opengl-vsync. I tried adding back just the opengl-video switch (without opengl-vsync) and the crashing continued... also, it makes playback on some of my OTA HD channels horrible.

comment:11 Changed 15 years ago by danielk

Resolution: duplicate
Status: newclosed

Dup of #4185. TV's osd pointer needs locking, which is provided in the mythtv-vid branch and will eventually make it to head.

Note: See TracTickets for help on using tickets.