Beiträge von hivdr

Also nach einem Artikel in der vorletzten c't (Nr. 13) über LibreElec mit DVB-T2 habe ich endlich nochmal einen Versuch auch mit TVH gestartet. Im Artikel gehts zwar nicht um den Wetek Hub und auch nicht um SAT-IP, aber wesentliche Punkte sind identisch. Ich habe also in der TVH-Weboberfläche unter DVB-Inputs erst mal ein neues "Netzwerk" hinzugefügt (Name frei vergeben) und dabei vordefinierte alte DVB-T Muxes meiner Region gewählt. Diese habe ich (unter "Muxes") dann erst mal aufgeräumt: alle weg bis auf die drei ÖR Transponder/Frequenzen (wie unter http://www.dehnmedia.de/?page=sender&subpage=tsender2 zu finden). Beim Editieren der Muxes muss man neben der Frequenz (falls nötig) v.a. die Übertragungsart von DVB-T auf DVB-T2 ändern. Die restlichen Detail-Parameter scheinen zu DVB-T identisch zu sein, können bleiben. Da bis dahin kein SAT-IP Device zur Verfügung steht, bleibt der Status noch auf "pending", d.h. es wird kein Scan probiert.
Erst wenn man unter SAT-IP dann die Tuner/Frontends (bei mir 2 Stück, obwohl 4 angezeigt werden) nicht nur aktiviert, sondern auch dem vorhin selbst angelegten "Netzwerk" zuordnet, startet irgendwann der Scan. Und voila - er fand dann tatsächlich alle Sender, die man abschliessend unter "Services" noch "mappen" kann.

Mit dem TVH HTSP Client klappt dann (analog zur VDR-Kombination aus Service+Client) auch Live TV. Auch aufnehmen kann man, in meinem Fall (wie zu erwarten) auch zwei Programme von unterschiedlichen Transpondern und live ein weiteres von einem davon. Die Umschaltzeiten sind nicht so doll, ziemlich zäh. Und gelegentlich ist auch die Darstellung der Sender etwas zäh (nicht so 100% flüssig - Sorry, ist so).
Alles in allem kann man aber damit "arbeiten" - dass es kein Ersatz für meinen "richtigen" VDR wäre ist klar, allein schon wegen der viel umständlicheren Bedienung von Kodi.
Doch bei LibreElec auf dem Hub (jedenfalls die damals aktuelle Version 8.0.1) ist derzeit TVH die bessere Variante gegenüber VDR, weil damit kein Initialisierungsproblem nach dem Booten auftritt.

Von daher kann ich nach wie vor kein Netzwerk-Problem feststellen - weder in der eigenen Infrastruktur noch beim Octo.
Natürlich ist SAT-IP ein etwas komplizierteres Protokoll als 1-Port-TCP: aber auch wenn es zahlreiche Ports in UDP+TCP sind - was konkret würde da denn typischerweise schiefgehen, und wie könnte man es feststellen? Letztlich müssten es doch sowas wie Paketverluste sein? Das LAN interface des Linux-Server (uptime halbes Jahr) zeigt bei 157 Mio TX Paketen: errors:0 dropped:0 overruns:0 carrier:0 (ebenso bei den 91 Mio RX). Spezialitäten wie Multicast (was wohl tatsächlich auch bei gewissen Switchen/Routern mal Probleme machen kann) kommt laut Protokoll-Infos erst bei mehreren SAT-IP-Clients gleichzeitig zum Einsatz.

Am Netzwerk ist nichts verdächtiges: klassisches LAN mit (solidem) Switch, Gateway/DHCP ist ein Linux-Server, seit Jahren unauffällig.
Der dort eingehängte Octo wird ja auch problemlos gesehen von zB Windows-Clients wie auch dem tvh von libreelec (was dort nicht klappt ist ein Scan, habe ich aber bisher wohl auch immer nur mit nicht zum neuen DVB-T2 passenden Voreinstellungen probiert).

Lediglich der vdr-Service des libreelec auf dem Wetek Hub zeigt ihn eben oft nicht an bzw. erfordert mindestens ein disable/enable des Service. Ein Problem bzgl. "auf Netzwerk warten" ist ja offenbar in diesem Zusammenhang altbekannt (darum gibt es den Konfig-Schalter) - und ob das beim vdr einfach nicht immer so wirkt wie beabsichtigt, das zu beurteilen können wir dann ja erst mal CvH überlassen.

