Voyage MPD

[gut_man]

Er et ikke Mono som er importør? Jeg kjøpte mitt fra Resonans i Stavanger.. Koster ca 1500kr

 

[marsboer]

Jeg fikk mitt tilsendt fra stereofil.

 

[Ludo]

Bestilt

 

[Ludo]

Ser at det snakkes mye om kompilering av egen kjerne tilpasset behov og hardware. Noen som har testet ut Gentoo Linux? Jeg har brukt det endel tidligere, der får man utrolig god utnyttelse av den hardwaren man har om man optimaliserer det på en smart måte...


http://www.gentoo.org/

 

[marsboer]

Jeg benytter ikke egenkompilert kjerne (har riktignok laget flere for testing av diverse ting underveis). Siden kjernen som standard kun inkluderer det meste av drivere som moduler som igjen kun lastes dersom det faktisk er behov, er det ikke så mye å hente på egenkompilert kjerne utover redusert størrelse. Unntaket er selvsagt om du ønsker å patche inn endret funksjonalitet. Faktisk har jeg kun ferdige pakker fra Debian på systemet, med unntak av et lite program som gir meg airplay-støtte slik at jeg kan streame spotify/wimp/etc. via ipad til anlegget. Dette er imidlertid ikke relevant for Linux/MPD i seg selv.

Gentoo prøvde jeg for flerfoldige år siden. I mitt tilfelle fikk jeg ikke økt ytelse siden ferdigkompilert 64-bit Debian Linux fungerer veldig optimalt som standard for dagens CPUer. Selv om gentoo har et slags programvareinstallasjonssystem synes jeg også at ting var en lidelse å jobbe med i form av at man alltid trengte dokumentasjon tilgjengelig og at ting tok mer tid enn nødvendig fordi alt skal kompileres.
I tillegg er gentoo såpass bleeding edge til enhver tid at det alltid var bare et tidsspørsmål før et eller annet måtte håndteres og justeres på.

Ting kan selvsagt ha endret seg til det bedre, men så vidt jeg har skjønt er de grunnleggende prinsippene fremdeles de samme med mindre man er fanboy eller spesielt interessert: Plenty of pain, no gain IMO.

Du må selvsagt ta innover deg at jeg etterhvert har endt opp med å foretrekke en av de trausteste Linux-distroene på markedet, så dette må for all del ikke stoppe deg fra å prøve selv og danne deg dine egne erfaringer.

 

[Goophy]

Problemet med Gentoo er at de ikke offisielt tilbyr et bibliotek med ferdige binærpakker. Å måtte kompilere absolutt alt du skal ha blir rimelig irriterende i lengden.
Vil du ha en god distribusjon som er bleeding edge med et stort pakkebibliotek kan jeg anbefale Archlinux.

Som marsboer nevner er det veldig lite å hente på ekstra optimalisering for x86-arkitektur. Kompilatorene nå om dagen er veldig god og på et helt annet nivå enn da Gentoo var populært (2004++).

 

[Ludo]

Helt enig i det dere sier om Gentoo - jeg har ikke brukt det selv siden tidlig 2000-ish. Greit å vite at jeg kan kjøre videre med Debian Wheezy og bruke wiki'n til Marsboern... Men jeg trenger litt assistanse rundt dette med cover art; når man sier sette opp en webserver for dette - hvordan skal man strukturere filene/bildene? Må jo være et system for det antar jeg. Funker Apache greit eller finnes det en innebygget variant i MPD eller tilsvarende?

 

[Oblivion]

Men jeg trenger litt assistanse rundt dette med cover art; når man sier sette opp en webserver for dette - hvordan skal man strukturere filene/bildene? Må jo være et system for det antar jeg. Funker Apache greit eller finnes det en innebygget variant i MPD eller tilsvarende?

Jeg bruker avahi og slet lenge både med avahi og alternativer for å få en robust og konstant fungerende lokal cover art funksjon.

Under /etc/avahi/services måtte jeg opprette en fil med navnet mpd.service med følgende innhold:

