User Tools

Site Tools


Clementine Scrobbling Fixed

I have stumbled upon a fix for Clementine's inability to scrobble to which I reported earlier. It turns out to be a problem with Firefox, not Clementine: I mentioned last time that the error reported seemed to indicate that was replying to Clementine's authorisation request in plain http when secure https was expected. This was close! In fact, explicitly do use http for this authorisation process and it's Firefox's built-in attempts to upgrade the connection to https that's causing the problem.

So the fix is to temporarily stop Firefox attempting to upgrade to https all the time. This is done in the about:config page; search for security.csp, as shown here:

The first option shown (security.csp.enable) is the one which, if enabled, causes this 'escalate to https' behaviour (since the “csp” in its name stands for Content Security Policy). So double-click it to flip to 'false' and then try your Clementine↔ authorisation process again:

As you can see, Clementine is now registered and happy with its connection to That done, you should double-click the “security.csp.enable” item in about:config once more to flip it back to being enabled: using secure http rather than its insecure cousin is something you probably want to do more often than not.

2019/03/24 09:49 · dizwell

Debian Blues...

So, Day 1 with a fresh Debian Testing install. It has completely locked up my PC three times thus far: at this point, I'm thinking there might be something wrong with my PC! No logs to help me out, of course: just sudden and unpredictable system freezes requiring the use of the power switch to resolve.

Also, this is a bit of a show-stopper:

Clementine has long been my music player of choice and it has always been able to 'scrobble' details of the music I play to the website. Only now, it can't! The error message you see there implies that is sending a partially plain http response when a secure https message is expected, which would make it's fault (I guess). On the other hand, I did find a report which suggested that Debian itself might have removed things that break this particular feature.

In any case, happy though I am with the ease of setup of this particular Debian installation, no scrobbling is a deal breaker… and I've prepared a Fedora KDE live USB to test things out on instead. If it scrobbles, it's replacing Debian. :-)

Updated to add: the live USB of Fedora doesn't include Clementine, but it's easily installable… and once it's running, it can't scrobble either. It's clearly a problem with this version of Clementine, rather than a Debian or Fedora issue, therefore. Debian can thus stay (at least until the next unexpected system lock-up)! Meanwhile, I need to find an alternative, scrobbling music player for KDE… (I shan't hold my breath).

Further updated to add: The problem isn't Clementine, but Firefox's built-in security mitigations. A description of how to fix Clementine's inability to be authorised with is to be found here.

2019/03/24 09:30 · dizwell