Wäre natürlich cool, wenn das Problem beim Hochfahren behoben werden könnte, so dass der VDR immer stabil den satip-Server findet.
Wenn Du mir sagst, wo ich interessante Log-Ausgaben finde, kann ich die gerne auch mal prüfen / hier reinstellen.
(Update wäre dann wohl wie hier beschrieben: https://wiki.libreelec.tv/inde…e=HOW_TO:Update_LibreELEC)

Wie man bei tvh oder vdr einen "Komplett-Scan" unabhängig von vordefinierten Parametern für bestimmte Regionen macht, weiss ich nicht. Bei VDR fand ich immer fertige channels (und neue auf bestehenden Transpondern fügt er eh ganz automatisch hinzu). Dieser Scan in der Kodi-GUI jedenfalls verlangt doch eine Auswahl soweit ich mich erinnere. Bei tvh kann ich ja nochmal einen Versuch unternehmen, aber keine Ahnung ob ich da von selbst draufkomme wie man das macht.

Mittlerweile habe ich aber auch passende/fertige channels bekommen:
yaVDR und DVB-T2?

Die habe ich an zwei Stellen unterhalb /storage hinterlegt (wo eben mittels find ein channels.conf zu finden war) - welche der beiden Stellen die "richtige" war und was die andere ist weiss ich nicht.
Erst half auch das nichts (trotz disable/enable VDR-Service) - aber da war eben dann auch bei Blick in die VDR-config satip-plugin wieder der satip Server nicht zu sehen.
Nach einem Reboot und disable/enable dann konnte ich tatsächlich über VDR-Service/VDR-VNSI-Client im Bereich Live-TV die Sender sehen.
Soweit stabil / Audio synchron. Umschaltung dauert zwar immer noch viele Sekunden, aber das ist viel schneller als beim IPTV-Addon.
Aufnahmen funktionieren im Prinzip, haben aber immer wieder Aussetzer. An der Micro-SD-Karte dürfte es nicht liegen, die war beim Image-Schreiben ziemlich schnell - aber vielleicht ist sie es ja im Kartenleser des Hub nicht so sehr. Oder aber da ist die HW des Hub dann eben doch gelegentlich überfordert, den Datenstrom unterbrechungsfrei abzulegen.

Immerhin kann ich jetzt die satip-Tuner (bzw. einen, ein zweiter Transponder bei 1 Aufnahme ging auch nicht) mal grundsätzlich stabil für Live-TV nutzen (wenn der VDR den satip-Server findet).

Yepp, jetzt frag ich mich auch wieder wieso ich den Post nicht gefunden hatte bei der Suche..
Danke jedenfalls, hat grundsätzlich geklappt jetzt damit (mehr berichten werde ich hier: Octopus NET S8 + vdr + KODI (LibreELEC) )

Zitat von seahawk1986

Die Channelpedia hat am Wochenende noch keine DVB-T2 Kanäle akzeptiert - ich habe hepi deswegen schon angeschrieben und ihm die DVB-T2 Kanalliste für München als Beispiel geschickt - ich denke er wird die Channelpedia bei Gelegenheit entsprechend anpassen.

Auch aktuell finde ich dort nichts zu DVB-T2 - mit Ausnahme von Hessen/Wiesbaden:
http://channelpedia.yavdr.com/gen/DVB-T/de/Wiesbaden/
Das sogar mit Datum von Ende März, was also grade so nicht ganz zu Deiner Aussage passt.

Aber warum ich poste: ich wäre auf der Suche nach einer channels.conf für DVB-T2 Muc - und finde eben nirgendwo welche.
Magst Du sie einfach hier mal reinpasten? Das würde vielleicht noch viele andere in der Zukunft freuen, wenn sie das hier finden können..

(ich möchte sie einem vdr unter libreelec auf einem Wetek Hub "unterschieben", da das Scannen mit einem sat-ip device Octo Net V2 mit 2xT2 einfach nicht klappt)

Früher habe ich eigentlich alle Kanäle immer aus irgendeinem Post in diesem Forum rauskopieren können (S2), aber mit DVB-T2 scheinen auch nach 2 Monaten noch nicht wirklich viele Leute unterwegs zu sein.

Danke!

OK, Einstellung gefunden, Danke. Geholfen hat sie leider nicht: auch mit der Einstellung (nach Reboot) taucht beim Scan erst ein Device auf, wenn man den VDR vorher disabled/enabled hat.
Als Wartezeit habe ich sogar 10s - da bei Dir 4 zu reichen scheinen, sollte das nicht zu knapp sein. Mein LAN/DHCP arbeitet normal.
Das mit Yatse klingt interessant (ein Tablet hab ich rumliegen), wenns denn funktioniert (laut Bewertungen längst nicht bei jedem).

Aber das alles sind ja leider eh nur Nebenschauplätze: der eigentliche Scan für DVB-T2 klappt eben nicht. Bis auf weiteres muss ich wohl aufgeben, bis sich da was tut. Oder ich habe mal ganz viel Zeit, finde raus wo die Scan-Parameter hinterlegt sind, kann die anhand der config des DD-TV manuell anpassen (welche Felder stehen wo / wie das eine aufs andere Format abbilden) usw. Oder mache das ganze mit m3u Playlist zu channels.conf. Oder schaffe es mal mit einem DVB-T2 Stick an einem Rechner mit ausreichend aktuellem Linux (Treiber) einen Scan zu machen.

Also falls jemand wo mal VDR channels für DVB-T2 Muc/Wendelstein gesehen hat..

Naja. Frühestens weiter nächste Woche.

Danke für die Hilfe CvH. Die Einstellung "Warten auf Netzwerk" habe ich erst mal nicht gefunden (obwohl garantiert schon mal wo gesehen), aber der Hinweis scheint korrekt: nachdem ich den Service VDR-Backend disabled und enabled habe, war dann tatsächlich der Octo in der satip-plugin-config zu sehen. Obwohl es LAN ist, kein WLAN.

Die Möglichkeit ins VDR-OSD einzusteigen hatte ich auch noch nicht entdeckt! Problem nur: mit der (schon erwähnten) Minimal-FB des Hub kommt man da nicht mehr raus! (keine Info-Taste) Nur Reboot hilft (Power wirkt mit Verzögerung, aber auch ohne Anzeige am Bildschirm). Auch zB Farbtasten gibt es nicht, ebensowenig wie Ziffern etc. Also VDR-Bedienung wäre wohl generell auch ziemlich eingeschränkt.
Trotzdem konnte ich so wie oben gesagt dann in der plugin-config für satip erst keinen satip-Server sehen, bei vorherigem disable/enable des VDR dann schon.
Und damit war dann auch beim "Scan" mehr zu sehen: als device "sat->ip 0", und er hat Frequenzen hochgezählt. Allerdings recht flott und ohne irgendwas zu finden.

Ich befürchte dass auch hier (wie schon bei tvh) mit der vordefinierten Auswahlmöglichkeit DVB-T/Germany einfach noch die Parameter fürs alte SD-DVB-T1 hinterlegt sind und deshalb nichts gefunden wird. Frage wäre also, wie bekommt man neue configs fürs (inzwischen immerhin fast 2 Monate alte und vorher 1 Jahr im Testbetrieb befindliche) neue dt. DVB-T2 da rein (und wo bekommt man sie her)?
Wenn man fertige channels hinterlegen würde (aber auch da finde ich wie gesagt nichts für DVB-T2), müsste er dann automatisch erkennen dass der Octo ein geeignetes Device dafür ist?

Mühsam das mit dem DVB-T2. Würde ich das alles mit DVB-S2 machen, hätt wahrscheinlich fast alles auf Anhieb funktioniert..

Zur Wiedergabe. Zum einen habe ich auch den Eindruck dass es besonders zum Start sehr ruckelt (zB Anfang Folge 3 von Hindafing, BR-Mediathek) und dann etwas besser wird. Natürlich auch nur bei Szenen wo sich etwas mehr tut (sprich Bewegung und höhere Datenrate - am Internetzugang liegts nicht, 100Mbit). Zum anderen glaube ich man gewöhnt sich so ein bisschen dran. Wenn man es aber mit dem FFHD-VDR vergleicht, ein Unterschied wie Tag und Nacht. Aber da bin ich halt verwöhnt / anspruchsvoll. Wäre auch erstaunlich, wenn man für 99 Euro einen VDR bekommt, der so gut ist, wie wenn man da sehr viel mehr investiert.. wie gesagt, wäre trotzdem dankbar, wenn der bis auf weiteres für DVB-T2 verwendbar wäre, da eine FFHD nun mal leider kein H.265 wiedergeben kann (und der einst selbst ganz manuell installierte VDR so alt ist, dass man nicht mal eben das satip-plugin nachrüsten kann - und ein Neu-Aufsetzen des bestehenden scheidet aus, absolute Stabilität/Verfügbarkeit des status quo hat absolute Priorität. Wenn dann also kompletter Neubau irgendwann).

Also bis jetzt ist es auch mir nur gelungen, die Sender mit dem Simple IPTV Client zu streamen - gelegentlich etwas ruckelig, und mit einem gewaltigen Audio-Versatz von 1.75s ("ahead" einstellen).
Dazu muss man die .m3u playlist bei der Octo T2 ziemlich umständlich mit dem Dvbviewer-Demo scannen (unter Verwendung der config für T2 aus der DD-eigenen Viewer-Software, DDTV glaub ich, denn die kann das zwar scannen aber nicht exportieren) und dann mit diesem Octo-Cast Tool exportieren. Denn leider kann die Octo selbst mit ihren T2-Tunern noch überhaupt nicht richtig "umgehen", also kein Kanal-Scan, nicht mal nachträglich importieren kann man eine Kanalliste, die sie dann wenigstens selbst direkt bereitstellen könnte. Ist für die nächste Firmware versprochen.

Ein "richtiger" Sat-IP Client ist also gefragt, der selbst scanned - und das mit dem dt. DVB-T2 auch hinbekommt. Ich hatte bisher noch mit keinem abseits der Windows-Clients DDTV und DvbViewer Erfolg - etwa unter Android mit dieser Elgato-App - die kann natürlich auch kein DVB-T2.

Zitat

VDR benutzen? Würde auch besser ins Forum passen.

Ja, LibreElec enthält auch ein VDR-Backend/Service und Client. Doch da siehts auch schlecht aus bisher.
Der VDR-Service installiert wohl das "vdr config" addon mit, in dem man tatsächlich ein satip-plugin aktivieren kann. Doch ob das Erfolg hat, ob er den Octo "findet" oder nicht (ist nat. im gleichen Netz und wird von anderen Clients mindestens "gesehen"), da ist nichts zu erkennen. Man kann mit dem Button ganz unten (der bei mir nicht richtig als "aktiv" angezeigt wird, man muss ihn "blind" ansteuern) dann einen Kanalsuchlauf starten - aber da tut sich absolut garnix. Fertige Kanallisten für DVB-T2 (Muc) scheinen auch noch nirgendwo zu existieren (in channelpedia neulich sah ich Hessen - Rest des Landes noch überall die alten DVB-T channels).

Falls gemeint war ein "richtiger" VDR - ja, ist wie gesagt mein Ziel, aber das kann noch dauern. Einen seit 6 Jahren perfekt laufenden FFHD-VDR (samt pöhsem für HD-) ersetzt man nicht mal eben ohne grösseren Aufwand - jedenfalls wenn man sich dabei nicht massiv verschlechtern will.

So faszinierend es ist, in diesem winzigen Kästchen (Wetek Hub) eine vollständige Media-Distri samt VDR (wenn es denn fkt. würde) zu haben, so sehr fühlt es sich dann schon auch immer wieder nach "Spielzeug" an. zB die Mediathek-Wiedergabe (zB BR H.264) ruckelt immer wieder mal ordentlich - kein Vergleich zur FFHD. Ähnlich eben die H.265 Wiedergabe von DVB-T2. Und die Bedienung mit der Minimal-FB. Auch Hänger/Komplett-Freezes kommen vor.

Also ja, es geht nichts über einen "richtigen" VDR. Nur hier gehts mir erst mal darum, die vorhandenen Octo T2-Tuner für eine (möglicherweise längere) Übergangszeit halbwegs brauchbar nutzen zu können. Bis sich eine vernünftige Dauerlösung abzeichnet, wie man einen VDR mit DVB-S2 _und_ DVB-T2 baut, der dem vorhandenen in nichts nachsteht.

Habe versucht, unter LibreElec auf einem Wetek Hub (aktuelle Version auf mSD-Karte) mit TVHeadend (bin kompletter Neuling) die DVB-T2 Sender
über einen Octo (2 Tuner) zu scannen (und nat. dann zu schauen und gerne auch aufzunehmen - bis irgendwann später mein Projekt VDR-neu mit
DVB-T2 mal anläuft..)

Ich konnte unter dem LE-Kodi den tvh service installieren und erreiche ihn über die Web-GUI (9981).
Die Octo wird erkannt, 2 Tuner "aktiviert" (aus welchen Gründen auch immer werden 4 angezeigt).
Ein neues "network" hinzugefügt - DVB-T - die "muxes" tauchen auf. Doch sie bleiben alle dauerhaft auf "pending", keinerlei Spur von gefundenen Kanälen (im Tab nebendran).

Ich schätze das liegt auf alle Fälle auch schon mal daran, dass die vordefinierten "services/networks" (oder
wie das hiess) beim Anlegen eines neuen "network" eben für Deutschland noch das alte DVB-T(1) betreffen.
Gibt es schon neue Konfigurationen für DE DVB-T2 (Bayern), und wenn ja wo und wie bekommt man sie ins System?

Danke für alle Hints..

Zitat

Ein Tvh/VDR Howto für LibreELEC ist in "Arbeit" - aber Zeit und Lust sind derzeit Mangelware

Also ich wäre jedenfalls auch ein interessierter Leser!

Ich kann für beide meiner VDRs bestätigen, dass die Hänger/Restarts Geschichte sind - Danke!

Den zusätzlichen delete habe ich grad mal angetestet - leider kein Erfolg!
Hätte mich aber auch gewundert, das ist ja kein schleichendes Speicherloch, das sich nach langer Laufzeit irgendwann mal auswirkt. Es passiert unmittelbar - wenn man die recordings-Seite aufgerufen hat, ist dann gleich das OSD "tot" (auch bei skincurses) - und zwar, wie ich nun festgestellt habe, nicht nur, wenn eine Aufnahme läuft oder man eine startet, sondern es reicht schon die Aufnahme-Liste im Menu zu öffnen (sie erscheint nicht mehr), auch ohne laufende Aufnahme. Sieht also eher so aus, als würde die Liste durch die recordings-Seite irgendwie "kaputtgemacht" - bei C mit den Pointern ist sowas ja immer schnell mal passiert.

Mit laufenden Aufnahmen kann der recplayer wie beschrieben umgehen: er spielt bis zum Ende zum Zeitpunkt des Wiedergabe-Start. Ich denke man könnte grob so vorgehen: das Flag isStillRecording beim Wiedergabe-Start in der Instanz sichern (recstreamer oder recplayer?), und wenn dann das Ende erreicht wurde und dieses Flag gesetzt ist, müsste er sich selbst neu instanziieren mit Beginn = bisheriges Ende (die Aufnahme würde neu eingelesen, und das Spiel beginnt erneut).

Dass die Liste so sortiert ist, wie im VDR-Menu, konnte ich nachvollziehen - allerdings muss man die Liste dazu eben auch erst mal im VDR-Menu geöffnet haben. Bei einem reinen Streaming-Server zB wird das nie passieren. Man müsste also wenigstens den Aufruf vom Plugin aus initial mal "simulieren". Dann wär das soweit OK. Ansonsten meine ich mit Sortierung ja nicht zwingend eine Umsortierung der Indices (sobald die Seite gut funktioniert ist man ggf. nicht mehr so auf die Indices angewiesen, aber solange man die URLs selbst eingibt/zusammenbaut sind sie ja die einzig praktikable Variante) - nur die Reihenfolge der Liste in der Ausgabe sollte alphabetisch und nach Datum sortiert werden können - die Spalte mit dem Index würde eben mitsortiert. Notfalls könnte man das auch via JavaScript erledigen (zB JQuery tablesorter).
Das mit der eigenen Seite je Aufnahme zum komfortablen Abruf sämtlicher Möglichkeiten klingt gut
Jeglicher sich daraus ergebende Streaming-Link sollte natürlich immer auch als Text herauskopiert werden können - denn das direkte Anstarten per Browser-Klick im Streaming-Client klappt nach meinen bisherigen Erfahrungen wie schon mal erwähnt kaum. Etwa der Desktop-Firefox bei "öffnen mit vlc" versucht das als Datei herunterzuladen und das Ergebnis dann an den vlc zu geben - nicht den vlc selbst die URL öffnen zu lassen. Unter Android ist der vlc nicht mal im Angebot. Man wird also häufig die URL selbst kopieren müssen.

Und um die letzte potentielle Baustelle auch nochmal zu erwähnen, die mir vorschwebt: ein Modus /current (neben /<channel> und /<aufnahme>.rec), der im Optimalfall alles was am VDR passiert 1:1 auch so streamt. In einer ersten simplen Variante könnte er nur beim Start das grade laufende live-Programm bzw. die grade wiedergegebene Aufnahme ab resume (wobei das glaub ich doch nicht während der Wiedergabe regelmässig geschrieben wird) rausgeben. Bei Änderungen (Umschalten, Wiedergabe-Start/Stop etc) müsste man eben erst mal die /current URL im Client neu starten.

Wenn ich was "probiere", dann wären das höchstens Experimente, am ehesten bzgl. Thema laufende Aufnahme, deren Erkenntnisse ich Dir zeitnah mitteilen würde. Ist aber sehr ungewiss im Moment. Lass Dich nur von nichts abhalten - und Danke!

Nachtrag zum Hänger bei Aufruf der recordings-Seite während/vor Aufnahme: konnte das auch mit dem ursprünglichen Stand aus dem August reproduzieren, und auf dem Test-VDR, der ausser streamdev-server nur noch das Plugin skincurses enthält, sonst keinerlei Plugins.

Eine weitere Anforderung, die man in der Praxis brauchen wird: steigt man in laufende Aufnahmen ein, so ist immer dort Schluss, wo zum Zeitpunkt des Wiedergabe-Starts grade das Ende war (hängt man nur wenige Minuten zurück, ist dauernd Schluss und man muss dauernd etwa mit pos=time.x an fortschreitender Position wiedereinsteigen). Entweder automatisch durch Erkennen, dass die Aufnahme noch läuft, oder via Parameter sollte man erreichen können, dass solche Aufnahmen dann nicht mit fixer Länge (range-header / content-length) laut Stand bei Wiedergabe-Start gestreamt werden, sondern wie beim live-Streaming mit "open end". Wozu vermutlich die Aufnahme bei Erreichen des vermeintlichen Endes nochmal neu eingelesen werden muss.

Damit das prompt erscheint, an dem man "quit" eintippen kann, muss ich je nach Terminal verschiedene Tastenkombinationen verwenden:

putty: Ctrl-+
xterm: Ctrl-] (Ctrl,AltGr,9)

