Package libavresample-dev is not available, but is referred to by another package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source
And then the script terminated unsuccessfully
I didn’t have an issue with this when I was at Ubuntu Studio version 20.04, and when I search for this package, I’m only finding it associated with that version of Ubuntu (or earlier). It is an "FFmpeg compatibility library for resampling. This library is provided for compatibility reasons only. The FFmpeg project advises to use libswresample instead. " Debian -- Error
Is this a case were I should replace libavresample with libswresample and submit a documentation issue?
sudo apt install bluetooth bluez bluez-tools rfkill
and then
sudo usermod -aG lp $USER
newgrp lp
I then ran;
$ systemctl status bluetooth.service
â—Ź bluetooth.service - Bluetooth service
Loaded: loaded (/lib/systemd/system/bluetooth.service; enabled; vendor preset: enabled)
Active: active (running) since Fri 2023-01-27 12:51:41 EST; 1h 15min ago
Docs: man:bluetoothd(8)
Main PID: 877 (bluetoothd)
Status: “Running”
Tasks: 1 (limit: 38160)
Memory: 2.5M
CPU: 11.273s
CGroup: /system.slice/bluetooth.service
└─877 /usr/lib/bluetooth/bluetoothd
Jan 27 12:52:17 will-g55590 bluetoothd[877]: Endpoint registered: sender=:1.118 path=/MediaEndpoint/A2DPSource/sbc
Jan 27 12:52:17 will-g55590 bluetoothd[877]: Endpoint registered: sender=:1.118 path=/MediaEndpoint/A2DPSink/sbc_xq_453
Jan 27 12:52:17 will-g55590 bluetoothd[877]: Endpoint registered: sender=:1.118 path=/MediaEndpoint/A2DPSource/sbc_xq_453
Jan 27 12:52:17 will-g55590 bluetoothd[877]: Endpoint registered: sender=:1.118 path=/MediaEndpoint/A2DPSink/sbc_xq_512
Jan 27 12:52:17 will-g55590 bluetoothd[877]: Endpoint registered: sender=:1.118 path=/MediaEndpoint/A2DPSource/sbc_xq_512
Jan 27 12:52:17 will-g55590 bluetoothd[877]: Endpoint registered: sender=:1.118 path=/MediaEndpoint/A2DPSink/sbc_xq_552
Jan 27 12:52:17 will-g55590 bluetoothd[877]: Endpoint registered: sender=:1.118 path=/MediaEndpoint/A2DPSource/sbc_xq_552
Jan 27 13:50:02 will-g55590 bluetoothd[877]: profiles/audio/avdtp.c:avdtp_connect_cb() connect to 58:A6:39:58:71:EA: Permission denied (13)
Jan 27 13:50:36 will-g55590 bluetoothd[877]: profiles/audio/avdtp.c:avdtp_connect_cb() connect to 58:A6:39:58:71:EA: Permission denied (13)
Jan 27 13:56:03 will-g55590 bluetoothd[877]: profiles/audio/avdtp.c:avdtp_connect_cb() connect to 58:A6:39:58:71:EA: Permission denied (13)
It is not clear to me if the Permission denied is my issue, and if so, can be resolved.
I then ran;
$ rfkill
ID TYPE DEVICE SOFT HARD
0 bluetooth hci0 unblocked unblocked
1 wlan phy0 unblocked unblocked
On the off chance it just might work, I installed libswresample-dev and started from scratch. However, the same result was realized (stuck on bluetooth)
I attempted to find and install libavresample-dev anyway, with the following results;
$ sudo apt install libavresample-dev
Reading package lists… Done
Building dependency tree… Done
Reading state information… Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:
The following packages have unmet dependencies:
libavresample-dev :
Depends: libavutil-dev (= 7:4.2.7-0ubuntu0.1) but 7:4.4.2-0ubuntu0.22.04.1 is to be installed
Depends: libavresample4 (= 7:4.2.7-0ubuntu0.1) but it is not going to be installed
E: Unable to correct problems, you have held broken packages.
As I upgraded to Ubuntu 22.04 to get past some issues with an earlier version, unless I’m off in left field (which is indeed possible if not likely), it appears the current linux manual build documentation needs a relook. What is the process for investigating that?
After many additional fruitless hours trying several different approaches to solve the bluetooth hass setup issue, I’ve decided to instead go an entirely different route to obtaining my solar output data altogether. I’ve now set up 4 IoTaWatt CTs (originally targeted to other circuits) to gather my solar data, aggregated from split-single phase 240V inverter output to the subpanel, as well as output back to the main panel. It appears relatively easy to do the math right in IoTaWatt, and send the final calculation through the IoTaWatt integration, though waiting for sunlight this morning to confirm.
If you have bluetooth problem or problem with your bluetooth adapter you could try upgrading your kernel to 6.x branch. Upgrading kernel to 6.x branch resolved my bluetooth problem with adapter.
Thanks @ddaniel , that’s helpful to know. I use my laptop for studio recording and video editing, among other uses, so use Ubuntu Studio 22.04, which has a low-latency kernel to preclude dropouts in complex recording mixes/mastering. The kernel is 5.15, and if I were to upgrade to 22.10, the kernel would be 5.19. Not being a Linux expert, I’ll stick with the supported releases, at least for now.
The initial approach I devised works (accessing Darfon’s engineering website from a different RPi using Selenium to specify dates for the data extract and downloading a CSV every 30 minutes which would give me 6 readings [5 mins apart], and then parsing the CSV to pass the data via MQTT), though the second half of the project was coming up with a HACS integration to feed HA.
As an electro-mechanical engineer and scientific software engineer, I’ve had reservations about the quality of data sampled and sent every 5 minutes, so I’m much more comfortable with relying on IoTaWatt data collected every 30 seconds, composing the algorithm in IoTaWatt, then using the HA Riemann integration. Additionally, the Darfon feed is frequently down anywhere from 4 to 36 hours, which would create a highly distorted solar output profile on HA.
The ancestral Scotsman in me hesitated to dedicate so many (4) CTs to just one value (solar output), but I’ve decided to use smart plugs for those devices that are not hardwired into one of the electrical panel circuits. Hence, I’ll be able to monitor over 90% of my electrical consumption with this approach, which is acceptable to me.