Desktop Woes (Part #94)

Slightly over two months ago, I installed OpenSuse Leap 15 as my main desktop operating system. I managed to tweak it to be the way I liked and it has been a mostly happy experience since.

But not entirely.

Some bugs appeared from time-to-time, for example. Mostly transient and of so little real consequence that I didn't make a note of them and can't, therefore, now describe what they were particularly.

But then a week ago, something much more problematic started happening and hasn't really stopped: anything to do with Dolphin (the file manager) would go e x t r e m e l y … …. s  l   o    w     l      y. To the point where the desktop would effectively hang for tens of seconds on end, with mouse-clicks doing nothing until suddenly doing everything at once. Copying a 1GB file to my file server became a 'start it and come back after dinner' affair.

I couldn't explain it, and still can't. All my PC's hard disks are solid state; the link to the file server is gigabit ethernet. Nothing is running out of space; all SSDs have been trimmed. There's neither rhyme nor reason to it, other than the fact that I have continued to apply updates to the OS as they've been produced (perhaps thereby introducing instability: constant updates are something I really need to get out of the habbit of doing!

I've put up with it for a week because I hoped it would resolve itself, but after a week, I thought it was time to bite the bullet and replace OpenSuse Leap 15 with something less problem-prone. The great distro hunt of 2019 therefore began!

In searching around for a suitable replacement for OpenSuse 15 (which, it turns out, has a bit of reputation for being a tad buggy), I made some brief notes from assorted test installs I performed onto a spare (and somewhat sacrificial!) laptop. I reproduce them now, verbatim:

  • Kubuntu wireless network keeps asking for password, no matter how many times I supply it
  • Debian 9.8 Stable -incredibly old software (eg, LibreOffice back at version 5.x etc)
  • Debian testing - No live environment, but easy install. Can't use wireless network during install (no firmware and cannot install it by presenting a second USB with relevant file). This wouldn't be an issue on a desktop without wireless networking, of course.
  • Zorin - looks incredibly childish. Would not be happy long-term with this look-and-feel.
  • Mint - no KDE version at all these days, and I'm not touching MATE, and dislike Cinnamon. Non-starter.
  • Fedora - not keen. Too bleeding edge. Want something less prone to breakage.
  • KDE Neon - Same as Kubuntu in that it constantly re-asks for wifi password, even though I've supplied it a zillion times. Also missing most software out-of-the-box. Nothing to distinguish it otherwise.
  • Gecko. Got the STATIC plasma version. Boots live (unlike 'real' OpenSuse), but is extremely slow to do so. So laggy when it finally finishes booting that it's practically unusable. Tried again using USB3 instead of USB2, but speed is still poor. Software reasonably modern (LibreOffice, for example, though 'real' OpenSuse is up to KDE continually prompting for wifi password even so, just like with Kubuntu and Neon.

One of the common themes there is KDE forever asking for a wifi password. That seems to be a widely known problem, too! Unfortunately, I couldn't really find a fix that applied to me in a live session, other than to 'save the password for all, unencrypted', which seems a bit of a blunderbus approach to things.

Anyway, long story short: none of these distros seemed perfect, but the least bad one, I think, is probably Debian Testing. Debian Stable is way too out-of-date, software-wise, for my tastes, but Testing is pretty much as up-to-date as you could ask for. Every piece of application software I require seems to be readily available in the standard repositories, too. It's KDE implementation is pretty vanilla and thus nicely customisable. Of course, it's essentially a Beta version of what will eventually be Debian 10 …and running beta-quality software is not exactly my cup of tea. But, reading around the place a bit, it seems that Debian Testing might be a good deal more stable than many other distros' stable releases!

This weekend, therefore, I shall be backing up my main PC with a bit of rsync magic and a spare USB drive and then wiping the lot and starting afresh with a brand new Debian Testing install. We'll see if this can make it to the middle of Summer, at least!

2019/03/23 13:18 · dizwell


We have just returned from a short break in Leipzig, formerly the home of Johann Sebastian Bach. It was something of a music pilgrimmage for me, though we found time to do less music 'sights', such as the immense (and immensely impressive) Völkerschlachtdenkmal, a memorial to the dead of the Battle of Leipzig in 1813. I hadn't even realised there was a Battle of Leipzig then, but it turns out to have been the largest battle ever fought by mankind up to that point and sealed the fate of Napoleon, who abdicated shortly thereafter.

Anyway: I have to say I was a bit disappointed in the Bach side of things. There is certainly the Tomaskirche (pictured), where Bach was Director of Music for the last 27 years of his life. We went to a service there, which was moving enough. The church has two organs, JSB's grave, a memorial window to him and an excellent continuing choral tradition. Except the organs are relatively modern and definitely wouldn't have been played by Bach; the church interior was renovated extensively throughout the 20th Century, so that it looks nothing like what Bach would have known; and we're not even quite sure if the contents of the Bach grave are actually of Bach and not some random other gentleman. Bach was actually buried at St. John's, which was destroyed by bombing in WW2, so what were thought to be his remains were moved to the Tomaskirche in 1950 -but the identification of the St. John's grave as Bach's relied on 'folk memories' of him having been buried in a certain location.

Meanwhile, Bach also ran the Nicolaikirche, which was just a hundred yards or so from our hotel. It had its interior completely re-done during the late 18th Century in fantastic neo-classical style -meaning that it too bears no relation to anything Bach would have seen, no matter how splendid it looks today.

So we drove to Eisenach, Bach's birthplace. There, the Bachhaus is the place where Bach grew up until he was about 10. It is full of furniture from the mid-18th Century -except none of it was actually owned by the Bachs. The house, though, is as he would have known it -except for the minor detail revealed by one display photograph, of the morning after an American bombing raid in 1944 -namely, that the building was extensively damaged and thus what you see today is, mostly, a fairly modern repair job.

Back to Leipzig: the Bach Museum opposite the Tomaskirche is well worth an extended visit. I think we spent the best part of three hours in there, which is a bit of a record for us and museums of any sort! At one point, their guided audio tour invites you to look out of a window to a place where the Thomas School that Bach worked in (and composed in) would have been. Why isn't it there now? Because the Mayor of Leipzig decided to demolish it.

Yup. Just like that, in 1902, the place where Bach composed some of the most glorious works of music the world possesses was demolished. They managed to save a door (which they transplanted to the Eisenach Bachhaus museum).

So, sadly, I came to the conclusion that Bach isn't really in Leipzig anymore (unlike, say, Britten in Aldeburgh: go to that part of the Suffolk coast and Britten's presence is still real, tangible and immediate). There are some places he would have wandered, some buildings he would have known -but they mostly don't bear any resemblance to what he would have seen. Some of the most important places he lived and worked in don't exist. Even his grave might not be his.