Ich habe nun endlich meinen Haupt-VDR nach zweieinhalb Jahren mal wieder aktualisiert, auf 2.0.3 - so dass nun auch das aktuelle streamdev plugin damit läuft.

Erst da fällt nun auf, dass die recordings-Seite so noch wenig brauchbar ist, denn sie ist völlig unsortiert - weder alphabetisch noch nach Datum (wie ich es mir wünschen würde) - was bei 265 Aufnahmen im Moment nicht wirklich praktikabel ist (einziger Ausweg: Browser-Textsuche). Ausserdem bräuchte man möglichst noch einen resume-Link je Aufnahme. Das sind ja Dinge, wo ich vielleicht wieder selbst sehen könnte, ob ich sie irgendwie hinbekomme.

Leider gibt es noch ein grösseres Problem. Der VDR stürzt ab, sobald man die recordings-Seite aufruft und gleichzeitig eine Aufnahme läuft. Dabei reagiert er sofort nicht mehr auf die FB. Das was grade läuft läuft weiter, auch Streaming funktioniert noch - so lange, bis dann der watchdog zuschlägt und einen Restart auslöst.
Im Log findet sich absolut nichts, abgesehen vom watchdog PANIC.
Verwendet man nur das Streaming als solches, ohne die recordings.html aufzurufen, gibt es keine Probleme. Für den Aufnahmen-Index kann man ggf. auch das svdrpsend Kommando LSTR verwenden - wenn man denn eine Konsole verfügbar hat. Aber für den Alltag ist das nat. nichts. Ausserdem ist mir früher schon aufgefallen, dass manchmal die Reihenfolge (und also die Indices) der recordings-Seite nicht die gleiche ist wie die, die LSTR liefert.
Ohne laufende Aufnahme passiert erst mal nichts. Aber wenn man die recordings-Seite aufgerufen hatte und später dann eine Aufnahme startet, ist das Phänomen sofort wieder da. Vielleicht lässt sich aus diesen Tatsachen ja eine Theorie des Problems ableiten..

