New to the forum here. Been using mAirList for about 3 months now (although the organisation has had it for years!)
Currently on version 4 … and 3 times this week whilst we were on air the database went missing. Had to restart mairList for it to return. There was an error message hiding behind the main window but I was in too much of a panic to wrte the hex numbers down.
Has anone got any ideas?
I’m using a remote database on a network drive, along with the songs (in a different folder structure…)
The PC doesn’t lose the network connection as the drive is still available in explorer - it’s just mAirList that loses sight of the database.
Any help for a new user would be greatly appreciated.
Check the system log (double click the status bar at the bottom of the main window and the log window will pop up), there should be a message about it. You can copy the messages with Ctrl+C and post them here if you need advise.
If I understand correctly, this is a “local” (single .db file) database with the db file stored on a network folder? This is not a recommended setup, at least when you plan to access it from multiple computers at the same time.
As the database file is kept open all the time, even small “hiccups” of the network drive can have a negativ influence and make the database connection drop.
If it’s only one computer, consider moving the db file onto the local hard disk. If there’s multiple clients, you should move to the PostgreSQL backend.
SQLite should only ever be used for the scenario where there is one single mAirList PC in use. If there is (or could be) more than one mAirList PC, you must use PostgreSQL.
Even if there is only ever one computer accessing the database, if the .DB file is not and cannot be stored on a locally-attached drive (internal or external hard drive, SSD, memory stick, whatever) for some reason, again you should use PostgreSQL and not SQLite. PostgreSQL is designed to be used on networks, SQLite is not. That may sound like overkill, but it gives you MUCH greater reliability. Also, using PostgreSQL to start with makes it MUCH easier to add more mAirList licences/PCs later.
Most likely this was some sort of network glitch. Without poring through the Windows Event Logs on all PCs concerned, it’s hard to say what exactly is going on. However, things to check (apart from Event Logs!) are network cards (properly seated? cables secure and not ‘hanging?’), network card drivers (crashed? out of date? not correctly set up?), and network switch boxes, hubs, routers, etc. (ALL cables secure? any error lamps? correctly set up?). And, of course, the network cables themselves.
Oh, and if you use WiFi in your network, I suggest you convert ASAP to Cat5 cabling. Yes, it’s uglier and ‘old-school,’ but it’s much less vulnerable to problems than WiFi. I work in tech. support and it’s a simple fact that WiFi networks, especially in areas with a lot of electronic kit around, are not as reliable.
We’re off-air now (we were running a course with an RSL licence) so I have more time to dig into things and so on.
My tech guy assures me we are running on CAT5 cabling (he speaks from bitter experience!)…
What confused me is that the PC didn’t lose site of the network drives. It seems it was just mAirList that was affected. (Admittedly it was the only software officially running at the time!)
In all the database went missing 3 times in 7 days. Very worrying! Mostly it was early morning after a night’s worth of auto-scheduling. (If that makes any difference?)
What concerns me more is if we go to longer broadcast schedules (perhaps web-streaming all year) when will the problem recurr? If so, what can be done to prevent it.
Like most intermittend problems they’re the Devil’s own to try to replicate and repair.
So, thanks for the comments and support. Don’t know if we’re any closer to a solution, but at least we won’t loose any air time!
Can you please elaborate on “the database went missing”?
The “database” is actually two parts: The TCP connection to the PostgreSQL server, and file access to the audio files (which may or may not be located on a remote server).
mAirList checks if the TCP connection is alive every few seconds, using PostgreSQL’s PING command. If the connection drops, you’ll see a message in the system log, and mAirList will try to reconnect immediately, and make a new attempt every few seconds. mAirList should never crash if the connection goes away like this.
Regarding the second part, the audio files, I don’t think mAirList would crash if the connection goes way in the middle of a song (even for an unnoticable short duration). Nevertheless it is a good idea to turn on File Management in the config (it will be on by default from v4.2 anyway), and check the option that makes mAirList copy all network files onto the local harddisk before starting playback. This is a good protection against possible dropouts of the file server.
I think I am confusing people by using words in the wrong context. ???
mAirlist didn’t actually crash. It continued running but no playlists were loading. (I had a script rinning at 58 minutes past each hour to load the next playlist)
The database browser window said “no database.”
The songs playing continued to the end.
Windows explorer showed the network drives were still available. (I could browse/explore them.)
When mAirlist was closed an error message dialogue was revealed that was behind the main mAirlist window. This contained a series of numbers (probably indicating a memory issue?). I was so anxious to get the software running again that I didn’t have time to note what the message was.
When mAirlist was restarted the database was available and the playlists continued to load as expected, although I obviously had to load up the current playlist rather than wait for the event to load the next playlist.
Hope this makes things clearer!
As we are not on air I am not running the software so cannot monitor it for a recurrence of the error. Perhaps I will try to pursuade my tech team to allow me to have the dedicated server remain running until I can get sight of the message that appears…
The issue occurred when in AUTO mode at the start of the day - having run through the night...