An empty Container loaded into a Player correctly shows ERROR both in the Player and (if you have the Time column showing) in the Playlist. If you then open the Container tab in the container item’s Properties dialog and drag/drop items into it and click OK, the container is not re-checked for errors. The only way to correct this is to drag the container item up/down the Playlist to force it to load into a different (or the same) Player.
I would call this a bug. If a container’s item list (Container tab) is changed whilst it is loaded in a Player, it needs to be checked again for errors. I didn’t try clearing all the items from the Container while it is playing in a a Player, but obviously any fix would need to cater for that possibility (if it doesn’t already).
Maybe you internally need to add some kind of ‘dirty’ flag specifically for a Container’s item list (again, if doesn’t already exist! ;D)?
[EDIT] Also, when an empty container is loaded in a Player, the Player’s Title test is set to Container is empty. The message would be more helpful to the user if it read [containername] container is empty; or maybe you would prefer to leave the Title text as it is and instead set the Player’s Artist text to [containername] if it’s empty? Your choice, Torben! ;D
Not a bug. Rather a known limitation: Once an item is loaded into a player (or prebuffered, as in v4), its contents cannot be changed anymore. You have to reload the item in order to update the playback.
This is not only the case for containers, but also for ordinary file items - you cannot change the filename when the item is already loaded. Well, you can, but it doesn’t make any difference, the player will still play the old file.
The message “Container is empty” that you see is the error message returned from the audio layer when trying to play an empty empty, and the message does not include the title of the element.
I can understand this for a file but, to the user, a container doesn’t ‘feel’ the same as a file item. I now understand why changing container ‘content’ won’t work while it’s loaded …
OK. But you can change things like fixed times, cue marker values, Title and Artist, etc. in an item loaded into a Player, correct? Including containers?
So, the audio layer ‘controls’ the Player, correct? Hence the Player doesn’t ‘know’ any Properties of an item until the audio layer loads it? It would be better (if possible) to have the audio layer pass at least item Type (file/container/region container/stream), Title, and Artist values to the Player before it attempts to load the file (or container): then the Player message could contain helpful information.
For containers - to some extend. v4 has improved the situation a lot. The container playback uses the same new code as the Mix Editor, and just like you can move cue points etc. in the Mix Editor during playback, you can do so for a loaded (and even playing) container, although you will notice a small gap in playback.
So, the audio layer 'controls' the Player, correct? Hence the Player doesn't 'know' [b]any[/b] Properties of an item until the audio layer loads it? It would be better (if possible) to have the audio layer pass at least item [i]Type[/i] (file/container/region container/stream), [i]Title[/i], and [i]Artist[/i] values to the Player [b]before[/b] it attempts to load the file (or container): then the Player message [b]could[/b] contain helpful information. ;)
What I called “audio layer” is the IAudioSource object (and in v4 the ISourceControl object on top of it).
Basically, when loading an item into a player, the player calls the BuildAudioSource method of the item, passing the sound card on which the item is going to be played, and receiving an IAudioSource object which can then be used to start, pause, stop etc. playback.
The IAudioSource object does in fact observe the item and adjusts itself when cue points etc. change. In particular the IAudioSource object is responsible for reporting when Start Next or Fade Out is reached, so it needs to have these positions up to date at any time. However, the IAudioSource object cannot do anything when the content of the item changes - in this case, a new IAudioSource object has to be created, which means that BuildAudioSource must be called again, which in turn means: reload the player!
If BuildAudioSource fails for some reason - file not found, container is empty - the player changes into Error state and displays the error message instead of the title.
I don’t think it makes much sense to include the item’s artist or title in the error message, because it takes up space which might be missing on the right edge, causing the actual error message to be cut off. You can also just look at the playlist to identify the failing item.
