Beiträge von kodinerdskw

easy4me ffmpeg -version bringt command not found. Kann es etwas verbessern mit iptvsimpleclient, wenn ich ffmpeg installiere? Oder ist das nur für tvHeadend zum Aufzeichnen von Sendungen? Viele Grüße

"Mit dem IPTV simple client addon im Kodi und dort hinterlegst du die URL von Telerising."

Woti In dem IPTV simple client addon steht bei mir doch immer schon die URL von Telerising. Da verstehe ich den Unterschied nicht.

Zitat von easy4me

Keine Ahnung, ob es damit zu tun hat. Diese Version funktioniert bei mir ohne Buffering.

ffmpeg version 4.3.6-0+deb11u1+rpt1 Copyright (c) 2000-2023 the FFmpeg developers

built with gcc 10 (Debian 10.2.1-6)

Und easy4me: ffmpeg: Diese checkbox habe ich bisher nicht angekreuzt im telerisingAPI. Soll die das Streaming flüssiger machen. Hab ich nun mal probiert, checkbox markiert in der API-Oberfläche, save gedrückt und das Fernsehprogramm gestartet: keine Verbesserung des Ruckelns erkennbar. Wie kann ich sehen, ob und welche Version ffmpeg ich habe? Im telerising-Ordner scheint das nicht zu sein ..

rolapp  easy4me Nochmals danke schön für die Erklärungen, nicht dass ich sie bereits alle durchschaue.

Also für die telerisingAPI-Variante dann womöglich ein SmartDNS, um VPN Schwierigkeiten zu umgehen, oder irgendwie InputstreamAdaptive (das geht glaube ich auf dem alten Pi nicht).

Würde tvheadend evtl. etwas verbessern?

Einen schönen Abend noch ..

easy4me Ja, wie man auch oben in den scrots sehen kann, openvpn. Ist aber doch für telerising und zattoohiq dasselbe, weil derselbe RPi1B+.

Aber in https://de.wikipedia.org/wiki/HTTP-Streaming steht, wo rolapp doch dash und HLS7no erwähnt hat:

"Ähnlich Apples Lösung, dem HTTP Live Streaming (HLS), funktioniert MPEG-DASH, indem die Inhalte in eine Folge kleiner HTTP-basierter Datei-Segmente zerlegt werden, wobei jedes Segment einen kurzen Abschnitt der Gesamtspielzeit eines Medienobjektes von potenziell mehreren Stunden Dauer enthält, etwa eines Films oder der Live-Übertragung eines Sport-Ereignisses. Die Inhalte werden in einer Auswahl verschiedener Bitraten vorgehalten, also alternative, inhaltlich übereinstimmende Abschnitte, die mit unterschiedlichen Bitraten kodiert sind. Wenn Inhalte von einem MPEG-DASH-Client wiedergegeben werden, wählt dieser für den nächsten Abschnitt aus den angebotenen Alternativen automatisch die für die derzeitigen Verbindungsbedingungen passende aus. Der Client wählt das Segment mit der höchstmöglichen Bitrate aus, das in der verfügbaren Zeit bis zur Wiedergabe übertragen werden kann, ohne dass die Wiedergabe stockt und erst wieder gepuffert werden muss. Dadurch kann sich ein DASH-Client nahtlos an veränderliche Netzwerkbedingungen anpassen und hochwertige, flüssige Wiedergabe gewährleisten."

Kann es sein, daß ZattooHiQ mit Dash sich besser dynamisch anpasst als TelerisHLS7, währende TelerisHLS5 einfach weniger geliefert hat und somit in der Umgebung auch gut lief? Danke nochmals für Eure Geduld ..

rolapp  Publish3r Vielen Dank für Eure Antworten und auch für die Erläuterungen. Vieles ist mir nicht klar. Aber festhalten möchte ich:

1) RPi1B+ lief zuletzt in der Regel ruckelfrei als TelerisAPI-HLS5, der Pi war nicht das Problem. Läuft nun als TelerisAPI-HLS7 nur noch stark ruckelnd.

2) RPi1B+ lief und läuft mit ZattooHiQ ruckelfrei, der Pi war und ist so gesehen nicht das Problem.

Die Frage, die für mich bliebe, wäre:

Wie und was stelle ich am RPi1B+TelerisAPI ein oder um, damit das auch mit HLS7 wie vorher nicht mehr ruckelt?

Viele nette Grüße

.. und nun mal ein typisches Lastbild vom selben RPi1B+, während der jetzt gerade SRF stetig ruckelfrei streamt über ZattooHiQ (weil das mal den Login-Fehler überwunden hat). Max. 60%, der langsame RAM-Speicher scheint nicht zu stören:

