Slik så filene ut med ls:

hovenko: /mnt/Innskannet$ ls -l
totalt 182748
-rw------- 1 hovenko users 16310600 okt.  12  2013 '1981-08 Lizzie s'$'\370''la.tif'
-rw------- 1 hovenko users 16373000 okt.  12  2013 '1981-08 Lizzie.tif'
-rw------- 1 hovenko users 18903752 okt.  12  2013 '1981 Bonzo og Ditho.tif'
-rw------- 1 hovenko users  6497864 okt.  12  2013 '1984-07 Bonzo og Ditho.tif'
-rw------- 1 hovenko users 27627336 okt.  12  2013 '1986-08-23 Elisabeth og Carro.tif'
-rw------- 1 hovenko users  3685982 okt.  12  2013 '1994 Scott i skog.jpg'
-rw------- 1 hovenko users  2917307 okt.  12  2013 '1994 Scott.jpg'
-rw------- 1 hovenko users  6406824 okt.  12  2013 '1999 Lady p'$'\345'' hytta med ball.tif'
-rw------- 1 hovenko users  6449736 okt.  12  2013 '2000 Bonzo.tif'
-rw------- 1 hovenko users  6449736 okt.  12  2013 '2000 Rex og Oliver.tif'
-rw------- 1 hovenko users 25834760 okt.  12  2013 '2000 Rex.tif'
-rw------- 1 hovenko users  6485128 okt.  12  2013 '2001-05 Lady og Rex.tif'
-rw------- 1 hovenko users  6497736 okt.  12  2013 '2001-07 Rex.tif'
-rw------- 1 hovenko users 25683208 okt.  12  2013 '2002-05-22 Lady.tif'
-rw------- 1 hovenko users   182923 okt.  12  2013 '2005 Bonzo.jpg'
-rw------- 1 hovenko users   106015 okt.  12  2013 '2005 Bonzo ligger i kratt.jpg'
-rw------- 1 hovenko users  4910601 okt.  12  2013 '2011 Buster p'$'\345'' '$'\330''deg'$'\345''rdsodden.jpg'
-rw------- 1 hovenko users  5434227 okt.  12  2013 '2012 Spot p'$'\345'' hytta.jpg'
-rw------- 1 hovenko users    53760 okt.  12  2013  Thumbs.db

I filbehandleren Dolphin ble spesialtegnene vist med ?, og det var ikke mulig å åpne filene derfra eller døpe de om.

Jeg hadde en del flere filer enn disse som hadde feil tegnsett, så manuell omdøping av alle filene var ikke gjennomførbart.

Løsningen ble convmv.

Først en “dryrun”:

$ convmv -f latin1 -t utf-8 *
Starting a dry run without changes...
mv "./1981-08 Lizzie s�la.tif"  "./1981-08 Lizzie søla.tif"
mv "./1999 Lady p� hytta med ball.tif"  "./1999 Lady på hytta med ball.tif"
mv "./2011 Buster p� �deg�rdsodden.jpg" "./2011 Buster på Ødegårdsodden.jpg"
mv "./2012 Spot p� hytta.jpg"   "./2012 Spot på hytta.jpg"
No changes to your files done. Would have converted 4 files in 0 seconds.
Use --notest to finally rename the files.

Og så endringen:

$ convmv -f latin1 -t utf-8 --notest *
mv "./1981-08 Lizzie s�la.tif"  "./1981-08 Lizzie søla.tif"
mv "./1999 Lady p� hytta med ball.tif"  "./1999 Lady på hytta med ball.tif"
mv "./2011 Buster p� �deg�rdsodden.jpg" "./2011 Buster på Ødegårdsodden.jpg"
mv "./2012 Spot p� hytta.jpg"   "./2012 Spot på hytta.jpg"
Ready! I converted 4 files in 0 seconds.

Med opsjon -r så går den rekursivt igjennom underkatalogene.

Jeg fikk feilmeldinger ala:

