[ghmerrill]

I'm just starting out with backups and restores.  I backed up (in Windows) and restored (on Chromebook).  Everything looks okay EXCEPT my (only) setlist wasn't restored.  The header on the Chromebook instance shows "Setlists (0/1)".  The header on the Windows instance shows "Setlists (1).

What's happened here?  Did I somehow fail to back it up?  Or did I back it up, but it hasn't been restored?

[Zubersoft]

It sounds like something has gone wrong with the data in that setlist. What is the name of the setlist? It sounds like the Chromebook may think the setlist has a blank name (which normally should be impossible), which is causing it to get filtered out.

Mike

[ghmerrill]

The name of the setlist is "Sept. gig".  I suppose I could try to rename it to "SeptGig" in case it's barfing on the '.' or the ' '.  But I just couldn't imagine why it would do that (well, I could imagine it, but that would imply really terrible design/coding/testing).

So what does the "(0/1)" notation in the "Setlists (0/1)" tab on the Chromebook side mean?

[Zubersoft]

Having a period or space in the name should have no impact. What is happening is that the app recognizes that there is one setlist in the library, but that setlist has a blank name which should be impossible, so it ignores that entry, creating a situation where you have 0/1 setlists displayed. I don't want to support having a blank setlist name, as it shouldn't normally be possible for that to occur, so I'm very curious how the library ended up in that state. I fyou want to share the backup file with mike@zubersoft.com, I can take a look at it to see if I can reproduce the same issue. I should be able to repair the setlist, then create a new backup for you.

Mike

[ghmerrill]

Thanks.  I was experimenting with it and I'm not sure I still have that backup.  However, if I don't, I should be able to create another one since I haven't changed anything in the pieces, collections, or setlists.  I'll try to do that today, but currently the Windows tablet it's on is having its battery replaced.  Should get it back this afternoon.  If not, it will be the weekend before I can make the backup available to you.  Thanks.

I suppose it may also be another example of how performance on a Chromebook may be unpredictable.  I'd expect the backup/restore stuff to be fully portable, but you never can tell.  It could be that the backup is really okay, but the Chromebook version just can't restore it correctly for some odd reason.  I didn't try to do the backup and then the restore just to/from the Windows system, but I can backup/save the setlist separately (so I'll still have it in any event), and then try that as well.

[Zubersoft]

It would be strange if this had anything to do with it being a Chromebook, because the data for the setlist is all saved in the SQLite database, and that should be identical across devices and platforms. Once I have the backup, I can let you know what I find.

Mike

[ghmerrill]

It would be strange if this had anything to do with it being a Chromebook, because the data for the setlist is all saved in the SQLite database, and that should be identical across devices and platforms. Once I have the backup, I can let you know what I find.

Mike

Yes, one would think.  But as I'm sure you know, bugs can hide in funny places and reveal themselves only under odd circumstances. 

Eons ago and far away, in the outer reaches of what was called "Chicagoland", I was porting a C cross compiler to a VAX/VMS system.  The compiler had been successfully ported to a number of hosts at that point, including various PCs, SUN/OS, various versions of *IX, and even 370/MVS and CMS. It was solid, portable code.  Everything went well, and as expected, using the VAX native C compiler to do the chore, and the test suite was run.  It failed -- and in a bizarre way.  Immediate investigation showed that it had failed to generate code at what appeared to be random locations in the object file.  The code that the compiler thought it was generating just wasn't going into the output file.  Typical effort in the debugger revealed no apparent errors in the compiler's front end or code generator:  it was doing what it was supposed to do.

Even more effort was devoted at a lower level to determine when the pieces of code were disappearing.  Finally, after narrowing things down by test case after test case, it was evident that when the cross compiler's code output buffer was exactly 4K in size, was filled all the way to the end, and was flushed to the file, a piece of that buffer ended up not being flushed -- and that was the missing code, appearing as apparently (but not really) random errors in the output.  Yup, it was a bug in the VAX C output library.  Who would have thought?  They fixed it virtually immediately of course.  But ... you just can't ever tell. 

[ghmerrill]

Well, after some drama in getting the battery replaced on the Windows notebook/tablet and dealing with Lenovo's/Window's reaction to that, I have tried to recreate this problem and can't.  The problem is definitely not anything to do with the characters used in the setlist name since I tested that.  Unfortunately, I don't have the original backup that exhibited the problem.  I'm left thinking that it was a result of either some odd glitch in that particular backup operation itself, or that it was a result of my doing multiple adds/deletes to the setlist as  I was also moving things around in it -- though that certainly didn't manifest on the Windows side, and testing that thoroughly would be very time-consuming.  I'm going to regard this as "not really a problem" and live with the single anomaly unless it happens again, which I think is unlikely given how much the backup/restore operation has been exercised at this point.

[Zubersoft]

I'm glad to hear that Gary. Hopefully you never see an issue like that again.

Mike