rolapp Ich weiß, anderes Forum, aber ist ZattooHiQ, welches auf Python beruht und somit dem auf C aufgebauten TelerisingAPI-Weg von der Effizienz unterlegen wäre, auch intern mit HLS7? Oder puffert das irgendwie anders, wenn nicht besser ? ...

Zitat von Lehmden1

Ich hatte das nicht mal auf einem RasPi3B hin bekommen, weswegen ich mir nun ein Intel System mit einem Celeron N3350 dafür angeschafft habe. Der ist fast doppelt so stark wie ein RasPi4, ...

Zitat von Woti

... Nehme ich aber die Stream-URL direkt von Telerising, ist kein Buffern und kein verzögertes Laden zu bemerken.

Hab das auch noch mal mit Kodi probiert und da funzt es auch.

Nur hab ich keine Aufnahmemöglichkeit wenn ich direkt von Telerising streame. ...

Lehmden1 Ja, aber solange es ein Softwareproblem sein kann, neige ich weniger zu neuer Hardware. Z.B, auf dem RPi1B+ gerade, telerising umgestellt von HLS5 auf HLS7, dann bei laufendem SRF1 bzw. ruckelnd, 10 Sek. Bild, dann 10 Sek. Bild steht usw., brauchen Kodi und openvpn gerade mal gut 30% CPU:

Bei sauber gestreamten Bild war das mit Telerising auch kaum über 70% CPU.

Woti Wie probiere ich das denn mit Kodi, so daß es funzt, die Stream-URL direkt mit dem Raspi, bitte?

Zitat von easy4me

Update auf v0.10.7:

• HLS7 wird nun standardmäßig genutzt. Sämtliche Optionen für HLS5 wurden entfernt, da Zattoo den Zugang dafür deaktiviert hat

Zitat von Woti

Braucht man für HLS7 bestimmte Hardwarevorraussetzungen?

Muss einfach mal dumm fragen weil HLS5 läuft ruckelfrei und sobald ich auf HLS7 umstelle ist Kodi nur am Buffern. Egal welche Auflösung ich wähle.

Anscheinend geht die Zeit für den RPi1B+ mit TelerisingAPI durch den Fortfall von HLS5 dann zu Ende. HLS5 konnte der nämlich gut verarbeiten. Oder wie kann man TelerisingAPI-HLS7 runterregeln, so daß der kleine Pi das gut schaffen kann? Eigentlich war der ja nicht überfordert für normales Fernsehen ..

Natürlich würde ich eine neue Leia Version auch aufspielen und auf das Wiederauftreten des Loginfehlers achten und ob die Version funktioniert. Ansonsten gedulde ich mich aber auch. Viele Grüße

Zitat von rolapp

Zattoo setzt die Verbindung zurück, wenn ich das Problem in den aktuellen Kodi Versionen gelöst habe kümmere ich mich um Leia.

Guten Abend, nun möchte ich mal höflich nachfragen, ob die zwischenzeitlich entstandene

ZattooHiQ auch für Leia gedacht ist?

Ok. Und das mit den Favoriten stimmt: die 5 SRF-Einträge waren unter "Kanäle" mit Favoriten überschrieben.

Außerdem: beim wiederholten Aufruf von ZattooHiQ ist der Loginfehler nicht wieder hochgekommen, läuft derzeit wieder.

Und über den Aufrufweg "Vorschau" kann ich auch wieder die anderen vielen Sender, deutsche und ORF usw., anwählen.

Das mit dem "mal geht es, mal kommt der login-Fehler" hat also unter Leia ruhig noch Zeit.

Schönen Dank für die prompte Antwort, und schönen Abend noch ..

.. das mit den Favoriten kann ich noch nicht einschätzen, da wäre ich auch noch skeptisch.

Leider aber ist gerade wieder, nachdem ich den RPi1B+ gestartet habe, der ZatooHiQ-login-Fehler aufgetaucht,

schade eigentlich. Die kodi.[definition='1','0']log[/definition] habe ich gleich wieder angehängt ...

Zitat von rolapp

lösche mal im Userverzeichnis alle Dateien mit .cache und die zattoo.db Die Datenbank muss auf jeden Fall neu erstellt werden.

rolapp Ja, das hilft, die Dateien mit .cache und die zattoo.db nach backup.

Dann ZattooHiQ starten, und ein paar Minuten warten auf den RPi1B+, dann sehen, wie nicht mehr der ZattooFehler kommt, sondern wie der das Programm von Donnerstag lädt. Prima.

Allerdings gibt es danach in ZattooHiQ nur noch die 5 SRF-Programme zur Auswahl. Das waren früher mal Dutzende, auch Deutsche, glaube ich. Die automatisch neu angelegte zattoo.db ist mit 4MB auch viel kleiner als die gesicherte mit ca. 22MB.

