Beiträge von maluhi

  • NetworkBrowser Automount erzwingt udp

    Es ist nicht möglich ein NFS-Share über den Automount des Network-Browsers als tcp zu mounten. Trägt man nämlich als mount option "tcp" ein, fügt AutoMount.py wieder ein udp hinzu. In der fstab stehen dann sowohl tcp als auch udp.


    Da ist nämlich ein "not" zuviel in sanitizeOptions():

    Code
    if not 'tcp' not in options and 'udp' not in options:
    options.append('udp')

    Habe ich bei mir lokal behoben, bitte auch bei Gelegenheit auf dem Feed übernehmen.

  • Cache für Videowiedergabe

    Zwischenstand: Ich kann kleinere Filme jetzt ruckelfrei abspielen - bei etwas größeren, habe ich noch Probleme. Aber keine Zeit mehr heute das weiter zu testen und die Grenze zu testen. Mache ich morgen oder übermorgen.
    Danke jedenfalls schonmal - das hilft etwas :smiling_face:

  • kein HD / IPTV Streaming bei meiner MD920

    Weil es dann anscheinend egal ist, ob die anderen auch encoded sind oder nicht. Und es so einfacher war per copy/paste einfach alles in den encoder zu packen. Und es für mich richtiger aussieht, weil ein ein Slash normalerweise ein neues Verzeichnis angibt... Wichtig ist aber hauptsächlich, dass zweimal(!!) encodiert wurde.


    Habe ich vorhin sogar extra getestet - und ein Link, den VLC bei mir ohne Probleme abspielt: http://192.168.4.99:8001/1:0:1…A0%253A0%253A0%253A%0D%0A


    Da greift VLC auf meine Client-Box zu, die sich den eigentlichen Stream von 10.8.0.1:8001 holt (meiner Server-Box)... Und das funktioniert. Auf seinen Link übertragen, müsste der so aussehen, wie ich oben geschrieben habe.

  • kein HD / IPTV Streaming bei meiner MD920

    Du streamst nicht per rtsp (port 554), sondern ohne transkodierung auf Port 8001. daher sind die Transcoding-Optionen irrelevant. Das ist aber im lokalen Netz völlig ok so.
    Da ich keine IPTV-Streams von meiner Serverbox weiter streame (wozu auch), knn ich Dir nicht sagen, ob es normalerweise funktionieren müsste. HD Kanäle müssten aber problemlos gestreamed werden können. Hab ich sowohl über rtsp als auch ohne laufen.
    Geh doch mal per telnet oder ssh auf die Box, führe "journalctl -f" aus und starte dann in VLC den Stream. Entweder erkennst Du da schon selbst den Fehler, oder postest das Log hier.


    Edit: Der IPTV Link ist aber definitiv falsch, weil z.B. die Slashes nicht richtig encoded sind. Aber wir sollten erstmal den HD-Fehler finden, bevor Du Dich an IPTV versuchst.

  • Cache für Videowiedergabe

    Ich kann übeigens den Kopiervorgang einer 2,5 GB großen .mkv (x264) mit "cp" starten und nur 1 Sek später die Wiedergabe der noch unvollständigen Datei starten und dann ohne Ruckler schauen. Leider ohne Ton (liegt wohl daran, dass zum Zeitpunkt des startens der Audiostream noch nicht korrekt gelesen werden konnte). Aber das zeigt ja, dass es nicht an der Bandbreite hapert oder die Box irgendwie überlastet ist, sondern der MoviePlayer lediglich nicht rechtzeitig genug (für eine remote Wiedergabe) die Daten liest und ein (größerer) Cache helfen würde. Da ruckelt es nämlich schon bei 600MB großen Filmen mit niedriger bitrate.

  • Cache für Videowiedergabe

    > Habe ich das richtig verstanden?
    > Deine Box nutzt eine VPN Verbindung zum Server, d.h. der Server ist nicht im lokalen Heimnetz?


    > Wie baust Du die VPN Verbindung auf?
    >Welche Geräte sind da im Spiel?


    > Hast Du mal gemessen, welche Datenrate grundsätzlich durch deine VPN Verbindung geht?


    Die Box baut eine VPN-Verbindung zum Server auf. Ist OpenVPN. Keine Compression und kein Cipher. Ergo nur Zertifikatbasierter Login - danach keine Encryption mehr (ist mir aber auch egal, da über dieses VPN lediglich eine NFS-Freigabe des Film-Ordners besteht und das mein Provider ruhig mitlesen darf).


    Die VPN-Verbindung nutzt mssfix, NFS wird per tcp gemountet und MTU-Pathdiscovery funktioniert (mit tcpdump überprüft). Daher gibt es auch keine Beeinträchtigung durch unnötige Fragments.


    Klar habe ich gemessen, wieviel durch die VPN-Verbindung geht. Ich habe das auch alles nur so ausführlich geschrieben, damit deutlich wird, dass es nicht an der VPN-Verbindung oder dem mount liegt. Ich habe über besagte Konstellation das Movie-Dir gemountet. Und dann per rsync --progress /mnt/file /local/file die Übertragungsrate gemessen und bin auf 1MB/s (=8Mbit/s) gekommen. Das ist SUPER für eine Leitung mit 10Mbit Upstream, da ja von der Bruttobandbreite noch Overhead für VPN und NFS abgeht.


    Wieviel Bitrate meine Filme haben spielt keine Rolle (soll heißen es ruckelt sowohl bei niedrigen als auch bei hohen Bitraten). Dass die Bitrate unter der zur Verfügung Stehenden Nettobandbreite liegen muss, ist natürlich klar. Aber selbst wenn nur 20% der Bandbreite genutzt wird, ruckelt es immer wieder. Es wird einfach zu lange gewartet, bis neue Daten gelesen werden. Dann sind die natürlich nicht schnell genug aufgrund von Latenz und Übertragungsgeschwindigkeit. Würden die Daten vorher gecached (auch wenn es nur ein relativ kleiner Cache wäre), hätte man das Problem nicht, denke ich.


    Wie gesagt passiert das auch bei Filmen, die ich in 15 Minuten vom Server zum Client kopieren kann (natürlich über VPN und NFS). Wird allerdings direkt von dort der Film gestartet, ruckelt es, obwohl zum Lesen der Daten nicht nur 15 Minuten sondern eine Vielzahl davon zur Verfügung stehen würden (zur Verfügung steht ja die gesamte Laufzeit des Films, also 90 Minuten oder mehr).

  • Cache für Videowiedergabe

    Hallo,


    ist es möglich den Cache bei Videowiedergabe zu vergrößern?


    Hintergrund ist, dass ich gerne meine Filmsammlung mounten möchte. Das funktioniert im Heimnetz super, über das Internet allerdings nur mit Rucklern. Grund hierfür ist aber nicht etwa zuwenig Upstream, sondern meiner Meinung nach ein zu geringer Cache.


    Ich habe auf auf meiner Server-Box 10 Mbit/s Upstream und viel mit verschiedenen Protokollen und Parametern experimentiert. Die beste Möglichkeit, die ich gefunden habe war ein zweites VPN aufzusetzen, das die eigentlichen Daten (nach der auth) nicht verschlüsselt und dieses nur dafür zu benutzen, den Film-Ordner per NFS zu mounten. Damit habe ich eine Übertragungsrate beim Kopieren von Dateien von fast 1 MB/s.


    Allerdings ruckeln ALLE Filme. Auch solche, die nur einige hundert MB groß sind. Diese kann ich innerhalb von rund 15 Minuten vom Server auf den Client kopieren. Spielt man sie allerdings direkt vom Mount ab, ruckeln die Filme. Da die Spielzeit 90 Minuten und mehr beträgt, ist auch laut Router der Upstream nur zu einem Bruchteil ausgelastet.


    Im Umkehrschluss ist also meiner Meinung nach das Problem, dass zu wenig Daten in den Cache geladen werden und somit viel zu spät (für einen entfernten Mount) die Daten gelesen werden, die als nächstes abgespielt werden müssen. Würden diese bereits etwas früher gelesen, bevor sie gebraucht werden, hätte man keine Ruckler.


    Toll wäre daher eine Config-Option, mit der man die Größe des entsprechenden Caches frei konfigurieren kann.


    Danke :smiling_face:

  • Partnerbox Remote-Timer encoded sref nicht überall

    Das kann ich leider grad schlecht testen, sieht aber vom Code her so aus, als wenn es funktioniert :smiling_face:


    Und da Du das bei Dir getestet hast, wird es bei mir auch sicher funktionieren. Wenn das bei Gelegenheit so ins git und somit auf den feeds übernommen wird, bin ich glücklich. Dann muss ich das nicht nach jedem Update selbst patchen. :grinning_squinting_face:


    Danke!

  • Partnerbox Remote-Timer encoded sref nicht überall

    Genau, ich habe mir die Bouquets der Serverbox mit Hilfe des Partnerbox-Plugins auf der Client-Box eingerichtet und dann manuell die http-Url gegen die rtsp-Url ausgetauscht.


    Mehr habe ich nicht gemacht und möchte auch keine exotischen Funktionen nutzen oder irgendetwas zurücklegen, sondern lediglich die ganz normalen Remote-Timer nutzen. D.h. einfach vor der Client-Box sitzen und einen neuen Timer, der bisher nirgends hinterlegt war, erstellen. Aufnehmen soll diesen dann die Server-Box.


    Dabei entsteht dann das Problem, dass getServiceRef die sref nicht korrekt abschneidet, weil nur nach "http", aber nicht nach "rtsp" gesucht wird.


    Was das mit dem Live-Flag zu tun hat, verstehe ich ehrlich gesagt nicht. Ich möchte einfach nur, dass ein Timer für meine rtsp-Kanäle auf die gleiche Weise angelegt werden kann wie man das für normale Partnerbox-Kanäle machen könnte. Da werden ja auch nur die ersten 10 "Felder" der sref übertragen.


    Für die Verwirrung dadurch, dass ich von fehlerhaftem Encoding gesprochen habe, entschuldige ich mich :smiling_face: - Ich hatte schlicht den Fehler falsch interpretiert und nicht auf dem Schirm, dass die sref normalerweise abgeschnitten wird.


    Falls weitere Verwirrung entstand, weil ich die Rückgabe von timerlist hier gepostet habe: Nochmals sorry :smiling_face: - Die werte ich nicht aus, sondern habe sie nur mit tcpdump mitgeschnitten. Ich wollte damit einfach nur zeigen, was für ein Fehler entsteht, wenn die sref nicht nach dem 10. Feld, sondern erst nach dem 11. Feld (was dre's Code anscheinend so gemacht hat) abgeschnitten wird. Anscheinend wird nämlich dann das Feld, das bei 12stelliger sref die Url enthält, als Sendername interpretiert. Meine Schlussfolgerung ist: Einfach die sref immer und überall nach dem 10. Feld abschneiden. Genau das macht der Patch, den ich heute gepostet hatte. Und Partnerbox-Kanäle mit http-Url werden mit dem Code weiterhin an genau der gleichen Stelle abgeschnitten wie vorher. Es ändert si h somit nichts an der Funktionalität, außer dass damit dann auch andere Url-Typen untersützt werden.

  • Partnerbox Remote-Timer encoded sref nicht überall

    Hmm. Meine Links sind aber doch bis auf die folgenen zwei Unterschiede gleich:
    1) rtsp:// statt http://
    2) :554/stream?ref= statt :8001/


    Eigentlich ist es aber doch total egal wie die Links aussehen. Der Aufbau der ServiceRef ist soweit ich weiss immer gleich. Sie ist in 10 bis 12 Teile unterteilt, die durch : getrennt sind. Die ersten 10 Teile geben die "ID" des Kanals an. Der 11. Teil die URL (optional) und der 12. Teil den Namen (optional).


    Daher hat mein Code einfach die gesamte sref bis zum 10. : gesplittet. Mein Array hat also höchtens 11 Felder gehabt. Wenn das 11. Feld vorhanden war, hat es entweder "[url]:[name]" enthalten oder nur "[url]" bzw nur "[name]". Das wird dann auf "" gesetzt. Hätte man auch mit del löschen können, dann hätte aber nach dem join der Doppelpunkt am Ende gefehlt, der ansonsten auch bei normalen Sendern bei mir immer vorhanden war.


    Was mein split-Code einfach nur macht, ist alles nach dem 10. ":" abschneiden. Egal wie die Url aufgebau ist, egal ob da noch ein Name hinterherkommt und egal ob DMM irgendwann noch ein zusätzliches Feld einbaut und unterstützt. Ist das nicht genau das Verhalten, das eigentlich richtig ist?

  • Partnerbox Remote-Timer encoded sref nicht überall

    Habe ich jetzt mal getestet, mit folgendem Resultat:


    Code
    Feb 13 20:40:28 dm520 enigma2[193]: [Connector] - Running command  http://10.8.0.1:80/web/timeradd?sRef=1:256:19:88:E:85:C00000:0:0:0:rtsp%3a//XXXXX%XXXXX@XXXXX%3a554/stream?ref=1%3a0%3a19%3a88%3aE%3a85%3aC00000%3a0%3a0%3a0%3a&begin=1518550800&end=1518552000&name=Two%20and%20a%20Half%20Men&description=Feuchtfr%C3%B6hliche%20Weihnacht&dirname=/media/hdd/movie/&tags=None&eit=3380&justplay=0&afterevent=3&repeated=0


    Dadurch, dass jetzt kein Sendername mehr enthalten ist, wurde der Timer angelegt.


    Allerdings wird mir die Aufnahme nun in der Remote Timer Liste angezeigt, als wenn der Name des Senders "//XXXXX:XXXXX@XXXXX:544/stream?ref=1:0:...." ist.


    Es kommt nämlich von timerlist folgende Rückgabe:



    XML
    <?xml version="1.0" encoding="UTF-8"?>