<?xml version="1.0" standalone='no'?>
<!DOCTYPE service-group SYSTEM "avahi-service.dtd">
<service-group>
 <name replace-wildcards="yes"> [COLOR=#0000ff]rARM[/COLOR] </name>
 <service>
   <type>_mpd._tcp</type>
   <port>6600</port>
 </service>
</service-group>

rARM er et valgfritt "server" navn..

Orginal koden for mpd.service fra Hack:avahi mpd.service - Music Player Daemon Community Wiki er:
(Hack:avahi mpd.service - announce mpd with avahi)

<?xml version="1.0" standalone='no'?>
<!DOCTYPE service-group SYSTEM "avahi-service.dtd">
<service-group>
 <name replace-wildcards="yes">music player daemon on %h </name>
 <service>
   <type>_mpd._tcp</type>
   <port>6600</port>
 </service>
</service-group>

192.168.5.204[COLOR=#0000ff] rARM[/COLOR].local

rARM er igjen valgfritt "server" navn..


Med disse tilleggene / endringen fungerer både automatisk "discovery" fra mPad / mPod og lokal cover art i 10 av 10 tilfeller og også med forskjellige versjoner av mPod / mPad.

Med "Man made Voyage MPD" eller "marsboer skript" fungerte IKKE disse funksjonene tilfredstillende...

 

[Ludo]

Takk Raymond - skal forsøke dette!

 

[marsboer]

Det oblivion skriver stemmer ikke om du følger min wiki. Jeg skal forklare både cover art og avahi i løpet av kvelden. Har bare mobil nå.

 

[Oblivion]

Det oblivion skriver stemmer ikke om du følger min wiki. Jeg skal forklare både cover art og avahi i løpet av kvelden. Har bare mobil nå.

Det var det jeg indikerte at dette ikke er ifølge din (marsboer) wiki.

Men dette var nødvendig for å få et stabilt system slik at MPD oppdages automatisk fra iPhone, iPod, iPad med ulike versjoner av mPod og mPad- samt at lokal cover art også fungerer med de ulike fjernkontroll variantene / versjonene.

Hvis jeg fulgte "marsboer skript" var det vilkårlig hva som fungerte og i hvilken konfigurasjon det fungerte.

Intet vondt ment, men for meg er det viktig at "ting" virker forutsigbart selv med mange system variabler..

 

[marsboer]

Det oblivion skriver stemmer ikke om du følger min wiki. Jeg skal forklare både cover art og avahi i løpet av kvelden. Har bare mobil nå.

Det var det jeg indikerte at dette ikke er ifølge din (marsboer) wiki.

Men dette var nødvendig for å få et stabilt system slik at MPD oppdages automatisk fra iPhone, iPod, iPad med ulike versjoner av mPod og mPad- samt at lokal cover art også fungerer med de ulike fjernkontroll variantene / versjonene.

Hvis jeg fulgte "marsboer skript" var det vilkårlig hva som fungerte og i hvilken konfigurasjon det fungerte.

Intet vondt ment, men for meg er det viktig at "ting" virker forutsigbart selv med mange system variabler..

Som vanlig utviser du en totalt fraværende forståelse og selvinnsikt. Når skal du egentlig innse at det av og til (eller når det gjelder Linux/MPD/USB-audio, stort sett alltid for din del) er bedre å kikke i speilet og ta en grundig titt før du går hardt ut mot alle som faktisk har vesentlig mer erfaring enn deg selv på området? Når ingen andre enn en selv har et problem, vil de fleste andre tenke at feilen kanskje ligger hos seg selv, men ikke o' ufeilbarlige Oblivion, hvis selvtillit aldri kan knekkes uansett hvor mange ganger han driter seg ut offentlig (heldigvis på noe som er så teknisk at 99% ikke får det med seg).

Scriptet har ingen verdens ting med funksjonalitet, installasjon eller konfigurasjon å gjøre. Det er kun tweaking av systemparametre og er helt irrelevant for selve funksjonaliteten (med mindre man feilkonfigurerer noe totalt selvfølgelig). Man kan droppe scriptet og alt fungerer like bra rent teknisk.

Avahi-funksjonaliteten er dønn stabil og det eneste som kreves er å installere pakken "avahi-daemon". Man trenger ikke gjøre noen som helst konfigurasjonsendringer om man ellers kjører programvaren som installeres i wikien (dvs Debian Wheezys mpd som har avahi-støtte allerede innkompilert)
Zeroconf-annonseringen fungerer 100% hver dag, hele året, og er ikke forbundet med noen form for upålitelighet.

Avahi, samt med stor sikkerhet flere tjenester, fungerte ikke skikkelig som en konsekvens av en nybegynnertabbe du selv ikke har forstått implikasjonene av. Jeg vil imidlertid ikke være urimelig og skal gi deg en time eller to til å gjenvinne et snev av faglig integritet ved å selv innse hva som var årsaken til problemene og beskrive dem her, før jeg beskriver hvorfor du hadde problemer. Problemet kan reproduseres enkelt for den som måtte ønske det.

Da vil jeg også beskrive oppsett av apache for cover-art for vår gode mann Ludo.

Det lyste selvsagt ingen alarmer hos deg når MPD konfigurasjonen din til og med er definert som et "hack":
Hack:avahi mpd.service - Music Player Daemon Community Wiki


Kommentar:
For nykommere så virker dette svaret sikkert veldig ufint men jeg er møkk lei av Oblivions oppførsel etter flere tilsvarende runder tidligere i tråden.
Jeg har forøvrig ingenting i mot nybegynnere og støtter mer enn gjerne selv ved de dummeste spørsmål.

 

[Oblivion]

Kommentar:
For nykommere så virker dette svaret sikkert veldig ufint men jeg er møkk lei av Oblivions oppførsel etter flere tilsvarende runder tidligere i tråden.
Jeg har forøvrig ingenting i mot nybegynnere og støtter mer enn gjerne selv ved de dummeste spørsmål.

Hmm... Selverklært verdensmester i stort sett det meste- alias marsboer har talt

Sikkert mangt og meget som kanskje fungerer med standard kernel, base filsystem og applikasjoner

Nå har det seg slik at mitt system er kompilert og konfigurert ned til et absolutt minimum, og det er derfor en rimelig mange funksjoner, protokoller og kommandoer som det ikke er inkludert kode for... Dette gjelder både kernel, base filsystem og MPD.

Det er jo utmerket at du vil komme med noen forklaringer rundt lokal coverart og avahi for standard installasjoner etc. fordi både mpdPUP og Voyage MPD i flere standard utgaver har hatt utfordringer med lokal coverart og avahi...

Det blir interresant å se hva du legger vekt på- teknisk kunnskap eller hersketeknikk

PS! Fortsatt er NRPACKS settingen antall PACKS og IKKE en setting i millisekunder.
Det faktum at NRPACKS settingen indirekte på grunn av underliggende USB timing vil ha en relasjon til millisekunder eller microsekunder betyr ikke veldig mye uansett fordi det er USB adapteret som har den overordnede kontrollen og styrer feedback timingen. NRPACKS og MAX_PACKS trenger bare å være satt til tilstrekkelig høye verdier som USB adapteret kan utnytte. Derfor er forklaringene om at NRPACKS settingen er en millisekund setting for kontroll av USB adapter og eller USB overførsel totalt feil fordi det er USB adapteret som utfører denne kontrollen. Riktignok vil for lave verdier på blant annet NRPACKS tvinge USB adapteret til å fungere mindre optimalt fordi det må sende feedback interrupt mye ofterer fordi data mengden i hver URB blir for liten til at den optimale og forventede timingen kan opprettholdes..

 

[Ludo]

La nå NRPACKS ligge for en stund nå da - er jo tross alt helg

Btw - jeg tar imot alle innspill og er veldig takknemlig for at dere mer enn gjerne deler av kunnskapen

 

[Oblivion]

La nå NRPACKS ligge for en stund nå da - er jo tross alt helg

Btw - jeg tar imot alle innspill og er veldig takknemlig for at dere mer enn gjerne deler av kunnskapen

Ja det er helg og jeg lar gjerne marsboer ta seg av kunnskapen vidre, men når det slik som med NRPACKS blir gitt en helt feilaktig fremstilling så er det ikke så lett å la slike "flat earth teorier" få stå ubesvart, men jeg har jo observert at det blir "full blokade" og person angrep i fortvilelsen....

For min del er dette utrolig lite inspirerende og får håpe at marsboer er ferdig med å gå på person og kan holde seg til sak...

 

[marsboer]

Hmm... Selverklært verdensmester i stort sett det meste- alias marsboer har talt

Sikkert mangt og meget som kanskje fungerer med standard kernel, base filsystem og applikasjoner

Nå har det seg slik at mitt system er kompilert og konfigurert ned til et absolutt minimum, og det er derfor en rimelig mange funksjoner, protokoller og kommandoer som det ikke er inkludert kode for... Dette gjelder både kernel, base filsystem og MPD.

Det er jo utmerket at du vil komme med noen forklaringer rundt lokal coverart og avahi for standard installasjoner etc. fordi både mpdPUP og Voyage MPD i flere standard utgaver har hatt utfordringer med lokal coverart og avahi...

2 ting.

1. For det første får jeg en definitiv følelse av at at du selv mener du opplever problemene dine fordi ditt oppsett er så avansert og spesialisert, aka bleeding edge innen hi-fi. I tillegg får jeg en følelse av at du underliggende anser det du holder på med å være på et høyere nivå enn de aller aller fleste og at du nærmest driver med nyskapende forskning som vi andre ikke forstår oss helt på. Dette er ikke ting du har sagt direkte, men en definitiv følelse jeg får når du uttrykker deg om det meste. Dette inntrykket settes fullt på kontoen for tvilsomt menneskesyn og jeg anklager ikke deg på noe vis for å uttrykke dette direkte.

2. Hvorfor sier du først at wiki-oppsettet mitt ikke fungerer, ihvertfall ikke pålitelig, for så å feie bort kritikken og komme med forklaringen om at det sikkert fungerer fint for oss som kjører et standardoppsett, men at du kjører et helt custom-oppsett? I tillegg drar du inn to linux-distroer som i forhold til Debian Wheezy 64-bit ikke kan sammenlignes versjonsmessig i det hele tatt.

Det blir interresant å se hva du legger vekt på- teknisk kunnskap eller hersketeknikk

Bare tiden vil vise, og jeg lar det være opp til deg og andre å bedømme om det er tomme ord eller faglig berettiget.

PS! Fortsatt er NRPACKS settingen antall PACKS og IKKE en setting i millisekunder.
Det faktum at NRPACKS settingen indirekte på grunn av underliggende USB timing vil ha en relasjon til millisekunder eller microsekunder betyr ikke veldig mye uansett fordi det er USB adapteret som har den overordnede kontrollen og styrer feedback timingen. NRPACKS og MAX_PACKS trenger bare å være satt til tilstrekkelig høye verdier som USB adapteret kan utnytte. Derfor er forklaringene om at NRPACKS settingen er en millisekund setting for kontroll av USB adapter og eller USB overførsel totalt feil fordi det er USB adapteret som utfører denne kontrollen. Riktignok vil for lave verdier på blant annet NRPACKS tvinge USB adapteret til å fungere mindre optimalt fordi det må sende feedback interrupt mye ofterer fordi data mengden i hver URB blir for liten til at den optimale og forventede timingen kan opprettholdes..

2 ting her også:

1. Denne diksusjonen akter jeg ikke å ta opp igjen med deg. Jeg bryr meg ikke om at vi er uenige om "måleenheten" for NRPACKS og diskusjonen er tatt i detalj tidligere. Der får folk som er interesserte sjekke tidligere poster i tråden (alle er vel lei av NRPACKS for lengst siden dette dras frem igjen og igjen som et gnagsår på hælene på den militære tremila...)
Jeg bryr meg i stedet mer om at du hele tiden tilpasser din forklaring og at din forståelse ikke holder vann mot kode og teori i nær sagt noen tilfeller.

2. Jeg legger merke til at du har gått fra å blankt benekte at frames og microframes i det hele tatt eksisterer:

Det stemmer ikke. Nrpacks 1 tilsvarer 1ms, d.vs 1 frame, med data. USB 2.0 bruker microframes i tillegg. Det går 8 microframes i en vanlig frame.

Er det du som er sjefen til Linus
Eller er det source koden til linux og de som har skrevet koden som er feil
Fikk du med deg at for USB 2.0 - 480Mbit så ganges det opp med en faktor på 8 ??

til:

Det faktum at NRPACKS settingen indirekte på grunn av underliggende USB timing vil ha en relasjon til millisekunder eller microsekunder betyr ikke veldig mye uansett...

...at det er et faktum, ikke bare at det er en relasjon der, men at dette også styres av underliggende USB-timing som du så elegant og innsiktsfullt prøvde å avfeie som en umulighet med dette glimrende argumentet i en tidligere post:

Kan du også forklare hvorfor NRPACKS = 1 skulle tilsvare 1ms på alle maskiner
Med CPU klokker som variere fra 100MHz til nærmere 10GHz (overklokking) og med "RT" klokker som varierer fra (100Hz) 200Hz i følge linux source koden til 4000Hz eller mer i praksis slik dere har forklart dette.

det er USB adapteret som har den overordnede kontrollen og styrer feedback timingen

Denne forståelsen dukket på magisk vis opp etter at jeg la frem de sniffede dataene fra mitt USB-kort. Ikke noe problem med det, siden det trossalt er dette et faglig forum dreier seg om, men dette er likevel en endring fra dine tidligere uttalelser.


Samtidig har du også endret ståsted på NRPACKS etter vår siste runde med krangling rundt denne parameteren. Før sto du knallhardt på at NRPACKS var antall pakker per URB. Men etter denne posten: http://www.hifisentralen.no/forumet/datahja-rnet/64040-voyage-mpd-15.html#post1419752
... hvor det ble helt stille fra din side i etterkant, har du nå plutselig åpnet for at NRPACKS i realiteten er:

Det faktum at NRPACKS settingen indirekte på grunn av underliggende USB timing vil ha en relasjon til millisekunder eller microsekunder

... en faktor som plutselig er indirekte slik som vist med eksempelet fra kildekoden i innlegget jeg linket til ovenfor.

Jeg håper du innser hvor lite tillitsvekkende du virker faglig på meg som person og hvor mye integritet du mister, når du gang på gang anklager meg, man, eller til og med kernel-utviklere for å være helt eller delvis på jordet, når du for hvert argument du fôres med tar din egen forklaring, endrer på den, kaster argumentene som ikke lenger passer på grunn av ugjenstridelig bevis og så finner en ny liten filleting å fokusere på. Dette gjentas til du tilslutt sitter igjen med en hyssing som er helt tynnslitt. I dette tilfellet har det gått fra å bestride at det i det hele tatt eksisterer en fast USB-timer, frames og microframes og at settingen betyr antall pakker direkte, til å ende opp med en loslitt gnaging om den mest korrekte tolkningen av den i utgangspunktet enhetsløse NRPACKS, som jeg og man velger å tillegge en spesifikk beskrivende tolkning.

Det er ingenting i veien med at man lærer underveis. Det som jeg imidlertid, dessverre må jeg få si, lar meg irritere over, er din totale mangel på ydmykhet hele veien. Det er helt tydelig at du må ha innsett underveis at flere av tingene du på en selvsikker og overlegen måte, indirekte eller direkte, har anklaget oss for å ha feil angående, faktisk stemmer. Dine utsagn harmonerer i langt større grad med den virkelige verdens forståelse nå enn tidligere og du bruker nærmest de samme argumentene nå, bare omskrevet til eget bruk, som du faktisk ble møtt med tidligere i diskusjonen.

 

[quade777]

Dette var en interessant tråd. Nå har den utviklet seg til flisespikking og smålig skittkasting.

 

[Ludo]

Den tar seg nok inn igjen skal du se

 

[Høvdingen]

Personangrep er ikke nødvendig, og det holder med å si at en er uenig.

Jeg håper diskusjonen kan fortsette uten personangrep.

 

[Ludo]

Det gjør den nok skal du se

 

[marsboer]

Nok personlige intriger. Nå til det faglige! Hurra!

Avahi/zeroconf:
Avahi er Linux-implementasjonen av zeroconf. De fleste har nok et bedre forhold til Apple-implementasjonen av zeroconf, nemlig bonjour. Uansett så er rollen til avahi i Linux/MPD-sammenheng å annonsere MPD som "Music Player" på nettverket slik at maskinen dukker opp automatisk i mPad/mPod uten behov for å spesifisere serveradressen manuelt. En ulempe er at tjenesten baserer seg på lokal multicast og man kan derfor ikke få dette til å fungere mellom to nett med en router i mellom. Dette er selvsagt fullt løsbart og jeg er avhengig av dette for fri zeroconf-flyt mellom nettene her hjemme både for MPD, airplay og airprint.

For at dette skal fungere på en Debian Wheezy installasjon med standardpakken for mpd er det kun en eneste pakke som må installeres og det er "avahi-daemon". Dette står i wikien, men nevnes ikke spesielt fordi det bare fungerer. Denne pakken lå ikke i førsteutkastet for wikien fordi jeg ikke benyttet meg av avahi før jeg fant ut hvordan jeg kunne løse dette med min nettseparasjon. Det er imidlertid noen uker siden jeg la til pakken i pakkelisten på wikien.

I anledning denne posten, og for enklere bevaring, har jeg lagt til litt om Avahi/zeroconf troubleshooting på wikien min nå i kveld: Hi-Fi Debian MPD USB transport - marsboer.net wiki

Dette skal normalt ikke være et behov med Debian Wheezy, men det kan være noen som skreddersyr sin egen mpd som trenger litt ekstra informasjon. Basically er det tre typiske feilkilder:

1. MPD er kompilert uten avahi-støtte og vil derfor ikke automatisk annonsere zeroconf-parametre til avahi
2. MPD fungerer som en avahi-tjeneste men avahi-tjenesten fanger ikke opp de lokale tjenestene
3. zeroconf er deaktivert i konfigurasjonen

Nr 1 vil oppstå om man glemmer å inkludere avahi når man kompilerer mpd. Det er imidlertid fullt mulig å manuelt legge til en avahi-service på den måten Oblivion beskrev, som igjen er hentet herfra: Hack:avahi mpd.service - Music Player Daemon Community Wiki
Dette medfører at man får annonsert MPD, men uten at dette skjer automatisk. Med mindre det er et helt bevisst valg å fjerne avahi fra mpd er dette egentlig en kamuflering av symptomer i stedet for at man reellt sett har fikset problemet.

3 er i Debian tatt hånd om, men om man kompilererer egen MPD kan det hende at man må skru på zeroconf manuelt.
2 vet jeg ikke hvordan man kan trigge uten å tukle til noe på egenhånd.

Her er en liste som viser ting slik det skal se ut på MPD-maskinen:

root@hifi:~# avahi-browse -t -a
...
+   eth0 IPv6 Music Player                                  Music Player Daemon  local
+   eth0 IPv4 Music Player                                  Music Player Daemon  local
...

Listen min er forøvrig mye lenger fordi jeg har mange nettverksenheter og både airplay- og airprint-tjenester.
Her ser man at MPD annonseres både med en IPv4 og en IPv6 adresse. Det er vanligvis mest interessant at IPv4 adressen annonseres.


Men det er mer:
I dagens verden hvor mer eller mindre alt henger sammen i nettverk er det svært vanlig at de aller fleste tjenester består av en serverdel og en klientdel. Dette virker veldig logisk når man tenker seg en fysisk PC på pulten som typisk har en klientrolle og en server i et eller annet serverrom som typisk har en serverrolle sett fra en tjenestes ståsted. Men hva gjør man når disse tingene kjøres på samme maskin? Hva om web-serveren skal snakke med SQL-serveren på samme maskin? Hva om man vil styre MPD med MPC lokalt?

Må man konfigurere en parameter som beskriver IP-adressen på nettverkskortet?

Må tjenestene skrives om slik at prosessene klarer å kommunisere med hverandre internt i tillegg til over nettverk?

Svaret er selvsagt nei. For å sikre seg at server/klient programvare kan kommunisere selv om de kjøres på samme maskin fant man opp et såkalt loopback-interface. Dette er et software-basert nettverksinterface som alltid er oppe uavhengig av fysiske nettverkskort i systemet. loopback-interfacet har så godt som alltid adressen 127.0.0.1, men i praksis er hele nettverket fra 127.0.0.0 -> 127.255.255.255 avsatt til dette formålet. I tillegg ligger det en statisk navneoppføring på systemet (/etc/hosts på en Linux-maskin) som mapper localhost mot loopback-interfacets adresse, dvs 127.0.0.1 i Debians tilfelle.
Når klienttjenestene da settes opp til å prøve localhost som default, vil trafikken sendes til loopback-interfacet, hvor serveren faktisk også står og lytter. Det blir derfor nettverkskommunikasjon som foregår helt uten å gå ut på nettverkskortet. I tillegg går alle tjenester ut fra at localhost mapper til et gyldig loopback-interface for å fungere korrekt.

Men hva om loopback-interfacet forsvinner?
Vel.. dette vil i praksis aldri skje. Det er alltid definert på systemet, med mindre man aktivt går inn for noe annet. Dette vil imidlertid være svært dumt siden svært mange tjenester da ikke lenger vil fungere uten ekstra konfigurasjon og noen ikke i det hele tatt.

And the plot thickens

Utdrag fra post 171 i denne tråden:

Løsningen er at du må oppdatere wiki for nettverks oppsett (/etc/network/interfaces) og legge til:

auto lo
        iface lo inet loopback

Når jeg nå har bygd debian wheezy (armhf) fra bunnen med debootstrap og har konfigurert alt 100% manuellt fra USB konsoll på CuBox og fant jeg ut at både nfs og mpd trenger dette for å fungere.
Mye mulig at dette kan gjøres på andre måter, men jeg setter nå opp linux på den enkleste måten jeg greier å få til...

Oi, du har fjernet loopback-oppføringen ja. Det forklarer litt. Da er det egentlig rart at du ikke har opplevd en masse krøll generelt.
Wiki'en sier at du skal redigere konfigurasjonen for nettverkskortet ditt, dvs at loopback-konfigurasjoen skal stå i fred. Jeg ser imidlertid at det kanskje ikke er intuitivt for personer uten nettverksbakgrunn at loopback-interfacet alltid må være tilstede.

Og noen få poster tidligere gir Oblivion uttrykk for noe frustrasjon rundt avahi/zeroconf og lokal bruk av mpc (CLI klient for MPD):

Slik mpd.conf er satt opp og uten Zeroconf / Avahi så er saken så enkel at med ´bind to "localhost"´så fungerer MPC - og ikke MPoD,
med ´bind to "xxx.xxx.xxx.xxx" så fungerer MPoD - og ikke MPC.

Har du en anbefaling til en oppskrift slik at både MPC og MPoD fungerer?

Hvorpå jeg svarte:

Har du en anbefaling til en oppskrift slik at både MPC og MPoD fungerer?

Siden "any" som jo ville vært det naturlige valget kommer i konflikt på ipv6 siden (med mindre du har en egenkompilert versjon av mpd uten ipv6) er følgende metode anbefalt:

bind_to_address "10.0.0.151"
bind_to_address "localhost"

Bytt ut IPen med din egen.

Det skal ihvertfall fungere fint å legge til mange bind_to_address linjer i følge "man mpd.conf".

Før konklusjonen kom i neste innlegg om at problemet skyldtes at loopback-interfacet manglet og at wikien var feil selv om den aldri nevnte et ord om å fjerne loopback-interfacet fra /etc/network/interfaces

(Til info så har jeg i etterkant endret teksten som beskriver endringen i interfaces-fila slik at det spesifikt nevnes at det allerede eksisterende loopback-interfacet ikke skal fjernes, noe jeg selv tok som en selvfølge omtrent som om at katta ikke skal tørkes i microen. Dette sto til Oblivions forsvar IKKE der opprinnelig.)

Men her er uansett den tekniske forklaringen på problemene Oblivion beskrev med mpc og avahi (disse er helt urelatert):
MPD lytter som standard bare på nettverkskortinterfacet (etter konfigurasjonsendring fra "any" som har problemer med ipv6 i Wheezy). MPC vil imidlertid som standard forsøke oppkobling mot localhost. Dette går dermed ikke bra uten å manuelt spesifisere server IP i MPC. mPad vil imidlertid fungere helt fint siden denne alltid aksesserer serveren via den eksterne mpd-adressen som mpd faktisk lytter på og avahi annonserer.

Oblivion forsøkte deretter å sette mpd til kun å lytte på localhost, noe som på grunn av sin natur aldri vil fungere skikkelig mot noen eksterne klienter, og da virket plutselig mpc men ikke avahi og mpad/mpod. Siden mpd nå kun lytter på localhost-adressen (127.0.0.1), som forøvrig ikke finnes siden loopback-interfacet var fjernet, vil avahi ikke kunne annonsere mpd med gyldig nåbar ekstern adresse. Adressen som mpd lytter på, og som avahi annonserer om den ikke har sperrer for dette, er jo 127.0.0.1. Og selv om den hadde eksistert så ville 127.0.0.1 kun ført til at mpod/mpad prøvde å aksessere egen localhost-adresse, ergo seg selv. Jeg får i tillegg feilmelding på mitt system om jeg prøver å starte mpd med "bind to" satt til "localhost" i mpd.conf uten at loopback-interfacet eksisterer og mpd starter dermed ikke i det hele tatt.

Løsningen for å få i pose og sekk er da:
- Fungerende loopback (en selvfølge som vanligvis aldri er et issue for å si det slik)
- mpd må lytte på ekstern adresse for å ta imot eksterne tilkoblinger og slik at avahi kan annonsere en faktisk nåbar ekstern adresse
- mpd må lytte på localhost-adressen for å kunne ta imot lokale tilkoblinger fra f.eks mpc uten noe mer dill

På grunn av disse problemene, sammen med at en egenkompilert versjon av mpd benyttes, vil jeg derfor påstå at det er overhengende sannsynlighet for at Oblivions problemer utelukkende har skyldtes rene tekniske brukerintroduserte feil og at hans problemer ikke på noe vis bør legges til grunn for å betrakte avahi/zeroconfi i kombinasjon med mpd som noe som er hverken vanskelig eller komplisert å få til på en pålitelig måte.

Dette er ment i beste informative mening for å avkrefte påstanden om at min wiki ikke kan benyttes for å få en fungerende avahi.

 

[nma]

Jeg har aldri hatt problemer med hverken Avahi (autodiscovery, slik at mPad på iPad automatisk finner MPD-serveren uten noe konfigurering), eller cover art via lokal webserver. Jeg og Oblivion har mailet frem og tilbake ang. dette da han ikke fikk det til å fungere, og jeg hjalp han da til å sette opp lokal cover art.
Avahi-hacken m.h.t til MPD stammer nok fra den tiden MPD ikke hadde støtte for Avahi eller at de ferdige binær-pakkene (til MPD) via apt-get ikke hadde kompilert inn støtte for Avahi.
Ellers krever Avahi absolutt ingen konfigurering whatsoever, om Avahi-støtten allerede er der i de programmene som benytter Avahi. (MPD støtter nå dette som default om man bruker APT-get, men man må manuelt kompilere inn Avahi-støtten om man kompilerer MPD fra source) Voyage MPD tror jeg hverken støtter avahi eller cover art som standard. Forøvrig er Voyage MPD er også helt utweaket, og bruker samme kernel som vanlig Voyage Linux (Bedre å benytte apt-get og installere en offisiell kernel fra Debian), noe som ikke er helt optimalt med tanke på lyd og funksjonalitet p.g.a manglende støtte for et par essensielle ting.

De jeg har hjulpet med å få i gang MPD via minnepinne på sine Mac'er har koblet til via Mpad via Avaha/autodiscovery alle som en. Jeg har ikke fått tilbakemelding på at dette er ustabilt.

 

[marsboer]

Cover-art server

Her tar jeg den enkle varianten hvor web-serveren kjører på samme server som MPD med samme musikkmappe (/var/lib/mpd/music). Web-serveren må rett og slett dele ut selve musikkmappen på rotnivå på URLen du refererer til i mPad. Dette tar jeg på husken så ta det med en klype salt.

Installer apache2:

apt-get install apache2

Opprett en konfigurasjonsfil for apache2. Denne er rimelig clean kun for å dele ut filer, men den er tilpasset litt med mod_autoindex for å få finere presentasjon og sortering av mapper og filer kontra standardpresentasjonen.

nano /etc/apache2/sites-available/music

<VirtualHost *:80>
    ServerAdmin webmaster@localhost

    DocumentRoot /var/lib/mpd/music/

    <Directory />
        Options FollowSymLinks
        AllowOverride None
    </Directory>


    <Directory /var/lib/mpd/music/>
        Options Indexes FollowSymLinks MultiViews
        AllowOverride None
        Order allow,deny
        allow from all
        <IfModule mod_autoindex.c>
            IndexOptions IgnoreCase FancyIndexing FoldersFirst SuppressHTMLPreamble SuppressDescription
        </IfModule>
    </Directory>


    ErrorLog ${APACHE_LOG_DIR}/error.log


    # Possible values include: debug, info, notice, warn, error, crit,
    # alert, emerg.
    LogLevel warn


    CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>

Slå deretter av default-siten (/var/www), aktiver music-siten og restart apache2

a2dissite default
a2ensite music
invoke-rc.d apache2 reload

Du skal i teorien nå kunne nå musikk-mappen din på http://<mpd-ip> fra nettverket. Gjør du ikke det må du finne ut av dette før du har noe håp om å komme deg videre.

Når serveren er oppe og tilgjengelig kan du deretter gå inn på mPad players -> finne serveren din -> advanced -> Local Cover Art:
Legg inn URLen som du finner rotnivået på musikkmappen din slik mpd ser det i /var/lib/mpd/music, i dette tilfellet: http://<mpd-ip>
Legg deretter inn riktig cover filename. Dette er case sensitivt. Standard er Folder.jpg. Mine cover-filer heter imidlertid folder.jpg med liten F, så jeg endrer navnet her. mPad takler ikke hummer og kanari her, så du er nødt til å sørge for at musikksamlingen din er ensrettet og konsekvent på cover-navn. Jeg brukte selv et script til denne jobben, og Man har vel også kjørt sine filer for renaming via dette.

 

[Oblivion]

Nok personlige intriger. Nå til det faglige! Hurra!

Dette er ment i beste informative mening for å avkrefte påstanden om at min wiki ikke kan benyttes for å få en fungerende avahi.

Jammen er du etterrettlig

Får være litt "snillere" enn deg...

Det er forkastelig å argumentere på den måten du gjør - vannvittig blanding av usammenhengende bruddstykker og utelatelser og person sjikane i vilter blanding,
men jeg vil kun påpeke det du med vitende unngår og som er hoved poenget:
De forskjellige MPD versjonene som er "apt-get install" fra de forskjellige debian repositoriene og da med forskjellige versjonsnummere er som jeg har rapportert helt forskjellige i forhold til konfigurasjon av nettverk / avahi.
Altså må mpd.conf konfigureres helt forskjellig med hensyn til "bind to address"..

Ved å bruke

<?xml version="1.0" standalone='no'?>
<!DOCTYPE service-group SYSTEM "avahi-service.dtd">
<service-group>
 <name replace-wildcards="yes">music player daemon on %h </name>
 <service>
   <type>_mpd._tcp</type>
   <port>6600</port>
 </service>
</service-group>

fungerer det uansett nedlastet MPD versjon eller oppsett.

Har du tenkte å holde på videre så får du gjøre det alene, men siden jeg ikke akter å stryke deg med hårene så trekker jeg meg ut fra de sammenhenger hvor du ønsker å briljere

 

[H.R]

Såså gutter . Litt småkjekling er bra, driver tråden videre og skjerper sansene.
Fint å se forskjellige innfallsvinkler og til syvende og sist kommer alle videre ved å kjøre litt steilt fra tid til annen.
det som dere med den kompetansen dere har vil resultere i en distro som er 100% optimalisert for god lydgjengivelse og la nå for guds skyld ikkke forskjellige innfallsvinkler ødelegge dette.

 

[Oblivion]

Såså gutter . Litt småkjekling er bra, driver tråden videre og skjerper sansene.
Fint å se forskjellige innfallsvinkler og til syvende og sist kommer alle videre ved å kjøre litt steilt fra tid til annen.
det som dere med den kompetansen dere har vil resultere i en distro som er 100% optimalisert for god lydgjengivelse og la nå for guds skyld ikkke forskjellige innfallsvinkler ødelegge dette.

Neida jeg skal la de holde på uten at jeg trenger å bry meg

 

[marsboer]

Jeg forstår at mitt tilbakeblikk svir, men jeg kan love alle som orker å faktisk lese innleggene før og etter at den faglige essensen er bevart, konteksten er ikke utelatt på en spekulativ måte (mye urelevant tomprat fra begge parter er selvsagt utelatt), og de tekniske beskrivelsene er ikke konstruert utfra tilvridde spesiallklipp fra dine innlegg, men reflekterer faktiske tilstander på det stadiet.
Faktisk reduserte jeg mye av det jeg egentlig fant av til dels enda mer faglig uheldige kommentarer fra din side bare for å ikke bli alt for injurierende.
Jeg skal ikke dra dette videre på noen som helst måte, så du kan være trygg på at historikken får hvile fra min side i hvertfall.

En kommentar på det faglige i siste inlegg:
Manuell annonsering fungerer til og med om det faktisk ikke er mpd-serveren som går på port 6600. Dette er en svakhet som selvsagt sjelden vil bli et reellt problem.
Jeg har aldri forholdt meg til noe annet enn Debian Wheezy 64-bit, og har vært krystallklar på dette. Det er uansett ingen ekstra utfordring å få til automatisk zeroconf-annonsering når man kompilerer selv med de siste versjoner.

Det finnes i grunn bare ett bruksområde for den manuelle varianten og det er dersom man insisterer på å kjøre en ferdigkompilert pakke med en gammel MPD-variant uten avahi. Kanskje ikke spesielt relevant for oss, siden du jo holder på med de nyeste versjoner som har denne muligheten om du ønsker, og de fleste andre holder på med typisk Wheezy-varianter.

Det er jo imidlertid greit å ha din workaround tilgjengelig som referanse i tråden dersom man får dette behovet, eller ikke ønsker å løse de virkelige problemene med nyere versjoner.

Man trenger ikke endre noen ting med forskjellige bind to addresses med standard MPD/Avahi oppførsel. MPD vil, gitt at avahi er medkompilert, automatisk oppdatere riktig adresse til avahi. Det er hele poenget med å ha automatikken i orden.


Mine alternative forslag fremfor å flisespikke for nykommere:
- Gjør nøyaktig som i wikien min inntil du føler deg trygg på noe annet. Det virker, kan skreddersys etter behov, og installasjonen er samtidig enkel å oppgradere i fremtiden!

- Få et ferdig image av Man. Enklere enn dette blir det vel neppe, uten at jeg har prøvd imaget selv!

- Ta Oblivion-varianten og tenk helt selv! Kvistene blir mange, men du lærer i hvertfall mye!

 

[Oblivion]

Jeg forstår at mitt tilbakeblikk svir

Forstår dessverre din tankemåte etterhvert, og ønsker deg lykke til videre

 

[gut_man]

Slutter meg til HRs oppfordring. Ikke la dette utvikle seg til noe som fører til at tråden stenges. Dette er imo den mest innovative tråden i hfs historie! Det ville være fryktelig synd om dette skulle stoppes av uenigheter. Skulle ønske at man kunne få til løsninger som gjorde det hyperenkelt for alle å få høre hvilke enorme gevinster som ligger i supertweakede MPD maskiner. Noe av det mest revolusjonerende er jo ar det ffs nesten ikke koster penger. Problemet er at man foreløpig (i hvertfall på mitt kompetansenivå) er avhengig av "snille onkler" som hjelper å lose en til trygg havn. Når MPD er oppe å gå, er det etter min erfaring dønn stabilt og lydmessig herlig overlegent alle windowsbaserte avspillere jeg har testet! MPD til folket burde være motto og mål for tråden imo!

 

[grelv]

....Når MPD er oppe å gå, er det etter min erfaring dønn stabilt og lydmessig herlig overlegent alle windowsbaserte avspillere jeg har testet! MPD til folket burde være motto og mål for tråden imo!

Jeg har også kjørt MPD siste halve året, og har akkurat samme erfaring.
Helt enig i resten av innlegget også. Dette er den mest interessante tråden på HFS for tiden.

 

[Ludo]

Får connecta til MPD, og finner alle sangene. MEN, når jeg trykker på Play så står det bare Paused og ingen lyd kommer...

Forslag?

 

[Ludo]

Jeg sjekker interrupts:

             CPU0       CPU1       CPU2       CPU3
 23:         32         31         30         26            IO-APIC-fasteoi   ehci_hcd:usb1, uhci_hcd:usb3

Sånn det står nå er HRT Musicstreamer II+ koblet til på en USB3-port. Hvorfor står det ehci/uhci her da? Skulle det ikke stått xhci?

 

[Ludo]

Har også lagt inn blacklist på moduler jeg ikke bruker for å unngå feil denne veien...

 

[quade777]

Spent her. Vi har rimelig like oppsett Ludo og jeg har lurt på hva vi har å hente på å skifte usb-device... Foreløpig er exadevices rett for meg, men har lekt med en dualboottanke... Da med mdp på minnepinne og 1. Boot priority satt til usb.

 

[Ludo]

It Works! Flere tilbakemeldinger kommer etterhvert...

 

[marsboer]

It Works! Flere tilbakemeldinger kommer etterhvert...

Med mindre det er en åpenbar blunder som du helst vil feie under teppet, så kan du gjerne si noe om hva du gjorde i tilfelle andre kommer borti det samme

 

[Ludo]

Feil adresse på lydkortet i mpd.conf Av en eller annen grunn byttet lydkortet adresse når jeg restartet den. Blokkerte driverne til andre enheter og lydkort slik at hw0,0 alltid blir korrekt.

 

[Ludo]

Spent her. Vi har rimelig like oppsett Ludo og jeg har lurt på hva vi har å hente på å skifte usb-device... Foreløpig er exadevices rett for meg, men har lekt med en dualboottanke... Da med mdp på minnepinne og 1. Boot priority satt til usb.

Heisann,

jeg har tenkt samme ting! Akkurat nå spiller jeg av med HRT Musicstreamer II+, den hadde jeg nesten avskrevet totalt pga ikke så veldig bra lyd. Men med MPD så våkner denne virkelig til liv selv om det er et stykke igjen til exaDevices I2S og Buffalo DAC. Og fjernkontroll via iPhone/iPad er jo genialt! Kommer til å teste dette mer, mye mer!

 

[quade777]

DeLOCK Card reader ( internal ) - Serial ATA - CompactFlash Card type I, CompactFlash Card type II, Microdrive - PC, Mac kanskje dette er veien å gå? Da slipper man å overbelaste USB-controlleren med OS. Man kan vel bare sette en slik til 1. Boot device i Bios og så sette evt andre HD til 2. Boot device og disable disse i linuxen slik at de ikke åpnes...

 

[Ludo]

Ser interessant ut den der! Hvordan er det å kjøre dualboot på en sånn installasjon? Burde vel funke fint det! Har en 90GB SSD stående med i5 CPU, det hender jo man spiller av musikk med Spotify også - ihvertfall her i huset...