View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0011097 | MMW v4 | Framework: Scripts/Extensions | public | 2013-07-24 05:17 | 2013-07-26 17:29 |
| Reporter | zvezdan | Assigned To | |||
| Priority | high | Severity | minor | Reproducibility | always |
| Status | assigned | Resolution | reopened | ||
| Fixed in Version | 4.1 | ||||
| Summary | 0011097: Strange behavior of ISDBPlaylist::CreateChildPlaylist | ||||
| Description | Here is the description from Wiki: "Creates a new sub-playlists of this playlist with the given Title. Reference to the newly created playlist is returned.". Please note the words "NEW" and "NEWLY". Now, we have two problems. 1. If there already exists a sub-playlist with the given Title, we would get a reference to that existing playlist, but not really "to the newly created playlist" with the same name. Well, it is fine for me because I really don't understand why MM GUI allows creating of playlists with the same name inside of the same parent playlist. However, I think that we should be somehow informed if the reference is to the new sub-playlist or to the existing playlist with the same name. Also, you should modify your description accordingly, because it is now misleading. 2. If there already exists a sub-auto-playlist with the given Title, we would get a reference to that existing auto-playlist. This is really unwanted because MM API doesn't allow modifying of auto-playlists and because of that behavior we could get the issue with AddTrack method mentioned in [11092]. One solution to the first problem would be adding a new property ISDBPlaylist::ChildPlaylistExists(Title As String) As Boolean, which we could test before CreateChildPlaylist. ISDBApplication::PlaylistByTitle cannot be used for this purpose because of this another problem with the mentioned property: "If multiple playlists with the same name exist, PlaylistByTitle returns the first one it finds in the database." Now, I am using For ... Next loop with ChildPlaylists to test if such playlist already exists, but it would be much cleaner if you add the suggested ChildPlaylistExists property for that. Alternatively, or maybe even better, you could add one new property similar to PlaylistByTitle, but with one more argument, e.g. PlaylistByTitleEx(ParentPlaylist As Object, Title As String) As ISDBPlaylist. | ||||
| Tags | No tags attached. | ||||
| Fixed in build | 1652 | ||||
|
|
Added new ISDBPlaylist::ChildPlaylistExists(Title As String) As Boolean in build 1652: http://www.mediamonkey.com/wiki/index.php/ISDBPlaylist::ChildPlaylistExists And updated the description of http://www.mediamonkey.com/wiki/index.php/ISDBPlaylist::CreateChildPlaylist |
|
|
Thanks for the new property. However, we still have the second mentioned problem with auto-playlists. I think that there is not any valid reason for CreateChildPlaylist to return reference to some auto-playlist, even if it has the given Title. As I said, your API doesn't allow modifications of auto-playlists, your API even doesn't allow creating of truly new auto-playlist, i.e. if you specify Title which have none playlist, then you would always get the new static playlist as a result. So, if we cannot create some new auto-playlist, why should we get a reference to some existing auto-playlist using the mentioned method? Actually, when I think more about those problems, it seems to me that you should remove a possibility for CreateChildPlaylist to return a reference to some existing playlist, static or auto-playlist. I think that you should create another static playlist with the same name anyway. Yes, I don't like multiple playlists with the same name inside of the same parent, but your GUI already allows that. Then, why not allowing that to your API as well? As I said, it would be better if you have added a property which returns the playlist object. The script could test if playlist with the given Title exists even with such property, comparing it with Nothing. Here is the example how to get a reference to the existing playlist with the same name if you decide to modify CreateChildPlaylist to always create a truly new static playlists: If oParentPlaylist.ChildPlaylist("Title") Is Nothing Then Set oChildPlaylist = oParentPlaylist.CreateChildPlaylist("Title") Else Set oChildPlaylist = oParentPlaylist.ChildPlaylist("Title") End If However, if some script wants to create the another playlist with the same name, it could have just: Set oChildPlaylist = oParentPlaylist.CreateChildPlaylist("Title") Please note that I am using here one another suggestion for the property mentioned in issue 0011100. |
|
|
After even more thinking, I begin to see how complex this problem is. I hate to say, but it seems that none of my suggestions is too much useful. Let say that I want to add static playlist within some parent. If I check with ChildPlaylistExists if playlist with the same name exists, and if I get True as a result, I still don't know if that playlist is static or auto-playlist. If you add my another suggestion with ChildPlaylist property, I could test its resulting playlist if it is static or auto-playlist, but if it returns auto-playlist I still don't know if there exists the static playlists with the same name, but with higher ID. I would need to use For ... Next loop and ChildPlaylists property anyway, just to be sure that the static playlist with the given Title exists. Nevertheless, I still think that CreateChildPlaylist should not return a reference to existing playlists, but to create a new static playlist with the same name in case that playlist with the given name already exists. |
