Beiträge von SHF

  • ChatGPT - script um channels.conf obsolete etc. zu löschen

    Mein "Minimalskript" für sowas sieht so aus:

    Code
    grep --invert-match " OBSOLETE;" channels.conf > channels.new

    (Über die Jahre haben sich bei mir übrigens einige solche nützlichen Schnipsel gesammelt, mit denen man fast alles gelöst bekommt.)


    Das kann man auch ganz gut um weitere Befehle erweitern:

    Code
    grep --invert-match " OBSOLETE;" channels.conf > channels.new && mv -f channels.conf channels.save && mv channels.new channels.conf


    Grep kann die Suchmuster übrigens auch aus einer Datei einlesen.

    Die gewünschte Funktionalität ist also auch mit dem Einzeiler zu erlefüllen.

    (Bei vielen Suchmustern und großen Dateien ist das unter Umständen auch deutlich effizienter.)

    Code
    grep --invert-match -f channel_remove.txt channels.conf > channels.new
    Code: channels_remove.txt
     OBSOLETE;
^.;
_alt
^TEST

  • Gibt es eine Alternative zu DVB-C welche mit VDR funktioniert?

    Für mich sieht es so aus, als ob da was mit dem ersten Zeilenumbruch nicht stimmt.

    Evtl. mal so probieren:

    Code
     LC_NUMERIC=C ffmpeg -loglevel fatal -re -i "${URL}${BUFFER}" \
-ignore_unknown -map 0:0 -map 0:1 -map 0:2? -map 0:3? -map 0:4? -c copy \
-streamid 0:$VPID -streamid 1:$APID -streamid 2:345 \
-f mpegts -mpegts_transport_stream_id $TID -mpegts_pmt_start_pid 4096 -mpegts_service_id $SID \
-mpegts_original_network_id $NID "udp://$HOST:$PORT?pkt_size=1316&buffer_size=65536&overrun_nonfatal=1" &>/tmp/ffmpeg.log &

  • Gibt es eine Alternative zu DVB-C welche mit VDR funktioniert?

    Ups, da hatte ich die \ übersehen.

    Doppelt quoten mit \ und " mach natürlich keinen Sinn.

    Einmal ist aber bei mir zwingend notwendig, damit die Optionen auch bei ffmpeg ankommen.

    "udp://$HOST:$PORT?pkt_size=1316&buffer_size=65536&overrun_nonfatal=1"

    (Ohne die " wenden die Teile nach den & als eigene Befehle ausgeführt und da die nicht ausführbar sind bewirken sie natürlich nichts.)


    Die Variante mit \ könnte evtl. auch gehen, habe ich aber nicht probiert

    Zitat von Paulaner

    Ich habe jetzt keine Ahnung von den vielen Funktionen in ffmpeg, aber wie ich das deute, geht es doch hier um die Sortierung der Audio-Video-Streams und anschließender Umwandling in TS-Streams.

    Die -map wählen die Streams aus.

    Selecting streams with the -map option


    Zitat von Paulaner

    Wäre das mit dieser "pipe" nicht etwas das man auch für unsere Umwandlung nutzen kann?

    Prinzipiell kann das iptv-plugin auch aus Pipes lesen.

    Anscheinend wird aber in Verbindung mit einem externen Skript immer eine UDP-Verbindung erwartet.

    Das müsste man sich als nächstes mal näher ansehen.


    Die ffmpeg Kommandos sehen eigentlich recht brauchbar aus und könnten so auch mit dem iptv-plugin zusammen funktionieren.


    Zitat von Paulaner

    Das Umschalten zwischen den Streams dauert ca. 4...8 Sekunden. ist noch etwas lang, aber noch machbar.

    Das ist ja schon besser.

    3-4 Sekunden hätte ich auch erwartet, es ist halt ein Puffer zu viel drin.


    Zitat von Paulaner

    Was noch nicht geht ist das Umschalten der beiden Audio-Spuren.

    Kein Wunder, ffmpeg wählt standardmäßig nur eine Audio-Spur, das begrenzt die Auswahl fürs Umschalten deutlich ;) .

    Default Behavior: Only 1 stream per type will be selected.



    Zitat von don-baba

    Wäre es nicht einfacher die Umwandlung und streamerstellung über tvheadend und tele-dings direkt in eine Fifo Datei leiten zu lassen und die Datei dann mit dem iptv plugin abzuspielen?

    Je mehr unterschiedliche Komonenten der Stream durchläuft, desto schwieriger wird es eine anständige Unschaltzeit hin zu bekommen. Die Streams will man ja auch nicht die ganze Zeit laufen lassen und in /dev/null entsorgen.


    Am iptv-plugin fehlt nicht viel, damit die von der "tele-dings" gelieferten ffmpg-Befehle funktionieren.

    Streammässig müsste alles schon da sein, was fehlt ist "nur" die Unterstützung für die m3u8-Playlists.

    Irgendwie muss man das automatisieren können, die Angaben sollten reichen einen für den VDR gültigen Kanal zu erzeugen.

    Dazu gibt es bei diesen Playlists nur 2 Container-Formate mp4 und mpeg2ts. Letzteres ist vom VDR sowieso unterstützt.

    Bei mp4 könnte man sich an KODI ran hängen, die bekommen von ffmpeg via pipe auch mpeg2ts serviert. Und da waren die Umschaltzeiten bislang ja mit Abstand die besten, wenn ich mich nicht täusche.


    Problem ist momentan aber erstmal das Mapping der Streams mit ffmpeg.

    Was bei telerising gut funktioniert, scheitert zB. beim ZDF grandios, weil die Streams anders liegen.

    Mit -map 0 einfach alle Streams zu wählen funktioniert nicht, da man mehrere Video-Streams erhält, was für Chaos sorgt.

    Für je eine Audio und Video-Stream scheint das Default Verhalten von ffmpeg ganz gut zu gehen.

    Wenn man aber mehr als einen Audio-Stream möchte, muss man vorher wissen, welchen Video und welche Audio-Streams man haben will.


    Einen Vorteil hat das statische Mapping aber, man kann die Zeit fürs proben sparen (wenn ffmpeg da mit macht).

    Bei telerising scheinen alle Kanäle zum Glück die gleichen Einstellungen zu haben.

    Ich habe jetzt mal einen neuen ffmpeg-Aufruf aus unserem und dem aus der Playlist zusammen gebastelt:

    Bash
    #!/bin/bash