Was all die DVB/TS/MPEG-Details angeht, da bin ich auch "raus", kenn mich da nicht aus, da werden mir vlc-debugging Ausgaben auch nicht helfen (ich verwendete für die Tests eh die Linux-Version und sehe alles in der Konsole: wenn alles OK ist (neben freetype-errors) lediglich ein paar "TS discontinuity", im Fehlerfall aber tatsächlich sehr viel für den Laien unverständliches Zeugs (kurzer Anfang s. unten)).

Wobei ich eben - siehe auch letzter Post - sowieso Zweifel habe, ob sich Aufwand hier auszahlen würde, weil zumindest der vlc eigentlich absolut alles "frisst", was man ihm vorsetzt, sprich egal ab welchem Byte-Index man ihm die Aufnahme vorsetzt. Einzige Ausnahme ist eben nur, wenn man auf die initiale 0- Anfrage mit einem range-Header antwortet, der nicht mit 0 startet (um so auch ein Springen zurück bis max. zum Anfang zu ermöglichen, hier immer als "full_" Modus bezeichnet).

Dass das ganze vielleicht demnächst auch in yavdr landet freut mich (auch wenn ich es bisher selbst nicht benutze).

[mpeg2video @ 0x7f75cc003ee0] ac-tex damaged at 7 0
[mpeg2video @ 0x7f75cc003ee0] ac-tex damaged at 5 1
[mpeg2video @ 0x7f75cc003ee0] ac-tex damaged at 7 2
[mpeg2video @ 0x7f75cc003ee0] ac-tex damaged at 4 3
[mpeg2video @ 0x7f75cc003ee0] skipped MB in I frame at 14 4
[mpeg2video @ 0x7f75cc003ee0] ac-tex damaged at 3 5
[mpeg2video @ 0x7f75cc003ee0] ac-tex damaged at 20 6
[mpeg2video @ 0x7f75cc003ee0] Warning MVs not available
[mpeg2video @ 0x7f75cc003ee0] concealing 1620 DC, 1620 AC, 1620 MV errors
[mpeg2video @ 0x7f75cc003ee0] ac-tex damaged at 7 0
[mpeg2video @ 0x7f75cc003ee0] ac-tex damaged at 5 1
[mpeg2video @ 0x7f75cc003ee0] ac-tex damaged at 7 2
[mpeg2video @ 0x7f75cc003ee0] ac-tex damaged at 4 3
[mpeg2video @ 0x7f75cc003ee0] skipped MB in I frame at 14 4
[mpeg2video @ 0x7f75cc003ee0] ac-tex damaged at 3 5
[mpeg2video @ 0x7f75cc003ee0] ac-tex damaged at 20 6
[mpeg2video @ 0x7f75cc003ee0] Warning MVs not available
[mpeg2video @ 0x7f75cc003ee0] concealing 1620 DC, 1620 AC, 1620 MV errors
[mpeg2video @ 0x7f75cc003ee0] 00 motion_type at 41 18
[mpeg2video @ 0x7f75cc003ee0] invalid cbp at 23 11
....

