On Thu, 27 Apr 2017 10:42:27 +0100, Andy Furniss wrote:

FWIW ... no such file or directory is the error you will get when mixing
32bit/64bit around so that error probably doesn't mean that gnutls is
not found.

I've most often seen the "can't fine libxxxxx.so" message, but I've also
seen the loader complain about the ELF format. I think the latter was a
binary that hadn't been recompiled for several years and could well have
last been compiled pre-PAE kernels.

TBH, I know nothing about multilib - pure 64bit LFS here, far too lazy
to do multilib LFS just for steam/old games, which is about all I miss
out on.

Its best to consider that the only programs that are going to run without
problems are scripts (Perl, awk and friends that don't generate permanent
p-code executables) and languages that compile but use runtime VMs (Java).

NOTE: some C programs, particularly those that haven't been recompiled
for a while, that were written for 32 bit architectures or that use casts
to map addresses into ints, typically for debugging displays, will throw
compilation errors, but these are easily fixed.


--
martin@ | Martin Gregorie
gregorie. | Essex, UK
org |

On Thu, 27 Apr 2017 12:03:55 +0100, Jim Lesurf wrote:

In article , Martin Gregorie
wrote:
On Wed, 26 Apr 2017 18:14:01 +0100, Jim Lesurf wrote:

Error while loading shared libraries: libgnutls.so.26: cannot open
shared object: no such file or directory.

I assume this means it can't find libgnutls.so.26 ?

I've tried installing what I *thought* might be the relevant
package(s) from the respositories the machine offers. But still get
the above. I don't know if this means I haven't found it, or if the
machine requires me to re-build on it to make a version of ffmpeg it
will be happy with. (Although simply copying across the executable
was fine on my other machines.)

I've recently upgraded my last remaining Intel-based 32bit PAE systems
(Intel core-Duo and AMD dual Athlon hardware) to X86-64 operating
systems on the same hardware and have seen the same problem with code
that is using dynamically linked libraries. The fix has been simple:
recompile programs that fail this way in the X86_64 environment.

I think I've installed the 32 bit versions of the OSs in the machines I
have. Plan to go to 64 bit next time.

Don't forget that some libraries have what looks suspiciously like a
version number in their name. It that's what it is and the version
changes as the result of an OS upgrade or reinstall, then that could
prevent the library from being found and, again, a recompile should fix
that.

No source so you can't recompile? Then raise a bug so the maintainer gets
a heads-up to fix it.


--
martin@ | Martin Gregorie
gregorie. | Essex, UK
org |

On Thu, 27 Apr 2017 12:00:12 +0100, Jim Lesurf wrote:

OK. However I should add that I've tended to use 32 bit distro versions
even on machines that may be 64bit. I do plan in future to use 64bit
ones for my next OS changes, but the laptop is 32 bit I think. However
I've now used uname and lsb_release on the laptop and got

So did I. Those eventually morphed into the PAE kernels I mentioned: PAE
is a form of extended addressing (typically to 40 bit addresses from 32
bits and the PAE kernels were happy to run to old binaries with 32 bit
addressing.

However, the move from 32b / 32b-PAE to X86_64 *does* generally require
recompilation of anything you've compiled yourself that not written in a
scripting language or that uses a VM like Java or Mono.



--
martin@ | Martin Gregorie
gregorie. | Essex, UK
org |

In article , Martin Gregorie
wrote:
I think I've installed the 32 bit versions of the OSs in the machines
I have. Plan to go to 64 bit next time.

Don't forget that some libraries have what looks suspiciously like a
version number in their name. It that's what it is and the version
changes as the result of an OS upgrade or reinstall, then that could
prevent the library from being found and, again, a recompile should fix
that.

No source so you can't recompile? Then raise a bug so the maintainer
gets a heads-up to fix it.

I could refetch (git) the ffmpeg sources for this. But in this case:

A) It was more of a faff than usual as I have to shift back the sources and
add a patch. Although maybe that isn't needed now for the flac dash?

B) The machine in question is very low power, so the build would then
probably take a long time.

And in practice I don't need to run the result on this machine as it works
on two others I can use anyway. Just that it was a suprise that I couldn't
install libraries, etc to get it working.