Die 5 laufen aber in gewohnt sehr guter Qualität.

Ein echter Fortschritt also und ein Grund zur ..

Zitat von rolapp

kodinerdskw wie lange hast du das Addon nicht benutzt?

lösche mal im Userverzeichnis alle Dateien mit .cache und die zattoo.db Die Datenbank muss auf jeden Fall neu erstellt werden.

rolapp Das Addon habe ich vllt. 2 Wochen nicht genutzt, den RPi1B+ aber in der Zeit mehrfach genutzt, rauf und runtergefahren.

Z.B. letzten Samstag noch F1 Qualifying per TelerisingAPI geschaut.

Besten Dank für Deinen Rat, kann ich frühestens heute abend machen ..

Zitat von rolapp

Muenster. habe die ganze Sache überarbeitet, bitte mal die leia Version testen.

Matrix und Nexus veröffentliche ich gleich.

Guten Abend an die Nerds, auch bei mir gab es mit ZattooHiQ das Login-Problem. Auch nach dem Update auf die neue Version ist das leider noch da. Das Update habe ich sowohl über die Aktualisierungsfunktion des Kodi durchgeführt als auch auf dem ZIP-Einspiel-Weg.

Mein Konfiguration, zur Erinnerung:

Rasberry Pi 1B+ 1Prozessor ARM11 32Bit 512MB RAM, Cat5-Kabel-Ethernet

Kodi: OSMC_TGT_rbp1_20201227.img = Kodi Leia (18.9). Platform: Linux ARM 32-bit = debian_version 10.9

Das wäre dann ja leia und müsste gehen. Die Logdateien sind anbei.

Der andere Test von gerade, SRF über das TelerisingAPI, Raspi über openvpn in CH, funktioniert.

Bestimmt habe ich wieder eine blöde Kleinigkeit übersehen ...

Zitat von kodinerdskw

