Playlist - Add track from local track ID...online track ID in playlist changes!? [Region Issue] about opentidl

[jackfagner]

Can you provide some example code for me to repeat this issue, or is it fully random?

[scgough]

OK, I have:

Update This code seems to do it every time. Adding ID 58085907 to a playlist actually adds ID 14831266...

            string playlistID = "[your-playlist-id]";
            string trackID = "58085907";   //'Range Life' by Pavement
            string tidalToken = "[your-tidal-session-token]";

            OpenTidlClient client = new OpenTidlClient(ClientConfiguration.Default);
            var mySession = await client.RestoreSession(tidalToken);    //session id
            if (mySession.SessionId != "" && mySession.UserId > 0)
            {
                string etag = String.Empty;
                try
                {
                    var tidalPl = await mySession.GetPlaylist(playlistID);
                    if (tidalPl.ETag != null && tidalPl.ETag != String.Empty)
                    {
                        etag = tidalPl.ETag;
                    }

                    var trackIds = new List<int>();
                    trackIds.Add(Convert.ToInt32(trackID));

                    var result = await mySession.AddPlaylistTracks(playlistID, trackIds, toIndex: 0, ifNoneMatch: etag.Replace("&quot;", ""));
                    
                }
                catch(Exception e)
                {
                    var t = e;
                }
            }

It does seem to be random though...I can't seem to 'catch' it in a debug....

[jackfagner]

Just a quick guess:
Maybe searchResponse.Items ordering is somewhat random, and searchResponse.Items.First() gives you different tracks from time to time?

[scgough]

That side of it is fine. I don't mind what order the search comes back in. The problem is that I say:

1. 'give me the first track'.
2. the id for this track is 58085907
3. I say add track ID 58085907 to the playlist
4. the playlist on tidal has track ID 14831266 in it?! (which is the same track but off a different album)

My problem is then that the ID I have 58085907 is then useless in the context of my playlist.

[scgough]

@jackfagner I've updated my example above. this is happening for every test I've done with it.

[jackfagner]

Thank you. I will have a look at it.
The API does not alter or process the track ID in any way, so it might be a server side "feature".

[scgough]

maybe...i'm wondering if it's something in the search...

thanks for looking anyway!

[jackfagner]

In the search? I don't see any searching in your example code (any more).

[scgough]

sorry @jackfagner - ignore the search. I was just thinking out loud.

[scgough]

@jackfagner - I've got a little further with this...the problem does seem to stem from what comes back in the search. I'm using your SearchTracks method in /method/opentidlpublicmethods to search.
I've slightly adapted it though to return the raw JSON from Tidal (as there are some more fields in it).

When I get the 58085907 ID back it only seems to be in a result set of 1. When I add this track ID it is auto-replaced on Tidal.

I'm trying to get that to come back in the raw JSON (but it's decided not to do it at the moment) as I'm wondering if there are any extra bits of data I can use to know whether to ignore the result and try to search again or skip on....

My thoughts are this is a legacy track of some kind on Tidal know that ID 58085907 should be replaced with another.

[scgough]

@jackfagner i think i've got it. the API is switching my territory between requests. There is a method GetCountryCode attached to each call and it is switching between US and GB. I've attached a screen grab. I noticed the ISRC codes were prefixed with the different regions.

I'm going to update the requests to allow a forced region code in my code.

On this result set, I've run the same search request twice but on one forced US and the other GB:

[scgough]

This wasn't just a matter of forcing one region (i.e. US) on every call. Tidal knows my user session is GB and always forces this on their side when I perform an action like 'add' a track.

Because of that I've worked the solution in another way. Searches and other lookups weren't honouring my session region so I've added a method to check the current session countrycode and make sure the client LastSessionCountryCode is always the same.

I've added this to OpenTidlClient.cs

public void SetCountryCodeFromSession(string countryCode)
{
    if (!string.IsNullOrEmpty(countryCode))
    {
        this.LastSessionCountryCode = countryCode;
     }
}

Then, when I successfully restore my session (to perform whatever action - search, add, etc) I call it so:

...
OpenTidlClient client = new OpenTidlClient(ClientConfiguration.Default);
var tidalSession = await client.RestoreSession(myToken); 
if (tidalSession.SessionId != "" && tidalSession.UserId > 0)
{
    client.SetCountryCodeFromSession(tidalSession.CountryCode); 
   ...
}

[jackfagner]

Should be fixed in 5edce4f
When I have time I will update the models and publish a new NuGet package.