Qobuz streaming tjeneste

[raw]

Har opplevd det samme som deg via Qobuz Connect, men ikke når jeg spiller av via Eversolo sin app, @PeriodeLytter

 

[Harry Stoteles]

Niks, ingen sånne problemer verken i MacOS, iOS, iPadOS eller via Roon.

 

[joha]

undrer om det er andre på HFS som sliter med at sport avsluttes for tidlig?

Ja, det hender av og til her også. Wiim Pro Plus med Qobuz Connect.

 

[joha]

Jeg spurte vår alles gode venn ChatGPT. Her er en del av svaret (noen får si ifra om det ikke passer i tråden):

Den avgjørende forskjellen: Hvem eier tidslinjen?

Når du spiller:

A) Ikke-Connect (telefon → streamer)

• Telefonen:
  • laster hele track-metadata
  • kjenner eksakt lengde
  • eier playback-klokka
  • sier til streameren: «spill dette PCM-/FLAC-strømmen, jeg sier ifra når vi er ferdige»

Streameren er i praksis en dum DAC/renderer
Ingen tvil om når låta slutter


B) Connect (streamer → internett)

• Streameren:
  • åpner selv HTTP-strømmen
  • tolker metadata, chunking og signaler
  • styrer egen avspillingsstate
• Appen:
  • er bare en kontrollflate
  • får status tilbake fra streameren

Streameren er 100 % ansvarlig for å vite når låta er ferdig

Her ligger kjernen i problemet.

Hvorfor tror streameren at låta er ferdig?

Dette er ikke buffer-størrelse, men state-maskin-logikk.

Connect-protokoller er hendelsesbaserte, ikke filbaserte
De er bygget rundt:

• track_start
• track_progress
• track_end
• next_track_ready

Problemet er at “track_end” ikke alltid er entydig definert.

De tre vanligste reelle årsakene (på tvers av merker)
1. Uklar eller feil Content-Length / duration

I Connect får streameren ofte:

• estimert lengde
• segmentert strøm
• adaptiv chunk-størrelse

Eksempel:

• Qobuz sender FLAC i variable segmenter
• Streameren regner samples → tid
• En liten avvik (f.eks. feil padding / encoder-delay / metadata-offset)
• Spilleren når “0 samples igjen” → TROR låta er slutt

Den hopper videre uten feil i nettverket

Dette skjer:

• oftere på høyoppløst materiale
• oftere på enkelte mastere
• tilfeldig fra spor til spor

2. Avspillings-state styres av tid, ikke EOF
Mange Connect-implementasjoner gjør:

yaml
if playback_time >= reported_track_duration:
go_to_next_track()


I stedet for:

scss
wait_for_stream_EOF()

Hvis:

• track_duration er feil (for kort)
• stream har encoder-delay / tail-padding
• DAC-klokka og stream-klokka ikke er perfekt synket

Avspillingen kuttes før EOF

Dette forklarer:

• hvorfor det skjer tidlig, ikke alltid på slutten
• hvorfor det aldri skjer i WiiM-appen
• hvorfor det aldri skjer når telefonen spiller

3. Race condition mellom prefetch og end-event

Connect er designet for:

• gapless
• rask “next track”

Det betyr:

• neste spor lastes før nåværende er ferdig
• to state-maskiner lever parallelt

En klassiker:

1. Streameren begynner å prefetch neste spor
2. Nåværende spor når et internt end-condition
3. “Next track ready” vinner racet
4. Spilleren bytter spor for tidlig

Dette er ren logisk feil, ikke nettverksfeil

Og ja:

• Spotify Connect har samme type bug
• Tidal Connect også
• Sonos, Bluesound, WiiM, HEOS, etc.

Hvorfor skjer dette på alle merker?

Fordi:
Qobuz / Spotify leverer:

• SDK
• sertifisering
• minimums-API

Produsentene:

• implementerer selv
• på ulike OS
• med ulike audio-pipelines
• med egne klokker og DAC-drivere

Connect-spesifikasjonen er ikke deterministisk nok til å forhindre dette.

Det er ingen absolutt “EOF-garanti” i Connect slik det er når telefonen er avspiller.

Konklusjon:
**Det er en strukturell svakhet i hvordan Connect håndterer:

• tidslinje
• spor-slutt
• prefetch
• metadata-tillit**

Når streameren selv er “sjef”, må den gjette når låta er ferdig.
Og noen ganger gjetter den feil.

 

[joha]

Videre:
Så: Hva måtte endres i Connect-spesifikasjonen?

Her er det viktigste – konkret, ikke teoretisk.

1. EOF-autoritativ slutt (kritisk)
I dag:

• “track_end” kan trigges av:
  • tid
  • metadata
  • intern buffer-state

Må endres til:

• Track kan kunavsluttes av:
  • eksplisitt EOF fra stream
  • eksplisitt STOP fra tjenesten

Metadata skal aldri være avgjørende.

2. Separere prefetch fra playback state

I dag:

• next_track_prefetched == “klar til å spille”
• kan trigge for tidlig

Må endres til:

• Prefetch = passiv
• Playback state kan ikke påvirkes før:
  • EOF er bekreftet
  • eller tjenesten eksplisitt sender NEXT

3. Sample-basert rapportering (ikke tid)

