My app for mopidy works with some playlists which are not frequently changed. One of them is a radio playlist another one a playlist for music tracks.
All handling of these playlists is based on tracklists and tlids. If I change between these playlists the tracklist is cleared and the correponding tracklists is loaded.
The app stores all needed trackdetails for all playlists so that a change between music an radio does not require websocket communication except uploading new track uris.
However, whenever a tracklist is created mopidy assigns another range of tlids to the tracks than before for the same playlist. This makes it necessary to read the tracklist into the app to be able to update the existing tlids there. For the about 500 tracks of the music playlist this means a little delay. Not anoying, but I wonder wether there is another possibility. Of course I could go away from the tlids, but the tlid handling is quite comfortable. When scanning the modipy documentation I stumbled over the possibility to read the tracklist version. This brought up the idea wether it might be possible to restore specific tracklist versions without a new upload of track uris.
In the documentation I did not find any hint about a command to restore a tracklist.
question 1: can tracklists (within the version history) be restored - if yes, how ?
question 2: is it possible to force mopidi to start the tlid numbering for a new tracklist from a specified value ?
Another point which I experienced was that the tlids are not unique over subsequently loaded tracklist. Sample: I load the radio uris to mopidy to create a tracklist. After hearing some radio, lets say that was the third track, I want to change to my music playlist and upload the music uris. Now by chance I want to start the third track from the music tracklist. This did not work with my app and it turned out that the reason was a check of tlids before sending the play command. If the play method sees the same tlid as before then it usually sends a stop command except status is stopped. No problem to work around this, but I was surprised to see that the same tlids can occur in different tracklists.
From my understanding the tracklist entity is not to be confused with the library entity. Tracklists are loaded per request given and tlids are normaly reused. This becomes very obvious once you call on services like mopidy tidal, call on tidal:track:1231212 loads a tracklist as well as tidal:album:272727dd8a7s67s or tidal:playlist:2727u22u22 (all fake ids just in case). I’m very surprised about your findings:
“The app stores all needed trackdetails for all playlists so that a change between music an radio does not require websocket communication except uploading new track uris.”
I would expect this to be more of a coincidence due to so few playlists being used. But I might be wrong.
Adding tracks to the tracklist will always return you the TlTrack objects you just added. You can decide to ignore that response data if you want but Mopidy will always send it so you are not actually saving any data transfer. The tlid for each Track is different each time you add it to the tracklist. There is no avoiding that.
Caching the Tracks themselves is a reasonable thing to do, but there’s no point keeping old tlids.
The tracklist version is specifically for clients to tell when they have an outdated view of the tracklist. Perhaps another client made a change, or tracks were consumed or whatever. You cannot restore old versions of the tracklist, Mopidy only stores the current tracklist state.
So the answers to your two questions are no and no.
I don’t think I understand your last paragraph. Tracklist IDs are not reused and they should be unique. They are only reset back to zero when Mopidy is restarted (unless you are using the restore_state config option, I think, then they will carry on where they left off?). Mopidy will check the tracklist ID you provided is present in the tracklist. I don’t follow what the problem is, or exactly what you are doing. Please provide a debug log if you want us to take a look at this else we can’t help.
Hi kingostick,
thanks for that hint. Again I learned to really read completely! When I looked at the documentation of “core.tracklist.add” I did not notice that it already returns the tracks including tlids. So, no need to call “core.tracklist.get_tl_tracks” after that. Code is changed and works.
In my case there is no risk for outdated tracks - mopidy has only one client in that Alarm-Clock-Radio. I replaced the electronics of an old NP3900 from Philips. Only the case, amplifier and power supply is still the old. As often seen in Audio/Video components from known brand companies the quality of the system itself is excellent but all data components remind to “Commodore” or “PET” times (1970th).
About the identical tlids in different tracklists I will do more tests later. I am quite sure to have seen that - however checking the current logs show allways different tlids.
if self.core.tracklist.get_length().get():
self.core.tracklist.clear()
self.core.tracklist.add(uris=track_uris, at_position=1)
first_tlid = self.core.tracklist.get_tl_tracks().get()[0].tlid
play = self.core.playback.play(first_tlid)
first_tlid is the first track of the newly added playlist.
As it is still under development it may contain obsolete code.
If there is a better way feel free to suggest ;-(