Playlists really don't carry any of that information. Its just a list of files without any additional data attached - any actual data is always on the files.
I would recommend to just store your own playlist seperate from the last MC playlist that you retrieved. That way you can determine what changed on your side and what changed on MCs side, and apply any kind of smart merging of changes.
I don't need to store my own playlists. Androids Media Store stores playlists system wide and I insert into it. Witch is also kind of important or this kind of app would be useless. I do not intend to write a music player on top of it. I already store playlists with the ID they have in JRiver and in the MediaStore in my own database as well as witch entries within that playlist where synced by my app at what time. But that does not change that I still know absolutely nothing about when JRiver added or removed songs. So the "smart merging" will be destent to fail in many situations.
It can work, sort of. But not perfectly well without screwing up ever. It will mess up the moment you change the same playlist on both ends and then hit sync at the very least. The rest is possible to mostly get working ok'ish.
---
Even if it's just files without having that version yet. You could always add another place to store that information in. Just how you do it with all the other stuff you persist. I don't know what your concern is about adding that. It's more whether you think it's important enough to actually do it, or not?
Either way you have some time to think about it. I have a boat load of other things that I want to implement in that same app.
I'd be very thankful though, if you could make this a thing at some point!
----------------------------------------
Rough, abstract examples how I think the solution could be as I have no idea how exactly JRiver works internally.
If I understood that correctly what you are doing is probably something like
playlist1.txt
path
path
path
"path" could be a file path or effectively the ID of sorts the song has in JRiver or some internal link to it. But let's call it path, path is fine. Path always works.
Probably not a good idea to add the timestamp to that I agree. Since it would break the playlist should you move down a JRiver version. But nobody would ever notice if instead of writing only to that one file you create another.
playlist1.info
path or song id | timestamp | maybe something else someone might want at some point
I'm just saying it's file for now. But it could be a DB whatever you use a lot in JRiver. Then you can add it as a field to the already existing playlist endpoint, or another one should you choose to do so, since your API is versioned (is it actually?) it seems like you'd want do that instead maybe. But it seems like the format you went with for the XML makes breakage by adding more fields very unlikely.
I would prefer a log type of situation where whenever a song is added, removed or moved in a playlist you just add that to a playlist history type of file or db,then that could be returned by a new playlist history endpoint. Would give out more information. Would be more to parse, but that's fine with me. When syncing my 2515 file library, the XML parsing currently takes a little more than half a second (on my phone). That includes reading the 78.571 lines of XML with all the songs listed in it. The history DB cannot be that big I don't think and you could add a TTL to those history entries or a maximum size.
Author
Topic: MCWS: Playlist Item Timestamps (Read 3384 times)