Player#browse startIndex, 0 based?

[jeffandersen]

I have a question regarding this method: here

Player.prototype.browse = function (objectID, startIndex, requestedCount, callback) {

When browsing media and I pass the following arguments:

browse('A:TRACKS', null, 10, myCallback);

I receive a list of tracks, and I presumed that I would be able to then do:

browse('A:TRACKS', 10, 10, myCallback)

to receive the next ten tracks. That doesn't seem to be the case. I end up getting way different results when simply incrementing the startIndex value (even by one).

Can you shed some light on the operation of this method?

[jishi]

Hi, yes startIndex is 0 based, so 1 would skip the first track. When I'm testing this using device spy, I get the expected result, also when I'm testing sonos-discovery I also get the same result, meaning that:

p.browse('A:TRACKS', 0, 1, function (status, result) {});

Will return the first track in your library, and

p.browse('A:TRACKS', 1, 1, function (status, result) {});

will return the second track from your library.

Your example should return the first 10, and the second example should return 11-20 as you expected. What is your observation? I only have 7 tracks in my own library, so it might not be representative of the common setup, but the amount of tracks shouldn't matter, unless the sorting becomes random.

[jeffandersen]

I'll provide some examples of inputs/outputs given my current library:

p.browse('A:TRACKS', 0, 5, cb);

• Podcast - Track 1
• Podcast - Track 2
• Podcast - Track 3
• Song 1, Artist 1
• Song 2, Artist 1

Now this would assume the two top podcast tracks would not be included:

p.browse('A:TRACKS', 3, 5, cb);

• Podcast - Track 2
• Podcast - Track 3
• Voice memo - Track 1
• Voice memo - Track 2
• Voice memo - Track 3

So all of a sudden, introducing an offset while viewing the tracks list causes three new items to be shown and not the originally shown song tracks.

I did the same test with the A:ARTIST id:

p.browse('A:ARTIST', 0, 5, cb);

• Artist 1
• Artist 2
• Artist 3
• Artist 4
• Artist 5

p.browse('A:ARTIST', 3, 5, cb);

• Artist 3
• Artist 4
• Artist 5
• Artist 6
• Artist 7

Which works as expected. So something appears to happen when your library consists of mixed types? Maybe A:TRACKS sorts different in that case? Baffling.

[jishi]

Well, it's weird because I only relay the response that I receive from the players, so if this occurs here, you should see the same behavior from the players. Du you have any UPnP testing tool that would allow you to query the players directly? The intel tools has one called "Device Spy" which allows you to invoke the actions with your own values.