[BUG] UI Freezes when changing EQ and recording SQ Drive

[TabsParticipant]

I was mixing for church this morning and had an issue with my SQ7, the issue was reproduceable and happened twice.

We were running the SQ Drive in multitrack mode for the purposes of recording and training.
While recording, we changed the EQ on one of the mic’s.

As soon as we changed the EQ the UI froze and ultimately we needed to restart the board. The audio processing was still working (At this point the pastor was in his sermon and that kept working fine), but we had no control over fader levels or mutes, all the LED’s froze in their current position, and the screen (still on the EQ) froze in place.

Every once in a while it would act like it was getting back to normal (channels that were muted would blink the mute button like 2-3 times, signal level LED’s would update, but thats about it)
The screen was not working, so i was unable to stop my recording, but i did try unplugging my external USB drive, that did not fix anything.

We are running firmware version 1.5.1 if that helps.

[Mfk0815Participant]

This issue should be fixed in version 1.5.2 according to the release notes. So, update the board to the newest firmware version.

[jb07Participant]

version 1.5.5 is available

[TabsParticipant]

Thanks, updating.

[Rob TParticipant]

I’m not sure this is completely fixed.

I ran across a more minor version of this bug on 1.5.4 (system is old enough that there didn’t appear to be benefits to updating to 1.5.5 or 1.5.6, so it hasn’t been a priority), and there was a note from another tech that they’d seen a “touchscreen lockup with multitrack recording and RTA)”.

When I saw it, the touchscreen (only) would freeze on the EQ screen with a multitrack recording running, but only about 2 hours into the recording. Recording was at 48khZ, 24 tracks being recorded to an external SSD. S-link to a DX168 connected to the console, but no other network connections (so no iPad connected). Rebooting the console fixed the lockup, although the scene status was reset on the reboot (console settings hadn’t changed, but the scene that had been loaded at lockup was no longer shown as loaded).

This bug is more than a little disconcerting, as without a softkey to stop the recording (which fortunately I had), the console reboot would result in a loss of the (at this point, 2+ hours of) recording. And there isn’t any way to access the SQ-Drive from the iPad app, so that isn’t a recovery option either.

[TobiParticipant]

I am really wondering why not just use latest Firmware?

Tobias

[Rob TParticipant]

This situation is a small rental company that downsized dramatically (and almost disappeared) during the pandemic. As there isn’t any shop tech (or really, any fulltime employees other than the owner) firmware updates either involve updating on a jobsite (with the associated risk of no console if something goes wrong, and the extra time required), or setting up the console in the storage room (not really fair to call it a “shop”) to do the update. So firmware updates that don’t bring benefits (at least per the release notes) aren’t a priority given the hassle involved with updating.

[EdwinParticipant]

Here also z freeze, after 1 hour livestreaming and recording (8 channels+mix).
Had to reboot.
We have to decide not to record on the SQ anymore, to critical.

[KeithJ A&HModerator]

This bug was fixed, so as with any issue, please do contact us using support.allen-heath.com and we will investigate further with you.

Most incidences of freezing we’ve heard about are due to other components of the system spamming the SQ’s control system with messaging or because of issues with a connection between MixPad and the console.

Regarding a freeze after 1hr livestreaming and recording – either both the live streaming and recording was happening over the same USB-B connection or an SQ-Drive recording was being made whilst sending to the computer some other way.
If analogue, then the livestreaming side of things would not be interfering with anything.
If Dante or Waves, then there is a possibility of network traffic getting to the console if the control network bridge is on.

@Rob T
As there was no connection to the network, it would be great if you could contact us as above with some more information, but some info for you and anybody else who see’s this thread –

but the scene that had been loaded at lockup was no longer shown as loaded

There is never a scene ‘loaded’ and being worked on directly, there is only the current state of the desk which is overwritten when recalling a scene. Once a scene is recalled and you move a fader, the state of the desk no longer matches the data stored in the scene file. The ‘Current:’ scene shown at the top of the screen is just a better way of saying “Last recalled scene since the SQ was booted”.

