Over the last few weeks, some playlists loaded and run from a simple event run for a few seconds and then fade out. I’ve noticed that where I have a playlist with 3 or 4 short items of a minute or so each, this doesn’t happen. The main playlists tend to have 1 item which is usually a 58 minute long MP3 - but we have them running 24/7 with a new event running at more or less the beginning of each hour. The files are OK because if I run them manually they work fine. Mairlist is running in AUTO mode. Is this a configuration item that I’ve accidentally set or is there a workaround that could solve my problem (like putting a dummy entry into the single item playlists so there is more than 1 entry like the small lists that seem to work OK but hold 3 or 4 or 5 entries).
What I have difficulty in understanding is why it is only recently that this problem has emerged - I must have somehow changed something. I updated to 4.1.4 to see if that would help and then to build 1505, but it was happening on 4.0 as well.
Version 4.1.4 build 1505 on Windows 7 64 bit Home Premium with 2GB RAM and 390GB free disk capacity
I’ll look at the log as soon as i can, but it does start to play the files and then begins a fade out. The status on the right hand side of the file displays fade.
The are no fixed times set as far as i can tell - the files are all about the same length of 58 mins give or take a few seconds.
I’d be surprised if this is a bug since it has worked fine for ages, so i’m sure its something else like a configuration item. The playlists rotate over a 4 week period - there are about 20 playlists set to run per day so many many events all set to run once and then i change the date for them to play again on the next 4 weekly rotation. I did have them set to run against a range of dates but in the end went back to simplicity which means more events but easier to manage. This is the only change i’ve introduced in the last month.
Ive just checked the current playout and it is playing ok. One of the obvious differences between the playlist thats running at the moment and the ones that have failed is that this one has 2 files in it - a short 5 second introduction and then a long file that is about 88 minutes.
Have now checked the system log and the only indicator is that Playlist 0 ran empty. This will of course happen if the the playlist completes and the next one doesn’t start for a few seconds, but also if the item in the playlist fades itself out.
Cue Out - will check, but I don’t set them. Basically I have a 2nd player configured with a different USB sound card (because this is a single live app) and typically, if I have to create a new playlist to trigger using the Event Scheduler, I drag the file into the 2nd player and save Playlist2 to a realname.mlp in its target folder. Then I go into the Event scheduler and setup the date and time and point it to Load and Play the new mlp.
The only tricksy thing I do is to use a generic filename for the MP3 so, when a new radio show is created (next week), the new version replaces the old one using the same name and the playlist picks it up by default from the same place.
We receive an off air email when the playout isn’t playing and it looks like it has run fine overnight ( a glitch at 08.00am for 40 seconds but I know that’s a human error).
Overnight will have involved about 20 events running (ad break, message about not sending in texts, show every 60 or 90 mins from midnight to 08.00am).
Perhaps I just need to take it off line for 4 hours and remake all of the events so I can eliminate spurious cues etc that may have crept in. Oh for the luxury of a a dev system !!
It’s possible that mAirList is adding a FadeOut point you aren’t aware of.
I would make sure you DON’T AutoCue pre-recorded shows when you first import them into mAirList, and that you ALWAYS check them in the Cue Editor after loading them the first time. If that’s not possible, and the first time the show audio file is loaded is when it goes on-air, then make sure on the Miscellaneous, Auto Cue dialog in Config that ALL checkboxes are cleared.
Thanks. Weve got a silence detector running 24/7 that sends me an email, so i can work out which playlists are failing and when. Planning to delete them and recreate the playlist and event. When i do that i’ll make sure the boxes are unchecked as you advise. This’ll take a while because we run a 4 week rotation of events.
Revisiting this one again. After eliminating human error in playlists, event scheduling etc, there are still some unexplained failures. Recently saw a message that pre buffering had failed for a playlist - this seemed to take place whilst an event triggering a playlist had been underway for about 20 minutes or so. Also noted that ad hoc failures sometimes seem to co-incide with some Windows events taking place (such as the reminder that I haven’t made an image copy of the PC). As these things occur, I’ve tried turning them off or making changes (reducing % on buffer). Also seen an error that says application frozen. I had intended to put Mairlist onto a different platform, but haven’t got any PCs that are significantly better spec wise
Could you just confirm the minimum and optimum hardware spec in terms of RAM required (we have 2GB on W7 64 bit Home) and anything else that could be relevant. Disk space is fine (about 22GB free)The PC may be running into occasional brick walls.
Just have a look at the Task Manager. A typical mAirList instance doesn’t need more than 30-40 MB when idle. But that could increase, of course, when you use things like RAM buffering for network files etc.
Typically each playlist will have a single MP3 stereo 128K file varying between 25MB through to 85MB or thereabouts. The failures have happened on shorter and longer playlists. Here’s another odd thing that may or may not be normal. The On Air / Auto ‘bar’ that shows when the next event is due seems to flicker or pulse a bit, a bit like it’s being refreshed. There are usually 2 playlist windows running - playlist 1 which runs the 24/7 events (i.e all of the broadcast playlists) and playlist 2 which is only there to enable me to amend playlists (which are then called through the Playlist 1 set of events). The 2nd playlist bar doesn’t pulse, the 1st one does.
Does the software keep polling against an event list when it’s running and could that be the reason for the pulsing?