Ich danke ebenfalls, für die Aufnahme der Funktion ins Plugin (und die gründliche Überarbeitung meines Patch)!

Was PMT/PAT angeht - abgesehen davon dass ich mich erst mal etwas schlau machen musste und trotzdem keine Idee habe, wie das konkret zu bewerkstelligen wäre - so spricht natürlich eine Sache gegen die Theorie, dass das helfen würde: alles was beim full_ Modus anders ist, sind die Range-Header, die eben eine Position "mittendrin" signalisieren, obwohl 0- angefordert wurde. Die Daten als solche sind ja völlig identisch, und da hat vlc keinerlei Probleme mit der Wiedergabe, ob nun an beliebigen Frames oder sogar an irgendwelchen Byte-Indices. So dringend wird er das also doch nicht brauchen, oder aber selbständig finden, egal ab welcher Position man die Daten schickt.
Warum das nur im Fall der Übergabe eines Mittendrin-Range-Header dann anders ist, bleibt wohl bis auf weiteres ein Mysterium. Vielleicht gibt er sich bei einem Stream-Anfang mehr Mühe mit der Erkennung und verlässt sich dann bei Sprüngen auf diese "Initialisierung" - und denkt bei der full_response mittendrin es wäre ein Sprung gewesen. Nur das erklärt wiederum nicht, warum es in Einzelfällen auch mit full_ gutgeht.

