Chapter 4: Adventures With Change Tracking

So This week I was working on change tracking in Music.

What is change Tracking?
So change tracking is a mechanism to let the source know that there have been some changes in the server data, and your client should adapt to those changes. For example, let’s say we have an album and, I deleted a song from that album, so my source sends a signal to my client that there is a change in album container and, you need to update it accordingly.

We had to implement the same thing in Music. There was one problem with dleyna-server, But wait, what is dleyna-server? it is a set of services that allow clients to discover and manipulate media from DLNA server.
So the problem with dleyna-server is that it changes the media id set by DLNA server to its own path, although the path is unique for each item, it couldn’t be used to trace back to the element. I needed DLNA id to query the element, which was not possible with the path property.
To overcome this problem what I did was, I added an ID property to the media objects, that had the original IDs of object straight from DLNA sources. And now these IDs could be used for querying the elements from the DLNA source.

Now there’s a major problem with DLNA sources that, there is no defined structure to the server. Each provider has its own implementation, and hence a different structure. So there can be two or more containers for albums.
The problem was when a song from the server is changed, there is no way to tell for sure which container id we’ll get. To get over this problem what we do now is query all the albums and artists whenever we get a content-changed signal.

It was later in the week that I came to know that there was functionality in grilo-plugins that lets me get complete media from the path property, and I didn’t need the changes in dleyna-server for change tracking. But still, it would be great to have actual ids so that we can query media using ids.