Hallo Georg,
vielen Dank für die Tips. Habe gerade beides ausprobiert.
Leider wird der gleich Fehler ausgegeben (vgl. Screenshot im Anhang)
Gruß
Kai
Nachtrag: Habe nun als Benutzername meine E-Mailadresse gewählt. Sie beginnt ja nicht mit einem "-", sodass der Anmeldeversuch mit o.g. Befehl sofort funktionierte.
Quoteroot@volumio:~# sudo /root/spotify-connect-web.sh --name Volumio --username -bindestrichvorundnachdemusername- --password whatever --bitrate 320
usage: main.py [-h] [--device DEVICE] [--mixer MIXER] [--debug] [--key KEY]
[--username USERNAME] [--password PASSWORD] [--name NAME]
[--bitrate {90,160,320}] [--credentials CREDENTIALS]
main.py: error: argument --username/-u: expected one argument
Hallo,
ich habe offenbar Pech mit meinem Benutzernamen bei Spotify. Mein Benutzername hat sowohl am Anfang und am Ende einen Bindestrich. Daher bekomme ich die Fehlermeldung (main.py: error: argument --username/-u: expected one argument) ausgeworfen.
Jemand eine Idee?
VG
Kai
Hallo, ich erhalte nach dem ersten Login als Administrator in OC dieselben Meldungen wie informathe.
Wäre auch an Hinweisen hierzu interessiert.
Danke und Grüße
Kai
Hallo,
ich bin auf folgende Webiste aufmerksam geworden: http://myxbmc.bplaced.net/blog/?p=1339
Diese Version scheint ja einige Performance-Sprünge mitzubringen.
Nun stelle ich mir gerade, ob ich den derzeitigen Daten- und Einstellungsstand meiner aktuellen OpenElec Version zu dieser modifizierten OpenElec Alpha Build Version übertragen kann.
Hat jemand einen Plan, wie ich vorgehen müsste, um mit der Alpha Build Version nicht wieder bei "Null" anfangen zu müssen?
Ich habe meine derzeitge Version nicht auf einem USB-Stick installiert und wollte diesen Schritt auch bei der Alpha Build nicht umsetzen.
Für Hilfe wäre ich sehr dankbar. Anmerken möchte ich, dass ich ein gewöhnlicher Windows-User bin, ohne einschlägiges Linux Know-How 
Vielen Dank und Grüße,
Kailly
Hallo,
ich war auf der Suche nach einer umkomplizierten Backup-Lösung, um hin und wieder ein vollständiges Backup meines Openelecs (inkl. sämtlicher Datenbanken, Einstellungen, etc.) vorzunehmen. Mittlerweile wäre es schon mit einem gewissen Zeitaufwand verbunden, alles wieder so herzurichten, wie es derzeit ist.
Da ich nicht besonders linuxaffin bin und die Implementierung eines automatischen Backup-Scripts (wie in diesem Forum über die Suche auffindbar), über meine Fähigkeiten hinausgehen, habe ich via Google den Vorschlag gefunden, einfach ein Backup-Image mit der "Win32 Disk Imager" zu erstellen.
Dazu habe ich einfach die Karte mit einem Kartenleser an meinem Windows-PC angeschlossen und das Backup erstellt. Das ist in der Tat sehr einfach. Das Backup lege ich anschließend auf meiner NAS ab.
Gibt es hierzu bereits Nutzer-Erfahrungen? Sollte das Rückspielen das Backups entsprechend einfach und problemlos sein?
Daneben bin ich auf das Add-On "XBMC Backup" gestoßen. Wäre dieses Add-On eine gute Alternative zu meiner oben beschriebenen Vorgehensweise? Oder ist es noch nicht ganz ausgereift oder enthält es noch Bugs, die den sicheren Einsatz dieser Backup-Lösung in Frage stellen könnten?
Die Lösungen verfolgen ja relativ unterschiedliche Ansatzpunkte. Daher bin ich mir unsicher, welche der Varianten besser für meine (simplen) Backup-Wünsche geeignet ist.
Vielen Dank für Eure Rückmeldungen,
Kailly
Dieses hier vorgeschlagene "Entschleunigen" habe ich bereits ausprobiert, aber es hat zu keinem positiven Ergebnis geführt.
Spiele mal eine film über das Netzwerk ab und benutze dabei einen anderen switch. Zumindest nicht die fritzbox.
Falls das funktioniert, kennst du deinen Übeltäter.
Pass-Through bedeutet, dass z.B. der DTS-Ton nicht vom RPi decodiert wird, sondern dies erst im Endgerät (z.B. dem Onkyo) geschieht.
Sobald ich die o.g. Optionen "unterstützt DTS" u. "unterstützt AC3" in Openelec aktiviert habe, werden die Tonspuren offenbar von meinem Onkyo decodiert und auch sauber wiedergegeben. Der Onkyo zeigt bei mir im Display auch die entsprechende Tonspur an (entweder "DTS" oder "DolbyDigital").
Nehme ich im RPi die beiden Häkchen jedoch raus, erkennt der Onkyo das eingehende Ton-Signal schon nicht mehr. Im Display des Onkyos gibt es dann keine der o.g. Anzeigen.
Das heißt also weiter, dass bei aktiviertem "unterstützt DTS" u. "unterstützt AC3" automatisch ein Pass-Through der nicht-decodierten Tonspur stattfindet. Das ergibt sich für mich auch aus der Erläuterung hier: http://wiki.xbmc.org/index.php…tings/System#Audio_output.
Vielmehr stellt sich mir die Frage, weshalb es in anderen XBMC-Versionen extra noch ein Auswahlfeld für das "Passthrough-Output-Device" gibt. Das würde ja nur Sinn machen, wenn man parallel mehrere unterschiedliche Geräte per HDMI mit XBMC verbunden hat.
Am RPi kann zu selben Zeit jedoch immer nur ein HDMI-Gerät angeschlossen werden.
Gruß,
Kailly
darf man erfahren wie du das realisiert hast... die option für Pass-Through finde ich in der Openelec Version nicht
die Netzwerkproblematik die du beschreibst kann ich nicht nachvollziehen.. ich spiele 3D Filme in 1080p und DTS ab ohne Probleme im 1Gb Netz..
In den Audio-Einstellungen die Häkchen bei
- "Receiver unterstützt DTS" und
- "Receiver unterstützt AC3" setzen.
Zu der Netzproblematik:
Ich nehme an, dass du keine Fritzbox in Betrieb hast, sondern einen anderen Router und/oder Switch, der besser mit dem RPi die zu verwendende Bandbreite abstimmen kann.
Meine Message oben war nicht, dass GBit-LANs ungeeignet sind, sondern dass in meinem Fall meine Netzwerk-Hardware (Fritzbox, Switch) nicht sauber die zu verwendende Bandbreite mit dem RPi abstimmen konnten.
Jedes Gerät in einem Netzwerk teilt den anderen Geräten eigentlich mit, welche Bandbreite es nutzen. Und genau hier lag der Hund bei mir - und wahrscheinlich vielen anderen auch - begraben.
Die meisten suchen das Problem nämlich im verwendeten Betriebssystem oder im RPi selbst und nicht in der physischen LAN-Verbindung.
Ich hoffe, dass ich das hierdurch noch mal etwas verständlicher machen konnte.
Gruß,
Kailly
Bin gespannt, wie dein Test verläuft.
Evtl. kann man ja auch eine Testumgebung schaffen, in der man ausschließlich einen 100Mbit-Switch verwendet, an dem sowohl der RPi als auch das NAS/Server/PC (Medien-Quelle) hängen.
Gruß,
Kailly
Möglicherweise hilft euch eine Problemlösung weiter, die mir in einer ähnlichen Problemlage geholfen hat:
http://www.forum-raspberrypi.d…ateien?pid=28395#pid28395
Bei mir musste ich einfach das komplette Netzwerk auf 100MBit drosseln (vorher 1GBit), damit das Nachladen endlich ein Ende hatte.
Hallo,
hier ein Vorschlag, der zumindest in meinem Fall zum Erfolg geführt hat:
Problem/Rahmenbedingungen:
Ich habe seit kurzem auch einen RPi und hatte ebenfalls das Problem mit dem ständigen buffern (1080p, mkv-container, h.264 codec)
Da ich es mir nicht erklären konnte, habe ich sehr viel gelesen und Unterschiedliches probiert:
- alternatives OS (Openelec, Raspbmc)
- Übertakten (mitsamt dem Einbau von Kühlkörpern)
Beides führte nicht zum Erfolg.
Mein RPI ist per HDMI mit einem Onkyo TX SR 876 verbunden. Das Gerät ist in der Lage DTS und AC3 per Pass-Through vom RPi zu erhalten, ohne dass der RPi sich hierfür mit eigener CPU-Leistung krumm machen müsste (und damit wertvolle Ressourcen, die er für das reibungslose Streamen benötig, verschwendet).
Die Hinweise in einem Forum, man solle sich die Codecs kaufen, halte ich für Quatsch, da nämlich h.264 gerade vom Raspberry unterstützt wird. Das konnten auch durch andere User verifiziert werden, die sich die Codecs gekauft haben und weiterhin "Stutter"-Probleme bei 1080p-Material hatten.
Nun lass ich weiterhin, dass manche User bei einer Kabel-Lan-Verbindung absolut keine Schwierigkeiten hatten und andere wiederum Abhilfe durch die Verwendung eines WLan-Sticks erzielen konnten. Die meisten der aktuellen Wlan-Sticks schaffen die 150MBit (oder gar mehr), mithin also mehr als das 100Mbit-Kabel-Lan.
Das der Lan-Port im RPi wohl an einen insgeamt relativ langsamen USB-Host gekoppelt ist (so hab ich es zumindest beim Lesen verstanden), existiert also sowohl für die Lan-Verbindung über Kabel als auch Wireless derselbe Flaschenhals.
Es leuchtete mir aufgrund dessen also überhaupt nicht ein, dass der vermeintlich schnellere WLan-Dongle ein besseres Ergebnis in der Bandbreite und damit beim Streaming erzielen sollte, da er seine Daten durch denselben Flaschenhals wie auch das Kabel schiebt.
Nun habe ich angefangen, den Fehler bzw. die Lösung des Problems in meinem Netzwerk zu suchen.
Mein Netzwerk ist wie folgt aufgebaut:
1. Fritzbox 7390 (1.000er LAN):
- Port 1: Raspberry (100er LAN)
- Port 2: weiterer D-Link-Switch (siehe unten)
2. Weiterer D-Link Switch (1.000er Lan)
- Port 1: PC (1.000er LAN)
- Port 2: Windows Home Server (100er LAN) (Samba-Freigabe)
Die Geräte sind jeweils über Cat5e-Kabel verbunden. Alles in allem also eine Infrastruktur, die grundsätzlich dazu geeignet ist, dass die Medien in 1080p ganz entspannt vom Homeserver zum RPi gestreamt werden müssten (wenn auch der Homeserver in diesem Fall auch nur mit einem 100er LAN ausgesattet ist), ohne dass es zu Aussetzern kommt.
"Beschneidung des Netzwerks":
Wer selbst eine Fritzbox 7390 in Gebrauch hat, weiß, dass man in den Netzwerkeinstellungen für jeden Port auswählen kann, ob er mit 1GBit oder 100Mbit (energy saver) betrieben werden soll.
Aus irgendeinem unerfindlichen Grund habe ich alle Ports von 1 Gbit auf 100Mbit umgestellt. Anschließend den Raspberry neugestartet und wieder eine Test-File abgespielt.
Wie durch ein Wunder hatte ich von jetzt auf gleich keinen Aussetzer mehr. Auch die Debugging-Anzeige, die ich während des Abspielens dazuschaltete, zeigte, dass der Puffer nun immer konstant hoch blieb und nur in Ausnahmefällen mal kurzzeitig auf 80% fiel, aber dann sehr schnell wieder hoch auf 90+.
Anschließend habe ich noch ein paar mal hin- und hergewechselt zwischen (1Gbit und 100Mbit auf allen Ports), um dieses Ergebnis zu verifizieren. Nach jedem Umstellen im Router war es immer nötig den RPi neuzustarten. Ich hatte es nun in der Hand den RPi bei der Wiedergabe zum "Stutter" zu bringen (Fritzbox auf 1Gbit auf allen Ports) bzw. die Wiedergabe flüssig und ohne jeden Aussetzer zu gestalten (Fritzbox auf 100 Mbit auf allen Ports). Es handelt sich also um keinen Zufall. Das Ergebnis ist bei mir absolut rekonstruierbar.
Anschließend bin ich noch dazuübergegangen wahlweise nur Port 1 (RPi) auf 100Mbit und Port 2 (D-Link-Switch) auf 1GBit zu stellen. Das Ergebnis war, dass der Puffer nun wieder abbaute, aber sehr viel langsamer als sonst als die Fritzbox insgesamt auf allen Ports auf 1GBit lief.
Lösung:
Kurzum lautet die Lösung für ruckelfreies/stutterfreies Streamen: Entschleunigen der für das Streamen verwendeten Netzwerkverbindungen von 1 GBit auf 100Mbit.
Dieses Ergebnis hätte ich (kein Informatiker) nie erwartet.
Fazit:
Das Ergebnis passt auch gut zu den widersprüchlichen Angaben, die man sonst in Foren liest. Die User haben bei ihren Äußerungen ("Bei mir läuft alles wunderbar über das LAN-Kabel" oder "Bei mir ruckelt es nur über LAN-Kabel") nie dazugesagt, welche LAN-Verbindung sie nutzen. Offenbar sind all diejenigen User benachteiligt, die eigentlich ein schnelleres LAN daheim installiert haben, damit nichts dem FULL-HD-Streaming im Wege steht *welch Ironie*.
Dass mit den WLan-Dongles offenbar auch unproblematisch gestreamt werden kann, hängt möglicherweise mit der Wandlung der elektrischen Signale in Funksignale zusammen?! Das muss kann uns ja dann mal ein Fachmann näher erläutern.
Ich hoffe, dass diese Erkenntnisse künftig auch anderen Nutzern von Hilfe sind, die wie ich absolut keine Erklärung für die Bild-Ruckler bei der Wiedergabe von 1080p-Material hatten.
Gruß,
Kailly