I came to the conclusion that the only substantial, real monument to Bach these days is his music -and after learning about the Battle of Leipzig (some 60 years after his death), with thousands of Napoleon's troops camping in the town in a cold October, with their tendency to burn anything made of wood or paper to keep warm, I'm rather more surprised than I was that so much of Bach's music has survived the predations of time!

It was a flying visit, of course (three days), so no time to visit Weimar, Arnstadt, Mühlhausen, Köthen or the many other places in that corner of Germany that Bach would have known and visited or lived in. Perhaps the presence of Bach is better felt in those other places? Future visits may tell me!

I nevertheless enjoyed Leipzig a lot. It just wasn't the 'Bach lives Here' memorial I'd hoped to discover there -which probably says more about the level of my expectations than anything else.

2019/02/24 11:27 · dizwell

Determining a CD Drive's Read Offset in Linux

CDs are becoming a bit of an historical artefact these days, what with the proliferation of music streaming services! Even my favourite music purveyor now offers much of its catalogue in the form of downloadable digital files, rather than physical CDs.

Nevertheless, you will still come across music which is only available in physical form -and, of course, you may have hundreds or even thousands of physical CDs from your past which need to be converted to digital files at some point (a process called 'cd ripping')

When you come to do that ripping, though, it's important that the computer CD (or DVD) drive you use to do the deed is reading the physical CD accurately… and that's harder to do than it perhaps ought to be!

For starters, an audio CD doesn't allow random access: you have to start somewhere and read sequentially on from that point. Which means it's rather important to know precisely what that starting point is… and most CD players can't reliably tell you that! Nearly every CD player mis-places its reading head by a number of audio samples: so your audio program says “read audio sample 1000” (for example), and the drive will actually return data from sample 1000 + or - something. The “something” tends to vary by manufacturer and/or by model. In other words, it doesn't vary depending on what CD you're playing but by what device is doing the playing. Once you have determined that your player adds 6 samples when playing CD x, you can be fairly certain it will add 6 samples when playing CDs y, z and a, too. Most NEC CD drives will, for example, add 48 to the sample number it's supposed to be reading. This difference between where a drive is meant to be reading and where it's actually reading is called the 'Drive Offset' -and it's important to know it if you genuinely want perfect duplication of CDs.

There are software tools which can work out what the drive offset is for a particular CD (or DVD) drive; unfortunately, they tend to be Windows-based and require tricks to get them working on Linux (Exact Audio Copy, for example, can tell you your drive's offset, but only runs on Linux via Wine, which I dislike using on my desktops unless I really have to). Whipper is a native Linux program that can also determine your drive's offset -but it's difficult to install on OpenSuse 15 (my distro of choice).

So, instead, I've consulted AccurateRip, which is a publicly-accessible list of known CD and DVD drive models and the known drive offsets for each. If you know the model of your drive, you can consult that list and work out what your offset is.

Unfortunately, that's all a bit manual for my tastes! So, I've automated it somewhat :-)

