Hifidelio-User.de

Das (inoffizielle!) Forum für Hifidelio-User
Aktuelle Zeit: 20.10.2017 07:27

Alle Zeiten sind UTC + 1 Stunde [ Sommerzeit ]




Ein neues Thema erstellen Auf das Thema antworten  [ 81 Beiträge ]  Gehe zu Seite Vorherige  1, 2, 3, 4, 5, 6  Nächste
Autor Nachricht
 Betreff des Beitrags:
BeitragVerfasst: 05.01.2007 09:13 
Offline
Benutzeravatar

Registriert: 08.04.2005 22:09
Beiträge: 147
Wohnort: Wien
Musikuss hat geschrieben:
Ich vermute, da kann nur ein mt-daap-Entwickler helfen.


Getan: http://forums.fireflymediaserver.org/viewtopic.php?t=1663

Und nu?

_________________
Revox B760, NAD 325C BEE, KEF iQ5, Hifidelio EEPRO-80, DAC "Monica" from DIY Paradise. http://blog.caswane.com


Nach oben
 Profil  
 
 Betreff des Beitrags:
BeitragVerfasst: 05.01.2007 09:27 
Offline
Moderator
Benutzeravatar

Registriert: 21.05.2005 14:31
Beiträge: 2388
Wohnort: 52.429105,10.810525
Zitat:
I'm following up on this issue. Unfortunately, it is still the same problem as dksoft reported some time ago.
Except that firefly is now running in version 1463.
If you want, I can send you the debug log file from firefly.



No, I've seen it. The issue is that the hifidelio doesn't respect the Connection-Type: Close header. It's possible I could keepalive the connection, but it would mean that transcoding wouldn't work, as I don't know how long the song is until I finish transcoding it. It also means I'd have to keep some kind of quirks table, and special case that player.

Which is doable, but frankly isn't high on my todo list.

If you bump me on it periodically, though, you'd probably have better luck with it moving up the priority list. Smile


-- Ron


Ich würd mal meinen, "bump him periodically" könnte jetzt noch weiterhelfen ... oder?

_________________
nope!


Nach oben
 Profil  
 
 Betreff des Beitrags:
BeitragVerfasst: 05.01.2007 09:35 
Offline
Moderator
Benutzeravatar

Registriert: 29.01.2005 00:43
Beiträge: 1750
Wohnort: CH, Bern
Spacesson hat geschrieben:
Zitat:
I'm following up on this issue. Unfortunately, it is still the same problem as dksoft reported some time ago.
Except that firefly is now running in version 1463.
If you want, I can send you the debug log file from firefly.



No, I've seen it. The issue is that the hifidelio doesn't respect the Connection-Type: Close header. It's possible I could keepalive the connection, but it would mean that transcoding wouldn't work, as I don't know how long the song is until I finish transcoding it. It also means I'd have to keep some kind of quirks table, and special case that player.

Which is doable, but frankly isn't high on my todo list.
If you bump me on it periodically, though, you'd probably have better luck with it moving up the priority list. Smile

-- Ron


Ich würd mal meinen, "bump him periodically" könnte jetzt noch weiterhelfen ... oder?


oder: HF soweit korrigieren/modifizieren dass er auch spezifikationsgerecht kommuniziert...

_________________
Was war ST-64 :?:


Nach oben
 Profil  
 
 Betreff des Beitrags:
BeitragVerfasst: 05.01.2007 09:40 
Offline
Moderator
Benutzeravatar

Registriert: 21.05.2005 14:31
Beiträge: 2388
Wohnort: 52.429105,10.810525
langweilig.

"bumpen" ist doch viel schöner ....

;-)

_________________
nope!


Nach oben
 Profil  
 
 Betreff des Beitrags:
BeitragVerfasst: 05.01.2007 17:54 
Offline
Benutzeravatar

