Some more recent bluetooth codecs (such as LDAC or aptX) are better ahead in audio compression, which given bluetooth's limited bandwidth (and given than higher bandwidth usage means also more battery consumption), is something to keep in mind at all stages. In general, bluetooth audio quality is quite a mess of codec negotiations that happen mostly transparently to the user when an earphone connects. When a call is placed and the headset needs to also send audio besides receiving it, further codec changes are negotiated on the spot, prioritizing latency vs quality. Here's a quick (kinda) guide to the most common bluetooth codecs any given audio device might use: https://www.whathifi.com/advice/what-are-the-best-bluetooth-codecs-aptx-aac-ldac-and-more-explained
iturnedintoanewt
With Airalo? Not really. If you manage to get the eSIM from the local provider, then sure, you can get the same rates, and before you even pack for the trip. But not all local providers are so readily to offer you an eSIM. And Airalo offers convenience at a not terrible rates, but definitely the best rates are local providers, physical or eSIM.
Thanks! Seems more about how to properly map a local host path/mount on docker. For which I'm completely noob...I think this is where I'm failing right now.
Not as good as the local sim (in Asia not by a long mile if I recall correctly), but it's way more convenient. Then again, here we can get some daily limited (500MB-1GB, depending the country) data roaming packages for the equivalent of 1-2€ daily. If it's quite a few days I'd go local sim, it's a bit of a hassle the first day, but their data packages are silly cheap. I guess in Europe/US/Canada I'd consider seriously some Airalo or equivalent.
Wow thanks! Let me take a look, I missed the portainer part! Sigh...I followed through the instructions. I deleted the previous stack, and created a new one, this time all the way from portainer. This time I ONLY modified the .env file, well and according to the instructions the .yaml referring to the .env as stack.env now. Made it deploy...and nothing. Still getting the same mkdir error :(
Yeah, the ones being VMs cannot be transferred easily to containers...I would have done so over to LXC, as it's been my preferred choice until now. But Home Assistant was deployed over a VM template provided by HA, and the windows VMs...well, they're Windows. I also have an ancient nginx/seafile install that I'm a bit afraid to move to LXC, but at some point I'll get to it. Having Immich for pictures would reduce a bit the size of some of the Seafile libraries :)
Thanks...I did follow their guide, step by step. The only thing that I customized was the immich uploads folder, which I want it to go to my NAS. I have it set up on an NFS mount handled by proxmox, and then it's just a transparent bind mount in the LXC. The user in the lxc container has read/write access to this location, and docker runs on this same user. But I reckon I'm addressing this in docker in a horribly messed way, as I've never used it before. Checking the docker logs immich_server, I'm getting this:
[Nest] 7 - 04/08/2024, 9:53:08 AM LOG [SystemConfigService] LogLevel=log (set via system config)
node:fs:1380
const result = binding.mkdir(
^
Error: EACCES: permission denied, mkdir 'upload/library'
at mkdirSync (node:fs:1380:26)
at StorageRepository.mkdirSync (/usr/src/app/dist/repositories/storage.repository.js:112:37)
at StorageService.init (/usr/src/app/dist/services/storage.service.js:30:32)
at ApiService.init (/usr/src/app/dist/services/api.service.js:72:29)
at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
at async ApiModule.onModuleInit (/usr/src/app/dist/app.module.js:58:9)
at async callModuleInitHook (/usr/src/app/node_modules/@nestjs/core/hooks/on-module-init.hook.js:51:9)
at async NestApplication.callInitHook (/usr/src/app/node_modules/@nestjs/core/nest-application-context.js:223:13)
at async NestApplication.init (/usr/src/app/node_modules/@nestjs/core/nest-application.js:100:9)
at async NestApplication.listen (/usr/src/app/node_modules/@nestjs/core/nest-application.js:169:33) {
errno: -13,
code: 'EACCES',
syscall: 'mkdir',
path: 'upload/library'
Let's see... So let's say my LXC container has a /mnt/NAS-immich-folder path, already mounted and with rw permissions. Then I edited my docker-compose.yml volumes line as follows:
volumes:
- /mnt/NAS-immich-folder:/mnt/immich
- ${UPLOAD_LOCATION}:/mnt/immich
- /etc/localtime:/etc/localtime:ro
And my .env path looks like:
# The location where your uploaded files are stored
UPLOAD_LOCATION=/media/immich
...I'm sure I'm doing something horribly wrong besides the no-no of docker over LXC...Is there anything messed in these paths? What am I doing wrong? Thanks so much!
Thanks! When I type my LXC's IP:2283, I get unable to connect. I checked the docker-compose.yml and the port seems to be 2283:3001, but no luck at either. Is there anything that needs to be done on docker's network in order to..."publish" a container to the local network so it can be seen? Or any docker running with a port can be reached via the host's IP with no further config? Checking the portainer's networks section, I can see an 'immich-default' network using bridge on 172.18.0.0/16, while the system's bridge seems to be running at 172.17.0.0/16. Is this the correct defaults? Should I change anything?
Thanks!
Thanks! When I type my LXC's IP:2283, I get unable to connect. I checked the docker-compose.yml and the port seems to be 2283:3001, but no luck at either. Is there anything that needs to be done on docker's network in order to..."publish" a container to the local network so it can be seen? Or any docker running with a port can be reached via the host's IP with no further config? Checking the portainer's networks section, I can see an 'immich-default' network using bridge on 172.18.0.0/16, while the system's bridge seems to be running at 172.17.0.0/16. Is this the correct defaults? Should I change anything?
Thanks!
Thanks! When I type my LXC's IP:2283, I get unable to connect. I checked the docker-compose.yml and the port seems to be 2283:3001, but no luck at either. Is there anything that needs to be done on docker's network in order to..."publish" a container to the local network so it can be seen? Or any docker running with a port can be reached via the host's IP with no further config? Checking the portainer's networks section, I can see an 'immich-default' network using bridge on 172.18.0.0/16, while the system's bridge seems to be running at 172.17.0.0/16. Is this the correct defaults? Should I change anything?
Thanks!
Thanks...So you think a full VM will result in less overhead than a container? How so? I mean, the VM will take a bunch of extra RAM and extra overhead by running a full kernel by itself...
Qualcomm? Not... Arm in general?