I dag:

• streameren rapporterer:
  • “playback_time = 182.3s”

Må endres til:

• “samples_played = N”
• “samples_total = M (valgfritt)”

Da:

• encoder-delay
• FLAC-padding
• VBR-variasjoner

…slutter å være relevante.

4. Entydig “track authority”

I dag:

• både app
• tjeneste
• streamer

…kan initiere state-endringer.

Må endres til én av to modeller:

Modell A – Roon-aktig

• tjenesten er autoritet

Modell B – UPnP-aktig

• EOF er eneste sannhet

Alt annet er en kompromiss-løsning.


Hvorfor dette sannsynligvis aldri blir fikset helt

Fordi:

• Spotify / Qobuz prioriterer:
  • respons
  • UX
  • mobil-først
• Ikke:
  • sample-perfekt hi-fi-logikk

Å gjøre Connect deterministisk ville:

• øke latency
• redusere “snappiness”
• bryte kompatibilitet
• kreve ny sertifisering

Markedet vil ikke ha det – unntatt oss.

Brutalt ærlig konklusjon

• Roon fungerer fordi endpoint er dum
• UPnP fungerer fordi EOF er sjef
• Connect feiler fordi streameren må gjette

Og:
Så lenge Connect er “prediktiv”, vil spor av og til bli avsluttet feil – uansett produsent.

Sitat fra ChatGPT slutt.

 

[Evo III]

Har opplevd det samme som deg via Qobuz Connect, men ikke når jeg spiller av via Eversolo sin app, @PeriodeLytter

Samme her, med connect på HiFi Rose.

 

[PeriodeLytter]

Siden CGPT kan lede tanker over på mye rart la oss se på hvordan jeg kjenner Qobuz. Men først om noen av dere kan være snill å verifisere at Qobuz Connect kan styre endpoint tilsvarende Spotify sin Connector? Hvor man starter avspilling av et album/spilleliste og Connctor ferdigstiller denne selv om telefonen blir slått av eller tatt med ut av huset? Om dette er tilfelle vil jeg tro Connectoren benytter samme tilnærming som Lyrion pluggen.

Qobuz pluggen for Lyrion benytter filbasert FLAC stream over HTTPS som cashes til en midlertidig fil. I praksis vil si den utfører egentlig avspilling helt identisk som om det er en lokal FLAC-fil. Hvor den først leser inn METADATA block #0 streaminfo* hvor totalt antall samles er definert. Dette kan brukes sammen med sample rate til å kalkulere spilletid på sporet og det det slik lokal streaming i Lyrion gjør det. Spilletid blir også levert via en egen lenke hvor alle metadata for sporet som spilles finnes. Tags utenom METADATA block #0 (STREAMINFO) og #1 (SEEKTABLE) finnes ikke i selve FLAC-strømmen.

FLAC -> PCM trankoderen (player) behøver egentlig ikke denne streaminfo for å spille FLAC da hver eneste FLAC ramme inneholder** sekvensielt rammenummer og offset fra start. Men FLAC-rammen har ikke info om lengden på sporet så da blir det EOF som gjelder. Når jeg ser at cash-filen lukkes tolker jeg det slik at det da enten er server som sender EOF, eller at TCP forbindelse blir avsluttet og cash derfor lukkes lokalt.

Her er det verd å tenke på at under normalt drift så vil hvert nytt spor i spillelisten/album åpne opp en ny stream***. Derfor hverken ser eller logger streamer dette som feil om det EOF den opplever. Dette til tross for at analyse av cash faktisk inneholder feil som:
FLAC__STREAM_DECODER_ERROR_STATUS_LOST_SYNC
ERROR, decoded number of samples is smaller than the total number of samples set in the STREAMINFO.

LOST_SYNC er de fleste endpoints trent til å ignorere for heller søke opp neste ramme uten feil og fortsette avspilling. Den siste feilen forutsetter at enpoint er trent opp til å kalkulere totalt antall samples og logge dette som feil om det ikke samsvarer med streaminfo. Spørsmålet er om man anser det som transkoderen sitt ansvar gitt EOF er ganske defnetivt noe kilden er ansvarlig for. Og noe jeg har bekreftet faktisk er hva som skjer her ved å overvåke hvordan cash oppfører seg. Kan også nevne at spor lengde er riktig visualisert siden CGPT tar fram dette som mulig problem.

Siden problemet oppstår oftere på hi-res og/eller lange spor 7+ minutter har jeg spekulert om det er flaskehalser i nett eller cash på lokale servere hos QB som tuller. Herunder mulig authetisering som jeg ikke har oversikt om hvordan egentlig foregår i en lenger streamperioder. Repeterer man samme spor mange nok ganger får man innimellom hele låten uten feil. Som da om ikke annet friskmelder QB sitt arkiv som var det jeg først mistenkte var problemet før jeg erfarte at problemet eskalerte.


*) Om man selv vil tittel litt på dette bruk metaflac --list trackname.flac
**) Typisk ser vi blocksize: 4608 samples pr ramme.
***) Om man lytter til f.eks. Radio Paradise er det lenger sammenhengende stream med flere låter. Hvor avbrudd gjerne sees når radioverten snakker. Hvor streamer da lukker stream og åpner en ny.