*CRITICAL*: Deleting bugs from iPod bug

Maximilian Kossick maximilian.kossick at googlemail.com
Mon Aug 17 19:15:48 CEST 2009


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
>


More information about the Amarok-devel mailing list