It seems that the following rules apply to the icons shown for items in a database playlist on the Playlist tab:
— LIGHT GREEN for audio items drag/dropped from the library;
— ORANGE for ‘light green’ items which are customised; and
— LIGHT BLUE for non-audio items (e.g. Break, Silence).
So far, so good.
It seems also that every imported item also has a LIGHT BLUE icon (confusing), and any imported item with customised Properties does not change icon colour: it will always be LIGHT BLUE, no matter what you do to it (even MORE confusing).
I don’t know if this is a bug, or if it is intentional (?).
I think it would be much better to a) have a new icon colour for imported items (maybe purple?); and also (if possible?) another new icon colour for customised imported items (maybe yellow?).
[ledpurple.png and ledyellow.png, respectively, in Nuvola\16x16\actions ;)]
Would be interested in feedback on this suggestion.
I’ve seen those icons on the playlists pane of the database, next to the associated audio file. However, I’ve never undertood the relevance beyond a notation that the specific file is customized. Are these icons carried over to somewhere else?
Light blue does actually mean “item that does not exist in the database library”, aka “non-database items”. This applies to both non-audio items added through the Insert menu on the Playlist pane, as well as audio files (not from a listed mAirListDB storage) you drag into the playlist from an Explorer window.
Note that non-audio items can also be green, namely when you add them to the library first, and then drag (or schedule) them into the playlist from there.
Customized means that a database item was modified on playlist level, which is I indicated by the orange icon.
Non-database items can also be edited on playlist level, but as they don’t have a “reference copy” in the database, this is just regarded as editing rather than customizing, and their icon remains blue.
When you look at the “playlist” table in the SQL database, you will notice two fields: “item” (ID referencing the items table used for the library) and “xmldata”. For non-customized database items, only the item field is used. When the playlist is loaded, the item is restored from the library. For customized items, both the item and the xmldata fields are used. The former to keep in mind that the item was originally added from the library, to enable internal logging, etc., and the latter to store the actual XML data, just like an MMD file. For non-database items, only the xmldata field is used, and the item field is NULL.
That also applies to imported playlists, including MLP files. Which introduces an anomaly, IMHO. Here’s what I mean: open mAirList, open a database browser, drag items into the playlist from the database, then save that playlist as an MLP file.
Now open mAirListDB, go to a database playlist, and import your MLP file. All the items have light blue icons, which is technically correct because they came from an external source; on the other hand, it seems ‘wrong’ because the items in the MLP file did originally come from the database library.
A good point!
OK, but I still think it would be useful to have an ‘edited’ icon to indicate that.
If I recall correctly (don’t have a DB in front of me to check), item is a numeric field, yes? Perhaps ‘edited’ non-DB items should have -1 in that field to indicate that they have been edited? Just a suggestion.
I tried that, and it worked for me. All items will be displayed in green.
Have a look at the XML output in the MLP files. The items should have a “…” and “…” node. These nodes are used to restore the link to the database when you load the MLP file into either mAirList or mAirListDB.
Customized items should also have an entry in the “…” node.
[quote="Torben"]Non-database items can also be edited on playlist level, but as they don't have a "reference copy" in the database, this is just regarded as editing rather than customizing, and their icon remains blue.[/quote]
OK, but I still think it would be useful to have an 'edited' icon to indicate that.
No, I don’t think so. Because there is not “initial state” they could be restored to. Well, the data stored in an MMD file or tag, perhaps. But mAirList doesn’t keep track of any changes vs. these data sources. The main playlist doesn’t do either.
If I recall correctly (don't have a DB in front of me to check), [b]item[/b] is a numeric field, yes? Perhaps 'edited' non-DB items should have -1 in that field to indicate that they have been edited? Just a suggestion. :)
The field is declared as “item INT REFERENCES items”. That means it can only contain numbers that are also present as IDs in the “items” table, or NULL values (in case of non-database items). The “xmldata” field is used to tell apart edited and non-edited database items:
If xmldata is NULL, it’s the original item, and it will be restored from the “items” etc. tables when you load the playlist.
If xmldata is NOT NULL, it’s a customized item, and the data from the “xmldata” field will be used instead. (Exception: For file playlist items, the filename will always be restored from the item_filenames table, to avoid problems with hard-coded paths in the xmldata, in particular when accessing the playlist from a different PC with a different storage root folder.)
Summary:
item NOT NULL, xmldata NULL => original database item
item NOT NULL, xmldata NOT NULL => customized database item
)