Please try to use more descriptive bug summaries.

Have you tried any upnp server software besides mediatomb?  Any other clients?

Sorry for lack of words I used a picture.

Yes server vise I have tried MediaTomb and Twonky, same result. Clients no, so far I have only found Rhythmbox in the package manager that supports Upnp. I have chatted with another user with Rhythmbox / Twonky and he does not have this problem but mentioned ID3 tags but I cannot find any setting for that nor do I know if it is the problem.

I installed Elisa this morning and it shows the media as it should. I can now only assume its a fault in Rhythmbox or the plugin.

Same here, and see Debian bug http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=546649 for more details about my symptoms

Hi, I am affected by the same problem using Rhythmbox and MediaTomb.
Tracks show up in Rhythmbox once per Mediatomb sorting category, apparently (Albums, Artists, Track, etc...). 
I get 6 per actual track.

I tried connecting to MediaTOmb with the following clients, and they did not encounter any problem:
- PS3
- Nokia N800
- HTC Hero (Android) using AndroMote

This seems to indicate that Rhythmbox's Upnp plugin is the problem here.
Any way I could help further (logs, whatever)?

I am also encountering this problem on Ubuntu Karmic using Rhythmbox (0.12.5-0ubuntu), and MediaTomb (0.11.0-1ubuntu). Tracks show up multiple times in the Shared Media browser for the MediaTomb resource. The UPnP plugin for Totem displays the media correctly. 

