Hi Torben,
Are you able to program the colour setting into the MMD info for each item ? Using an M3U playlist (from a scheduler), we’d be relying on most of the data in the meta file (in/out/fade) + hopefully, colour.
Browser - I have added the extension LNK in the config, hoping for mAirList to read Windows shortcut files, unfortunately, it doesn’t - Our library system creates shortcuts of music into various subfolders (whilst the real audio is all in 1 folder). When I enter LNK, the Browser will show them - But the item produces an error in the playlist when loaded.
This would allow DJs to browse our playlist groups more effectively, not pick “random” songs from the A-Z browser view.
I think mAirList is almost ready to go on-air here now, and Torben will get a cookie for his dedicated work
Charlie: a LNK file is Not a Nice Thing for programmers to deal with. You have to a) open the LNK file, b) decode its contents, and in this case c) check whether or not the Target File extension is one which your mAirList accepts or not, and finally d) check whether or not the Target File actually exists at the location specified.
This is all before you can load it into a Playlist or Browser; and this overhead will be needed for every LNK file. Plus, I assume you do know that LNK files are NOT updated by Windows when the associated Target File is moved to a new location and/or deleted?
PS: Do any other playout systems support Shortcuts to audio files, rather than the actual files? It’s not something I’ve ever tested (!), and I would be interested to know.
Exactly. It’s not a big deal to decode the LNK file (only takes a little overhead which will hardly be noticable on a fairly fast machine). This will most likely be done as soon as you drop the file into the playlist. However, mAirList does not know the actual file type then, but will just try to open the referenced file. So you have to make sure for yourself not to drop any link to a non-audio file into your playlist.
Charlie: Are these only links to file or also links to folders?
Torben - They are just links to files. Station Playlist Creator supports these shortcuts (this is how we schedule). It’s not mission critical - But a “nice to have” as it would then enable DJs to browse via groups/categories.
It might be better to decode LNKs when the Browser Directory or Tree is populated, because you could display ‘invalid’ LNKs (e.g. to a folder or to a non-supported file type) differently in the list—like strikethrough or greyed out?—or just not add them to the list at all.
I presume that the Drop event code for Playlists and Players could also check the LNK content and also reject LNKs which point to folders or non-supported file types, preferably with a MessageBox like:
The shortcut you are dropping points to a folder.
You can only drop shortcuts which point to supported file types.
or
The shortcut you are dropping points to a file type which is not supported.
You can only drop shortcuts which point to supported file types.
as appropriate.
[quote=“Cad”]It might be better to decode LNKs when the Browser Directory or Tree is populated[/cad]
This is out of my scope. The directory browser is a 3rd-party component which I cannot change (only customize).
Apart from the filter in the directory browsers, mAirList does never check the extension of file, not even when dragging a non-linked file from Explorer into the playlist. This is because BASS.DLL might be able to open and play certain file types mAirList is not aware of, for example through plugins. BASS.DLL can also detect the type of a file if it has an incorrect file extensions. MP3 files will play play properly even if you name them .doc. So it’s not a good idea to block any file by its extension only because mAirList does not know about it. If BASS.DLL doesn’t like the file, the item will have the error flag set.
- Our library system creates shortcuts of music into various subfolders (whilst the real audio is all in 1 folder). When I enter LNK, the Browser will show them - But the item produces an error in the playlist when loaded.