LC_NUMERIC=C ffmpeg \
-loglevel fatal -re -i "${URL}${BUFFER}" \
-ignore_unknown -map 0:0 -map 0:1 -map 0:2? -map 0:3? -map 0:4? -c copy \
-streamid 0:$VPID -streamid 1:$APID -streamid 2:345 \
-f mpegts -mpegts_transport_stream_id $TID -mpegts_pmt_start_pid 4096 -mpegts_service_id $SID \
-mpegts_original_network_id $NID "udp://$HOST:$PORT?pkt_size=1316&buffer_size=65536&overrun_nonfatal=1" &>/tmp/ffmpeg.log &

    Die zweite Audio-PID habe ich mal fest auf "345" gesetzt.
    Da muss man sich wirklich mal was besseres überlegen, aber für einen Test bezüglich der Umschaltzeiten sollte es gehen.

    Falls es Probleme gibt das -streamid 2:345 einfach mal entfernen. Ich bin nicht sicher, was passiert, wenn der Stream gar nicht existiert.

  • [remote] Plugin-Verwendung beendet VDR

    Dank den "tollen" Osterwetters, habe ich es doch noch mal mit valgrind und address sanitizer versucht.


    Den Fehler, den libefence zeigt (s.o.) zeigen beide nicht. Mit den Änderungen aus den vorherigen Beitrag bekommen keine Abstürze mehr.

    Ich vermute daher mal, das bei libefence ist ein false positive.


    Dafür finden sowohl valgrind als auch address sanitizer memory leaks im VDR (auch ohne jegliche Plugins.

    Immer im Zusammenhang mit libfontconfig.so.1. Ich vermute den Fehler momentan also eher da und werde erstmal das System updaten und hoffe das erledigt sich von selbst.


    Für die, die weiter basteln wollen:

    Für Valgrind vdr starten mit: (eher langsam!)

    valgrind --leak-check=yes vdr ....


    Der address sanitizer wird einkompiliert, dann ganz normal starten.

    Ich hatte das mit der folgenden Änderung an der Make.config vom VDR gemacht.

    Code: Make.config
     ### The C compiler and options:
 
 CC       = gcc
-CFLAGS   = -g -O3 -Walls
+CFLAGS   = -g -O3 -Wall -fsanitize=address
 
 CXX      = g++
-CXXFLAGS = -g -O3 -Wall -Werror=overloaded-virtual -Wno-parentheses
+CXXFLAGS = -g -O3 -Wall -Werror=overloaded-virtual -Wno-parentheses -fsanitize=address


    Ich denke, ohne laufenden SQL-Server kommt man nicht mehr weiter, da muss also jetzt jemand anderes ran.

  • Ubuntu: Anzeige des Speichers in dmesg

    Also diese Speicherangaben sind bei mir auch unterschiedlich, bislang war mir das noch nicht aufgefallen, faszinierend.

    sudo journalctl | grep Memory: | cut -d ":" -f 4- | sort | uniq

    Dieser kleine Test zeigt bei mir ca. 25 verschiedene Angaben von insgesamt etwa 1000.

    sudo journalctl | grep -c Memory:

    Kurioserweise ist sogar die rechte Seite unterschiedlich, aber nur 2 um 4K verschiedene Werte.

    Ob es da Häufungen bei einigen Werten gibt, habe ich nicht ausgewertet.

    Bei der Menge an Bootvorgängen müssen aber einige Kernel-Updates dabei sein, ich vermute da Abhängigkeiten.


    Zitat von cduerr

    Ich vermute: Es muss irgendwas softwareseitiges sein, was die Werte runtergehen lässt (erste Benutzung der TV-Karte?).

    Man könnte mal schauen, ob sich an den PCIe-Einstellungen was ändert.

    sudo lspci -vv | grep -E '[0-9][0-9]:[0-9][0-9]|LnkCap|LnkSta'

    Bei Datenfehlern sollte sowieso etwas im Syslog auftauchen.


    Zitat von cduerr

    Aber während das bei der SSD z.B. irgendeine Dauernutzung sein könnte, was die serielle Datenübertragungsrate einfach reduziert, fällt mir bei der NIC nichts mehr ein.

    Das sollte aber mit den üblichen Tools (top usw.) auffallen, wenn irgendwas das System auslastet.


    Die NIC ist für mich eh so eine Verdächtige. Die 2,5Gb-Teile sind recht neu und Realtek ist schon öfters mit Treiberproblemen aufgefallen.


    Zitat von cduerr

    Oder Power Management.

    Mit powertop mal die tuneables angesehen?


    Zitat von cduerr

    Ich habe /usr/local/bin/vdr-checkts gefunden und obwohl es mir nicht die Zeiten gibt, es erzeugt noch mehr Fragezeichen :)

    Irgendwie kommt man mit vdr-checkts an die Position und von da aus auch an die Zeit.

    Wenn ich mich recht erinnere mittels der index-Datei. Ist aber ewig her, dass ich damit was gemacht habe.


    Nachtrag:

    Bei lediglich einen einzigen Fehler würde ich mir den Aufriss aber nicht machen.

  • Ubuntu: Anzeige des Speichers in dmesg

    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.


    Zitat von rüsseltier

    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.

  • Gibt es eine Alternative zu DVB-C welche mit VDR funktioniert?

    -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.

  • Gibt es eine Alternative zu DVB-C welche mit VDR funktioniert?

    Zitat von Paulaner

    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!

  • Gibt es eine Alternative zu DVB-C welche mit VDR funktioniert?

    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.


    Zitat von Paulaner

    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!

  • dvb-t2 Empfangsprobleme

    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.

  • Gibt es eine Alternative zu DVB-C welche mit VDR funktioniert?

    Zitat von carel

    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.


    Zitat von carel

    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.

  • dvb-t2 Empfangsprobleme

    Zitat von fhg

    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.