The way that playlists are sent to subsonic clients confuses DSub

[StratusFearMe21]

The Problem

TL;DR, the way that this app stores and sends playlists to subsonic clients causes DSub to cache songs multiple times

For subsonic clients, according to this example, when you send them playlists, they expect the track number associated with each song in a playlist to be the same track number that the song has in it's parent album. This causes clients such as DSub which cache their music as files named like %tracknumber% - %title% to cache the same song multiple times if the track numbers in a playlist are in order relative to the list itself. For example, consider the following. You request DSub to cache the following album

1. Song 1
2. Song 2
3. Song 3

DSub will cache these songs under the following structure

└── artist
    └── album
        ├── 1-Song 1.ext
        ├── 2-Song 2.ext
        └── 3-Song 3.ext

Now, consider the following playlist where the 3 songs above are in the middle of the list

1. Cool Song 1
2. Cool Song 2
3. Song 1
4. Song 2
5. Song 3
6. Cooler Song 3

When DSub tries to play artist/album/3-Song 1.ext It will notice the file doesn't exist and consider it uncached. Causing this to happen

└── artist
    └── album
        ├── 1-Song 1.ext
        ├── 2-Song 2.ext
        ├── 3-Song 1.ext
        ├── 3-Song 3.ext
        ├── 4-Song 2.ext
        └── 5-Song 3.ext

Notice how every song from the album above is now cached twice.

Anywho, thanks in advance for considering this issue!

[paulijar]

Thanks for the report and that's an unfortunate design decision on DSub. I hate the idea of showing the album-based track numbers on the playlists as those make no sense in the context. But probably I have to do that anyway.

[paulijar]

The album-based track numbers are now used also on playlists of the Subsonic API in Music v1.6.0.