Bugzilla – Bug 1936
scheduler::remove_task removes all
Last modified: 2008-09-15 14:37:04 UTC
If the cache is wiped and multiple importers are active, iTunes Musicmagic and Moodlogic al seems to stall. Export only reports to song 3 (at best) and just stops sending log info, no indication of end of scan or any errors. If only folder scan is used, it works ok. Adding one importer at a time from there will also work safely.
musicmagic and moodlogic in combination is ok. itunes, paired with either will cause itunes to work but the other simply stops looping.
seems to be a problem with Slim::Utils::Scheduler::remove_task(\&scanFunction); at line 576 of iTunes.pm. I'm still chasing, but comenting this out does allow things to work. Of course, it also makes iTunes parser wrap and start again (tho fails and stops before scanning all over again).
right, well, it seems that the core problem is that remove_task actually appears to remove all tasks instead of just the one specified. I don't know how to get the info on the exact functions referencesd, but doing just a simple Data::Dumper on the @background_tasks before and after remove_task, shows that two sub {"DUMMY"} 's become none. Checking inside the loop, Dumper seems to suggest that every background task is a match for the $taskref. Any better debug stuff I can do on this?
Created attachment 699 [details] properly count through background tasks previously, if the taskptr matched the background_task[i], it would simply loop again without increment. It should increment even if there is a match, only doing the remove when a match is found. This seems to work. I wonder how much this has been affecting. This has been here since VERY early on. It only finally triggered due to the explicit remove_task in the new iTunes parser. Previously, a return 0 always ended the scheduled tasks seemlessly. dan, does this one make sense??
Yes - that makes sense. Looks good.
argh...itunes remove_task is still killing musicmagic now. why does this compare arrays instead of the actual scalar ref? removing the array cast seems to result in itunes not being able to remove, so that's no good. This may be broken beyond my ability to fix, but I'll keep hacking.
Created attachment 701 [details] add proper matching for the taskptr I found that the task pointers were not matching due to comparing the arrays. This parses out the original task pointer, and seems to fix the whole rescan. What I don't know yet is whether the args need to be compared as well. the only other place we use remove_task is from Scan::stopAddToList. I'm not sure when it might be possible to have several addToList_run tasks, requiring us to compare the listrefs.
Can't be any worse than what's there now..
committed current patch to trunk at change 3884. marking as fixed. can re-open if there is any issue with the adddToList. I went looking for it, and haven't seen any overlapping, so it should be ok.
There are 536 bugs in the database with targets of '---' that were fixed prior to new year 2006. I am setting them to targets of 6.2.1 to keep them from showing up in my queries.