On Mon, 26 Jan 2004 09:09:25 +0100
Niklas Peinecke <n.peinecke@web.de> 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.
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.