Hi, > ... >Despite this the packet_header checks around line 1858 are not >endian-safe. Anyway, I believe they are not required - is it ok to > I have sent you a patch to this for both branches, but they seem to have disappeared somewhere in your mailbox ;-)
>remove them and call the software demux callback unconditionally? The >demux will discard non-matching packets anyway, a double-check just >costs time... > I removed them, and it doesn't seem to work worse than before, perhaps, even better. :-) Doesn't this look suspicious as well: if (pid <= 0x1F) return 1; Return 1 usually means success, not failure. This can be found in the *HW* routines. I added a possibility to disable all hw_filters to track down my problems: scanning a transponder still seems to stop mplayer from working, which - I think - shouldn't happen: I'm not requesting a pid that it is currently using, I'm just scanning the (non-vpid, non-apid) pids found in the SI. My guess: there is still some bug in the interrupt routine. [scan has still less success than my own scan: my scan breaks mplayer, but scan doesn't find much more than the PAT, and breaks mplayer as well ;-)] My old problem seems to be solved: moving the dish out of lock, and then moving it back, doesn't seem to crash anything anymore: both mplayer -vfm ffmpeg, and mplayer -vfm libmpeg2 are recovering nicely ;-) Perhaps, this needs some more tests, though ... [ I have miserably failed to add 4:2:2 support to mplayer this weekend: at least I got a first idea how mplayer is working, now :-( ] Wolfgang -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as subject.
