Having recently ripped an album to my file server, I couldn't get the album art to display in xbmc. The solution turned out to be changing the file permissions to read/write for all users & groups.
Sources & References:
I recently converted my music collection to the mp3 format; however, whilst the playback quality is excellent, many of the tracks had erroneous track duration data. This wasn't a particular problem until I copied some of the tracks to my phone which started crashing while playing music and I began to suspect the duration error as the culprit.
Changing duration is not as straightforward as fixing tags (easily achieved using EasyTAG) but there is a great app in the Software Center for doing just that, MP3 Diags.
Track duration errors are caused by missing, incomplete, or corrupt variable bitrate (VBR) headers:
"There are 3 kinds of VBR headers: Xing, LAME, and VBRI. MP3 Diags identifies files having an incorrect or missing VBR header, and allows you to create Xing headers, should you need to." Source: MP3 Diags, MP3 Introduction
Warning, following this advice may corrupt your music files - backup first!
Despite the rather dire warning above, I've experienced no data loss or corruption (at least, none that I've found) and this great app has repaired all of my track duration errors and one or two other issues as well!
If you're using Ubuntu or one of it's derivatives, the best installation option is the Software Center. Open the Software Center and search for mp3diags - don't put a gap between mp3 & diags or you'll only be offered the MP3 Diags documentation. Simply install as usual.
When you open the app you must scan your files for errors. Just click the gear icon (1st on the left of the toolbar) and the browser will open. You can also scan remote files if you have mounted them using SSH: in Mint the route is a little convoluted, try:
...and then look for your music directory. Select your directory and then hit the Scan option. This can take several minutes on a single remote directory (album), so patience will be needed if you have a large music library with lots of errors. My repairs took over a week on a modest (3,500 track) library.
If the scan reveals any Xing errors, repair them by clicking the single transformation icon (a hammer with a green arrow) and selecting the Repair VBR data option.
Sources & References:
It's taken weeks of Googling, but I've finally found a fix for the internal microphone on the Presario CQ60.
I had no luck with the various fixes that I found online until I came across this post which, if I've understood it correctly, suggests that the problem with the internal microphone on the CQ60 is not a software issue but a hardware problem. As I understand the OP's problem, the kernel allocates the wrong pin id at boot: the workaround turns out to be surprisingly simple.
First we need an application developed by David Henningsson at Canonical. It's called HDAJackRetask and it was originally developed to turn unused microphone jacks into additional headphone jacks - brilliant! It's now part of the alsa-tools-gui, so there's no need to add a new repository. Open a terminal and do:
sudo apt-get install alsa-tools-gui
Alternatively, you can download it from the Software Center or Synaptic. When prompted about the additional space (in the terminal method), type y and hit enter.
Open HDAJackRetask from the Main Menu (in Mint Cinnamon it's under Sound & Video). Select your sound card and then, under the Options panel, check the Show unconnected pins option. In the Pin configuration section, look for your Internal Mic, Riser entry, click the Override checkbox, and set the spin button to Not connected.
Next, look for the Pin ID: 0x1d, check the Override checkbox, and the use the spin button to select Internal mic. Now click the Apply now option and test your microphone. If all's gone well, it's time to make this a permanent change: click the Install boot override. You'll see the following message dialog: click OK and reboot.
Sources & References:
There never seems to be enough hours in the day and I have a pile of topics that I want to get published here on Karmic Odyssey but haven't (yet) had the time. Nonetheless, posting my wallpaper for all to see is a cheap post and often gets the ball rolling: for my first post this month, here's the new desktop for the Presario CQ60
This is Llyn yr Arddu looking west towards Moel Hebog. It's another image taken with my Samsung Galaxy which is rapidly proving that I don't need to carry a large (and heavy) camera on the hills.
Sources & References:
Apart from loving the look and feel of the Cinnamon desktop, Mint 17 has another attraction over some other Ubuntu derivatives such as Lubuntu: Secure Shell (SSH) has native support from the file manager GUI.
Many of my posts over the last four years have been about networking & file sharing using Ubuntu and I have used (and promoted) Samba as the solution to my particular circumstances. However, recently I have become increasingly aware that Samba is not without its problems, particularly read/write permissions and lock files on the remote server. These problems aren't terribly serious and there are ways to work around the issues; but I want my file server to be just that and I don't want to find workarounds for simple file sharing on a private network.
As an example, you may know that I spend much of my free time in the mountains of North Wales and take some of my pictures on my mobile (cell) phone. Rather than slip the ssd out of the phone and into a card reader (meaning that I have to stop the card and disassemble the phone) I normally use Bluetooth and set up a personal area network (PAN) to transfer the files to a laptop or desktop. Using Samba, I find that I can't simply copy the new files to my pictures directory on the server because I don't have the necessary permissions. Try as I might, I can't seem get the read/write access right. I've also had problems with GnuCash, meaning that I have to use the program on the server to update my finances - not ideal!
Using Secure Shell to connect to my server resolves all of these permission issues at a stroke and, for all intents and purposes, it behaves exactly the same as accessing local files. It has the additional advantage in that directories on the server do not need to be shared in the conventional sense and that makes them accessible only to me (or anyone that steal my login credentials).
To access your files you need only to invoke the Connect to Server... dialog from Nemo (File > Connect to Server...) and provide the necessary details.
If you've set up Samba to recognize netbios names, then it's pretty straightforward: the port default for SSH is 22 (and will only change if you've changed it!). Once connected, you can access your files and directories from Nemo's GUI and use them locally. This may be overkill on a private network, but using SSH also resolves another irritating problem: file lock. Using Samba, if an application wasn't closed before shutting down the client pc, the file lock would remain on the server (effectively making the file, read only): SHH seems to resolve this problem because Nemo is closed down as part of the normal shutdown sequence.
One final tip, if you're having trouble connecting to your server, check that ufw is allowing incoming traffic on port 22:
sudo ufw allow proto tcp from 192.168.0.0/24 to any port 22
Sources & References:
It wasn't long before the new Presario CQ60 ran into problems: despite managing to achieve stable graphics using Mint 17 Mate, I couldn't seem to maintain a persistent WiFi link. Often, the hardware button wouldn't work and, even when it did, it rarely made a difference as to whether or not the laptop connected to my network. Issuing the terminal command:
would show the hardware blocked and the command:
rfkill ublock all
had no effect. It was sometime before I realized that this is by design! It was clear that I had to find a way to make the hardware switch work if I wanted this laptop to be more than a vanity project.
Having read some comment online that Lubuntu had a more reliable wireless platform, I installed the latest version (14.04 LTS) of the Ubuntu derivative to see if it made any difference: it did, effectively ruling out hardware as the source of the problem. Had I merely wanted a functioning laptop I could easily have left the lightweight operating system in place but, whilst this is undoubtedly a viable solution, the truth is that I'm not terribly keen on Lubuntu and I really love Mint Cinnamon. There are also some practical networking reasons for preferring Mint over Lubuntu (specifically, native SSH support) and I want to migrate from SAMBA to manage my network, so the research effort began!
This problem with the Presario is not entirely unknown and it seems that there is no single solution. Nonetheless, there does seem to be an online consensus that replacing the ath5k driver for the Atheros chipset for the ath9k driver is the most successful fix and I resolved to give it a try. However, fate intervened to scupper my plans.
At some time on Wednesday of this week I lost my WAN connection: this makes testing a WiFi connection problematic! It was twenty-four hours before the restoration of my connection and I didn't get around to reinstalling Mint until late yesterday afternoon. I decided to go for Mint 17 Cinnamon and, as always, the WiFi connection was flawless on the live disk but, more importantly, it was also flawless after installation to the ssd and I have no idea why! This condition has persisted beyond the initial (307MB) software updates and countless reboots (both restarts & cold boots), so I'm assuming that the problem is resolved. I can only identify two candidate processes that may have influenced this change in fortune:
It's not clear if either or both of these changes had the desired effect, but I remain connected a day after installation!
Having also had some unpleasant experiences with the graphics drivers during previous implementations of Mint, I decided to install the nvidia-304 legacy driver right off the bat and it has proved to be a good decision. Sure, the boot sequence isn't as pretty as it would be using the default nouveau driver, but, with the improved boot time delivered by the new ssd, who cares? Moreover, there is absolutely no flicker or distortion during operation and I now have a stable (as well as, connected) Mint 17 Cinnamon installation.
This little laptop has exceeded expectations although it has proved to be quite a challenge to get it running the Mint OS. The irony is that, despite learning a great deal about networing drivers in Ubuntu, I can offer no explanation as to why the problem has been rectified but I'm thrilled that they have been.
Sources & Reference: