*CRITICAL*: Deleting bugs from iPod bug

[Alejandro Wainzinger]

Indeed, was just mentioning it.  I'll see about doing what you said
with implementing Collection::isWritable.

On Tue, Aug 18, 2009 at 8:26 AM, Maximilian
Kossick<maximilian.kossick at googlemail.com> wrote:
> On Mon, Aug 17, 2009 at 9:33 PM, Alejandro
> Wainzinger<aikawarazuni at gmail.com> wrote:
>> 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.
>
> Ok, but that does not have anything to do with the multiple
> CollectionLocation destructor calls that Seb noted in the debug
> output.
>
>> 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
>>>>
>>>
>>
>