Auch könnte ich mir vorstellen, dass zumindest andere Player einen TS-Stream nicht so weitgehend unterstützen wie vlc, vielleicht sogar einfach nur Video-Daten erkennen, wiedergeben und alles andere ignorieren. Da in einer Aufnahme ja sowieso nur ein einzelnes Programm herausgefiltert wurde, gibts letztlich nicht wirklich die Notwendigkeit, irgendwelche PIDs zu unterscheiden, oder..

Lars
Das wirds wohl sein, ja - wobei das ja schon erstaunlich ist, wie der VLC das anstellt. Eigentlich kann er nur das EPG auswerten und dann anhand der aktuellen Uhrzeit die Anzeige von Fortschritt und Endzeit berechnen. Insofern wäre es im Fall von Aufnahmen wohl doch heftigste Trickserei: man müsste EPG-Daten "einbauen", die anhand der aktuellen Zeit und der Position eine virtuelle Sendung so erfindet, dass es grade passt..

Trotzdem wär ja noch die Frage, ob es nicht auch andere Möglichkeiten gibt, einem Player die Gesamtdauer zu übermitteln, so dass er auch die Zeit laufen lassen kann.
Der von vlc angezeigte Fortschrittsbalken dürfte wohl auf Basis der "rohen Bytes" gezeichnet werden, nicht anhand des tatsächlichen (Bitraten-abhängig schwankenden) Zeit-Fortschritts.