This bug is more than a little disconcerting, as without a softkey to stop the recording (which fortunately I had), the console reboot would result in a loss of the (at this point, 2+ hours of) recording. And there isn’t any way to access the SQ-Drive from the iPad app, so that isn’t a recovery option either.

SoftKeys are accessible and configurable from SQ-MixPad, so this is a recovery option.
In the worst case if there is absolutely no way to stop the recording, on in say, the case of a power cut, the data is often able to be recovered using the method detailed here – https://support.allen-heath.com/hc/en-gb/articles/4402934227857-SQ-Recovery-of-corrupted-SQ-Drive-recordings

But as I say, please do contact us if you haven’t already as we’d obviously like to understand what happened and ensure it’s nothing we could have prevented!

Thanks,
Keith.

[Rob TParticipant]

Keith,

I’ve spent a bit of time on the other side of this sort of technical support, so I’m somewhat sympathetic to the desire for getting a support ticket created, but it’s not clear to me how useful that support ticket is going to be. The console in question was a rental unit (yes, I have a bit of time on that specific unit, but it’s not my console and I don’t have access to it outside of using it on jobs), so getting more information about the state of the unit will be difficult. Additionally, the information that is available (which is mostly already in the forum post) is based on my recollection of the event, and may be incomplete as I had more pressing issues than troubleshooting a console at the time (like mixing the live show, and wondering if the recording the client was paying for was going to be corrupted). But I’m happy to copy the information into a support request if that’s what’s needed for someone to take another look at the issue.

I’ll also note that problems may have multiple causes, and the proximate cause that resolves a problem 99% of the time may not be the root cause that has to be fixed for the problem to be resolved 100% of the time. It’s also far too easy for folks in the office to lose sight of the realities of what’s involved with getting good data from the trenches – it’s very easy to ask for all the diagnostic data that makes trapping an issue easy, but actually getting that data may be impossible. So I’ll offer up a gentle reminder to start with the information you have, and not count on getting better data (and I say this as someone who is more often than not the person in the office, but who has lugged test equipment across the country and up onto scissor lifts to collect site data on occasion – I know exactly where the desire for more information is coming from).

Unfortunately, although I do like the SQ consoles and the other (mostly older) A+H gear I’ve worked with, my experience has been that it lacks the rock-solid reliability that some other manufacturers have (which sometimes comes at the expense of feature set and sound quality, and almost always comes at higher cost, to be fair). And this makes me a bit leery of using it in high profile situations. Consoles locking up mid-show (which has happened before on older firmware as well, likely due to since-fixed bugs) and requiring a reboot to resolve the issue pretty much obliterates any joy that comes from how the console performs when it’s functioning properly.

</rant>

[Rob TParticipant]

A followup on this, and an apology. It appears that despite my understanding that the console was on 1.5.4, the console in question hadn’t been updated past 1.5.0, and was experiencing the known lockup issue that was fixed in subsequent firmware releases. No issues were observed with multitrack recording on 1.5.7. So the “please verify you are running the latest firmware” request was absolutely warranted.

That said, from a customer service perspective, there’s a HUGE difference between a response of “This was a known issue with firmware version prior to 1.5.2. We’ve been unable to reproduce the described problem on the firmware version you state to be running, so please make sure you are running the latest firmware version and update if needed to be sure you have the latest fixes” and a response of “We fixed that bug, and aren’t going to take any further troubleshooting or problem reproduction steps on the issue you’ve reported until you can verify that the unit is running the latest firmware”, even if the final outcome is the same.

[KeithJ A&HModerator]

@Rob T

I’m sorry that it came across that way, that was certainly not my intention so duly noted.
Glad to hear you’re all sorted now though.

Thanks,
Keith.

[Author]

Posts