removed songs reappear in gmusicbrowser lists
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| gmusicbrowser (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned | ||
Bug Description
Populate a couple of lists of songs in gmusicbrowser. Remove one or two songs from one of them. Go to the other list. Then go back to the first. The removed songs will have reappeared, as if by magic.
-------
An aside of possible significance:
There are also other, more significant, though unverified concerns with gmusicbrowser lists. I am fairly certain that my lists have gained songs I didn't put in them and lost songs that I did. This aside may, however, not be as straightforward as it may seem.
Having not been catalogued, all I can see on this other point is that it seems to have happened with a fairly significant enough frequency for it to be a strong suspicion. I.e. there are definitely more than a few very odd songs appeared in my carefully curated lists. If there were just one or two I might put it down to hazy, late night flights of fancy. But its a not small few of very strange additions. More than a few tracks have most definately disappeared as well.
Needless to say, with the above verfified error (and the earlier reported bug where gmusicbrowser deleted lists when the library wasn't connected), I am now feeling quite wary of using gmusicbrowser lists - and by extension, I am sorry to say, gmusicbrowser - at all.
However, the earlier reported bug where gmusicbrowser deleted lists when the library wasn't connected caused me to follow a very useful piece of advice that may (at a - distant - outside chance) have had some impact on this aside. That is that I restored a fairly recent config file to restore the lost lists. I also copied the list part of the config to another machine so it could apply the same lists to the same (unchanged) library the same external disk. There might therefore have been some tracks added to the lists after the time of the chosen backup. And there might have been something wrong with the mapping of the lists when moved from one machine to another. I do doubt this though. At least a couple of the missing tunes were definately added much earlier than the chosen backup. And these were in lists in which the strange additions have not been made. So it couldn't be a mapping problem, at least not evidently there. Some of the tracks even seem to be in the wrong lists. And that really starts to put things in a spin.
| Quentin Sculo (squentin) wrote | #1 |
| Changed in gmusicbrowser (Ubuntu): | |
| status: | New → Fix Released |
Sorry for not replying sooner.
About the bug itself, I think it was fixed in 1.1.10, sadly (partly my fault due to my infrequent releases) the still current ubuntu still has a 1.1.9 version. I think there was 2 bugs, one was that the songs listed was cached, but the cache was not flushed when static list were modified. The other bug was only affecting newly created static list.
So if you could confirm the bug is fixed in version 1.1.10 I can close this bug.
About the instability of static lists. It is possible that there is a bug somewhere, I think I remember someone complaining about that once, and I've checked one old list I've made long ago, and there has been a "drift" (songs have been replaced with songs with a close id), though I can't say when it happened. So the question is is that bug still happening with recent versions ? I've spent some time looking at the source for possible bugs, but didn't find any. I've made a control list that I'll try to check often, but if you witness the problem I would appreciate if you could send me a "before" and an "after" gmbrc.
Note that labels shouldn't be affected by bugs in the static lists, as they are saved as a property of the song, and therefore in a totally different way.