[    2.957523] steal-ctty[125]: segfault at 0 ip 00007fbce02c4160 sp
00007ffe4dde3830 error 4 in libc.so.6[7fbce021f000+148000]
[    2.957551] Code: 8b e8 74 36 04 00 0f 1f 40 00 55 48 89 e5 41 57 41 56 41 55 41
54 53 48 83 ec 48 64 48 8b 04 25 28 00 00 00 48 89 45 c8 31 c0 <80> 3f 00 0f 84
47 01 00 00 49 89 f4 be 2f 00 00 00 48 89 fb 49 89
Segmentation fault
cat: can't open '/var/log/reopen-console': No such file or directory
rm: can't remove '/var/log/reopen-console': No such file or directory
touch: /var/run/brltty-Xorg: No such file or directory

Tok ikke vare på mine eksakte feilmeldinger, men jeg fant mailingliste-tråden https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=932149 om problemet, og med løsningen.

Selv om Debian er ganske gjærrig på CPU- og minnebruk, så viste det seg at jeg måtte sette “memory=1024M” i Xen-konfigurasjonen til den nye virtuelle serveren. Det holdt ikke med 512M.

Jeg endte opp med å installere fra CDROM-image med kernel og initrd fra https://deb.debian.org/debian/dists/Debian12.1/main/installer-amd64/current/images/cdrom/xen/.
Og med følgende XEN-node-konfigurasjon i /etc/xen/vm_srv-2023-1:

name = "srv-DEBIAN"

kernel  = "/xen/install-media/Debian12.1-installer-amd64-cdrom-xen/vmlinuz"
ramdisk = "/xen/install-media/Debian12.1-installer-amd64-cdrom-xen/initrd.gz"
extra   = "debian-installer/exit/always_halt=true -- console=hvc0 xencons=tty"

vcpus  = 1
memory = 1024

vif = [ 'mac=00:11:22:33:44:55,bridge=xenbr0' ]

disk = [
    'file:/xen/install-media/debian-12.1.0-amd64-netinst.iso,xvdd:cdrom,r',
    'phy:/dev/vg-data/xen-srv-DEBIAN-root,xvda,w',
    'phy:/dev/vg-data/xen-srv-DEBIAN-swap,xvdb,w'
]

on_poweroff = 'destroy'
on_reboot   = 'restart'
on_crash    = 'restart'

$ mpv \
  --audio-channels=5.1,stereo \
  --audio-spdif=ac3,eac3,dts-hd,truehd \
  --audio-device=alsa/hdmi:CARD=PCH,DEV=0 \
  audiofile.mp4

Fant tipset på https://forum.manjaro.org/t/how-do-i-enable-surround-sound-in-pulseaudio/56394.

Oppdatering 27.09.2023

Jeg støtte i dag på et tilfelle med en videofil med 6-kanals lyd, men hvor avspilling med kommandoen ovenfor ikke ga noen lyd over HDMI.

Uttrekk fra ffprobe gir meg:

Input #0, matroska,webm, from ...
  Metadata:
    encoder         : libebml v1.4.2 + libmatroska v1.6.4
[...]
    Stream #0:1(eng): Audio: eac3, 48000 Hz, 6 channels, fltp
    Metadata:
      title           : English
      BPS             : 384000
      DURATION        : 02:49:17
      NUMBER_OF_FRAMES: 317427
      NUMBER_OF_BYTES : 487567872

mpv-avspilling rapporterte 2-kanals lyd: AO: [alsa] 48000Hz stereo 2ch spdif-ac3.

MPV AD-parameter (Audio Decoder)

Jeg fikk surround-lyd med AD-parameteren (Audio Decoder):
--ad=spdif:ac3,spdif:dts,

mpv rapporterte AO: [alsa] 48000Hz 5.1 6ch s32 og receiveren min viste MULTI-CHANNEL lyd-input.

MPV AF-parameter (Audio Filters)

Jeg prøvde også med noen AF-parametere (Audio Filters):

  --af=lavcac3enc
  --af=scaletempo,lavcac3enc=yes:640:3

