Fairly new to xibo, I recently upgraded a non-docker version of xibo 1.7.4 to docker 1.8.0 then 1.8.1 then 1.8.2. When I got to the end I realised that I’d somehow managed to end up with a blank site key in the CMS and also for every item within each timeline I had to manually tick the box “enable a duration” , once I did that a box appeared below the tick box with the value in seconds I had previously entered on the original 1.7.4 database for that item.
The system now appears to be working correctly so I’m wondering are these quirks normal or have I found something new. Is there something I should check to make sure the upgrade completed correctly. 2 previous upgrade attempts had failed completely usually resulting in the upgrade wizard appearing, however after reverting to the original snapshot and attempting a third upgrade it completed without errors,I suspect I was trying to login to xibo cms too early and the upgrade hadn’t completed. The third time I waited about 20 minutes before I logged into the cms but once I did I experienced the symptoms listed in the top paragraph.
That is a new one on us - and to be honest I am not sure how that can have happened. We will do some digging to see if anything jumps out.
We did have a problem with that in one of the pre-stable 1.8 releases, but you shouldn’t have experienced that going from 1.7.4 to 1.8.0. The upgrade creates some archived xlf files in your library folder, which are the pre-upgrade state of those layouts. Can you select one which had the issue and send it over to us? We will run it through a diagnostic and see why it didn’t tick those boxes.
It would be interesting to know what step the upgrade wizard appeared on - i would imagine that it was some sort of timeout, and that completing the wizard through the browser would have been sufficient.
I’ve just tried upgrading to 1.8.0 almost an exact clone of the original 1.7.4 system mentioned here, it falls over at step 141 - 1.8.0-alpha3 Indexing on the Stat Table
SQLSTATE[42000]: Syntax error or access violation: 1061 Duplicate key name ‘Type’ - which I’m pretty sure was the step it failed at previously.
In relation to the original system I upgraded, yes there are archive.xlf files , is there a facility in this site to upload files, or do i need to upload to an external site and post a link. I also still have the original xibo-library and import.sql file the combined total is around 159MB. So if necessary I could upload that somewhere if needed.
I’m afraid I’m still stuck on my second system trying to upgrade to 1.8.2 from 1.7.4 . I’ve tried several times now and it’s still stopping at the same place which baffles me. Indexing on the Stat file - duplicate key name “Type”. Any suggestions how I can proceed past this.
Did you make any patches to your 1.7.4 installation? I remember that the index on the stat table was mentioned here before and I wonder if that has been applied pre-upgrade.
If so (and in any case) you can safely skip that step - the key already exists and that is sufficient.
Yes absolutely - you can go from 1.7.0 to 1.8.2
----[quote=“JezzatheBullfrog, post:3, topic:10630”]
SQLSTATE[42000]: Syntax error or access violation: 1061 Duplicate key name ‘Type’ - which I’m pretty sure was the step it failed at previously.
[/quote]
Sorry for the delay in my reply - had a busy few days! I see your support ticket and will get that looked at.
Apologies I can’t figure out how to quote previous replies.
You asked “Did I make any patches to our installation?” .
We got someone else to build the original xibo system for us which came to us with 1.7.4 on it and some basic layouts to get us started from an installation he had done for another company. Unfortunately the person who did that for us is on holiday at the moment so I can’t ask them if any additional patches were applied.
Ok this attempt was 1.7.4 standard direct to 1.8.2 docker version
ok as instructed on step 141 “Indexing on the stat table” I pressed skip nothing happened - I waited another 10 minutes still nothing, so I clicked on the start button and it burst into life and got as far as step 155 “Add the WidgeId to the Stat Table and sat there with the cog wheel” I waited for another 20 minutes and still no further forward.
so for some reason I decided to press refresh if refressed and gave me from step 157 with the start button, I pressed start again and it then progressed from step 157
There was no sign of step 156 so no idea if that was processed , also noticed that it took a while to complete step 158 - “Remove old stat records”
Finally I’ve got to the end and the upgrade has completed.
My cms site key is blank again, however all layouts and their timeline items now have their correct durations and the associated box is already ticked for me . However one layout which isn’t really used is putting several big X’s across it. So I’m not so sure what that is all about. The only other observation during all of this , is that in the list of upgrade steps there was a step 104 and 105 - both of which said “Allow events to have an empty to date”
So now even more baffled why this isn’t just doing a straight forward upgrade without several interventions.
I haven’t checked yet today if I’ve had a reply to the support email/ticket so I’ll update this is you’ve asked for anything else.
On a slightly off topic note, I’m noticing that most of this forum is dedicated to people asking how to fix things or how to do things. Is there a section for “We have used the system to do this, if you would like to do likewise this is how you do it” . I’m also slightly loath to make suggestions or for feature requests at this early stage as it detracts from the brilliance of the current software or the feature may actually already exist and I’ve just not found it yet, is there an area or preferred method of making suggestions.
I’ve done a bit of research myself on the missing site key in the CMS. When you first run the docker, the xibo_cms-web_1 runs a entrypoint.sh file. If import.sql is present it imports this file into the database it then runs a few other mysql commands , one of which is
mysql -D $MYSQL_DATABASE -u $MYSQL_USER -p$MYSQL_PASSWORD -h $MYSQL_HOST -P $MYSQL_PORT -e "UPDATE `setting` SET `value`=’$CMS_KEY’ WHERE `setting`=‘SERVER_KEY’ LIMIT 1"
before it then renames import.sql to import.sql.done
Unfortunately $CMS_KEY is blank at the point this statement is run, so not sure why this statement is here to change what is in the imported sql file and also unsure what sets $CMS_KEY
However Later in the script for a brand new database $CMS_KEY is generated by
CMS_KEY=$(head /dev/urandom | tr -dc A-Za-z0-9 | head -c 8)
mysql -D $MYSQL_DATABASE -u $MYSQL_USER -p$MYSQL_PASSWORD -h $MYSQL_HOST -P $MYSQL_PORT -e “UPDATE `setting` SET `value`=’$CMS_KEY’ WHERE `setting`=‘SERVER_KEY’ LIMIT 1”
This bit makes sense generate a new random key for a new database.
Should that initial mysql statement be there for an imported sql file . As far as I can tell this function is only there when switching from a non docker to a docker version of xibo and the need to import a “import.sql” file.
There’s a General Discussion category which I would say is suitable for that, although as you say, the majority of the traffic is people asking for support.