Das ist übrigens eins der wenigen Dinge, die mich beim VDR immer schon gestört haben - der fehlende Videotext in Aufnahmen. War ich einst vom Topfield so gewohnt, war immer interessant zu sehen wie spät es bei Ausstrahlung grade war (ohne zu rechnen) oder die "aktuellen" Nachrichten von vor einem Jahr.. eine Option um in Aufnahmen auch solche Sachen mitzuspeichern fände ich interessant - natürlich müssten sie dann auch bei Wiedergabe entsprechend "als wäre es live DVB" verwendet werden.

So, nochmal was neues..

Der aktuelle diff (vom gleichen Ausgangspunkt von Ende August) hängt an, diesmal im Nurp Format.

Ich habe noch eingebaut, dass generell iFrames verwendet werden. Bei resume stehen glaub ich sowieso nur solche drin, aber bei marks (Zeitangaben) und bei direkter frame-Angabe wird rückwärts der letzte iFrame gesucht und verwendet - das schadet nie.

Wirklich gebracht hat es aber nichts, generell kommt zumindest der vlc auch mit jedem anderen Frame klar, ausser im full_ Modus - da hat zufällig erst mal wieder alles geklappt nach der Änderung, kurz drauf war es wieder Essig. Letztlich konnte ich in einem Beispiel reproduzieren, dass bei mehreren hintereinander identisch abgerufenen Streams in den meisten Versuchen "Müll" dargestellt wurde, gelegentlich war es auch OK. Ich habe in wireshark verglichen was über die Leitung geht, und abgesehen vom Date-Header war es absolut identisch. Nur im Fehler-Fall hat vlc mittendrin angefangen die Verbindung abzubrechen (RST). An den empfangenen Daten kanns also nicht liegen, warum der vlc mal glücklich ist, und mal so gar nicht (gar nichts anzeigt oder nur Müll, versucht die letzten 200000 oder 128 Bytes abzurufen und damit aber auch nichts anfangen kann usw).
Insofern: gebe auf, finde aber man könnte den Code (minimal, i.w. zwei if-Abfragen) ruhig drin lassen, undokumentiert..
Wenn es initial gut geht, lässt sich danach einwandfrei in der (vollen) Aufnahme springen.

Eingebaut habe ich ausserdem auch noch, dass der pos-Parameter auch bei initialen nicht-range-requests ausgewertet wird. Der mplayer macht das zB so, dass er nur einen normalen HTTP-Request ohne range Header schickt, und erst wenn man vor/zurück springen will sendet er die range requests. In diesem Fall geht full_ natürlich schon aus Prinzip nicht, da ja gar keine range response erwartet wird.

