I’ve noticed that Synchronizing mAirlistDB is rather slow in my current version (4.3.9) compared with earlier versions. For approximately 15.000 songs it takes well over an hour, before it took a couple of minutes.
By coincidence I discovered that left-clicking and holding the title-bar of the Synchronize Window things start to speed up hugely. It works but it’s not very ergonomicaly. Could you have a look at this Torben?
I’ve started with 4.2 which didn’t have this problem. I’m pretty sure I have used all version up till 4.3.9 and I definately didn’t have this problem until recently. My best guess is that it started with 4.3.9. Hope you are able to reproduce the problem.
What Torben is trying to do is to narrow down (if possible?) which version introduced the problem you’re seeing. If he can do that, it will make it much easier to see what changed and to find and correct any problems; if not, he will have to look through many more versions of the code, which will take much longer.
Hi Cad, appreciate what you’re saying but like I said before, I’m afraid I can’t be more specific.
When I noticed that a newer version became available, I’ve updated the software. So I’m pretty sure I have used all versions since june 2013.
Problem occured somewhere in november I guess and has been there ever since. But I can’t point to the exact version.
My educated guess is that it started somewhere around 4.3.7.
I have not installed other soft- or hardware recently apart from normal updates. If it’s mAirlist related one might expect other users having the same problem. Anyone?
I believe that I am experiencing the same issue, when using mairlistDB it takes a huge amount of time to attempt to synchronize. I have noticed the following however, when mairlistDB opens, on this particular PC, it runs at 50% CPU usage varying slightly to around 48% - 57% but as soon as I click on one of the menu buttons at the top (Database, View or Administration) and move the cursor onto the menu the CPU usage drop drastically down to about 1% maybe less. We did previously have version 4.1.5 and have just upgraded to 4.3.9 but it is now causing this issue with the database, we can’t roll back to that version because of the updated schema of our PostgreSQL database.
If there is any information that I can supply that will help then let me know and I will try to obtain it. I will try it in our main studio to see if it is the same on that computer which is of a different specification ( a much better one) but I know that the mAirlistDB used to work perfectly fine on all of our computers.
Hi Torben, the issue arose between 4.3.7 and 4.3.8 and got worse between 4.3.8 and 4.3.9 . In 4.3.7 synchronising takes a fraction of the time with mairlistDB being able to quickly scan through our NAS drive, the mairlistDB interface uses no more than 10% cpu when browsing and up to 25% when scanning the NAS drive. In 4.3.8 the when browsing the database it is around 40% - 55% usually towards the top of this range. and 4.3.9 is as stated in my previous post on this thread. Hope this was helpful let me know if you need any more information about the computer, database etc.
Hi Torben, same here. Re-installed several versions:
4.3.6 very fast
4.3.7 very fast
4.3.8 slow
4.3.9 very slow
I noticed oddward is using a NAS too. Maybe this is useful?
By the way, when you say that synchronizing is slow - do you refer to the first step when the disk is scanned for new files, or the second step where the files are actually added to the database?
The first step; when my NAS is scanned for new files.
Like I mentioned in my first post, scanning speeds up to normal speed when I right click (and hold) the titlebar of the scanning window.
It would appear that it is mostly the scanning for file changes but it is sluggish when adding them to the database. From what i have noticed it does seem to be the mairlistDB software as a whole not just the syncing with the database that is an issue. The whole thing seems to be running slow
I just installed version 4.3.10 and I noticed a big difference in performance compared with the previous version (4.3.9)
When I start a jingle in a cartmachine for example, you can see the cart running straight away; the sound however starts 2 (!) seconds later.
Same with tagging songs, for example placing hooks. Because of the big difference in sound and the visual effect it is hardly possible.
Ramps are also off by 2 seconds.
Basically; sound and visual effects are off by two seconds.
I posted this comment in this topic because I think it might be related somehow.
If you need any specifications or other information I’ll be glad to provide this info.
Edit: Just reinstalled version 4.3.9 and sound and visuals are perfect in sync now. Hope you will be able to determine the cause Torben.
It appears as if there is a very large audio buffer in effect for your output device(s), for some reason. I’m not aware of any recent changes in that respect, but we’ll track this down.
I assume when you click STOP on the player, the audio will continue to play for 2 seconds before it eventually stops?
Can you please do the following:
Start mAirList
Click the small arrow next to the “mAirList” button in the main toolbar
Click “Generate bug report”
Click “Details”
From the dialog that appears, send the report to me
Bug reports now contain an additional section about your particular audio routing and settings. I would like to inspect that first.
Bugreport has been sent.
I had to install 4.3.10 again as I reinstalled 4.3.9 yesterday.
At present I cannot reproduce the out of sync problem. I will continue to use 4.3.10 and as soon as the problem reoccurs, I will sent a new report.
Edit: After some hours running 4.3.10 the problem reoccured. Indeed, when clicking STOP on the player the audio continues for a second or two.
I’ve sent a new bugreport.
Have not experienced this problem before (I started summer 2013 with mAirlist) and reinstalling 4.3.9 solves this problem straight away.
Just downloaded and installed the snapshot both at home and at work (hardware at work is more powerfull than at home)
I’ll keep you informed Torben, thanks!