There does not appear to be a one-to-one relationship to the sort categories (the MediaTomb database shows more entries for a track than appear in Rhythmbox' media browser). I have 6 categories for music (Albums, All - full name, All Audio, Artists, Genres, and Year), but only 3 entries show up in the Rhythmbox browser for each song.

There does seem to be a correlation between the way MediaTomb publishes the "Browse by Artist" tree, though. The tree looks like this:

+ Artists
  + <artist name>
    + All - full name
    + All Songs
    + <album1 name>
    + <album2 name>

and so on. This means each track shows up three times under the <artist name> branch. It seems plausible that Rhythmbox is simply querying the media server by artist and added all results, ignoring the subcontainers.

One thing that works against this theory: some of my tracks only show up twice in Rhythmbox. I have been unable to determine why this is the case.

With further experimentation, the duplicate entries appear to disappear if I remove the "All - full name", "All Audio", and "Genres" trees (making sure to delete without removing linked items). This works for my purposes, although obviously it's not a long-term fix.

More digging: it seems that the UPnP plugin for Rhythmbox does very simple test to check for duplicate values: it looks to see if an item with the same URI exists in the database already. If not, it adds new entry.

This breaks down with MediaTomb, though, and I believe this is why: the same track is published under multiple unique identifiers. A new ID is assigned for each object inside a container object, so for the track "Awesome Track" there will be multiple entries, each with a ID: one for the "Awesome Track" entry inside the Albums container, one inside the All Tracks container, one inside the Genres container, and so on. This is corroborated by the fact that each duplicate track has a unique URI--with the 'id' property being the only unique part--when you examine at its properties in Rhythmbox.

So it seems there are two options. The first is to modify duplicate detection routine in the UPnP plugin. I think something like "Does a track with this title, artist, album, track number, and disc number (if applicable) already exist in the database?" would be sufficient. The second option is to change the import routines in MediaTomb so each track is mapped to one and only one UID.

I'm not familiar enough with the ramifications of either approach to know which is better. It seems that modifying the dupe detection routine would make Rhythmbox less responsive, which doesn't seem desirable, but I'm not sure if changing the URI scheme in MediaTomb would break its URI resolution mechanisms...

Interestingly, I'm still encountering some duplication in the library, although it isn't nearly as much.

FYI, a workaround I found for mediatomb : I configured the import.js differently so that it only constructs one single chain (the first one). You need to change the <virtual-layout> type to "js" and then remove everything in import.js after the Array('Audio', 'All Audio') addition with addCdsObject().
Then you'd restart mediatomb, remove everything from the DB and reindex the filesystem.

Hope this helps.

Olivier, I'd be interested in seeing your import.js file. Has your solution worked out after restarting Rhythmbox and MediaTomb?

I had to completely remove all calls to addCdsObject() to get rid of duplicates once and for all--it seems that the PC Directory container structure is also advertised, with unique URIs. So it seems that at minimum you're going to have two unique URIs for a track--one in the built-in PC-Directory hierarchy, and whatever is URI is added by the addCdsObject call. This has been my experience when hacking MediaTomb's import.js

I don't know how to explain the fact that I was previously able to eliminate most of the duplicates by removing some of the Audio containers. It is a mystery!

After doing a bit of Googling, I found out how to hide the PC-Directory structure: add "<pc-directory upnp-hide="yes"/>" to Mediatomb's config.xml in the <server> node. More details in MediaTomb's documentation: http://mediatomb.cc/pages/documentation.

So, this seems to be the solution for all those using MediaTomb and Rhythmbox together: edit import.js (this is located in /usr/share/mediatomb/js on my Ubuntu system) to remove the duplicate entries, and add the "upnp-hide" option to the MediaTomb config file. This should remove all song duplicates.

I would file a bug against mediatomb for it to have unique IDs for the songs whichever folder they appear in.

The problem occurs with other media servers as well like Twonkymedia. You get multiple duplicate listings for categories and tracks.

So, July 2010 now - the problem still exists and no developer comments - come on guys!

I think that UNCONFIRMED is misleading - every user of the coherence plugin is experiencing this.

What with the decision to upgrade RB with a fix for the DAAP killer problem BUT using a libary no distribution includes (yet), and now this we have sod-all options for a GNome music player accessing standard libary servers!

(In reply to comment #14)
> So, July 2010 now - the problem still exists and no developer comments - come
> on guys!

The bug is in mediatomb, which uses different UUIDs for the same files.

> I think that UNCONFIRMED is misleading - every user of the coherence plugin is
> experiencing this.

The bugzilla status has nothing to do with whether or not the bug is being worked on.

> What with the decision to upgrade RB with a fix for the DAAP killer problem BUT
> using a libary no distribution includes (yet), and now this we have sod-all
> options for a GNome music player accessing standard libary servers!

At least Fedora includes libdmapsharing. Try with a server that's not as broken, such as rygel.

Created attachment 166984 [details]
Experimental UPnP plugin

I'm not quite content with saying it's completely Mediatomb's issue, since it also occurs in other servers like Twonkymedia. There are useful and valid applications for the container structure that Mediatomb uses.

So, not content with my import.js hack, I've been hacking the Coherence plugin for Rhythmbox to filter out duplicate entries. Basically it works by treating the UPnP containers like file folders, filtering on a list of valid paths contained in the 'self.filter' tuple in UpnpSource.py

It's still quite rough and untested, but if you extract the attached file to $HOME/.gnome2/rhythmbox/plugins/ and enable the experimental UPnP plugin in Rhythmbox, you should be able to load media from Mediatomb without duplication. Note this plugin *will* conflict with the version that's distributed with RB, so you'll need to uninstall the stock version before playing with this.

(In reply to comment #15)

> The bug is in mediatomb, which uses different UUIDs for the same files.

I suggest to do some reading on the UPnP spec and rethinking this statement.

Hmm, interesting. I was not aware of this requirement, but it seems Jin is correct. Section 2.2.21 in http://upnp.org/specs/av/UPnP-av-ContentDirectory-v3-Service.pdf for anyone wanting a link.

Hint: look at the refID of the object, it will point to the objectID of the original object. For details on refID see page 167, B.1.3 (above document).

So if a refID is present, you can assume that this is a virtual copy of some item (which btw may have a different title, different URL, etc.) and is actually the same data.

I just downloaded the Experimental UPnP plugin which was staged on 2010-08-02 15:04 UTC (upnp-plugin.tar.gz).  I am still testing but on first try I see no duplicates!!!

Glad to hear it works, although note that the solution in that experimental plugin is a hack, and doesn't address the underlying problem well.

I'm working on a solution using the refID check, but progress is slow because I've discovered a separate issue: browsing of certain items intermittently fails with no indication as to why. The PC Directory container often doesn't get browsed as a result.

This issue isn't resolved with MediaTomb because of the MediaTomb browse issues, but if you're using a UPnP MediaServer that properly sets refIDs, the version of the Coherence Rhythmbox plugin in the Coherence SVN repository will filter out the duplicates. See http://coherence.beebits.net/wiki/RhythmBox#ManualInstallation

not an issue with the new grilo plugin