That's right, but this should not cause a total hang. I can imagine that the sound driver returns some error code, then xine assumes that something has gone wrong when stopping the filters and tries again.On Mon, 26 Jan 2004 09:09:25 +0100 Niklas Peinecke <[EMAIL PROTECTED]> wrote:
Helmut Gildein wrote:
kernel: remove_pid: pid=136 kernel: remove_hw_pid: pid=136 kernel: remove_hw_pid: pid=136 searching slot=0 kernel: remove_hw_pid: pid=136 searching slot=1 kernel: remove_hw_pid: pid=136 slot=1 kernel: pid_set_hw_pid: id=1 pid=8191 kernel: pid_set_hw_pid: id=1 addr=300 h pid=8191 kernel: filter_enable_hw_filter: id=1 op=0 kernel: dvb_demux_feed_del: feed not in list (type=0 state=0 pid=88) kernel: dvb_stop_feed: PID=167, type=0 kernel: close_stream: dma_status=30000007 kernel: dma_start_stop: dma_mask=3 kernel: dma_start_stop: stopping dma kernel: remove_pid: pid=167 kernel: remove_hw_pid: pid=167 kernel: remove_hw_pid: pid=167 searching slot=0 kernel: remove_hw_pid: pid=167 slot=0 kernel: pid_set_hw_pid: id=0 pid=8191 kernel: pid_set_hw_pid: id=0 addr=300 l pid=8191 kernel: filter_enable_hw_filter: id=0 op=0 kernel: dvb_demux_feed_del: feed not in list (type=0 state=0 pid=a7) kernel: flexcop_diseqc_ioctl: FE_SLEEP
This really doesn't look unusual to me: PIDs for Audio/Video (136/167) are opened and hardware filters (== hw_filter) are started for them. Then they get closed down when the switch occurs. Nothing to see here.
Aren't that "feed not in list" suspicious? Is the application trying to free the pids twice or what? Never seen that message here.
@Helmut: What versions of xine, ALSA and the dvb-drivers are you using? Maybe I could try to reproduce the problem.
Niklas
-- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as subject.