Registriert: 29.10.2005 10:37
Beiträge: 225
Wohnort: Wendishain (Sachsen)
Zitat:
Der iTunes client weist in seinem HTTP request (header) ausdrücklich auf das Argument "connection=close" hin, wohin gegen der request vom Fidel kein Argument "connection=keepalive" mitschickt.


@blechkiste
In HTTP/1.1 hat sich die Bedeutung der (nicht vorhandenen) Keep-Alive Header ggü. HTTP/1.0 umgedreht, da der Default-Wert (kein Header vorhanden) "connection=keepalive" ist. Wenn der Client es (mit seinem "connection=close" Header) anfordert oder wenn der Server nicht anders kann (z.B. fehlender Content-Length Header, da Länge unbekannt), wird Keep-Alive in der Antwort des Servers abgeschaltet, und der entsprechende Header wird in der Response des Servers gesetzt.

Interessant sind in dem Zshg. die unterschiedlichen Request-Header der Clients, die auch zum unterschiedlichen verhalten des Servers führen können:

- x-audiocast-udpport
- Client-DAAP-Version

Ich schau mal in die firefly-Quellen.
[edit]
Das gefundene passt zu dem oben zu HTTP/1.1 gesagten.
Code:
if(strncasecmp(last,"HTTP/1.0",8)==0) { /* defaults to non-persistant */
             pwsc->close=!ws_testarg(&pwsc->request_headers,"connection","keep-alive");
 } else { /* default to persistant for HTTP/1.1 and above */
          pwsc->close=ws_testarg(&pwsc->request_headers,"connection","close");
 }

DPRINTF(E_DBG,L_WS,"Thread %d: Connection type %s: Connection: %s\n",
pwsc->threadno, last, pwsc->close ? "non-persist" : "persist");

Hier (webserver.c) steht auch warum ein close kommt, es liegt am 'user-agent' header, ich lag also schon fast richtig mit meiner Vermutung bzgl. der Client-Header :wink: :
Code:
    /* we'll force a close here unless the user agent is
       iTunes, which seems to get pissy about it */
    useragent = ws_getarg(&pwsc->request_headers,"User-Agent");
    if(useragent && (strncmp(useragent,"iTunes",6))) {
   pwsc->close=1;
   ws_addarg(&pwsc->response_headers,"Connection","close");
    }