<e2timerlist>
        <e2timer>
                <e2servicereference>1:256:19:88:E:85:C00000:0:0:0:rtsp://XXXXX%3aXXXXX@XXXXX%3a554/stream?ref=1%3a0%3a19%3a88%3aE%3a85%3aC00000%3a0%3a0%3a0%3a</e2servicereference>
                <e2servicename>//XXXXX:XXXXX@XXXXX:554/stream?ref=1:0:19:88:E:85:C00000:0:0:0:</e2servicename>
                <e2eit>3380</e2eit>
                <e2name>Two and a Half Men</e2name>
                <e2description>Feuchtfr..hliche Weihnacht</e2description>

  • dreamrtspserver hangup

    Danke!


    Allerdings wird jetzt zwar mein journal nicht mehr mit Meldungen vollgebombt, Bild gibt es leider trotzdem nicht.


    Hier das Log von dreamrtspserver:


    Dann trennt der Client (getestet mit dm520 als Client und VLC als Client) irgendwann die Verbindung, weil da nichts ordentliches vom Server gesendet wird.

  • dreamrtspserver hangup

    Dein Vorschlag mit der Pfadangabe in der Service-Ref funktioniert leider nur mit Aufnahmen (bzw. .ts Files). Sobald man versucht x264 oder xvid abzuspielen, funktioniert das nicht mehr:


    Mir ist klar, dass ihr am alten rtspserver nichts mehr macht. Wäre aber super, wenn ihr das in den neuen rtsp direkt mit einbaut, falls es der Arbeitsaufwand zulässt.


    Auch top wäre es, die EPG-Daten mit im rtsp-Stream unterzubringen :smiling_face:

  • Partnerbox Remote-Timer encoded sref nicht überall

    Ok, Problem gefunden.


    getServiceRef() aus PartnerboxFunctions.py schneidet die sref nur ab, wenn "http" gefunden wurde. Da meine Urls kein "http" enthalten, wird auch nichts abgeschnitten.


    Habe jetzt folgende Lösung bei mir lokal eingebaut:



    Ein Unterschied zwischen den Sendern ist mir allerdings noch aufgefallen:


    Beim http-Sender enthält die Timer-Description den Namen der aktuellen Folge (denke mal die kommt aus der epg description). Beim rtsp-Sender enthält sie den Namen der Serie (ist also gleich dem Titel der Aufnahme). Hast Du eine Ahnung woran das liegen könnte und ob man das einfach beheben kann? Schätze es liegt daran, dass das EPG mit EPGImporter importierte Daten enthält, während über den http-Stream ja auch noch zusätzliche EPG-Daten reinkommen. Sendungs-Info sieht allerdings bei beiden Sendern gleich aus - haben ja auch die gleiche sref und greifen auf die gleichen Einträge in der epg.db zu.


    Edit: Ok, vergiss die Timer-Beschreibungsfrage wieder :smiling_face: Liegt einfach daran, dass das EPG mit EPGImporter importiert wurde. Ich habe mir jetzt nämlich einfach mal die epg.db von meiner Serverbox gezogen. Jetzt wird die Beschreibung auch auf dem rtsp-Kanal richtig gesetzt.