, men i begge tilfeller rapporterte mpv om AO: [alsa] 48000Hz stereo 2ch spdif-ac3, selv om receiveren min identifiserte det som Dolby Digital. Også i kombinasjon med --ad-parameteren. Jeg gjorde ingen test på om det faktisk ble ekte surround-lyd fra receiveren.

Kilder

Fant tipsene fra:
1) Does anyone has realtime ac3 or dts encoding running? (Archlinux)
2) New To MPV. Trouble with EAC3 6 channel audio. (Reddit)

Disse bildene kopierer jeg over til en server av og til, slik at jeg har et sted å nå de også når jeg trenger å rense opp litt plass på laptopen.

Av og til har jeg behov for å reorganisere bildene mine i nye kataloger. For eksempel var det blitt så mange bilder fra Dropbox-opplastingene fra telefonen at det var vanskelig å bla igjennom de, så da flyttet jeg de til nye kataloger per år. Scriptet jeg har for å kopiere over bilder er ikke smartere enn at den tolker disse bildene som nå ligger i nye kataloger, som nye bilder. Og alt tar plutselig dobbelt så mye lagringsplass. I tillegg ligger nå bildene på flere steder slik at man mister litt oversikten, men akkurat det får bli et tema til en annen gang.

For å unngå at duplikate filer tar dobbelt med plass så kjørte jeg deduplisering. Serveren var gammel nok til å ikke ha noe godt dedupliseringsverktøy som jeg kunne installere fra pakkesystemet. Løsningen ble å montere opp nettverksstasjonen med NFS/CIFS og kjøre deduplisering fra laptopen.

Verktøyet jeg brukte heter hardlink.

$ mount /server         # forutsetter at denne er definert i /etc/fstab
$ cd /server/Bilder
$ hardlink -v -t .

Mode:     real
Files:    13999
Linked:   5850 files
Compared: 0 xattrs
Compared: 5863 files
Saved:    19.07 GiB
Duration: 1761.81 seconds

Opsjon -v skrur på verbose.
Opsjon -t ignorerer endringstid på filene når verktøyet sammenligner filene. Dette er nødvendig for at den nye kopien av bildet skal kunne tolkes likt som det gamle bildet på den gamle lokasjonen.

I tried to tune log levels and found some tools lacking, such as “flac” and “lame”, but none of them fixed my problem, and still no explanation in the log files.

But I found something in the logs that led me in the right direction:

[16-08-29 23:03:04.3358] Slim::Player::TranscodingHelper::enabledFormat (209) Checking to see if wav-flc-*-* is enabled
[16-08-29 23:03:04.3360] Slim::Player::TranscodingHelper::checkBin (250)    enabled
[16-08-29 23:03:04.3362] Slim::Player::TranscodingHelper::checkBin (252)   Found command: [flac] -cs --totally-silent --compression-level-0 $START$ $END$ -- $FILE$ | [sox] -q -t flac - -t flac -C 0 $RESAMPLE$ -
[16-08-29 23:03:04.3364] Slim::Player::TranscodingHelper::getConvertCommand2 (446) Matched: wav->flc via: [flac] -cs --totally-silent --compression-level-0 $START$ $END$ -- $FILE$ | [sox] -q -t flac - -t flac -C 0 $RESAMPLE$ -

I was missing the “sox” tool!
So, I installed “sox”, and now the media server is properly encoding WAV/PCM audio files to FLAC (or something).

$ sudo aptitude install haveged

$ cat /proc/sys/kernel/random/entropy_avail

Hovedsaklig møtte vi på to problemer: ingen flere ledige inodes, og lang venting på å liste ut alle filene, med millioner av filer lagret i én og samme katalog.

Filene ble lagret på filsystemet EXT4 i Linux, Ubuntu 14.04.1 LTS.

EXT4 har en fastsatt grense for antall filer som filsystemet kan håndtere, og denne settes under oppretting av filsystemet, så denne kunne vi ikke endre.
Videre klarer ikke EXT4 å håndtere stort mer enn ca 100k filer i én og samme katalog uten at alt går i sneglefart.

