It is currently Fri Mar 29, 2024 12:05 am


INF:2230 Sample Set re-cache every load

Hauptwerk software technical support only. Please make sure you have read the manual, tutorials and FAQ pages before requesting support.
  • Author
  • Message
Offline

pkuzan

Member

  • Posts: 80
  • Joined: Sun Aug 22, 2010 3:01 pm
  • Location: Romsey, Hampshire

INF:2230 Sample Set re-cache every load

PostWed Aug 17, 2022 6:13 am

Hi,

One of our installations is experiencing an issue, the sample set (Hereford) re-caches every load.
https://www.organworks.co.uk/news/st-michaels-southampton-2/

It is a 4.2 installation on a Late 2014 Mac Mini.
As this is an old version, I tried to purchase a support ticket, but I don't seem to be able to.
The Support Products page says I can purchase a support ticket here, but there is nothing to click.

The instrument has been fine for 5 years.
I've just been on-site and checked the clock, forced a change to the audio configuration and re-cached with no change.
If the sample set is reloaded once Hauptwerk is started, it loads fine, however if Hauptwerk stopped and restarted, it will always re-cache even if the computer has not been restarted.

I have a diagnostic file that I can upload.
I'd prefer not to do a V7 upgrade right now as it will also entail a macOS and audio interface driver update, however I do realise it will need to be done at some point.

Any help appreciated.

Paul
Romsey OrganWorks
Offline
User avatar

mdyde

Moderator

  • Posts: 15444
  • Joined: Fri Mar 14, 2003 1:19 pm
  • Location: UK

Re: INF:2230 Sample Set re-cache every load

PostWed Aug 17, 2022 7:26 am

Hello Paul,

You might need to be logged into your account on the MDA website in order to purchase a support ticket, although I'm not sure whether it's possible for a v4 installation, given that v4 is no longer officially supported.

My brief thoughts would be:

- Change the motherboard's battery if it has one. Even if the clock was correct when you checked, maybe it forgets the date/time erratically. (If the computer is sometimes connected to the Internet, then the OS will try to re-sync. the clock from a time server periodically, so you might not always notice a failing battery straight away.) v4's caches relied on timestamps (whereas v5+'s don't).

- Make sure Hauptwerk is always exiting cleanly. If it crashes (or if the computer loses power or crashes without shutting down properly) then settings files might be corrupted. In v4 the relevant timestamps were saved in the organ settings files and in the general settings file and compared. Check in the log that you always get the "Hauptwerk has finished shutting down" message preceding the next launch, which should indicate that it exited cleanly.

- Also make sure that you don't accidentally/sometimes have two instances of Hauptwerk running (e.g. if macOS is launching it automatically on boot). If two instances run, one will usually corrupt settings and caches of the other. If two instances were running you would also have a second "Welcome to Hauptwerk" message without the "Hauptwerk has finished shutting down" from the last run preceding it.

- Maybe the drive is failing, leading to the settings files and/or caches becoming corrupted.

- After Hauptwerk has launched, and after loading the relevant organ, check in the log that it doesn't report that the settings file was corrupted and needed to be restored automatically (which would happen from the last-known good backup of the file -- that backup file might have a wrong timestamp saved in it, e.g. due to the clock having previously been wrong).

- After checking everything else above (including changing the battery), force all organs to re-cache. I can't remember off-hand whether in v4 it was sufficient just to OK the "General settings | Audio outputs" screen, but in case it wasn't, and for good measure, insert a new dummy entry on that screen, OK it, then reopen the screen, delete the dummy entry, and OK it again. That would definitely do it, and will ensure that the correct current timestamp gets saved into the general settings file (and also into the organ settings files when you next load the the relevant organs).
Best regards, Martin.
Hauptwerk software designer/developer, Milan Digital Audio.
Offline

pkuzan

Member

  • Posts: 80
  • Joined: Sun Aug 22, 2010 3:01 pm
  • Location: Romsey, Hampshire

Re: INF:2230 Sample Set re-cache every load

PostWed Aug 17, 2022 8:08 am

Thanks Martin.

The PRAM battery seems OK, I connected the Mac to the Internet this morning just to make sure time was being synced.
I forced a re-cache by creating and deleting an output group, I can see the regen in the logs.

However looking at the logs, it would seem that there is an issue communicating with the dongle.
The dongle is connected and the LED is illuminated.
Despite the error, Hauptwerk still loads.

2022-06-08-20-41-03: INF:0403 Hauptwerk has finished shutting down.

2022-06-12-09-50-15: INF:0080 Could not communicate with Hauptwerk's USB key. 'Communication error between API and local Sentinel license manager.' (code: 33).
2022-06-12-09-50-21: INF:4165 Welcome to Hauptwerk.<BR><BR>Hauptwerk version: 4.2.1.003
2022-06-12-09-50-22: INF:2106 Starting to load the organ file Hereford-Cathedral-67-Stop-XL.Organ_Hauptwerk_xml.
2022-06-12-09-50-22: INF:3830 Starting MIDI.

...

2022-06-12-09-50-23: INF:2232 Your audio output settings have been updated since this organ was last loaded. The sample set data cache will be regenerated, which might be slow.</P>

