There is the theory that the HDMI output of the Raspberry Pi is only initialized if a monitor/television is connected and powered up before a Raspberry Pi 3 is turned on.
Yet when I connect my Raspberry Pi 3 to a old Panasonic Plasma display the Raspberry Pi actually turns on the device and the screen activates every time.
Not so with the Vizio P series I just hung on the wall.
Aside: some of the Panasonic HDMI ports were damaged in a painting disaster…never use a 20lb weight to hold a tarp.
With the Vizio, whether the monitor is on or off and the correct HDMI port is selected or not, the Raspberry Pi 3 simply never brings up HDMI output.
Edit the /boot/config.txt file and uncomment these two lines
And the device works every time from every state. The first line is as it appears, the second activates HDMI and enables sound rather than DVI mode which does not.
I did like that the Vizio takes edits the HDMI connection in its table to Raspberry
I am having backup problems, and was troubleshooting other issues earlier in the year, and my resolution at the semester was to export all the classes, create a clean database and reload the classes thereby getting rid of any cruft issues from a not-as-old-as-one-might-think Moodle setup.
The day started easily but I kept getting a nagging feeling that the classes were to large and found a mdl_log table in the database with entries from years ago and quite a large number of them. Apparently Moodle upgraded and did not remove the old log. So I used TRUNCATE and emptied the table. Of course I had researched the table and implications, backed up the database and so forth.
I then changed the log retention date to 2 days and ran cron repeatedly and was unable to trim the mdl_logstore_standard_log file at all and it was huge as well. I finally used TRUNCATE on that file as well.
I am a week along and the log files are running fine, no logs are appearing in the old table and I am hopeful the current logs are being pruned in accordance with the configuration.
I still haven’t resolved the backup issues and I am sure I have something else in the database and I pass on the obvious lesson that a Moodle site should be completely rebuilt annually, or on some regular schedule, to ensure that old data/tables are pruned or removed effectively.
If I could just resolve the backup stretching out as well as the backups in some, but not all, classes being retained I would have this system under control. Soon though.
I am back to troubleshooting, yet again, the problem of Moodle backups taking forever and a day. An actual day, for very small courses.
A second problem occurring with the automated backups is that the old backups are not being purged so the file system is filling up with them rather than purging/pruning them. I am solving the problem at present by a weekly manual clean up.
I could simply pour over the forums for an answer, which has not produced results. I could look at tables/records in the actual database for anomalies and that strikes me as time consuming. Or I could wait until the semester break in two weeks and backup and export each class and all the information and create a brand new instance of Moodle and restore the classes into that and see if that leaves the cruft and problems behind.
I am going with that alternative in the interests of cleaning up any other problems I am not yet aware of that affect other areas including performance.
This spring I reviewed the Packt publishing book Moodle 3 E-Learning Course Development – Fourth Edition
Within a week after it being published I had already recommended it for a teacher/consultant to use it to setup there online training course in support of their book/program. Take a look it is pretty great.
I have just finished reviewing another Moodle book for Packt which should be officially published soon.