fix: Handle missing track metadata tags in parse_track

[blacklight]

I'm not sure if this is a recent change in the Tidal API, but I could reproduce the error on at least two different devices:

Traceback (most recent call last):
  ...
  File "/usr/local/lib/python3.10/dist-packages/mopidy_tidal/workers.py", line 7, in func_wrapper
    items = f(*args)
  File "/usr/local/lib/python3.10/dist-packages/tidalapi/playlist.py", line 159, in tracks
    self.request.map_json(
  File "/usr/local/lib/python3.10/dist-packages/tidalapi/request.py", line 218, in map_json
    return list(map(parse, items))
  File "/usr/local/lib/python3.10/dist-packages/tidalapi/media.py", line 302, in parse_track
    self.media_metadata_tags = json_obj["mediaMetadata"]["tags"]
TypeError: 'NoneType' object is not subscriptable

This PR makes parse_track more conservative my handling both missing metadata and missing tags.

[dogukanarkan]

I encountered the same error when I tried to list the tracks in a playlist. It breaks most operations. I think it should be fixed as soon as possible @tehkillerbee

[tehkillerbee]

LGTM!

[tehkillerbee]

It would be nice with some examples of tracks/playlists where this occurs.. Anyways, LGTM merged now. Will update the latest python-tidal release asap.

[dogukanarkan]

I realized that my playlist has a track named "Unavailable", and it was the problem. Can you check your playlist too? @blacklight

By the way, I tried your changes on my local, but I faced another error for this "Unavailable" track from the get method you added.

I don't know how it's added to my playlist, here is the "Unavailable" track:

[dogukanarkan]

I suggest you wait before releasing the new version. Maybe @blacklight has the same track as me, and the problem will be solved by deleting this track without code changes.

[blacklight]

I didn't keep track of which specific tracks raised the error, but the pattern I spotted was indeed with "Unavailable" tracks (in my case they were tracks removed from Tidal that were still in my playlist, hence breaking the metadata parsing).

[tehkillerbee]

I suggest you wait before releasing the new version. Maybe @blacklight has the same track as me, and the problem will be solved by deleting this track without code changes.

Yes, Ive also seen some strange behaviour before with tracks / albums /artists that has been removed after they've been added to favourites. That can sometimes give some unexpected behaviour from tidalapi. Generally, "Unavailable" tracks should be handled in a different way instead of fixing some fields that are missing, as done in this PR. I would suggest skipping them from the playlist, as they can usually not be parsed / played back anyways.

[dogukanarkan]

I didn't keep track of which specific tracks raised the error, but the pattern I spotted was indeed with "Unavailable" tracks (in my case they were tracks removed from Tidal that were still in my playlist, hence breaking the metadata parsing).

In my case, your changes didn't solve the error. I had to delete "Unavailable" track from my playlist.

I suggest you wait before releasing the new version. Maybe @blacklight has the same track as me, and the problem will be solved by deleting this track without code changes.

Yes, Ive also seen some strange behaviour before with tracks / albums /artists that has been removed after they've been added to favourites. That can sometimes give some unexpected behaviour from tidalapi. Generally, "Unavailable" tracks should be handled in a different way instead of fixing some fields that are missing, as done in this PR. I would suggest skipping them from the playlist, as they can usually not be parsed / played back anyways.

Makes sense to me, this way will be more wise.