@Publish3r: Besten Dank für den Ansatz. Mit der Neuinstallation von telerising0.9.7 von neulich dürfte ich ja nah dran sein. Zudem habe ich die settings.json wieder beschreibbar gemacht und auch vom webinterface aus die hls5 und 432p25 mit SAVE sichern können (uuid wird in die settings.json geschrieben, siehe 2.717, mit der Vorversion scheint's nicht). Damit bin ich nun im Probebetrieb ... Irgendwas falsch: ich glaub, die anderen 100 haben einfach mehr Power, aber solange ich ganze Stunden problemlos fernsehen kann, möchte ich am RPi1B+ noch festhalten ..

Publish3r  easy4me

Zugegeben hat mein Probebetrieb mit dem RPi1B+ mit TelerisingAPI (auch mit ZattooHiQ) eine Weile gedauert.

Nundenn, was wurde herausgefunden?:

Der RPi1B+ reicht gut aus, um unterbrechungsfrei fernzusehen. Das gilt sowohl für TelerisingAPI

als auch für ZattooHiQ.

Allerdings dürfte mein VPN (ein Billigangebot zum Testen) die Ursache dafür sein, daß bei Sendungen, die alle

gleichzeitig sehen wollen wie z.B. F1, der RPi1B+ Schluckauf bekommt. Denn man kann über TelerisingAPI die weniger

gesuchten Sendungen so stundenlang ruckelfrei schauen. Der RPi1B+ zusammen mit TelerisingAPI und OpenVPN ist

bei solchen Sendungen nicht überlastet.

Ein Test ohne OpenVPN mit TelerisingAPI mit F1 ging schief, die Verbindung wurde nicht aufgebaut (vielleicht war die

verwendete IP beim DNS bereits geblockt). Weitere Versuche habe ich dann nicht gewagt.

Ein weiterer Test ohne OpenVPN mit ZattooHiQ hat der RPi1B+ tadellos und mit schöner Auflösung, ohne einmal zu

zuckeln, absolviert. Der Test war F1 am Sonntagabend, Miami ..

Zitat von Publish3r

Du solltest am Filesystem am besten gar nichts ändern. Weder an der Schreibberechtigung, noch am CHMOD oder sonst irgendwas.Einfach richtig installien bzw. entpacken und dann alles so belassen, wie es ist.
Kann ja nicht sein, dass du der einzige von, lass mich lügen, weit über 100+ Usern bist, bei dem es nicht funktioniert. Also mußt du ja irgendwas falsch machen.
Ich würde vorschlagen, du beendest alle API Prozesse, löscht Telerising komplett und setzt es dann nochmal neu auf. Ohne irgendwas zu verändern und am besten auch ohne dein Backup von der settings.json.
Komplett bei 0 anfangen.

@Publish3r: Besten Dank für den Ansatz. Mit der Neuinstallation von telerising0.9.7 von neulich dürfte ich ja nah dran sein. Zudem habe ich die settings.json wieder beschreibbar gemacht und auch vom webinterface aus die hls5 und 432p25 mit SAVE sichern können (uuid wird in die settings.json geschrieben, siehe 2.717, mit der Vorversion scheint's nicht). Damit bin ich nun im Probebetrieb ... Irgendwas falsch: ich glaub, die anderen 100 haben einfach mehr Power, aber solange ich ganze Stunden problemlos fernsehen kann, möchte ich am RPi1B+ noch festhalten ..

@Publish3r siehe 2.714 Also, um nicht gleichzeitig an zwei Stellschrauben zu drehen, hatte ich die settings.json ja gegen Überschreiben gesichert, siehe 2.699

Und um nun auch vorwärts zu gehen:
"Du solltest es am besten erstmal seinlassen im Webinterface UND in der settings.json gleichzeitig rumzudoktern.
Denn: Alles, was du im Webinterface einstellst, wird automatisch in die
settings.json geschrieben. Und auch direkt übernommen. (Nach Klick auf
Save Settings)"

Das oben scheint das Problem zu sein. Die Auflösung wird nämlich scheint's NICHT übernommen. Um das zu testen, habe ich die settings.json im Filesystem wieder beschreibbar gemacht. Dann webinterface gestartet, dort stehen 1080p50, für den kleinen RPi zu viel. Also im webinterface auf 432p25 gestellt, update für die session UND SAVE für die settings.json gedrückt, und:

cat settings.json
{"accounts": {"tby": {"login": "xxxx", "pw":
"xxxx", "no_auth": false, "manifest_type": "hls5", "bw": "1500",
"audio1": "aac1", "audio2": "none", "chnum_start": "1", "server":
"auto", "api_code": "", "yp_code": ""}}, "basic": {"password":
"xxxx", "uuid":
"6da41b6b-000b-480e-9d56-408896def61f"}}teleris@osmc:~/telerising$

Während z.B. durch das SAVE bw=1500 übernommen wurde, findet sich stets in der settings.json keine Auflösung. Die wird dort gar nicht durch SAVE gespeichert, würde ich nun sagen ...

Zitat von kodinerdskw

Hallo in die Runde,im oben genannten Kontext glaube ich zu beobachten, daß, egal was für telerisingAPI in der settings.json steht, z.B. Auflösung 432p25, telerisingAPI diese Einstellungen gelegentlich ignoriert und auf 1080/50 geht. Für die meisten Anwendungen ist das bestimmt prima, aber für den kleinen RPi1B+ nicht, der kriegt dann Schluckauf.
Wenn ich dann per Browser auf die laufende telerisingAPI-Session gehe, sehe ich dort jedenfalls 1080/50, trotz der 432p25 in settings.json.
Wenn ich dann per Browser wieder die 432p25 setze in telerisingAPI und die session update, scheint es wieder besser zu laufen.
Liege ich falsch? Und falls nein, wie könnte ich das scheinbar selbstständige Springen auf 1080/50 vermeiden?

Zitat von Publish3r

Zitat von easy4me

Kann man im Webinterface einstellen.

@Publish3r @easy4me: danke für die Anmerkungen
Bei meinen Einstellversuchen arbeite ich mit settings.json UND mit dem Webinterface, im Webinterface setze ich auch, wenn der RPi1B+ bei 1080p50 ruckelt, wieder auf 435p25 und update, dann geht's scheint's wieder besser.
FALSCH habe ich oben beschrieben, hab ich gerade erst gefunden, daß in der settings.json 432p25 gesetzt sind, dort steht nämlich gar nix über Auflösung drin. HLS5 z.B. steht drin. bw auch. Das erklärt dann vllt. auch, warum beim Fernsehen es so aussieht, als ob Kodi willkürlich die Auflösung auf 1080/50 setzt und ich dann im Webinterface mit update auf 432p25 korrigieren muß.

Wenn das so ist, lautet die Frage: kann ich in der settings.json überhaupt von Anfang an die Auflösung setzen und wie? Einfach reineditieren? Die Auflösung scheint in der settings.json anfangs nicht drin zu sein?

Eine sehr schnelle Antwort - vielen Dank. Das Webinterface ist ja der Browser des telerisingAPI. Dort finde ich allenfalls "API Protection Code", das wird es wohl nicht sein. Oder brauche ich eine Subscription? Die settings.json hatte ich bereits auf readonly gesetzt, vom unix-Filesystem her, vllt. ist das ja falsch ..