Vi måtte finne et nytt filsystem, noe som ikke hadde noen øvre grense for antall filer, med unntak av diskplass så klart.

Andre filsystemer til unnsetning

Vi måtte gjøre noen tester for å finne ut hvilket filsystem vi kan bruke istedenfor EXT4.
Kandidatene vi kom fram til var BTRFS, XFS og ZFS.

I tillegg vurderte vi OneFS, et produkt fra Isilon som vi allerede har kjørende i produksjon, et nettverkslagringssystem som er spesialisert til å håndtere veldig store datamengder, men dette produktet er heller ikke bra til å håndtere veldig mange filer i én katalog.
Vi kan rett og slett ikke bruke den på grunn av risiko for å krasje hele filsystemet og ta med oss alle andre systemer i produksjon som bruker dette.

Testingen jeg gjorde er relativt enkel:

1. Opprettet tomme filer på 20 GB, loopback-montert og formattert med filsystemet som skulle testes
2. Kopierte 1.6M (1.644.553) filer på til sammen 19 GB, alle i én katalog, til hver av filsystemene
3. Tømte Linux OS-cache før testing av hvert filsystem
4. Tok tiden for detailjert sortert utlisting (kald test)
5. Tok tiden for detailjert sortert utlisting enda en gang (varm test)
6. Tok tiden for usortert utlisting (varm test)

I tillegg tok jeg noen notater om komprimeringsgrad for de filsystemene som støttet komprimering, og hvor mye OS-cache og minne som ble brukt etter gjennomført testing.
Maskinene har noen bakgrunnsprosesser som vil kunne allokerer noe minne mens testene kjøres, men jeg anses aktiviteten på disse som lite i forhold til ressursbeslaget disse testene vil gjøre.

Hastighet på lesing eller skriving av innholdet i filene er ikke det viktigste for oss.
Det er små filer, fra 50 KB til 500 KB, så det er viktigere at vi kan lese flere filer raskt enn å lese én stor fil raskt.

Vi trenger et filsystem som lar oss jobbe med filene, skrive nye filer, flytte filer og kopiere filer når behovene melder seg, istedenfor å krype stille sammen for å dø – altså er uthenting av metadata om filer og utlisting av filene viktige kriterier.

For å tømme OS-cache på Linux kjørte jeg følgende kommando:

echo 3 | sudo tee /proc/sys/vm/drop_caches

For utføring av testen “detailjert sortert utlisting” kjørte jeg følgende kommando:

time ls -lht KATALOG | wc -l

For utføring av testen “usortert utlisting” kjørte jeg følgende kommando:

time ls -1 -U KATALOG | wc -l

Disse kommandoene tar tiden for å liste ut filer.
I steden for å bruke tid på å printe ut all teksten til konsollet så gjorde jeg en telling av linjer, som også ble en verifikasjon på at jeg hadde kopiert over alle filene til alle filsystemene som ble testet.

Testoppsett

Filene lå opprinnelig på Server1 på et EXT4-filsystem.
Disse ble kopiert over til Server2 hvor testene av de andre filsystemene ble gjort.
Server2 hadde omtrent ingen annen aktivitet mens testene pågikk, så målingene skal være nokså nøyaktige.
For å måle opp mot problemet vårt ble også testene gjennomført på Server1 mot EXT4.
I tillegg gjennomførte jeg en test på Server1 over NFS mot XFS-filområdet til Server2.

Filsystemene ble i hovedsak opprettet med standard-opsjoner på Ubuntu 14.04.1 LTS.
Komprimering ble aktivert i BTRFS og ZFS.

Resultater

På Server1 gjennomførte jeg en tømming av OS-cache, men målte ikke minneallokeringsbruk, da det er andre tjenster som kjører på serveren, og det kunne gitt villedende resultater.

NFS-testen fra Server1 mot Server2 sitt XFS-testoppsett mangler noen måletall, tall jeg anså som uviktige å måle på grunn av nettverksseparasjonen.
Den kalde testen av detaljert utlisting av filer ble ikke gjennomført over NFS.