If you create a blank document (say, and paste this set of commands in to it:

read -p "Which CD/DVD drive should I check? : " DEVICE
if [ $(lsscsi | egrep -i cd/dvd | egrep -i $DEVICE | wc -l) -eq "0" ]; then
  echo "That's not known as a CD or DVD device!"
  exit 1
  wget --quiet -O /tmp/cddriveoffsets.csv
  DEVICENAME=$(lsscsi | egrep -i cd/dvd | egrep -i $DEVICE | awk '{print $5}')
  DRIVE_OFFSET=$(grep $DEVICENAME /tmp/cddriveoffsets.csv | awk -F "|" '{print $2}')
  rm /tmp/cddriveoffsets.csv
  if [ ! -z "$DRIVE_OFFSET" ]; then
    echo "Drive Offset for $DEVICENAME ($DEVICE) is: " $DRIVE_OFFSET
    echo "Your drive's model name/number is not in the AccurateRip database."
  exit 0

…you can then run the script with the command:


You'll see output such as this:

Which CD/DVD drive should I check? : /dev/sr1
Drive Offset for DH-16AES (/dev/sr1) is:  6

When prompted, you type in the device name of the CD or DVD drive you want checked (if you type in a device identifier for a normal hard disk or anything else which isn't explicitly known to be a CD- or DVD-ROM drive, you'll be told as the script aborts).

Usually, that would be “/dev/sr0”, but because my PC has two CD drives and I only use the second of them for ripping, I've specified “/dev/sr1” (without the quotes, though). Armed with that information, the script then checks the model name/number for that device using the lsscsi command and then uses plain old grep to check if that model number is found within the AccurateRip database. If it is, it returns the known offset for that model; otherwise, it tells you your drive is not known by AccurateRip.

With only a limited number of CD drives in the house to test it on, I can't be sure whether lsscsi will always return useful and usable model numbers, but it works for me with my other CD drive, for example:

Which CD/DVD drive should I check? :/dev/sr0 
Drive Offset for DS-8D9SH (/dev/sr0) is:  6

…which is a different model number but happens to have the same offset as my main drive. (Note, a manual check of the AccurateRip database confirms the script isn't just outputting the number 6 no matter what input is thrown at it!!)

Once you know your drive's offset, you can use it when ripping a CD to compensate for your drive's inability to read precisely where it's told to read! For example, a basic command to rip track 1 from an audio CD using cdparanoia would be:

cdparanoia -B -z=40 -d /dev/sr1 "1"

Which means “please rip track 1 from device /dev/sr1, and if you encounter a scratch or other defect that makes reading the audio data tricky, take a maximum of 40 goes to do so before giving up”.

Except that command will rip (in my case) 6 fewer audio samples than it should, because my drive is known to mis-read starting points by 6 samples -so my rip won't be accurate.

Let's say I run it anyway, however:

[email protected]:~> cd Music
[email protected]:~/Music> cdparanoia -B -z=40 -d /dev/sr1 "1"
cdparanoia III release 10.2 (September 11, 2008)

Ripping from sector       0 (track  1 [0:00.00])
          to sector   22874 (track  1 [5:04.74])

outputting to track01.cdda.wav

 (== PROGRESS == [                              | 022874 00 ] == :^D * ==)   


Cdparanoia itself is happy: the “:^D” smiley face at the end there indicates it believes it's just performed a perfect rip. Now let's save that output file with a new name, and then re-rip the same track, but this time telling cdparanoia about our drive's known offset:

[email protected]:~/Music> mv track01.cdda.wav run1.wav
[email protected]:~/Music> cdparanoia -B -z=40 -d /dev/sr1 "1" -O 6
cdparanoia III release 10.2 (September 11, 2008)

Ripping from sector       0 (track  1 [0:00.00])
          to sector   22874 (track  1 [5:04.74])

outputting to track01.cdda.wav

 (== PROGRESS == [                              | 022874 00 ] == :^D * ==)   


I therefore now have two different audio files in my Music directory:

I can assure you, though obviously you'll have to take my word for it, that both files play just fine and sound identical. But are they, in fact digitally identical?

[email protected]:~/Music> ffmpeg -i run1.wav -map 0:a -f md5 - 2>/dev/null

[email protected]:~/Music> ffmpeg -i track01.cdda.wav -map 0:a -f md5 - 2>/dev/null

That ffmpeg command calculates an MD5 hash of the audio data from the named file. If the audio data were exactly the same in both files, the MD5 hashes for them would be identical. But you can see that the hashes are different. So in this case, sounds can be deceptive: the files sound the same, but aren't actually the same, and it's the file ripped with the offset parameter that is technically the more accurate replica of the original.

2019/02/05 17:32 · dizwell

<< Newer entries | Older entries >>

wiki/blog.txt · Last modified: 2018/12/12 14:06 by dizwell