On the other side of this: I just checked and the new distro has FF 50.1.
This uses the dash streams for the established 320k aac from iplayer by
default, which is nice. But lacks the awareness of being able to do this
for the flac trial (so the BBC webpages said). So I'm wondering if this
will be upgraded by the distro maintainers before the Proms. Anyone know if
they are aware of this? FF 51 can apparently now fetch the flac via dash
OK. Presumably in time this will ripple down into the distro version. (?)

Jim

--
Please use the address on the audiomisc page if you wish to email me.
Electronics https://www.st-andrews.ac.uk/~www_pa...o/electron.htm
Armstrong Audio http://www.audiomisc.co.uk/Armstrong/armstrong.html
Audio Misc http://www.audiomisc.co.uk/index.html

On 26/04/17 18:14, Jim Lesurf wrote:
Error while loading shared libraries: libgnutls.so.26: cannot open shared
object: no such file or directory.

When I've seen errors of this sort, it's usually been because of
a broken symbolic link. Typically, there should have been something like

libfred - libfred.5 - libfred.5.2

and somehow one of these has been corrupted, so that an executable that
looks for "libfred" finds a symlink to "libfred.4" or whatever instead.
Cured by re-linking.

--
Andy Walker,
Nottingham.

Jim Lesurf wrote:
In article , Martin Gregorie
wrote:
I think I've installed the 32 bit versions of the OSs in the
machines I have. Plan to go to 64 bit next time.

Don't forget that some libraries have what looks suspiciously like
a version number in their name. It that's what it is and the
version changes as the result of an OS upgrade or reinstall, then
that could prevent the library from being found and, again, a
recompile should fix that.

No source so you can't recompile? Then raise a bug so the
maintainer gets a heads-up to fix it.

I could refetch (git) the ffmpeg sources for this. But in this case:

A) It was more of a faff than usual as I have to shift back the
sources and add a patch. Although maybe that isn't needed now for the
flac dash?

You would still need to, there's no new patch at time of writing.

B) The machine in question is very low power, so the build would
then probably take a long time.

And in practice I don't need to run the result on this machine as it
works on two others I can use anyway. Just that it was a suprise that
I couldn't install libraries, etc to get it working.

On the other side of this: I just checked and the new distro has FF
50.1. This uses the dash streams for the established 320k aac from
iplayer by default, which is nice.

The AAC streams are HLS not DASH AFAIK.

But lacks the awareness of being able to do this for the flac trial
(so the BBC webpages said). So I'm wondering if this will be upgraded
by the distro maintainers before the Proms. Anyone know if they are
aware of this? FF 51 can apparently now fetch the flac via dash OK.
Presumably in time this will ripple down into the distro version.
(?)

Don't know about distros, but a bin version of FF I tried needed pulse,
you have to build your own to get alsa, though maybe distros will build
like that.

In article , Andy
Furniss spam@spam wrote:
On the other side of this: I just checked and the new distro has FF
50.1. This uses the dash streams for the established 320k aac from
iplayer by default, which is nice.

The AAC streams are HLS not DASH AFAIK.

OK. However IIRC a right click did say 'DASH'. I'll check later on. My
memory isn't always reliable.


But lacks the awareness of being able to do this for the flac trial
(so the BBC webpages said). So I'm wondering if this will be upgraded
by the distro maintainers before the Proms. Anyone know if they are
aware of this? FF 51 can apparently now fetch the flac via dash OK.
Presumably in time this will ripple down into the distro version. (?)

Don't know about distros, but a bin version of FF I tried needed pulse,
you have to build your own to get alsa, though maybe distros will build
like that.

FWIW I used the OS controls on the panel to send the default output to the
USB device [1]. This is probably using Pulse. I've set the relevant
controls to 100% or '11'. This then let FF play the BBC iplayer out via the
USB DAC. So got it working despite the usual obsession distro people have
with assuming everyone *must* use pulse.

