- This topic has 11 replies, 4 voices, and was last updated 5 years, 7 months ago by
.
-
Posts
-
Hi there to all,
For some time now we are experiencing random crashes of BA ONE on our station using windows 10. Here's our last month:
Just the last 4 days we had 3 crashes.
BA is used for our streaming AND also as STL, meaning that when this happens we are completely DEAD.
In the mean time, after the setup of BA on the TX site on windows 7 (just like the setup is showing on the forum from Leif), The TX's BA is ultra stable and haven't crashed even once from the begging of the STL set up since 6 months. In that same period we had 40+ crashes of the studio's BA.
Differences between studio and TX:
1. TX site has windows 7 but studio has 10.
2. TX BA has management package and studio hasn't.Questions:
1. Are windows 10 to blame?
2. Will a purchase of the management package for studio, fix the problem or at least improve it?Please tell me your thoughts
I run BA1 on Win 10 with no stability problems, but I DO have the Management package, and therefore run BA1 as a service. I'm not sure that running as a service is the entire answer, but it certainly works for me. I have, on occasions, run Breakaway directly (not as a service), but only for relatively short periods. I never had a crash, but the running times were not very significant.
Do you run the TX version as a service?
Having said all of that, I would look at possible driver or code bloat as the culprit. Look at all unnecessary programs and processes and shut them down permanently. Also check for scheduled tasks. A lot of updates are now set up as a scheduled task and, if you delete them, they magically come back. This includes things like Adobe updates. I run a very "skinny" version of Win 10 (64 bit) and it seems very stable.
We just had 2 crashes more just now, and in an hour.
Our windows 10 64bit installation consist of:
Windows with all unnecessary programs deleted
BA one
BA Pipeline
Jazler Radiostar automation
Teamviewer
Drivers for the Audio Interfaces@ Milky From your reply i get the feeling that you are not running BA 24/7, do you? Our TX version is running as a service with rock solid results, but the studio version is not (i think the Management Package is for this purpose after all).
Do you run the BA as a service 24/7 with sound input/output and streaming encoders on windows 10?
Questions:
1. Is there anyone that runs BA One on Windows 10 24/7 without the Management Package, with solid performance, like the one we have with windows 7 on our TX site with the management package?2. Is there a formal way to get support on BA other from this forum?
I can't completely relate. But I run BAOne with one HD Core and streaming add-on 24/7 on Windows Server 2016 (same core OS as Windows 10) on a consumer grade Dell Desktop 4th gen i7 CPU 16gb RAM. I run it on my user, not as a service (no management pkg) and have never had it just crash on me. I've manually taken it down to make config changes or windows updates. But the program itself has never once crashed or stopped working. I only use Breakaway Pipelines hooked to my station playlist automation, no physical sound cards are in use, unless I am editing or setting cue/intro points in my software. Again, not exactly the same situation or use case as you, but again, I've never had any reliability issues with BAOne.
[quote author=AntonisV link=topic=5731.msg19975#msg19975 date=1555336285]
@ Milky From your reply i get the feeling that you are not running BA 24/7, do you? Our TX version is running as a service with rock solid results, but the studio version is not (i think the Management Package is for this purpose after all).Do you run the BA as a service 24/7 with sound input/output and streaming encoders on windows 10?
[/quote]I only use BA1 for home entertainment now, so it gets a serious workout every day for at least eight hours continuously – longer on weekends. However, there is no streaming involved. I have the Management Package, and run BA1 as a service so that I can control it from a tablet or smartphone remotely e.g. when entertaining outside.
So unless anyone else is suggests something else my main course of action is:
Step A:
- Buy the Management Package.
- Update Windows 10.
- Try and see is if I have scheduled tasks (or anything else) running, and delete them (after the update because the update will affect them anyway).
Step B:
If the above won't work- I will try a setup without an automation program running alongside BA, so i will be sure that BA is not colliding with my automation in some weird way.
Step 3:
If even step 2 won't work- Maybe I have test on another PC OR trying with windows 7 on this one
I'll keep you posted with the results. (i 've had periods of 2 weeks without a crash with this setup).
If anyone has anything to propose to this, it will be very appreciated.
Your strategy is sound.
There are several variables here, each of which can be the problem, or may contribute in some way.1) The OS. Although Win10 has been around for a while now, it does not have the same track record as Win7. If it were easily possible, a solution could be to downgrade the Win10 PC to Win7 so the OS platform is the same. Maybe a corollary of this would be to update the Win7 PC to Win10 to see if that introduces issues that are not present or are masked in Win7.
2) The hardware/drivers. Unless the two PCs are identical, there can be a variation of components or drivers influencing the final results. It would be great if both devices were the same – ideally based around the more stable unit.
3) The BA1 Management Package. I'm not convinced that this is a game changer, but Leif is on record as saying that running BA1 as a service uses less resources and therefore may be more stable.
4) There may even be a hardware issue, such as bad RAM in the PC which fails. Simply replacing the RAM with the best you can afford might save a lot of frustrating testing to achieve nothing.
Hi i have some news and a new questions.
I got the management package. From the moment i installed it on the BA instance and made it run like a service, i didn't had any crashes.
Until today. Today something weird happened. I was at my desk, i heard the station stopping. When this happens and no human is evolved it's usually 3 things: The automation's fault, BA's fault, or STL fault (the connection and not BA).
With this kind of current history, i expected to be BA, so i started connecting to the machine through Teamviewer what happened.
As i typed the password to teamviewer's client, and it started connecting, the sound was already up again. When it connected i realized that BA had just restarted. It was running for some seconds.
So to my questions now:
1. Does BA restart automatically when running as a service with management package?
2. How can i find out what happened, in the logs i can see everything after the restart that took place at 14:09 today, but nothing prior to that.
3. Is there a way i can find out in the future? Some option that turns on logging or dumping in all the time the service is up?4. I am uploading here logs and dumps from a config dump i just did (the whole dump is exceeding the file size limits).
It's very hard to make an in-depth assessment from such a small grab of the logs, but my first reaction was that the warning on jitter rate seems to be quite regular, so, maybe BA1 hits a trigger point where the jitter is considered to be too high, and this forces a restart of the service.
Although I have seen jitter rates up to 100% without audible glitches, I try to get it down to less than 20%. Sometimes the recommended buffer size is not actually the best, and it does require a little experimentation between the ASIO buffer size of the actual sound card, and the internal I/O buffers.
Hi guys!
I've been gone a long time — dealing with urgent product development as well as building a house and moving. I've had no idle time to go on facebook for literally 6 months, and the little idle time I had was better spent away from the computer. I'm finally pretty close to being caught up. I do apologize for the troubles you've been having, and appreciate how patient you've been so far!
1) Yes, BaOne will restart automatically when running as a service.
2) Any time BaOne is shut down for any reason, there should be a trace left of some kind.
A shutdown event should be logged in one of several ways. There are many different types of logs.
a. If the service is shut down normally, the entire shutdown procedure is logged in the Startup log.
b. If the service crashes, there should be a crash dump (both a .dmp and .txt file) in the dump\ folder, and an entry in the startup log.
c. If any thread inside BreakawayOne freezes up for an extended period of time, first a warning is issued in dump\BreakawayOneApp_freeze.log.txt, and if it stays frozen for long enough, it repeats the warning and adds “- TERMINATING”, and then terminates the process, so that the service can be restarted. This happened once according to the log files you sent me, while reading streaming metadata, but temporary freezes appear to be happening regularly, in the streaming encoder thread.
That does not make sense to me — according to your settings, metadata is simply being read from a file on your drive. That should not be taking significant time. That is something I need to look into — there could be a bug in my code, or something else could be going on that I’m not yet understanding.
As designed, the only way it should be possible for BreakawayOne to exit without leaving a trace is if the process is forcibly terminated, for example with TASKKILL or with task manager.If Breakaway is crashing at the transmitter site, adding the management package to the studio site would NOT help.
I can add an option to log something every few seconds, but I’m not sure what that would tell us, since it still wouldn’t tell us what happened.
My current framework version is 3.19.77, and I’ve fixed several small bugs in multiple parts of the code since the last time I rebuilt BreakawayOne, and added more detailed logging in some places. Perhaps it’s time I build a new version for you to test, as a first step to tracking down and solving the problem.
Best,
///LeifOh WOW! Welcome back, Oh Lord High Poo Bah.
I've been soldiering on under fairly high duress here. Thanks for your clarification 🙂 🙂 :).[quote author=Leif link=topic=5731.msg20028#msg20028 date=1556264686]
Hi guys!I've been gone a long time — dealing with urgent product development as well as building a house and moving. I've had no idle time to go on facebook for literally 6 months, and the little idle time I had was better spent away from the computer. I'm finally pretty close to being caught up. I do apologize for the troubles you've been having, and appreciate how patient you've been so far!
1) Yes, BaOne will restart automatically when running as a service.
2) Any time BaOne is shut down for any reason, there should be a trace left of some kind.
A shutdown event should be logged in one of several ways. There are many different types of logs.
a. If the service is shut down normally, the entire shutdown procedure is logged in the Startup log.
b. If the service crashes, there should be a crash dump (both a .dmp and .txt file) in the dump\ folder, and an entry in the startup log.
c. If any thread inside BreakawayOne freezes up for an extended period of time, first a warning is issued in dump\BreakawayOneApp_freeze.log.txt, and if it stays frozen for long enough, it repeats the warning and adds “- TERMINATING”, and then terminates the process, so that the service can be restarted. This happened once according to the log files you sent me, while reading streaming metadata, but temporary freezes appear to be happening regularly, in the streaming encoder thread.
That does not make sense to me — according to your settings, metadata is simply being read from a file on your drive. That should not be taking significant time. That is something I need to look into — there could be a bug in my code, or something else could be going on that I’m not yet understanding.
As designed, the only way it should be possible for BreakawayOne to exit without leaving a trace is if the process is forcibly terminated, for example with TASKKILL or with task manager.If Breakaway is crashing at the transmitter site, adding the management package to the studio site would NOT help.
I can add an option to log something every few seconds, but I’m not sure what that would tell us, since it still wouldn’t tell us what happened.
My current framework version is 3.19.77, and I’ve fixed several small bugs in multiple parts of the code since the last time I rebuilt BreakawayOne, and added more detailed logging in some places. Perhaps it’s time I build a new version for you to test, as a first step to tracking down and solving the problem.
Best,
///Leif
[/quote]Hey Leif,
It's been a while! Glad to see you back! I am definitely on board with helping you test a new version. I'd love to get your thoughts on testing VST3 and WASAPI Exclusive mode for audio transport.
Thanks!
- You must be logged in to reply to this topic.