Es sieht so aus, als käme für den HTTP/1.1 Client (im Fidel) das 'close' unerwartet (weil nicht angefordert, damit sollte ein Client m.E. aber leben können). Dagegen hilft nur, den o.a. Code ändern oder einen eigenen Firefly bauen oder Mimikry, also den Fidel als iTunes-Client ausgeben oder dem Fidel HTTP-Client einen relaxteren Umgang mit dem close des Servers angewöhnen...
[/edit]
Zitat:
Was auch noch auffällt im firefly log am Ende (bei Uebergang von song1 zu song2:
firefly & fidel: With thread 1 exiting, 0 are still running
firefly & iTunes: With thread 1 exiting, 1 are still running

Wenn das die Worker-Threads sind, die pro Socket-Verbindung laufen, dann ist so ein Thread fertig, wenn die Verbindung geschlossen wird. Anderenfalls hängt der thread im 'read' oder 'select' auf dem Socket und wartet auf die nächsten Daten. Das erscheint mir somit nicht ungewöhnlich.
--
Gruß.

_________________
Due to budget cuts, the light at the end of the tunnel has been turned off.


Nach oben
 Profil  
 
 Betreff des Beitrags:
BeitragVerfasst: 06.01.2007 09:59 
Offline
Godfather of Hifidelio
Benutzeravatar

Registriert: 03.02.2005 12:45
Beiträge: 2040
Wohnort: Rheinhessen
Interessant, gehe ich recht in der Annahme, dass das also nur bei "transcodierten" Songs passiert? Das würde die unterschiedlichen Erfahrungen erklären.

Gestern war mein letzter Urlaubstag, nächste Woche kann ich also mal schauen. Soweit ich mich erinnern kann, ist connection-close in der daap Spezifikation (die ich vermutlich im Gegensatz zum Firefly Entwickler habe) verboten. Vielleicht kann man es dem Hifidelio dennoch beibringen, mal sehen.

_________________
Verallgemeinerungen sind generell schlecht.


Nach oben
 Profil  
 
 Betreff des Beitrags:
BeitragVerfasst: 06.01.2007 10:38 
Offline
Benutzeravatar

Registriert: 29.10.2005 10:37
Beiträge: 225
Wohnort: Wendishain (Sachsen)
Das mit dem Transcoding ist ein weiterer Grund (wie schon erwähnt, am Server unbekannte Content-Length impliziert Connection=close). Wahrscheinlich ist das beobachtete Verhalten eine Überlagerung aus transcodierten Songs und Clients, die sich nicht mit "iTunes..." im User-Agent melden.

Die ultimative Lösung ist also wirklich, wenn der daap-Client im Fidel mit Connection=close umgehen kann, selbst wenn die Spec. dazu etwas anderes sagt (wenn Connection=close nicht erlaubt ist, müßte der Client strenggenommen nach dem Auswerten dieses Headers den darauf folgenden Server-Response ignorieren).

Anmerkung: Eine Alternative aus HTTP/1.1, von der ich nicht weiß, ob sie die daap-Spec. zuläßt und ob sie praktisch unterstützt wird, ist das Transfer-Encoding "chunked". Das Transfer-Encoding ist optional und wird wie das Content-Encoding über die Header ausgehandelt (der Client sagt im Request, was er kann, der Server verhält sich entsprechend). Hierbei wird der Content in Chunks geliefert, vor denen deren jeweilige Länge steht. Am Ende kommt eine '0'. Somit ist auch ohne Content-Length-Header kein forciertes Connection=close notwendig, damit der Client weiss, dass der Server alle Daten geliefert hat. Das geht sicher auch, wenn transcodiert wird, denn da ist irgendwann auch der letzte 'Block' verarbeitet.
--
Gruß.

_________________
Due to budget cuts, the light at the end of the tunnel has been turned off.


Nach oben
 Profil  
 
 Betreff des Beitrags:
BeitragVerfasst: 11.01.2007 09:34 
Offline
Benutzeravatar

Registriert: 08.04.2005 22:09
Beiträge: 147
Wohnort: Wien
Musikuss hat geschrieben:
Gestern war mein letzter Urlaubstag, nächste Woche kann ich also mal schauen. Soweit ich mich erinnern kann, ist connection-close in der daap Spezifikation (die ich vermutlich im Gegensatz zum Firefly Entwickler habe) verboten. Vielleicht kann man es dem Hifidelio dennoch beibringen, mal sehen.

Any news?

_________________
Revox B760, NAD 325C BEE, KEF iQ5, Hifidelio EEPRO-80, DAC "Monica" from DIY Paradise. http://blog.caswane.com


Nach oben
 Profil  
 
 Betreff des Beitrags:
BeitragVerfasst: 11.01.2007 10:11 
Offline
Godfather of Hifidelio
Benutzeravatar

Registriert: 03.02.2005 12:45
Beiträge: 2040
Wohnort: Rheinhessen
Eigentlich hätte der automatische re-connect schon gehen müssen, dafür muss ich keine Header auswerten oder senden. Durch eine kleine Lücke in dem speziellen Fall ist der Hifidelio allerdings über sein eigenes Bein gestolpert. Habe das mal trocken gefixt. Da der Firefly bei mir nicht transcodiert, und ich deshalb den Fehler nicht habe, kann ich also auch den Fix nicht testen. Für Euch heißt das: abwarten bis zur 2.3.7...

_________________
Verallgemeinerungen sind generell schlecht.


Nach oben
 Profil  
 
 Betreff des Beitrags:
BeitragVerfasst: 20.01.2007 12:13 
Offline

Registriert: 13.04.2006 10:32
Beiträge: 12
Wohnort: Linz, Österreich
Habe jetzt die 2.3.8 PRO installiert - ist völlig dasgleiche: Der Fidel streamt 1 Titel vom Firefly und dann aus.


Nach oben
 Profil  
 
 Betreff des Beitrags:
BeitragVerfasst: 07.02.2007 21:58 
Offline

Registriert: 13.04.2006 10:32
Beiträge: 12
Wohnort: Linz, Österreich
gibts irgendwas neues?


Nach oben
 Profil  
 
BeitragVerfasst: 16.02.2007 20:57 
Offline

Registriert: 16.02.2007 20:50
Beiträge: 4
Wohnort: Speyer
Hi *,

hier ist ein Patch gegen mt-daapd svn-1498, der das Problem fixt. Es geht nich um den HTTP 1.1 Connection: close Header, sondern darum, das der Server den Socket zu macht.

--- plugin.c 2007-01-17 06:26:44.000000000 +0100
+++ /server/data/Matthias/Technik/prj/mt-daapd-svn-1498/src/plugin.c 2007-02-13 01:35:25.000000000 +0100
@@ -844,7 +844,7 @@
int item;
/* stream out the song */
- pwsc->close=1;
+ // FIXME-MS: pwsc->close=1;
item = atoi(id);
@@ -927,7 +927,7 @@
ws_addresponseheader(pwsc,"Content-Type","audio/%s",pmp3->type);
ws_addresponseheader(pwsc,"Content-Length","%ld",(long)file_len);
- ws_addresponseheader(pwsc,"Connection","Close");
+ // FIXME-MS: ws_addresponseheader(pwsc,"Connection","Close");
if(!offset)


Nach oben
 Profil  
 
 Betreff des Beitrags:
BeitragVerfasst: 20.02.2007 01:45 
Offline

Registriert: 13.04.2006 10:32
Beiträge: 12
Wohnort: Linz, Österreich
Wie kann der normale user das implementieren?


Nach oben
 Profil  
 
 Betreff des Beitrags:
BeitragVerfasst: 20.02.2007 21:56 
Offline

Registriert: 16.02.2007 20:50
Beiträge: 4
Wohnort: Speyer
Ja - eine wirklich sehr berechtigte Frage. Deswegen habe ich dem Maintainer des mt-daapd bereits zwei Mails geschrieben, mit der Bitte zur Integration. Ich habe aber keinerlei Antwort bekommen.

Für welche Plattform brauchst Du denn das gute Stueck?

cheers,

Matthias Schmidt


Nach oben
 Profil  
 
 Betreff des Beitrags:
BeitragVerfasst: 21.02.2007 00:04 
Offline

Registriert: 13.04.2006 10:32
Beiträge: 12
Wohnort: Linz, Österreich
Für Windows. (Dzt 1.0 svn-1498)
Vor dem Firefly habe ich iTunes als Server verwendet, ab iTunes 7 ists damit Essig. Firefly gefällt mir an sich sehr gut, weil er als Dienst läuft und auch die Überwachung der Bibliothek klappt sehr gut.
Interessant ist, daß dieses Unterbrechen des streamens nur beim Fidel auftritt, nicht jedoch wenn man mit iTunes (6 od 7) streamt.


Nach oben
 Profil  
 
Beiträge der letzten Zeit anzeigen:  Sortiere nach  
Ein neues Thema erstellen Auf das Thema antworten  [ 81 Beiträge ]  Gehe zu Seite Vorherige  1, 2, 3, 4, 5, 6  Nächste

Alle Zeiten sind UTC + 1 Stunde [ Sommerzeit ]


Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 2 Gäste


Du darfst keine neuen Themen in diesem Forum erstellen.
Du darfst keine Antworten zu Themen in diesem Forum erstellen.
Du darfst deine Beiträge in diesem Forum nicht ändern.
Du darfst deine Beiträge in diesem Forum nicht löschen.

Suche nach:
Gehe zu:  
cron
Powered by phpBB® Forum Software © phpBB Group
Deutsche Übersetzung durch phpBB.de