Bug - 4.2.1 b3764 still fails to backup when HPU is networked with console.

Good morning, can you please send the patch info or show file to HESservice@etcconnect.com so we can reproduce it and log a field report?  I will follow up here when I can.

Any word on this? Getting concerned that it's 100% repeatable for me, been trying to figure this out since August, and still not logged as a bug that I can see. 

Is it me? I'd really like to use v4 software but continually having to downgrade since I can't save my show.

Ned, Hog4 has NEVER supported backing up on a secondary console. Only the console where the show was started can you expect it to work. All versions going back to 1.0 in 2012 suffer this limitation. The backup button should be greyed out on those other consoles. It became more obvious to the user community a couple of years back once we started validating the backups. For years you'd get a success dialog but you were only saving partial data from your show - never the full show - on secondary consoles.

Downgrading won't help you. Only backup on the console that started the show. This is ticket 9436

I'm confused by this response.

Console Net 1 is a server (HPU). In a rack, in a MDF, not easily acessible. It runs the show and everyone signs into it. It is designated as the active server as spelled out in the 3.19 Manual Section 3.3.6 (Understanding Multi Server Fail Over Behavior)

Console Net 2 is a backup server (Full Boar). In the audience. This console is used to program the show

Console Net 3 is a client (Full Boar). In the booth. This is a tracking backup. 

Net 3 has never been able to backup since it's a client.

Net 2 has always been able to backup before because it is a server. 

In V 4.2.1 b3764, Net 2 Allows me to "backup show". It fails. 

If Net 1 is a Full Boar and Net 2 is a full boar, it succeeds. If Net 1 is an HPU or Hog PC , backing up on Net 2 fails every time with the errors posted above.

 4.1-4.2 b3746 unable to create backups after running on HPU 

Here's the thread where Alissa confirmed the same behavior I saw on a different show. 

Logged as Field Report 10312

For clarification, only the desk that originally started the show from a good showfile can reliably backup the show. It doesn't matter that you have a second desk that is running a server. 100 percent of the data from the showfile on the starting desk does NOT make it around the horn to the other desks, whether the other desks are running a server or not. That's why the backup fails. The fact that a backup "completed without error message" for about a decade was misleading. Not all of the data was there. Net number doesn't matter. Software version doesn't matter.

It was an oversight that the backup button was not greyed out since 2012 on the other desks. In an upcoming release the button will be greyed out on other desks.

Thank you for clarifying. To be honest, this blindsided me. To be told that this has always been a problem is new to me. I read all the release notes, test the beta software since 2007, read the tech bulletins. I've never heard of this and have only had it fail in version 4. Now I know.

To learn that it is acceptable to not be able to backup regularly from anywhere but the most inconvenient location is dumbfounding. 

The manual claims that all the data is backed up on all the servers locally for failover so that should be updated. 3.3.5. 

"#2. If all servers stay connected to the network and remain visible to each other, then all servers will have the same copy of the show. New data created on any console will immediately replicate to all servers." 3.3.6

This new loss of functionality will make this ecosystem unbelievably difficult to depend on.  None of the multiple programmers can save the show at their desk.  Sure it's 'always saving locally' but every programmer I know is responsible for protecting their show file(s) in multiple locations. This loss of basic functionality without a plan to fix or improve just feels like a shoulder shrug response.  

I agree with your sentiment and was also frustrated to discover that the backup on secondary servers wasn't as comprehensive as we originally intended. The measure that Chris mentions (disabling the backup button on non-primary servers) is only a stop gap measure to ensure that no one gets caught with partial show data while we implement this properly which is actually part of an epic we are calling "database everywhere". This effort involves fully loading the show file on every console and processor node in the show session so that all the show data is available on demand locally to each node. This will improve real time performance when executing large cues as well as provide the non-primary console show file back feature discussed here as well. It is in test right now but not yet stable enough for beta.

I agree with your sentiment and was also frustrated to discover that the backup on secondary servers wasn't as comprehensive as we originally intended. The measure that Chris mentions (disabling the backup button on non-primary servers) is only a stop gap measure to ensure that no one gets caught with partial show data while we implement this properly which is actually part of an epic we are calling "database everywhere". This effort involves fully loading the show file on every console and processor node in the show session so that all the show data is available on demand locally to each node. This will improve real time performance when executing large cues as well as provide the non-primary console show file back feature discussed here as well. It is in test right now but not yet stable enough for beta.