Mplayer crashes when zapping dvbt after changing audio track.

[lorefice2@…]

The following happens at least on mplayer 34578 and 34799 from archlinux packages.

To reproduce, have a dvbt card an a channels.conf file filled at least with two multi audio channels, say: Channel1,Channel2

Next, start in shell #1 mplayer this way:

#mkfifo /tmp/fifo
#mplayer dvb://Channel1 -ao alsa -vo xv -input file=/tmp/fifo

and wait for it to tune and start playing.

In shell #2:
#echo "switch_audio" >/tmp/fifo
#echo "dvb_set_channel 1 0" >/tmp/fifo #(Where 1 is the id of Channel2)

At this time, you probably will not hear anything from channel2, in shell #1 mplayer says:

VIDEO MPEG2(pid=481) NO AUDIO! (try increasing -tsprobe) NO SUBS (yet)!

Next, back in shell #2, try:
echo "switch_audio" >/tmp/fifo

Results: mplayer crashed:
MPlayer interrupted by signal 11 in module: key_events

• MPlayer crashed by bad usage of CPU/FPU/RAM. Recompile MPlayer with --enable-debug and make a 'gdb' backtrace and disassembly. Details in DOCS/HTML/en/bugreports_what.html#bugreports_crash.
• MPlayer crashed. This shouldn't happen. It can be a bug in the MPlayer code _or_ in your drivers _or_ in your gcc version. If you think it's MPlayer's fault, please read DOCS/HTML/en/bugreports.html and follow the instructions there. We can't and won't help unless you provide this information when reporting a possible bug.

#

[lorefice2@…]

I forgot and maybe could help you to know that mplayer2 works fine with those steps.

[reimar]

Most likely -demuxer lavf will avoid it then.
Since I don't have a DVB card I can't do all that much.
It would help if you could run MPlayer in gdb and post a backtrace (should be described in the bug reporting instructions in the documentation).
Also why are you describing this with the slave interface? Why wouldn't exactly the same thing happen if you just use the normal keyboard interface to switch channels and switch audio?

[lorefice2@…]

(In reply to comment #2)

It would help if you could run MPlayer in gdb and post a backtrace (should
be described in the bug reporting instructions in the documentation).

I'll try to.

Also why are you describing this with the slave interface? Why wouldn't
exactly the same thing happen if you just use the normal keyboard interface
to switch channels and switch audio?

Because i'm trying to use it to reduce the time needed to change dvb channel in a an mplayer GUI and i've just tested slave commands.

[lorefice2@…]

Full mplayer output + backtrace at the end.

[lorefice2@…]

Ok, even if the page that explains how to generate backtraces has some errors (disass $pc-32,$pc+32 - comma missing), i think i managed to generate a backtrace.
I'm attaching it.
The gdb backtrace is at the very end of the file.

Thanks.

[reimar]

Did you try with -demuxer lavf?
The backtrace unfortunately makes no sense, not sure why (I am out of practice for debugging 32 bit programs, it's a bit easier with 64 bit).
And sorry about the description not working, the problem is that gdb changed the syntax very recently and the documentation obviously hasn't been updated to mention both ways.

[reimar]

Also maybe you can try a few other random things to give me an idea where to look.
Can you somehow get MPlayer to play audio after switching channels, e.g. using the suggested -tsprobe?
Does using switch_audio with a specific audio channel number crash as well or only when you use the default of having it switch to the "next" channel?
What do you get if you instead run "get_property switch_audio"?
What about 'osd_show_property_text "${switch_audio}"'?
My best idea so far is that some state does not get reset as it should when switching channels, but I can't see what that would be.

[lorefice2@…]

(In reply to comment #6)

My best idea so far is that some state does not get reset as it should when
switching channels, but I can't see what that would be.

I suspect that too, maybe after switching audio mplayer try to find the same id on the new channel, without success and so stay mute ; and when you tell him switch, instead, it crashes because it search the old audio pids (?)

I'll try your suggestions as soon as possible and report back, thanks.

[lorefice2@…]

So,
1) -demuxer lavf works, but changing channels using dvb_set_channel becomes extremely slow,lives garbage on screen sometimes and the video is not smooth, so it is useless for my purpose (to speed up changing channels).

2) -tsprobe 5000000 (5M) still doesn't give me audio on channel change (note that 100000 (100k) ) gives me audio on the first channel.

3)
mplayer "dvb://channel" -ao alsa -vo xv -input file=/tmp/fifo -cache 4096 -cache-min 1 -aid 650, switch audio, change channel, and then issuing another switch_audio doesn't change the crash behaviour.

4)
mplayer "dvb://channel" -ao alsa -vo xv -input file=/tmp/fifo -cache 4096 -cache-min 1 , switch audio, change channel, and then issuing a switch_audio <audio pid here> doesn't change the crash behaviour.

5)
Just for test, i noticed that starting mplayer with a very low tsprobe could lead to missing audio; in that situation (and without change channel) switch_audio doesnt crash mplayer.

6)
trying with -cache 4096 -cache-min 99 doesn't change anything (apart from the time needed to start and change channel of course)

7)mplayer "dvb://channel" -ao alsa -vo xv -input file=/tmp/fifo -cache 4096 -cache-min 1
echo "get_property switch_audio" >/tmp/fifo
.. ANS_switch_audio=650
echo "switch_audio" >/tmp/fifo
...ANS_switch_audio=694
echo "dvb_set_channel 99 0" >/tmp/fifo
echo "get_property switch_audio" >/tmp/fifo
... the usual crash.

8) like #7, osd_show_property "${switch_audio}", crashes mplayer as usual.

Thanks