------------------------------------------------------------------------------------ Peter Dittmann APM-DS Philips Technologie GmbH Automotive Playback Modules Wetzlar / GERMANY Tel: +49 (0) 6441 3722 759 Fax: +49 (0) 6441 3722 566 E-mail: : peter.dittmann@xxxxxxxxxxx ------------ http:\\www.apm.philips.com --------------------------------------------------------------- vdr-bounces@xxxxxxxxxxx schrieb am 24.07.2006 17:51:55: > On Mon, 24 Jul 2006 09:58:00 +0200, Peter Dittmann wrote > > Had another kernel crash this morning with stuck SVDRP: > (...) > > Jul 24 04:19:05 vdr vdr[1399]: connect from 127.0.0.1, port 32792 - accepted > > Jul 24 04:19:05 vdr vdr[1399]: SVDRP message: 'Infosat:Received > 1490 of 1500 > > data blocks [ 99.33%]' > > Jul 24 04:19:05 vdr vdr[1399]: info: Infosat:Received 1490 of 1500 data > > blocks [ 99.33%] > > Jul 24 04:19:05 vdr vdr[1399]: closing SVDRP connection > > Jul 24 04:20:05 vdr vdr[1399]: connect from 127.0.0.1, port 32793 - accepted > > Jul 24 04:20:05 vdr vdr[1399]: SVDRP message: 'Infosat:Received 1497 > > of 1500 data blocks [ 99.80%]' > > Jul 24 04:20:05 vdr vdr[1399]: info: Infosat:Received 1497 of 1500 > > data blocks [ 99.80%] > > Jul 24 04:20:05 vdr vdr[1399]: closing SVDRP connection > > > > >> this seems to be VDRAdin as it's not the same 60sec raster as the > > messages from infosatepg > > > > Jul 24 04:20:41 vdr vdr[1399]: connect from 127.0.0.1, port 32794 - > > accepted > > > > Jul 24 04:21:42 vdr vdr[1399]: PANIC: watchdog timer expired - exiting! > > I don't know infosatepg, but as far as I've read, it first downloads the data > via DVB-S and then tvmovie2vdr uploads it to SVDRP. The whole process is > controled by infosatepg.sh. > > According to the log, infosatepg receives about 5-10 packets per minute, so it > is most likely finished at Jul 24 04:20:41. At that time the SVDRP upload > starts which is simply too fast. > Nope, infosatepg is not filling the data linearly. It takes around three runs here to accumulate all blocks as the FF has a high packet error rate. I'm shure that infosatepg would have been happily busy untin 4:35. This is supported by infosatepg still running and being the cause of the kernel crash once VDR has restarted. > Again: try to find out what's really happening when the watchdog is triggered. > Use a sniffer, add some debug lines to vdr - whatever. It's a ctvdr productive system, not much possibilities here to not break all plugin packages. However the problem seems to rise from VDRAdmin and the long timeout when adding timers. I had removed VDRAdmin already from the init and run it only during the infosatepg update time. I had strange crashes before. Especially when mp3ng plugin was running and a SVDRP message was comming in. This crashed VDR almost guaranteed. It looks like Morones mp3ng does not like messages completely. But that's different issue. I will try to backport the SVDRP changes to my productive system and check were this leads. regards Peter -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.linuxtv.org/pipermail/vdr/attachments/20060725/1a50c4cd/attachment.htm
