Hi, i’ve had a few incidents really where non tagged items in automation get to zero and freeze, they won’t disappear when stopped playing and in automation means playback stops.
I’m wondering if there is, or if it would be possible, to get a script that i could run that scans the playlist and forces a check on the cue in/out/fadeout points and sets them to whatever settings you have in the config e.g. -9.76db
Any ideas??
Best Wishes
I think the way to do that is:
If you use Excel, you can also use my scripts which import and export the contents of MMD files to ‘reconstruct’ any of the ‘old’ MMDs whose data (like Ramp points etc.) is ‘lost’ by this process. Sorry, but I haven’t had the time to finish the OpenOffice versions of those macros.
BFN
CAD
Hi Cad,
i believe im right in saying that if you insert a playlist to a playlist, the songs are added but mairlist doesn’t go through and analyse them like it does when inserted via the browser or explorer.
What i need to do is to get mairlist to scan and check etc all files when a playlist is inserted, again im thinking of the script by theo where i would have an automation playout system, where currently songs seem to freeze in players when ending if they don’t have some sort of fade out/start next point set.
Does anybody else have that problem? however, thinking about it, the timer counts down to 0.00.00, where i expect the next record to start, instead nothing happens and the timer starts counting up, when it ends everything goes dead in automation and the player won’t unload. without a restart there is no real way of getting that player back as it seems almost “stuck” in some sort of play mode!
I do realise this is turning into a bit more of a bug than a script question!
In the German forum, someone reported that in v3 a player might freeze when you have a Cue Out marker set. I haven’t been able to confirm this problem (at least not with the new Build 538, in which the internal cue point processing is somewhat different), but if it’s true, it might be the same problem as Lackster stumbled upon (if we’re talking about v3 here).
Can you please download the latest snapshot and confirm if the problem remains? If so, it must be related to the config. Timo, who discovered the issue in the first place, has sent me his already.
Hi torben,
we are talking about v3 here. has there been a new snapshot in the last 2 weeks? if not then i am currently using the latest snapshot.
It does sound exactly like the same problem that was mentioned in the german section.
Thanks
I have uploaded a new one just yesterday. It hasn’t been announced though 
(Except for the thread in the German forum where the issue was reported.)
Oh, and by the way, it was not Timo who pointed out the issue but Ssnake, but I don’t have Ssnake’s config. So if you think that the issue is still present in b538, please send a copy of your ini files to info@mAirList.com.
Hi Torben, i will send you a copy of my .ini files later on this morning (about lunchtime). Do you want all of the .ini or just certain ones?
I will download the latest snapshot in that case and see if the problem is still there.
Thank You.
I think only mAirList.ini will do.
Hi Torben,
i have sent you the file and also downloaded the latest snapshot and can report that the problem is still happening unfortunatly!
Thanks
Phil
I think I found the problem.
This happens when Cue Out is very close to the end of the track, actually so close that EOF is reached before the Cue Out notification is processed by the player in the first place. When the player tries to stop the channel as a result of the Cue Out notification, and it is already at EOF, the channel would complain “hey, I’m not playing anymore, you can’t stop me!”, and this causes the player to hang.
I will upload a new snapshot in a few minutes. Just looking into some other issues.
Blimey, that was quick!!
Thank you very much Torben, look forward to trying out the new players!
Many Thanks
Build 540 now available.
Everybody who follows @mAirList on Twitter knew first