Am Friday 19 March 2004 18:35 schrieben Sie: > > > "COMTYPE_PIDFILTER, Scan/FlushTSQueue" outcommands, but i think only > > > MultiPID make the trouble. > > > > IIRC Ralph said that he tried to debug this in the firmware, and > > the ARM just hangs inside a RTSL call. There isn't much we can do then. > > > > Anyway, I'll read through the MultiPID code of the firmware (again). > > Hi Johannes, > > i donīt think the problem is in MultiPID, because this command lay around > in the command buffer and looping this command (tested last night in case > the buffer is not cleared) would not help. I think the main problem is in > Scan/FlushTSQueue (i have always one of this two commands in the log before > MultiPID failed), īcause this commands are the last ones the arm executed > and and i think they run into an buffer underrun (because problems without > sinal) or something, so the ARM doesnīt catch the following call from > command buffer...
I did some tests with my card (siemens DVBs Rev. 1.3) as mentioned before: ves1893 frontend, no signal connected, feed with analogtv. I always got an ARM crash and before that several av7110_send_fw_cmd-errors although there is never an SetPID() called (?) in my setup. However - just 2 hours ago i tested the following: i call an ves_1x93_init(i2c) every 10 seconds - so far the ARM-crash is gone now! However - the av7110_send_fw_cmd-errors still appear and the video-decoding still has the same problems as before (video goes black, small audio fragments are played followed by some seconds of silence, mpeg2-decoding went obviously haywire). That leads me to the conclusion, that the ARM crash is just a "second order" error, happen because of something else went wrong (during playback in av7110). Guido -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as subject.