[fcastillo]

So, I've found this behavior in Nightingale pretty annoying and haven't figured out how to stop it.
So, I have my library populated, either by adding music manually or by folder watch (I've tried both approaches) The folder watch is the one that I use most often.
All is good until I decided to import some of my playlists that I've saved using the (Playlist Export add-on and they are M3U8 playlists with absolute paths to the songs location.
After importing a playlist, I start to see duplicate songs in my library, which are the songs I just imported from the playlist. This is also confirmed by The Exorcist add-on.
The problem is that the duplicate songs are the same song, in the same location, but Nightingale stores the songs in its database using a unique ID, and by importing the playlist Nightingale created different unique IDs for the new songs, instead of matching them to the songs already in my library.

To try to solve this problem I decided to leave my library completely empty, and before doing anything, I imported the playlists. This also populated my library with only the imported songs. Then I go to turn on Folder Watch, so the rest of my library gets populated. I thought that given that some songs are already in the library, the Folder Watch wouldn't add them if they are already there, but it adds them hence creating duplicates. These duplicates are again the same song, with exact same properties, in the exact same location but with a different ID, so the Nightingale database thinks they are different songs.

There's no way to differentiate one song from the other because they are the same song (except for the ID). The only way to not have duplicates is to populate my library and manually recreate all my playlists which is annoying and defeats the purpose of exporting and backing up playlists.

Also, the error console doesn't display any problems at all, everything is working the way it's "supposed" to.
If anybody needs any additional info, logs or anything to help fix this problem, please do let me know.

I forgot to mention that I'm using Ubuntu 13.04 64bit and I've tried both the stable and nightly PPA and also the .tar version from the Download page.

[rsjtdrjgfuzkfg]

I'm not aware of a good practice either. I know the issue, my personal solution is not to use folder watching, as it does not make things uncomfortable for the way I organize my music. But that surely does not apply to everybody.

I could think of multiple ways of targeting the issue:

• We consider duplicates as feature, thus the current behaviour is perfectly valid. We should then probably think about an add-on removing duplicates, for those not wanting them.
  
• We consider duplicates as bug, and try to prevent them on the lowest possible level (that is, in the database / local library stuff; adding a new item with an existing URI would then overwrite the old version or something). This will likely break stuff.
  
• We consider duplicates as something most people do not want in their library, but keep it possible. This would result in some sub-issues:
  • Watch folders creates duplicates when importing
    
  • Playlist import creates duplicates when importing
    
  • (maybe) There is no warning when the user tries to create a duplicate by re-importing the same media again
    
  • (maybe) Importing a folder creates duplicates if some of its content has already been added to the library
    

I'm not sure which way is better, however I tend to the last option. Open for discussion here, although it will probably not get implemented until someone has the time to work on it - independent of the discussions outcome.

[freaktechnik]

I would personally expect the URI of a file to be a unique ID in the database, since the content of the Music file is exactly the same and I don't see any reason to have the same song/video with different attributes on it.

[rsjtdrjgfuzkfg]

(10-15-2013, 07:06 PM)freaktechnik Wrote: I would personally expect the URI of a file to be a unique ID in the database, since the content of the Music file is exactly the same and I don't see any reason to have the same song/video with different attributes on it.

While this surely is true for most usages, I'm not totally sure thinking of web playlists. I could think of two websites linking the same URI, and while I'm not sure if it is possible currently, I could think of both websites providing different metadata.

Also, it could in theory be possible to serve different media from the same URI based on external stuff (referrer, users being logged in or not, etc.)...

[freaktechnik]

(10-15-2013, 08:59 PM)rsjtdrjgfuzkfg Wrote: While this surely is true for most usages, I'm not totally sure thinking of web playlists. I could think of two websites linking the same URI, and while I'm not sure if it is possible currently, I could think of both websites providing different metadata.

Also, it could in theory be possible to serve different media from the same URI based on external stuff (referrer, users being logged in or not, etc.)...

I was thinking in local URIs, but yeah, external content could vary. However local content has a unique URI, which is what watch folder and import do. So both could treat the URI as unique field. So Nightingale would have different behaviour based on the location of the file.

[rsjtdrjgfuzkfg]

(10-15-2013, 11:06 PM)freaktechnik Wrote: I was thinking in local URIs, but yeah, external content could vary. However local content has a unique URI, which is what watch folder and import do. So both could treat the URI as unique field. So Nightingale would have different behaviour based on the location of the file.

So it seems like you tend to the last option, too (consider the creation of local duplicates as bug, but do not change the library backend).

[fcastillo]

It's been almost a year and a half since we discussed this. Has any progress been made? Or at least the intention to do something about it?
My programming skills are basic, and after taking a look at stuff, I haven't been able to fix this.
For what it's worth, I also agree that the behavior should change only on local files, making the URI a unique field.