Monday, 6 August 2018

Computing resources optimisation [1D]

Well a few posts back "pc4" was being set up with Debian 10 (buster) as an evaluation computer and that was purely for that purpose and it had my media collection installed in order to evaluate it as a media player. But it does struggle to achieve that role because the hardware is too old and slow to play back videos and so Kodi gives a choppy display in playback.

Since writing therefore a new purpose has arisen for a computer to be on my desk that will be permanently connected to a tethered phone for which purpose the requirement is to have access to the internet for times and reasons that would be outside of the scope of the school's internet connection which I can currently use for 10 hours per day. However it is still not a solution for times when I want to watch streamed church content from Australia or elsewhere because the volume would blow my data cap relatively quickly. But having that computer on my desktop instead of using the bedroom computer over VNC reflects that I would expect to be using the desktop computer more often and also that the VNC option has proved unreliable because of software crashes and problems getting the software to run as a service. I haven't seen these issues with VNC on the Win10 computer but I have spent a great deal of time trying to resolve these problems on Bedroompc to no avail.

So the computer will be renamed from "buster" or "pc4" to "ministrypc" as it is being used for ministry work and that work could, at times, run into problems with the school web filtering system and I want to keep this work separate from the use of the school wireless system because of that. This will also provide me with a more convenient option for general internet use outside of the hours that the school wireless is available. The computer will be plugged into the Ubiquiti bridge that I have and this bridge will in turn be able to automatically connect to one of my two phones that can be used in tethered mode to provide the required data connection.

On or about the 21st July I wrote a post highlighting that I had had problems with using a Vodem with various computers to gain access to the internet via my cellular data connection. I blamed the problems I was having at the time on the Vodem as it seemed to be possible to get a direct data connection on the Galaxy Tab Android tablet that I had and this seemed to show the Vodem must be the problem. Subsequently I was able to get the tablet to work which seemed to prove this was the issue. However while I have been able to use the tethered phone on a number of occasions, last evening it would not work at all while the tablet again worked (and is being used to write this post). The fact that this issue keeps occurring with either Vodems or tethered phones suggests rather strongly that Vodafone in actuality does have some kind of system that they use randomly and without notice and subject to their own whims to impose a total obstruction of tethering. This is obviously of considerable concern to me and is something I will have to keep evaluating in coming days to try and work out exactly what is going on as it imposes severe limitations on the work I was expecting to do with this computer that really depends on the tethered connection.

So a couple of days later Vodafone has still not resolved the blocking issue with tethering still being blocked so regrettably the idea I was going to be able to use this computer for ministry is under question at the moment. If I cannot get any sense out of Vodafone I will have to try to find an alternative solution.

At the moment I am still testing out VF but at least the network has been more reliable and ministrypc is able to get onto the internet much more readily. Interesting is that every Linux PC in the house is now running Debian (except for laptops which don't get used much). So mediapc and even bedroompc are running it now. It is just so much better set up than Xubuntu which is a bit nanny state in so many ways (like in regard to hibernation and using the root account). 

Wednesday, 1 August 2018

Backup software / recap

About eight years ago I thought I was building a really special PC with a Intel DG41RQ mainboard, Celeron E3300 CPU and 2 GB of RAM. The article series started here: https://enzedtech.blogspot.com/2010/10/rebuilding-my-pc-1.html

Unfortunately I outgrew that computer pretty quickly because it could only take 4 GB of RAM in total and therefore became pretty slow with later versions of Windows. However it would work fairly well under Linux. I often wondered why I bought a LGA775 system that was right at the end of that generation of CPU, and it looks like cost was an issue. The Celeron E3300 did support hardware virtualisation though (that was something that would have been useful if the computer had enough RAM, as 4 GB was barely enough just for Windows).

These days I try to do a better job but at times there can still be a price/performance tradeoff to consider, the main reason why I have a serverpc that only has 16 GB of RAM in it because the board only has two memory slots. Well we could put 16 GB DIMMs into the two slots but would have to throw away the existing RAM. Most of the time I try to buy something with four slots, and that's why the computer this is being written on has 32 GB in it.

Now to focus on good free backup software for Windows. I may have written about this before but that particular post isn't easy to find. I get asked this question from time to time so here is an answer. The two best free packages in my view are NCH FileFort and Cobian Backup. FileFort is a commercial package that has a free edition for home use, while Cobian is just free. I used to use Cobian to backup my systems when everything was running Windows, but of course now I don't have a need for it.

FileFort is perhaps a little more user friendly than Cobian however whereas Cobian will simply stop reporting error messages if there are too many, FileFort's problem is it will stop running if there are too many errors. This is annoying because you should be able to just check the errors later (they may happen for reasons like being in use as not all software packages can handle this well). Cobian also has the ability to use VSS which means it can copy in use files. So Cobian is probably the better of the two, however FileFort is probably more up to date (Cobian does work with Win10 so it's OK for a few more years, anyhow).

PulseAudio settings in Debian

As everyone knows, PulseAudio is pretty common in Linux for controlling audio levels. It was written by the same guy who wrote systemd. You can make up whatever politics you want around that.

PulseAudio has a configuration file called daemon.conf that is located either in ~/.config/pulse or in /etc/pulse . An important setting is flat-volumes = no

What's important to note is that Debian is, apparently, the only major distro where this setting is not set to no, which means it defaults to yes. The problem with this being at yes, is that it will cause problems with applications because changing the volume on an application like Kodi (which has its own volume control setting) will also change the system volume level and this can create issues when other applications play sound. As it happens, Kodi sets the volume level up when a new track starts playing and this causes problems when you want the volume to stay at a lower setting.

In the case of mediapc, with my reinstallation of Debian, this file already existed in my home drive with the right setting and there was no such issue. However it is useful to note that if Kodi is the active window, it will respond to keyboard volume control buttons the same way as if the Pulse Audio plugin is being used (when Kodi is not active). The difference is you are setting Kodi's internal volume control this way.

There is an active bug report open at the Debian Project (541538) which has been going for 9 years so far but may actually be getting some traction by now as all that is needed is a change in a script or something to make this setting be done properly in the default install.