Bug 707 - odd behavior occurs on OSX when multiple copies of the same song in different formats exist on the system
: odd behavior occurs on OSX when multiple copies of the same song in different...
Status: RESOLVED DUPLICATE of bug 775
Product: Logitech Media Server
Classification: Unclassified
Component: Formats
: 5.x or older
: Macintosh MacOS X 10
: P2 normal (vote)
: ---
Assigned To: Dan Sully
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2004-12-03 09:39 UTC by Kevin Pearsall
Modified: 2011-03-16 04:18 UTC (History)
0 users

See Also:
Category: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Kevin Pearsall 2004-12-03 09:39:03 UTC
The album in question contains 20 tracks. The directory contains
    40 files - 20 mp3s and 20 identically named m4ps. The copy
    protected AACs where downloaded from the iTunes Music Store, burnt
    to a CD and finally reimported into iTunes as mp3s.

    Everything is OK when playing an album via the remote (Browse
    Music/Browse Artists/Artist/Album/Play). The SlimServer correctly
    adds only the mp3s to the playlist.

    When playing the same album via the web interface, using a similar
    procedure (Browse Artists/Artist/Album/Add To Playlist), the
    playlist contains all 20 songs - however, closer investigation
    reveals that there are a mixture of mp3s and m4ps in the list. No
    tracks are repeated.

    The current playlist was cleared in both instances prior to doing
    the above.

    It's also repeatable - the same m4ps appear each time.

    I've got quite a few directories containing similar mixes of mp3s
    and identically named m4ps (file extensions excluded). The web
    interface consistently mixes both types of file when adding to the
    playlist.

    That explains why the first two tracks wouldn't play - they were
    both m4ps. Please ignore what I wrote in my previous post - I was
    jumping about between the Linux and Mac version of the server and
    probably got a bit confused.

    The really odd thing to note is that this problem only occurs on
    the OS X port, not the linux port of the SlimServer.
Comment 1 Vidur Apparao 2005-03-01 11:38:41 UTC
With 6.0, both versions should show up. Kevin, could you confirm and resolve the
bug?
Comment 2 Kevin Pearsall 2005-03-02 09:26:30 UTC
i don't have a copy of an album like this, so i asked the customer that reported
it if he could try the latest nightly of 6.0.  if i don't hear back i'll create
something manually.
Comment 3 KDF 2005-03-02 13:12:57 UTC
This looks like a dupe of 775 actually.  6.0 builds recently were thining m4p's
were mp3 files, but 6.0a2 should be properly ignoring them in the scan.  This
will solve the m4p/mp3 confusion, but other formats need to be checked, possibly
resolving both this and bug775.
Comment 4 KDF 2005-03-11 16:36:29 UTC

*** This bug has been marked as a duplicate of 775 ***
Comment 5 Chris Owens 2008-12-18 11:50:16 UTC
Routine bug db maintenance; removing old versions which cause confusion.  I apologize for the inconvenience.