Skriving av filer til ZFS ble merkbart tregere for hver fil som ble skrevet – i starten var overføringshastigheten over 6.5 MB/s, men slutta på 3.2 MB/s.
Usikkert om det skyldes komprimering, diskstørrelse eller andre årsaker.

Tid ble målt i minutter og sekunder.
BTRFS, XFS og ZFS allokerer inodes dynamisk.

EXT4 var eneste som hadde et maksimalt antall inodes.
BTRFS rapporterte ikke om inodes i “df -i”, verken ledige eller brukte.
Både XFS og ZFS var fleksible i ledige inodes som ble rapportert og endret seg i takt med ledig diskplass.

Alle filsystemene gjennomførte testene innen akseptabel hastighet når systemet var varm.
Allikevel var BTRFS og XFS de raskeste her med svar på under 20 sekunder, mens ZFS brukte 33 sekunder og EXT4 brukte 44 sekunder.

XFS var klart raskest når systemet var kald med svar på under 2 minutter.
EXT4 og BTRFS var nokså like med omkring 3,5 minutter når systemet var kald.
ZFS brukte uakseptabel lang tid (over 8 minutter) når systemet var kald.

EXT4, BTRFS og XFS leverte et akseptabelt raskt svar på usortert utlisting av filene, på maksimalt 2 sekunder.
XFS var raskest, på 1 sekund.
ZFS brukte uakseptable 15 sekunder.

Alle filsystemene unntatt EXT4 allokerte mye minne og cache for å utføre testene.
Det er usikkert om loopback-monteringen på Server2 kan ha hatt innvirkning.
EXT4 allokerte bare 109 MB som cache, men den var også noe tregere enn de andre når systemet var varm.
XFS allokerte 3.5 GB minne, hvorav 830 MB cache.
ZFS allokerte 3.3 GB minne, hvorav 1.4 GB cache.
BTRFS allokerte 5.9 GB minne, hvorav 3.7 GB cache.

Konklusjon

Vi anså XFS til å være best for våre behov.
Den leverte svar innen akseptabel tid både da systemet var kaldt og varmt, og var også den raskeste til å levere usortert utlisting av filene.

ZFS skuffet stort med uakseptabelt trege svar.
BTRFS brukte for mye minne, men ellers virket den lovende.

Felles for både BTRFS og ZFS var at komprimering var aktivert.
Kanskje kunne minnebruken vært lavere for både BTRFS og ZFS om testingen ble utført uten komprimering.

Det er god aktivitet rundt BTRFS i Linux-kildekoden og ser ut til å bli arvtakeren til EXT3/4.
BTRFS har funksjoner for blant annet komprimering og snapshotting, og det vil være aktuelt med ny vurdering av BTRFS senere.

Avslutning-rant

Etter at ny diskenhet ble koblet til Server1 og XFS ble satt opp, så dukket et nytt problem fram – overføring av filene fra EXT4-partisjonen til den nye XFS-partisjonen gikk i trege 1 MB/s.
Løsningen ble å overføre filene tilbake fra Server2 sitt XFS-filsystem over NFS…

Et enda større problem møtte vi med en annen katalog, som inneholder omkring 1.1 millioner kataloger, som igjen inneholder filer, men mer om dette kan diskuteres over et par kanner kaffe – jeg har god tid…

Det jeg derimot glemte å skrive var hvordan man skulle koble opp mot den for å sende kommandoer, noe jeg så klart har glemt siden den gang og trøblet litt med i kveld.

Det jeg sleit mest med er at alle terminalklientene jeg testet har aktiv maskinvarebasert flytkontroll, noe som ikke fungerer mot denne receiveren. Så det må skrus av.

Dette kan gjøres via minicom eller kermit. Beskrivelse finnes blant annet hos Gumstix Developer Center.

Etter at flow control er skrudd av kan minicom kjøres:

minicom -b 9600 -D /dev/ttyUSB0 -8 -o

Et tips hvis du bruker minicom er å aktivere “Add linefeed” i konfigurasjonen av “Screen and keyboard”.