Have made changes and with a bit of luck made the entire track_change
scenarios for coverart display safer and less burdensome. Tried to consider
all possible scenarios...
Let me know of any probs.
On Thursday 19 April 2007 12:36, you wrote:
> Hi Peter, <- (Paul)
> sorry for the late reply.
> > - coverart_set_images() clears the current displayed cover images, free
> > the displayedtracks list and basically starts again recreating the
> > display based on the tracks from the selected playlist.
> And that can be quite time-consuming if you have thousands of tracks.
> > - Calling it in pm_remove_track () does mean that it gets the tracks from
> > the playlist before the call to gp_remove_track() thus potentially an
> > undefined pointer is lurking in the list?? Has never materialised despite
> > removing entire albums. Am I missing something - certainly confirms your
> > dangerous assertion.
> Yes, that could explain the crashes I had (before merging and your
> latest patches, so I didn't mention it until now).
> pm_remove_track(track) and pm_track_changed(track) are meant to
> propagate changes in a single track down to the trackview to avoid
> having to update all tracks. Therefore, if you want to use this function
> (which makes sense because you are dealing with the displayed tracks,
> other than my conversion code, which deals with all tracks) you should
> use the information about which track has changed/has been removed and
> update the display based on that information.
> > - Redo coverart_set_images:
> > -- take copies of the tracks for displaytracks rather than pointers to
> > actual tracks?
> Not a good idea I think (I had the same ramblings), but that just treats
> a symptom of the underlying problem.
> > -- when a track change occurs, determine if the track's coverart is
> > displayed. Not sure how to avoid reloading the pixbuf if a displayed
> > track has changed, ie. trade off between "safer to reload just in case"
> > and "reloading a 1MB even though it has not altered"
> Sounds like a better idea. Loading the pixbuf of one track is not a
> > Random ramblings I'm afraid. Let me know if any compile / runtime
> > problems occur from my latest changes.
> None so far -- but I'm always doing the same during my tests now: drag
> some flac-tracs from the local repository to an test-iPod-repository and
> see how the conversion is done in the background :-)