Soweit der aktuelle Stand.
Offen wären dann in erster Linie die Abspiel-Links auf der Aufnahmen-Seite. Der Android-FF bietet bei "Lang-Klick" an, die URL mit einer anderen Applikation zu öffnen - bietet aber nur den MX-Player an, nicht vlc - und wer weiss ob er das bei .rec ohne .ts auch noch täte.

Ach ja, übergibt man neben pos noch weitere Parameter (die eigentlich ignoriert werden sollten), kommt es mehr oder weniger zu Abstürzen (hängende Verbindungen), und pos wird nicht erkannt. Das Parameter Parsing klappt also evtl. auch nicht so 100%, das habe ich mir aber nicht mehr näher angesehen.

Aufgefallen ist mir, dass beim Live-Streaming nicht nur der Sendungs-Titel laut EPG übertragen wird, sondern auch die Dauer der Sendung, und dass die Zeit innerhalb dieses "Fensters" korrekt abläuft. Bei einem schnellen Sniffing neulich sind mir keine Header aufgefallen, das scheint im TS-Stream selbst drinzustecken? Und wird bei Aufnahmen ausgefiltert?
Eigentlich möchte man sagen, wenn sowas sogar live geht, dann müsste es bei Aufnahmen ja erst recht möglich sein, beim Abspielen die Gesamtdauer und die aktuelle Position zu bekommen. Aber wie genau überträgt man diese Infos an den Player..?

Hallo schmirl,

schön dass Du den Patch berücksichtigen möchtest. Hat natürlich alles die Zeit die es braucht, nur keine Hektik, ich verspreche ja auch nichts.

Grundsätzlich ist es Dein plugin, passe also alles so an wie Du möchtest.

In der Sache würde ich aber folgendermassen argumentieren.

Bei der Prozent-Sache hatte ich im Hinterkopf, dass es eben nicht funktioniert hatte, wenn ich nur ein "%" angehängt habe. Vielleicht habe ich auch was falsch gemacht (siehe eine auskommentierte Zeile im Patch). Wenn es funktioniert einverstanden, wenn man als Nutzer "%25" eingeben muss fände ich das nicht so dolle..

Das mit full_ könnte man ja auch noch ein bisschen weiterverfolgen, etwa indem man grundsätzlich dann noch iframes nimmt (da ist ja auch eine Funktion in recplayer). Falls ich demnächst noch dazukomme es zu testen.. Auch habe ich noch keine anderen Player probiert.

Ein Server-Header mit "Version x.y.z" ist übrigens auch noch im Patch, falls Du wüsstest wie man die VDR-Version und plugin-Version da noch reinbringt.. nicht nötig, aber wäre auch ganz schön.
Die ein oder andere Debugging-Ausgabe wirst Du vermutl. auch aus- oder besser umbauen wollen.

Das getFromByPos kann man nat. umziehen. Aber mich würde der eine übergebene Parameter, der da verarbeitet wird, weniger stören, als eben die ganzen Positions-Berechnungen in einer Klasse, die sich dem Namen nach nur um die reine HTTP-Verbindung kümmern soll. Ausserdem sind halt die recplayer-Aufrufe drin. Und diese Funktionen wiederum finde ich auch sehr wohl im "Player" richtig aufgehoben. Der Index etwa wird ja auch dort eingelesen, warum soll ich plötzlich resume und marks im recstreamer verarbeiten?
Nur meine Meinung, wie oben gesagt.. Hauptsache es funktioniert.

(ah, der Bot-Post ist wieder weg, schön..)

@seahawk ** diff -Nurp
Danke, mit Kontext etwas leserlicher, aber nat. auch "aufgebläht". Beim nächsten mal..

Mir ist grade aufgefallen (mit Original-Repository-Version gegengecheckt) dass die Links aus der Recording-Seite nicht funktionieren, weil hinten noch .ts mit dranhängt - laut Code wird dann das als file-extension betrachtet und ist dann also nicht ".rec"? (habe sonst meist die URL selbst eingegeben mit der Index-Kurzform)

Nächster Schritt wäre dann auch, diese Seite mit entsprechenden Links oder Icons für "resume" auszustatten.

Leider reagieren die Browser unter Android (probiert: FF und Chrome) auch nicht auf die Links, indem sie das Öffnen eines MediaPlayer anbieten. Gut, solange die Links das .ts enthalten, kommt wohl eh keine richtige Antwort mit passendem mimetype, aber auch wenn ich im Browser das .ts entferne startet er nur einen Download.
Kann man unter Android irgendwo die Mimetype-App-Zuordnung editieren (kleine Recherche war erfolglos)?

Auf dem Desktop (zB Ubuntu / FF) bietet er an es mit dem vlc zu öffnen, dann aber scheint er den kompletten Stream downloaden zu wollen, bevor er wirklich an vlc übergibt. Erst bei Abbruch des Streams (durch Stop des VDR oder Stop des Stream im plugin-Menu) startet der Player und zeigt den bis dahin geladenen Teil (dafür dann mit Zeit..)
Sowas wie eine Übergabe der Stream-URL aus demBrowser an einen Player ist nicht möglich?