Hi Philippe, I'll let you pay if you can convince me that LMS sending a volume control change because it felt like it is your fault :)
On more serious topic: I recompiled everything (inc. libupnp-1.6.19) from source, as it kept crashing on my FC20 32 bit box; used -g and -01 so valgring will track symbols. Few isses to report A) - Looks like something does not like the increase to 200 jobs: [09:54:03.630860] TimerLoop:616 discovered service http://192.168.1.87:1763/ConnectionManager/66b388dd-cef8-d1b6-d18e-ec5024bf7f36/control.xml http://192.168.1.87:1763/ConnectionManager/66b388dd-cef8-d1b6-d18e-ec5024bf7f36/event.xml [09:54:04.182824] CallbackActionHandler:522 Error in action callback -- -204 (cookie 2667) total jobs = 200, too many jobstotal jobs = 200, too many jobstotal jobs = 200, too many jobstotal jobs = 200, too many jobstotal jobs = 200, too many jobstotal jobs = 200, too many jobstotal jobs = 200, too many jobs[09:54:06.358837] CallbackActionHandler:522 Error in action callback -- -204 (cookie 2777) [09:54:07.126946] CallbackActionHandler:522 Error in action callback -- -204 (cookie 2778) total jobs = 200, too many jobstotal jobs = 200, too many jobs[09:54:07.896619] CallbackActionHandler:522 Error in action callback -- -204 (cookie 2779) [09:54:07.940042] CallbackEventHandler:661 uPNP search timeout b) Running via valgrind, it seems there is quite a bit of memory leaking : ==24927== LEAK SUMMARY: ==24927== definitely lost: 420,685 bytes in 9,673 blocks <<<<<<<< a lot! ==24927== indirectly lost: 3,131,371 bytes in 137,994 blocks ==24927== possibly lost: 7,113 bytes in 104 blocks ==24927== still reachable: 13,165,191 bytes in 5,724 blocks ==24927== suppressed: 0 bytes in 0 blocks ==24927== Reachable blocks (those to which a pointer was found) are not shown. ==24927== To see them, rerun with: --leak-check=full --show-leak-kinds=all ==24927== ==24927== For counts of detected and suppressed errors, rerun with: -v ==24927== Use --track-origins=yes to see where uninitialised values come from ==24927== ERROR SUMMARY: 134 errors from 42 contexts (suppressed: 0 from 0) ... with stack overruns, invalid reads, and the such. c) When running via valgrind, it seems to run without crashing; when running without it, it keeps crashing after an hour or two (No coredump tho) This behaviour is quite tipycal for code with memory handling isses. I would suggest checking out valgring output carefully, quite a bit of "interesting" stuff reported, and GCC compile warnings might be of interest too. Cheers, Andrej ------------------------------------------------------------------------ afalout's Profile: http://forums.slimdevices.com/member.php?userid=63706 View this thread: http://forums.slimdevices.com/showthread.php?t=102496 _______________________________________________ plugins mailing list [email protected] http://lists.slimdevices.com/mailman/listinfo/plugins