TBT My main difficulty here was the god-awful ergnomics of the way buttons,
etc, are shown by the default OS desktop. Not at all obvious which buttons
are 'on' and which are 'off'. Things like possibly using an 'x' to mean
something is *on*, or showing the 'button top' greyed as 'on'. Idiotic.
I had to experiment until I could work out what the appearance *actually*
meant from their effects! No doubt there is a more sensible 'theme' for
this, but if so, why not use it as the default rather than keep wanting
to 'impress' users with a 'k3wl' look that's disfunctional! :-/

At some point I'll use this to play an iplayer program and make a digital
capture.[2] Then compare that with using gip to get the file.

The aim is to let me compare what people will 'normally' get using their
system if they *don't* do things like use gip or ffmpeg, but simply use the
browser and OS as supplied. Personally, for iplayer I'l tend to use gip or
ffmpeg as it gives me a more direct way to get the audio data.

Jim

[1] Before doing this a command like "aplay foo.wave" wouldn't send
anything to the USB DAC and was clearly sending to the internal card. This
was *despite* my having added a .asoundrc file that specified the USB as
the default ALSA output pcm device. So it was clearly having the alsa
default grabbed by pulse and ignoring this. Although Audacious worked fine
into the USB once I'd set that as its output. Unlike previous occasions I
decided not to beat Pulse to death with a stick because I know most people
won't do that.

[2] The USB DAC setup has an spdif output I can record.


--
Please use the address on the audiomisc page if you wish to email me.
Electronics https://www.st-andrews.ac.uk/~www_pa...o/electron.htm
Armstrong Audio http://www.audiomisc.co.uk/Armstrong/armstrong.html
Audio Misc http://www.audiomisc.co.uk/index.html

On 28 Apr, wrote:

In article , Andy
Furniss spam@spam wrote:
On the other side of this: I just checked and the new distro has FF
50.1. This uses the dash streams for the established 320k aac from
iplayer by default, which is nice.

The AAC streams are HLS not DASH AFAIK.

OK. However IIRC a right click did say 'DASH'. I'll check later on. My
memory isn't always reliable.

Just tried playing programme from yesterday's R3. If I right click on the
plugin window whilst its playing I get a string which included

320kbps dash (af_limelight_uk_dash)

The winkin blinkin lighten on the DAC show the results as 48k and 24bit. So
pulse may be fiddling with the bits as this should be 16bit. But this may
be a 'feature' of whatever is being used to convert the aac into lpcm.

Jim

--
Please use the address on the audiomisc page if you wish to email me.
Electronics https://www.st-andrews.ac.uk/~www_pa...o/electron.htm
Armstrong Audio http://www.audiomisc.co.uk/Armstrong/armstrong.html
Audio Misc http://www.audiomisc.co.uk/index.html

Jim Lesurf wrote:
On 28 Apr, wrote:

In article , Andy
Furniss spam@spam wrote:
On the other side of this: I just checked and the new distro has FF
50.1. This uses the dash streams for the established 320k aac from
iplayer by default, which is nice.

The AAC streams are HLS not DASH AFAIK.

OK. However IIRC a right click did say 'DASH'. I'll check later on. My
memory isn't always reliable.

Just tried playing programme from yesterday's R3. If I right click on the
plugin window whilst its playing I get a string which included

320kbps dash (af_limelight_uk_dash)

Ahh, iplayer, yea get_iplayer does show dash or hls or flash for those.

I was thinking of the live streams - but then maybe there are dash urls
for those as well?
I only know the .m3u8 hls urls for those and currently I don't think mpv
would play any dash streams until the patch gets in to ffmpeg anyway.

I've just had an email from someone 'at the BBC' to tell me that what I'd
been told a while ago was incorrect. This is actually *good* news.

The plan is that *all* programmes on R3 during the Proms weeks will be flac
streamed. i.e. *not* only the actual Proms as I was previously told.

This makes sense as it saves having to turn things on and off and give
people time to start fetching, etc. It also makes me think the 'trial' was
judged a success. So it seems hopeful that flac will end up as a standard
stream at some later point.

Jim

--
Please use the address on the audiomisc page if you wish to email me.
Electronics https://www.st-andrews.ac.uk/~www_pa...o/electron.htm
Armstrong Audio http://www.audiomisc.co.uk/Armstrong/armstrong.html
Audio Misc http://www.audiomisc.co.uk/index.html