Beiträge von SHF

    32768k sind nur 32MiB???

    Bei mir ist die Angabe deutlich Größer (Faktor 10), aber deutlich unter dem verbauten RAM.

    Ich würde eher vermuten, dass es die Ramdisk-Größe oder sowas ist, da müsste ich aber auch suchen.

    edit:

    Die zweite Zahl nach dem / gibt die Speichergröße an, man muss die Meldung nur ganz lesen ;):

    Memory: 3595872K/8335796K available

    Wobei das bei mir auch nicht ganz passt (etwas zu klein), die erste Zahl ist der freie RAM.


    Ein echter Hardware-Fehler ist es jedenfalls zu 99,9% nicht.

    Defekter Speicher verursacht Abstürze und nicht sowas.

    Wenn es Hardware-Seitig ist, dann Überhitzung.


    Ich würde mal eine neue CMOS-Batterie einsetzen und wichtig! das BIOS zurücksetzen und ggf. Updaten.

    Merkwürdige Bootprobleme kommen, nach meiner Erfahrung, oft von einer schwachen Batterie.


    Bei der Fehlerbeschreibung wäre mein Tipp aber eher in Richtung Software.

    Evtl. mal mit einer Live-CD einer anderen, älteren Distri versuchen, wenn der Fehler gut reproduzierbar ist.


    Das Phänomen mit der abnehmenden Performance kenne ich übrigens bei SAMBA.

    Die erste Übertragung einer Aufnahme geht ruck-zuck, ab dem zweiten mal ist es viel langsamer.

    Die Ursache konnte ich nicht ergründen, hoffe aber, dass es das nächste Software-Update des Servers beseitigt.


    Du könntest auch mal versuchen testweise das Paket "intel-microcode" zu deinstallieren.

    Das könnte sich auf die Leistung der CPU auswirken.


    Ich hätte mir da schon längst einen bzw. zwei N100 besorgt, um mich dann ohne Ausfallerscheinungen bei gleicher Leistung an passiven 9W statt aktiv gekühlten 60W idle alleine des Xeon-Servers zu erfreuen.

    Das Board sollte idle bei etwa 20-25W liegen, ich habe selber welche aus der Serie und die original Intel-Boards waren immer recht sparsam.

    Die N100 sind sicher eine schöne Basis, aber ist der inzwischen voll unterstützt? Letztes mal, als ich schaute, ging die Videobeschleunigung noch nicht wirklich.

    Generell macht es IMHO schon Sinn den Fehler zu verstehen, bevor man alles neu kauft. Nachher liegt der Fehler wo anders (wie meistens), dann hat man nichts gewonnen.

    -map 0 ist hier keine gute Idee.

    Der Inputstream ist immer der folgende (HSE):

    ZDF ist aber vergleichbar.

    Man sieht das es da mehre Video mit den dazugehörigen Audio-Streams gibt.


    Output mit -map 0:

    Man hat am Ende einen Haufen Video und Audio-Streams im TS-Stream. Das mach eigentlich keinen Sinn.

    Am Ende will man ja einmal Video plus evtl. mehrerer Audio-Stream, falls angeboten.

    Ob die Datenrate dadurch ansteigt, habe ich noch gar nicht gemessen.


    Output ohne -map 0 und ohne Änderung der PIDs.

    nur -c copy ohne -codec:v $VCODEC $VCODEC_OPTIONS -codec:a $ACODEC $ACODEC_OPTIONS -streamid 0:$VPID -streamid 1:$APID

    Nur noch einmal Audio und Video.

    Hier sollte jetzt das Default-Verhalten von ffmpeg gegriffen haben.

    Bei mehreren Audio-Spuren muss man sich wohl noch was überlegen, aber erstmal sollte es so gehen.


    Probleme scheint es auch zu geben, wenn nicht Stream 0 und 1 gewählt werden (wie beim ZDF), dann klappt das mit dem Setzen der PIDs nicht.

    Könnte mal jemand das aktuelle Script "ffmpeg2iptv_raw" mit allen letzten Änderungen hier einstellen.

    Damit wir wieder einen gemeinsamen Stand haben. ;)

    Ich habe jetzt meine letzten Änderungen in diese Version #117 eingefügt. Das war doch die Letzte?

    Die Änderung sind lediglich die beiden " um die udp-url.

    Ohne die geht es bei mir auch nicht gescheit!

    Der Rest war nicht zielführend (siehe nächster Beitrag).


    Ich meinte letztes mal den Test aus Beitrag #139. Nur mit ffmpeg und xine.

    Ffmpeg ist da identisch konfiguriert, wie fürs iptv-plugin, aber halt ohne telerising und ohne VDR.

    Es geht da erstmal nur darum Fehlerquellen auszuschliessen.


    Wer Abwechselung zu hse sucht, hier ist die URL vom offizeillen ZDF-Livestream:

    https://zdf-hls-15.akamaized.net/hls/live/2016498/de/high/master.m3u8


    Nach dem, was ich inzwischen hier probiert habe, tippe ich auf ein Problem zwischen ffmpeg und der Anwendung. Also irgendwo am udp videostream.

    Obwohl der nie den Computer verlässt, scheint es da zu Paketverlusten zu kommen.

    Die von carel schon erwähnten Einstellungen:

    Code
    pkt_size=1316&buffer_size=65536&overrun_nonfatal=1

    scheinen extrem wichtig zu sein. Bei mir muss aber zwingend die ganze URL mit " gequotet werden, sonst geht es nicht!

    Im Forum zu der telerising.api gibt es auch einige mit derartigen Problemen, während es bei anderen einwandfrei geht.

    In dem Zusammenhang wird auch immer ffmpeg erwähnt. Ich vermute die Ausgabe geht dann über Kodi???

    Eventuell gibt es da wirklich Probleme mit einigen ffmpeg-Versionen oder Paketen?


    Paulaner könntest Du mal die beiden Befehle aus meinem letzten Beitrag probieren?

    So würde man mal die telerising.api und den VDR als Fehlerquelle ausschließen.

    Xine gibt es bei Debian im Paket "xine-ui", das müsste bei Ubuntu auch der Fall sein.

    Die beiden Befehle müssen in zwei Terminals parallel gestartet werden, erst ffmpeg, dann xine.


    Könne evtl. daher die vielen Meldungen mit den [hls @ 0x557766909a00] Skip ... kommen, die dann auch die Bildfehler verursachen?

    Die Meldungen gibt es bei mir auch massenhaft:

    Man müsste mal schauen, was das bedeutet, aber ein funktionelles Problem scheint es nicht zu sein.

    (Zumindest in meinem Setup nicht.)


    Mit -map 0 -c copy an Stelle -codec:v copy -codec:a copy geht es hier übrigens auch.

    Die PIDs scheinen da aber etwas durcheinander zu kommen.

    Code: vorher
    demux: starting stream 0x558892580460.
    demux_ts: PAT transport stream id 2836.
    demux_ts: found 1 programs, 1 pmt pids.
    demux_ts: pmt video descriptor 1b e0 64 f0 00
    demux_ts: new video pid 100
    demux_ts: pmt audio descriptor 0f e0 c8 f0 00
    demux_ts: new audio pid 200
    demux_ts: found no ISO 639 lang
    demux_ts: using 2 pids, 1 audio 0 subtitle channels
    demux_ts: PCR pid 100.


    Jedenfalls gibt es laut Xine --verbose=2 deutlich mehr PIDs.

    Und es ruckelt gelegentlich auch!

    Dann wird es an der Firmware wohl nicht liegen.

    Ich hatte eben mal versucht die beiden Commits rückgängig zu machen, das klappt aber nicht so einfach. (Da wäre Handarbeit notwendig.)


    Am besten Du schickst mal eine Mail an den Support von TBS. Die sollten beurteilen können, was da los ist, zumal es mit der alten Version ja geht.

    Die Commits scheinen Register im Tuner/Demodulator zu ändern. Ohne Datenblatt stochert man da leider ziemlich im Dunkeln.

    This is my ffmpeg command running

    Damit geht bei mir gar nichts.

    Ausgabe sind lediglich zwei PIDs von ffmpeg, sonst nichts.


    Debian 11 mit entsprechendem ffmpeg aus den original Quellen.


    Especially this part is important

    Da scheint es bei mir zu hängen, wenn man die komplette URL quotet geht es!

    Ich vermute die "&" machen Probleme mit meiner Shell.


    Mit dem überarbeiteten Befehl geht es bei mir:

    Code
    ffmpeg -y -hide_banner -user_agent Mozilla/5.0 -reconnect 1 -reconnect_streamed 1 -reconnect_delay_max 1 -probesize 8000000 -analyzeduration 8000000 -f hls -http_persistent 0 -re -i https://hse24.akamaized.net/hls/live/2006663/hse24/playlist.m3u8 -codec:v copy -codec:a copy -streamid 0:100 -streamid 1:200 -flush_packets -1 -f mpegts -mpegts_transport_stream_id 2836 -mpegts_pmt_start_pid 4096 -mpegts_service_id 6016 -mpegts_original_network_id 65281 "udp://localhost:4320?pkt_size=1316&buffer_size=65536&overrun_nonfatal=1"

    Den Stream kann ich mit Xine öffnen und ruckelfrei und ohne jegliche Aussetzer wiedergeben.

    Code
    xine udp://localhost:4320

    Mit VLC und Mplayer geht gar nichts, warum auch immer.

    Wenn ich Dich richtig verstehe, könnte es sinnvoll sein, von der alten Installation die Firmware aus /lib/firmware zu nehmen und im neuen System zu testen?

    Natürlich nur die Firmware von der Karte! Sofern die überhaupt eine benötigt.
    Bei Github habe ich eben beim Treiber keine Firmware gesehen.

    Wenn etwas geladen wird sollte es aber im Syslog auftauchen.

    Diese Probleme mit SSDs scheinen gelegentlich mal aufzutreten, ich hatte da einiges im Netz gefunden.

    Von alten Samsung SSDs hatte ich bislang noch nichts gelesen, das kann aber auch an meiner Suche liegen. Dem Hinweis werde ich bei Gelegenheit mal nach gehen -rein Interesse halber-, danke. Wenn hiese was dazu geschrieben hatte, sollte man das eigentlich finden können.


    Irgendwie scheinen einige Fehlerbilder extrem hartnäckig zu sein und Jahrzehnte zu überdauern :schiel .

    Von langsam werdenden Festplatten, die man mit dem Befehl reparieren kann, kann ich (wie schon erwähnt) aus eigener Erfahrung berichten.


    Meine SSD werde ich übrigens gelegentlich noch mal testen, inzwischen hat sie wohl langsam lange genug rum gelegen ;) . Ich berichte dann.

    Mehr kommt da nicht. Kannst Du da mal nachschauen, wo es da noch hakt?

    $URL scheint leer zu sein.

    Die kommt aus der Konfigurationsdatei für den Kanal.

    Wenn es mit der VLC-Variante von den Skript geht, sollte es das eigentlich auch hier.

    Evtl. ist da irgendwo noch was falsch, was ich nicht sehe, oder es liegt an der verwendeten Shell.

    Du könntest mal versuchen das "#!/bin/bash" wieder in "#!/bin/sh", wie im Originalskript zu ändern.


    Zum weiteren testen kannst Du auch erstmal nur mit dem Skript von carel weiter machen, das geht momentan besser.

    Ich denke das spart Zeit, wenn das andere Skript geht ziehe ich die Änderungen nach.


    Das Bild ist allerdings zerhackt, ruckelt, bleibt stehen und es gibt viele Blockartefakte.

    Der Ton ist manchmal da, aber meistens kein Ton.

    Ich hatte irgendwo im Zusammenhang mit der Telerising.api von derartigen Problemen gelesen.

    Irgendwas war da mit ffmpeg und hls7 und im Log taucht "hls7" auf.


    Ich lese hier nur am Rande mit, aber https://github.com/Zabrimus/remotetranscode beschäftigt sich doch eigentlich mit einem ähnlichen Szenario, Streams aus dem Web im TS- Container für den VDR aufzubereiten, oder?

    Das Thema kenne ich, hatte es bislang aber nur am Rande verfolgt, obwohl ich die ganze HBBTV-Geschichte echt interessant finde.

    Die Hauptinnovation von remotetranscode, die Ich sehe ist, dass der Aufruf von ffmpeg direkt erfolgt und (wenn ich das richtig verstanden habe) die Pipes weg fallen. Das könnte bei Umschaltzeiten und Zuverlässigkeit einiges bringen.

    Eigentlich wollte ich mir das zwischen den Jahren mal ansehen, inzwischen ist der Winter aber auch schon wieder rum ...

    Die Zeile #70 ist folgende: LC_NUMERIC=C ffmpeg \ . also genau an der gleichen Stelle, wie im anderen Script von SHF

    So war das auch beabsichtigt.

    Meins sollte, wenn alles klappt wie es soll, mit den ganzen VLC-Skripten austauschbar sein.

    Die Scripte von carel und SHF unterscheiden sich nur in der Funktion für die Auswahl der URLs für die einzelnen Kanäle/Streams.

    Das ist nicht verwunderlich, die Zeilen hatte ich aus dem anderen Skript kopiert.

    Das LC_NUMERIC=C setzt lediglich eine Umgebungsvariable und sollte unproblematisch sein. Das hat wohl mit dem Dezimalpunt/Komma zu tun.

    Dann kommt gleich der Aufruf von ffmpeg.

    Der zieht sich übrigens noch über mehrere Zeilen hin, der Backslash \ "entfernt" quasi den Zeilenumbruch. Das heisst, die nächsten Zeilen gehören zu den Aufruf auch noch dazu. (Mit Zeilenumbruch ist es lediglich besser lesbar.)


    Den eigentlichen Fehler hat carel ja wohl schon beseitigt.

    Wenn es weiterhin Fehler gibt, darauf achten ob der VDR in /tmp/ffmpeg.log auch schreiben darf.

    Und auch wenn es geht, kann, mal einen Blick in die Datei kann werfen, auch nicht schaden ;) .

    Eine invertierte Anzeige der LED, hatte ich bei einer SSD zwar noch nicht, ist durchaus denkbar.

    Das lässt sich aber recht einfach durch booten einer Live-CD (SystemrescueCD o.ä.) bestätigen. Solange die SSD nicht gemountet ist, sollte die LED normalerweise immer aus sein.


    Evtl brauch die SSD aber auch noch etwas Zeit, um sich zu "sortieren".

    Das Phänomen hatte ich auch schon. Das sollte dann aber nach ein paar Stunden erledigt sein.


    Bei meiner Problem-SSD im "Bummelstreik" (SSD extremst langsam) zeigte die LED zwar ein ähnliches Verhalten, das hättest Du aber schon lange gemerkt.

    m syslog gibt es folgende Fehlermeldung, wenn ich zum Kanal 101 umschalte:

    Warum es an der Stelle eine Fehlermeldung gibt, verstehe ich nicht.

    Ich hatte den ersten Teil komplett kopiert, bis zum veränderten Teil sind wir gar nicht gekommen.

    Meine Vorlage war dieses Skript: RE: config vdr-plugin-iptv mit vlc2iptv Das verwendest Du doch auch?


    Einfach nur das neue Skript nach vlc2iptv_raw verlinken (oder umbennen), channels.conf nicht ändern!


    Jetzt kommt die Frage, wo weise ich denn dem Script die URLs von der telerisin.api zu, also den iptv channel?

    Wenn ich dein Script richtig lese, dann sollte das in /etc/vdr/plugins/iptv/vlcinput/ sein.

    Es war eigentlich so gedacht, dass die beiden Skripte (vlc/ffmpeg2iptv) ohne weitere Änderungen austauschbar sein sollten.

    Dass die Konfigurationen von vlcinput verwendet werden war also beabsichtigt.


    Das ist so erstmal zum Testen gedacht, so kann man die Varianten vergleichen, ohne weitere Änderungen machen zu müssen.


    I used the 'cksum' command to generate them (see above)

    vlc2iptv macht das wohl mit unterschiedlichen PIDs für die Kanäle. SID und TID tauchen beim VLC-Aufruf jedenfalls nicht auf.


    Ich hatte jetzt gehofft, es klappt mit den default Werten von ffmpeg, das war aber wohl nix.

    Was VLC da macht ist mir momentan nicht ganz klar, die Doku ist da lückenhaft.

    Ich hatte gehofft, dass ich mir das Sparen kann, aber wenn ich am WE Zeit habe muss ich wohl mal auszuprobieren, was bei VLC raus kommt.



    Die Defaultwerte von VLC für NID und TSID scheinen zufällig zu sein.

    Von daher müsste es mit ffmpeg eigentlich so gehen.

    Generell sieht es ja mal ganz gut aus, was ankommt.

    hls und dash liefern entweder mpeg4 oder mpeg-ts Container, da habe ich heute nachgeschlagen.

    Eine Anwendung zum runterladen wird man aber wohl immer brauchen, da die Streams segmentiert sind.

    Letztlich ist es also wohl egal, was genau ankommt.


    Das Problem beim Umschalten wird sowieso wird eher am VLC oder Skript liegen, irgend was klappt nicht ideal.


    Allerdings ist das schon wieder ziemlich komplex, weil man da noch vorher für jeden Kanal einen extra Eintrag in einer /etc/vdr/plugins/iptv/urls.conf" erstellen muss.

    Dafür fallen die einzelnen Dateien pro Kanal der anderen Lösung weg.

    Im Endeffent kommt es also ziemlich aufs gleiche hinaus.

    Ideal wäre es, wenn man diese Konfiguration am Ende mit einem Skript automatisieren könnte...


    Ich habe mir eben mal den Spass gemacht und die ffmpeg-Kommandos in das VLC-Skript kopiert.

    Das ging eigentlich problemlos, lediglich bei der $SID und $TID musste ich raten.

    Das entstandene Skript sollte als direkter Ersatz für das vlc2iptv_raw laufen, wenn nichts schief gegangen ist.

    Hardwareprobleme würde ich nicht ausschliessen, das Board wurde 2012 eingeführt, da könnten schon ein paar Elkos ausgelutscht sein.

    Das Board sollte schon Polymer-Elkos haben, die sind deutlich langlebiger.

    Meine Boards aus der Serie haben jedenfalls alle schon Polymer-Elkos und laufen bislang auch alle Problemlos.


    Ausserdem führen ELKO-Defekte, nach meiner Erfahrung eher zu Plötzlichen Reboots oder Kernelpanic.


    Ein Blick ins Syslog könnte aber wirklich nicht schaden.

    Besonders, wenn man einen "Guten" und eine "Schlechten" zum Vergleich hat.

    Ich denke, das geht NICHT direkt, sondern nur mit Transkodierung

    Für mich sieht es danach aus, als ob maximal ein "umpacken" in einen anderen Container nötig ist.

    Das ist ein deutlicher Unterschied, was den Aufwand angeht. Ein "umpacken" sollte locker machbar sein.


    Momentan ist die Sache aber ziemlich unübersichtlich, man müsste erstmal wissen, was wirklich an Stream ankommt. Und dann, ob die telerising.api da noch was verändert.

    Wenn man das weiß, kann man sich überlegen, wie man das Skript darauf optimiert.


    In VLC kann man den Stream auch unbearbeitet speichern:

    Netzwerkstream öffnen -> Konvertieren -> Raw-Input speichern.


    Mediainfo oder FFProbe sollte da dann den Container raus finden können.

    Mit dem Kernel 6.1 von Debian 12 gehen einige DVB-Karten nicht. (Details)


    Kernel Updaten, dann geht die Karte wieder!

    Am einfachsten auf einen aus den Backports.

    Alternativ könnte man das auch mal als Bug melden.

    Ich hatte es zwar schon vor, bin aber bislang noch nicht mal zum Update auf Debian 12 gekommen.

    Ich meine jedoch, die Regelhaftigkeit "größere Dämpfung = weniger Fehler in der Aufnahme" zu sehen

    Ein zu hoher Pegel kann es auch sein.


    Dann gibt es auch noch Störungen, die von irgendwo rein kommen können und die sind nicht unbedingt abhängig vom Pegel.


    Die Signalparameter sind bei DVB-Karten auch eher ein Schätzeisen und zwischen den einzelnen Karten leider auch nicht unbedingt vergleichbar.


    Meine beiden Sat-Karten liefern am selben Kabel völlig unterschiedliche Werte. Die Eine hätte gerne ein stärkeres Signal, für die Andere ist es eigentlich ideal.

    Am Ende einem nur, das auszuprobieren. Ich hatte mir damals einen Inline-Verstärker und einen Dämpfungsregler für zusammen ~15€ bestellt.

    Damit hatte ich dann raus bekommen, dass die eine Karte wirklich gerne einen Verstärker hätte.

    Ist es das DZ77GA-70K?

    Da sind ein Haufen Schnittstellen drauf, die man eigentlich nicht braucht.

    Ausserdem teilen sich die zwei PCIEx1-Slots einen Link (siehe Manual S. 18)

    Ich würde erstmal alles unnötige deaktivieren, Firewire und die Marvell SATA-Controller.


    Die SATA-SSD muss natürlich an einen 6GB/s Port (AA), für die Festplatten reicht auch 3GB/s (BB). Die CC-Ports besser meiden, die hängen am Marvell SATA-Controller.

    Die NVME-SSD sollte in den PCIEx16, die Netzwerkkarte in den PCIEx8 und die DVB-Karte in den PCIEx4 Slot. Eine Grafikkarte brauchst Du im Server nicht, denke ich mal.

    Und dann mal schauen, ob es besser wird.


    Dann sollte man auch mal auf die Temperaturen schauen, evtl. sitzt zB. der CPU-Kühler nicht gut, das könnte auch eine derartige Wirkung haben.