*CRITICAL*: Deleting bugs from iPod bug

[Alejandro Wainzinger]

Yeah but that's not the only multiple-spawn problem with copying, and
I was looking to thread more copying stuff because I realized that
what took the longest of copying isn't the KIO CopyJob, but all the
metadata-processing code, DEBUG_BLOCK showed, so I need to thread the
adding of metadata into the Metadata QMaps.  Unfortunately since QMap
and friends aren't thread-safe (but re-entrant) I have to use some
QMutexLockers and such, and figuring out how best to do it is what
took me a bit.  Now that I'm back in Spain, I can do it with a little
less commotion.

On Mon, Aug 17, 2009 at 7:15 PM, Maximilian
Kossick<maximilian.kossick at googlemail.com> wrote:
> On Mon, Aug 17, 2009 at 5:34 PM, Alejandro
> Wainzinger<aikawarazuni at gmail.com> wrote:
>> Yikes... I was doing this very thing a few days ago and didn't get
>> this.  Compiling trunk now, checking to confirm it, and fix it ASAP.
>> As for the multiple CollectionLocation spawning thing, I was looking
>> into that a day or two ago but haven't finished a fix yet.  It
>> requires creating a few more Threadweaver classes for some subjobs,
>> and I'll get that fix in after I finish this very critical one.
>
> Are you sure that the spawning of multiple CollectionLocations has
> anything to do with Threadweaver jobs? There is one call to
> Collection::isWritable() in CollectioNTreeView::getCopyActions,
> getMoveActions, getRemoveActions and removeTracks respectively (which
> just happens to be the number of times the CollectionLocation dtor is
> called in the log). Collection::isWritable() creates a
> CollectionLocation (by calling location() on itself, so it gets the
> correct one), checks whether it is writable and deletes the
> CollectionLocation instance. The latter is the whole point of that
> default implementation) by default. The easiest way to create less
> CollectionLocations is too implement Collection::isWritable() in your
> collection.
>
>> On Mon, Aug 17, 2009 at 1:27 PM, Seb Ruiz<ruiz at kde.org> wrote:
>>> Yes, I can reproduce it.
>>>
>>> Here is the debug output:
>>>
>>> amarok: BEGIN: virtual
>>> MediaDeviceCollectionLocation::~MediaDeviceCollectionLocation()
>>> amarok: END__: virtual
>>> MediaDeviceCollectionLocation::~MediaDeviceCollectionLocation() - Took
>>> 4.4e-05s
>>> amarok: BEGIN: virtual
>>> MediaDeviceCollectionLocation::~MediaDeviceCollectionLocation()
>>> amarok: END__: virtual
>>> MediaDeviceCollectionLocation::~MediaDeviceCollectionLocation() - Took
>>> 4.9e-05s
>>> amarok: BEGIN: bool CollectionTreeView::onlyOneCollection(const
>>> QModelIndexList&)
>>> amarok: END__: bool CollectionTreeView::onlyOneCollection(const
>>> QModelIndexList&) - Took 4.9e-05s
>>> amarok: BEGIN: virtual
>>> MediaDeviceCollectionLocation::~MediaDeviceCollectionLocation()
>>> amarok: END__: virtual
>>> MediaDeviceCollectionLocation::~MediaDeviceCollectionLocation() - Took
>>> 4.4e-05s
>>> amarok: BEGIN: void CollectionTreeView::removeTracks(const
>>> QSet<CollectionTreeItem*>&) const
>>> amarok:   BEGIN: virtual
>>> MediaDeviceCollectionLocation::~MediaDeviceCollectionLocation()
>>> amarok:   END__: virtual
>>> MediaDeviceCollectionLocation::~MediaDeviceCollectionLocation() - Took
>>> 0.00012s
>>> amarok:   BEGIN: void CollectionLocation::prepareRemove(QueryMaker*)
>>> amarok:   END__: void CollectionLocation::prepareRemove(QueryMaker*) -
>>> Took 0.00015s
>>> amarok: END__: void CollectionTreeView::removeTracks(const
>>> QSet<CollectionTreeItem*>&) const - Took 0.00081s
>>> amarok: BEGIN: void CollectionLocation::resultReady(const QString&,
>>> const Meta::TrackList&)
>>> amarok: END__: void CollectionLocation::resultReady(const QString&,
>>> const Meta::TrackList&) - Took 0.00013s
>>> amarok: BEGIN: void CollectionLocation::queryDone()
>>> amarok:    we were about to remove something, lets proceed
>>> amarok:   BEGIN: void CollectionLocation::prepareRemove(const Meta::TrackList&)
>>> amarok:     BEGIN: void CollectionLocation::startRemoveWorkflow(const
>>> Meta::TrackList&)
>>> amarok:       BEGIN: virtual void
>>> CollectionLocation::showRemoveDialog(const Meta::TrackList&)
>>> amarok:         BEGIN: void CollectionLocation::slotFinishRemove()
>>> amarok:         END__: void CollectionLocation::slotFinishRemove() -
>>> Took 0.0001s
>>> amarok:       END__: virtual void
>>> CollectionLocation::showRemoveDialog(const Meta::TrackList&) - Took
>>> 1.3s
>>> amarok:     END__: void CollectionLocation::startRemoveWorkflow(const
>>> Meta::TrackList&) - Took 1.3s
>>> amarok:   END__: void CollectionLocation::prepareRemove(const
>>> Meta::TrackList&) - Took 1.3s
>>> amarok: END__: void CollectionLocation::queryDone() - Took 1.3s
>>>
>>>
>>> As a side note, that's a lot of CollectionLocations that we're creating.
>>>
>>> Seb
>>>
>>> 2009/8/17 Maximilian Kossick <maximilian.kossick at googlemail.com>:
>>>> Can you reproduce this error and provide the debug output?
>>>>
>>>> On Mon, Aug 17, 2009 at 12:58 PM, Seb Ruiz<ruiz at kde.org> wrote:
>>>>> Hi Alex,
>>>>> I stumbled across a grave bug this evening. It seems that trying to
>>>>> delete files from the iPod immediately after copying them will infact
>>>>> try to delete them from the collection they were copied from. Have a
>>>>> look at the linked screenshot for evidence.
>>>>>
>>>>> http://img43.imageshack.us/img43/4776/amarokipod.png
>>>>>
>>>>> This is certainly a bug that needs to be resolved ASAP!
>>>>>
>>>>> Cheers,
>>>>> Seb
>>>>>
>>>>> --
>>>>> Seb Ruiz
>>>>>
>>>>> http://www.sebruiz.net/
>>>>> http://amarok.kde.org/
>>>>> _______________________________________________
>>>>> Amarok-devel mailing list
>>>>> Amarok-devel at kde.org
>>>>> https://mail.kde.org/mailman/listinfo/amarok-devel
>>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> Seb Ruiz
>>>
>>> http://www.sebruiz.net/
>>> http://amarok.kde.org/
>>> _______________________________________________
>>> Amarok-devel mailing list
>>> Amarok-devel at kde.org
>>> https://mail.kde.org/mailman/listinfo/amarok-devel
>>>
>> _______________________________________________
>> Amarok-devel mailing list
>> Amarok-devel at kde.org
>> https://mail.kde.org/mailman/listinfo/amarok-devel
>>
>