Mopidy 4.0.0a15: Expected a TlTrack instance, not { ... }

Development
1

Sorry if this is a known issue, but I haven’t been following progress towards Mopidy v4 lately…

Running Mopidy-Mobile on top of Mopidy 4.0.0a15 on Ubuntu 25.10, every time I try to play a Track I get something like:

INFO Core-10 (_actor_loop) pykka
Exception returned from Core (urn:uuid:c323c8db-c76c-4329-b769-48cb08ff9161) to caller:
Traceback (most recent call last):
File “/usr/lib/python3/dist-packages/pykka/_actor.py”, line 242, in _actor_loop_running
response = self._handle_receive(envelope.message)
File “/usr/lib/python3/dist-packages/pykka/_actor.py”, line 353, in _handle_receive
return callee(*message.args, **message.kwargs)
File “/home/tkem/.local/lib/python3.13/site-packages/mopidy/core/_tracklist.py”, line 180, in index
validation.check_instance(tl_track, TlTrack)
~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^
File “/home/tkem/.local/lib/python3.13/site-packages/mopidy/core/_validation.py”, line 112, in check_instance
raise exceptions.ValidationError(msg.format(arg=arg, name=cls.name))
mopidy.exceptions.ValidationError: Expected a TlTrack instance, not {‘model’: ‘TlTrack’, ‘tlid’: 1, ‘track’: {‘model’:
‘Track’, ‘uri’: ‘internetarchive:tsp2007-06-06.mbho.flac16#tsp2007-06-06.mbho.d1t06.mp3’, ‘name’: ‘Today’, ‘artists’: [{‘model’:
‘Artist’, ‘uri’: None, ‘name’: ‘The Smashing Pumpkins\’, ‘sortname’: None, ‘musicbrainz_id’: None}], ‘album’: {‘model’: ‘Album’,
‘uri’: ‘internetarchive:tsp2007-06-06.mbho.flac16’, ‘name’: ‘Smashing Pumpkins Live at Columbiahalle on 2007-06-06’, ‘artists’:
[{‘model’: ‘Artist’, ‘uri’: None, ‘name’: ‘Smashing Pumpkins’, ‘sortname’: None, ‘musicbrainz_id’: None}], ‘num_tracks’: None,
‘num_discs’: None, ‘date’: ‘2007-06-06’, ‘musicbrainz_id’: None}, ‘composers’: , ‘performers’: , ‘genre’: ‘Rock\’, ‘track_no’: 6,
‘disc_no’: None, ‘date’: None, ‘length’: 205000, ‘bitrate’: 194, ‘comment’: None, ‘musicbrainz_id’: None, ‘last_modified’:
1429313735}}

I checked the Changelog and already improved 4.x compatibility for my extensions (e.g. “uri” being mandatory in “Track”), but this seems to be some sort of encoding/decoding issue related to frontends (educated guess)…

2

P.S.: I also tried upgrading mopidy.js to v1.3, but to no effect, AFAICS.

3

P.P.S.: Everything runs fine with Mopidy 3.4.2 on the same machine, of course.

4

I just released 4.0.0rc1, but looks like I maybe should try out some web clients before going ahead with a final release :sweat_smile:

5

Fixed!

I’m now successfully playing music with Mopidy-Mobile 1.1.0 combined with the just released Mopidy 4.0.0rc2.

Let me know if you find anything else not working!

6

Thanks for the quick (probably record-breaking) fix! I can confirm that browsing, searching and playing music from mopidy-internetarchive, mopidy-podcast and mopidy-dleyna now works with mopidy-mobile in mopidy 4.0.0rc2.
I will do some more “advanced” tests in the next couple of days, though.

7

I also did some tests with PlaylistsController, esp. creating/editing/saving/deleting playlists, since this is - in my experience - a less used part of the API. Looks good, so far :+1:

8

Thanks for taking the time to test!

According to the v4.0.0 changelog there has been no changes in the PlaylistController other than the addition of type hints, so it should hopefully no have any new bugs.

9

Yes, but AFAIK hardly any client actually uses this, so it’s my first go-to with new major Mopidy versions. My other “edge-case” test is searching for “Helden” globally, only for specific backends, and only on Mopidy-dLeyna → [server] → Music → Artists → David Bowie, by the way :wink:

Got some “Input should be a valid frozenset” from Mopidy-Podcast-iTunes and some random errors from Mopidy-dLeyna, but all on a per-item level, so general operations succeeded and faulty items were simply ignored.

So that’s probably something that I’ll have to look into, later.

So if you want to release, go ahead!