Sometimes there is no INF:0080 but always INF:2232

I'm not sure they are connected or are a symptom of another issue.

Thanks,
Paul
Offline
User avatar

mdyde

Moderator

  • Posts: 15444
  • Joined: Fri Mar 14, 2003 1:19 pm
  • Location: UK

Re: INF:2230 Sample Set re-cache every load

PostWed Aug 17, 2022 8:53 am

Hello Paul,

INF:2232 means that the timestamp of the last audio settings change that was saved in the currently-loaded general settings file is newer than that saved in the organ settings file. I think that could only occur spuriously if one of the things I mentioned previously is occurring (computer clock misbehaving, or files getting corrupted e.g. because of a drive fault, or two instances running, or Hauptwerk/computer not shutting down cleanly). The log file should show evidence of those things -- load the organ (letting it re-cache if it wants to), then load it again and if it still re-caches spuriously then check all lines in the log between those two events.

I don't think the HASP driver communication error is likely to be relevant but for good measure:

- Try reinstalling the latest HASP driver: viewtopic.php?f=16&t=19710&p=147779#p147779
- Also make sure that macOS 'App Nap' is disabled globally and reboot: https://osxdaily.com/2014/05/13/disable ... -mac-os-x/
- If you still get that warning and if macOS is set to launch Hauptwerk automatically on boot then adding a delay might help.
Best regards, Martin.
Hauptwerk software designer/developer, Milan Digital Audio.
Offline

pkuzan

Member

  • Posts: 80
  • Joined: Sun Aug 22, 2010 3:01 pm
  • Location: Romsey, Hampshire

Re: INF:2230 Sample Set re-cache every load

PostWed Aug 17, 2022 9:40 am

Thanks for your comments.
I know I'm pushing my luck here...

Looking at the organ settings in diags:

General Settings
<Control_LastConfigChangeTimestamp>1.660724314e+9</Control_LastConfigChangeTimestamp>
I guess this will be about 2022-08-17T09:00Z when I created and removed an audio output group.

St Annes
<Control_LastConfigChangeTimestamp>1.47939158e+9</Control_LastConfigChangeTimestamp>
Probably 6 years ago when I first installed Hauptwerk!

Hereford
<Control_LastConfigChangeTimestamp>0</Control_LastConfigChangeTimestamp>

I'm not sure how your timestamps are encoded, but I would assume that 0 is before 1.660724314e+9
I forced a re-cache by creating and deleting a tmp output group, I also changed the sample resolution of a rank in the Hereford. I can see this in the log.

What could cause Hauptwerk to write a timestamp of 0 in the Hereford Organ Config?

I really appreciate your time given that V4.2 is well dead!
Paul
Offline
User avatar

mdyde

Moderator

  • Posts: 15444
  • Joined: Fri Mar 14, 2003 1:19 pm
  • Location: UK

Re: INF:2230 Sample Set re-cache every load

PostWed Aug 17, 2022 10:57 am

Hello Paul,

pkuzan wrote:Hereford
<Control_LastConfigChangeTimestamp>0</Control_LastConfigChangeTimestamp>

I'm not sure how your timestamps are encoded, but I would assume that 0 is before 1.660724314e+9
I forced a re-cache by creating and deleting a tmp output group, I also changed the sample resolution of a rank in the Hereford. I can see this in the log.

What could cause Hauptwerk to write a timestamp of 0 in the Hereford Organ Config?


That setting in the organ-settings file would always be set to the current timestamp after the organ's cache had been generated successfully. The settings file will then be saved to the drive whenever the organ unloads (unless Hauptwerk or the computer isn't exiting cleanly).

I think it would only get set to 0 in one of the following circumstances:
- The settings file is all-default, e.g. if the file is corrupted or fails to load and gets automatically reverted to defaults. (The log file will report that if so.)
- The setting was already at zero and the settings file isn't getting saved properly (e.g. Hauptwerk/computer not exiting cleanly, or two instances running, or drive corruption, or drive file permissions aren't allowing it). Check log and also check OS file permissions and check file's OS timestamp to see when it was last actually saved.
- The organ fails to load from cache (or maybe is cancelled during loading from cache).
- The cache fails to regenerate.
- You specifically load the organ via the "Design tools | Load organ, with design options" screen and choose the options to load from raw samples and/or not to save the cache.
Best regards, Martin.
Hauptwerk software designer/developer, Milan Digital Audio.
Offline

HeAu

Member

  • Posts: 105
  • Joined: Sat May 21, 2005 1:33 pm
  • Location: Austria, Salzburg

Re: INF:2230 Sample Set re-cache every load

PostSun Aug 28, 2022 5:21 am

Dear Paul!

I don't know wether your problem is solved in the meantime. But I noticed that the timestamp in the excerpt of the logfile is "2022-06-xxxxx" whereas the date of your initial post ist "2022-08-17" (yyyy-mm-dd).
Are you sure date/time are set correctly on your HW computer?

Best regards
Heau

Return to Technical support

Who is online

Users browsing this forum: No registered users and 19 guests

cron