If you change the name of a song or the artist, this will be reflected directly in the playlist.
But in the following conditions, it will not:
- If you change the name of the song from a PlayIt Live instance that is syncing to the main instance. Then the changed name will only appear on the local instance and is not transferred to the remote.
- If you change the name of the song, the Shoutcast and "Now playing" plugins won't update until the song appears again as a result of the playlist being generated again in the future.
Any data must be changed at the server side (main instance). How are you changing the name of a song from a synchronised PlayIt Live instance - this should not be possible?
The playout log refers to tracks by ID so any updates to the track will be reflected in the playout log and in now playing data. The only exception to this is tracks that have already been loaded into players - these are not updated.
Interesting. Think I know how this happened. I didn't bother reading the manual and simply set it up by trial-by-horror. The key is that both instances use the same storage for everything and I then use "Track path substitutions" to fix the paths...
The automation server's C:\ProgramData\PlayIt Live is mapped to \\192.168.1.61\store (its IP)
The client is installed the same way and therefore the mappings indeed do work. This means Voicetracking is a matter of recording straight onto the server from the client and then the database is updated with the path.
Hmm.... I remember you said this is not a supported configuration when I asked about earlier..
I will look into my eclectic setup and try to change it to use it in a supported way.
As a slight aside, it is also true that with a single system just using one PC, if you edit a track that is playing (having spotted an error in the metadata) it will update in the playout log but not (understandably) in the player window or the track information used for streaming.
I don't think this is unexpected, I can see why it works like this and at least I've fixed the data for next time.
Agreed. Mr Allen's explanation made me understand why this is not really a problem. Seems totally logic to me now.
And the other thing is probably a problem on my part. So it's good that's been sorted out :)