Beiträge von Fourty2

  • vaapidevice: fast forward and rewind of all rtl transmitter does not work

    Jo, fein..


    Man kann das Verhalten auch bei Live-TV (einfach x-mal umschalten) provozieren. Dann hat man tonloses Live-TV mit "1 TS packet(s) not accepted in Transfer Mode" und Bild, nach 8s ein kurzes Einfrieren, danach geht es dann allerdings mit normalem Softstart-Sync und Ton weiter (hier auch bei ARD HD -> ZDF HD möglich).


    Also ein eher "allgemeines" Problem, so in etwa, als ob der berechnete Ton-PTS-Sync Zeitpunkt schon "Geschichte" ist.


    Stefan

  • vaapidevice: fast forward and rewind of all rtl transmitter does not work

    Zitat von 447377

    Und nachdem's nun funktioniert, fällt mir auf, dass meistens beim Start einer Aufnahme der Ton stumm bleibt. Erst nach dem Umschalten auf eine andere Tonspur spricht der VDR. Hat jemand Erfahrung? Was muss ich machen?



    Das war einer von den drei Punkten, weshalb ich mich an den Patch gemacht habe. Leider ist die Ursache eine (noch unbekannte) Andere.

    Workaround ist Abspielen, falls ohne Ton (und Auto-Stop nach ca. 8 sec) dann -> Back/Exit -> Ok.. (wieder abspielen)

    Ab und an erwischt das Vaapidevice dann die falsche Halbbildfolge (=Zittern), dann halt nochmal Back -> Ok...


    Mit Audio-Debug sieht das "Tonlos" so aus:


    Also, falls jemand eine Idee hat, her damit...

    Den Filmschnipsel kann ich gerne zur Verfügung stellen - zuverlässig tonlos ab Startpunkt "0"


    Grüße,

    Stefan

  • vaapidevice: fast forward and rewind of all rtl transmitter does not work

    Nur zur Info:

    Das Dauer-Frame-Duping kann ich bei mir auch aktivieren, wenn Softstart aus ist...


    Code
    Jun 15 12:22:15 roadrunner vdr: [2920] VAAPI: video: slow down video, duping frame (/\=102,18 ms, vClk 19:02:30.469 - aClk 19:02:30.358)
Jun 15 12:22:15 roadrunner vdr: [2920] VAAPI: video: slow down video, duping frame (/\=98,94 ms, vClk 19:02:30.469 - aClk 19:02:30.380)
Jun 15 12:22:15 roadrunner vdr: [2920] VAAPI: video: slow down video, duping frame (/\=102,03 ms, vClk 19:02:30.509 - aClk 19:02:30.398)
Jun 15 12:22:15 roadrunner vdr: [2920] VAAPI: video: slow down video, duping frame (/\=98,81 ms, vClk 19:02:30.509 - aClk 19:02:30.420)
Jun 15 12:22:15 roadrunner vdr: [2920] VAAPI: video: slow down video, duping frame (/\=101,97 ms, vClk 19:02:30.549 - aClk 19:02:30.438)
[..]


    Da ist also was im Sync-Code falsch. Bzw., es erfolgt nie eine vollständige Synchronisation.


    Habe dann auch "+89", wie im Ursprungsposting
    VAAPI: video: 19:02:28.829 +89 438 0/\ms 19+5 v-buf


    statt z.B.,

    VAAPI: video: 19:17:17.909 +6 331 0/\ms 20+3 v-buf
    (mit Softstart und Patch)


    Stefan

  • vaapidevice: fast forward and rewind of all rtl transmitter does not work

    Hmm, läuft hier (mit einem ähnlichen Patch, andere Mittelwertbildung, bringt aber nix).


    Sieht mir irgendwie so aus, als wenn die Zeitdifferenz zwischen Audio und Video schneller auseinanderläuft , als er Frames wegwerfen kann.

    Nur warum?


    Stefan

  • vaapidevice: fast forward and rewind of all rtl transmitter does not work

    Hi,


    da ist im Syncdecoder (und vermutlich noch an anderen Stellen) was kaputtgespielt.


    Bei mir (aktueller GIT-Stand) zeigte sich das Problem aber eher beim Abspielen von Aufnahmen, Live-TV war ok. Bei Aufnahmen hatte ich was a la 25i, wenn er mit etwas Glück beim richtigen Halbbild loslief und der Audio-Sync einrastet.


    Vielleicht hilft dies:

    https://github.com/pesintta/vd…8359/speedupdown.patch.gz


    Grüß

    Stefan

  • Suche Rat bzgl. Glasfaser

    Tja, eben. ;)

    Meist wird nicht bedacht, das ein "Überspannungsereignis" das lokale Erdpotential "ein wenig" anhebt, während der Hausanschluß (Strom (nur die 3 Phasen... ) / Tel. o. xDSL / ..) auf Fernpotential bleibt. Und hin ist die schöne Technik.

    Ganz besonders, wenn in der Nähe z.B. eine WKA Blitzableiter spielt. Nachdem unser Hausanschluß und TK eingehend geschützt waren (irgendwas um EUR 600,- Anno 2004), hatten dann halt nur noch die Nachbarn E-Schrott - und wir bisweilen ein heftiges "Klong" im Anschlußraum..

    Daher:
    Die 20 m oben machen trotz "nasser Erde" ausreichend mehr Potentialdifferenz für die arme Netztechnik als per Kupfer erheblich niederohmiger verbunden - daher der dicke PE-Leiter.


    Stefan

  • Suche Rat bzgl. Glasfaser

    Nur der Vollständigkeit halber:
    Man kann dies durchaus per Kupfer realisieren. Dann muß man natürlich auf den Potentialausgleich achten (sowie die Strecken und ggf. gleich zusätzlich den Hausanschluß mit Ableitern schützen).


    Die knapp 80m Strecke, die seit ca. 2006 bei einem Kunden zwischen Büro- und Privathaus (unterirdisch) liegt, führt daher eine 16 mm² Erde mit, die die Potentialausgleichsschienen der Gebäude niederohmig verbindet. Bisher immer problemfrei - sowohl bei LAN wie ISDN.


    Stefan

  • epgd / epg2vdr / scraper2vdr

    Hallo,


    mußte sowas in den epg2vdr (und entsprechendes in scraper2vdr) patchen

    Code
    cUpdate::cUpdate(cPluginEPG2VDR* aPlugin)
    : cThread("epg2vdr-update")
@@ -264,6 +264,8 @@
 {
    int status = success;

+   sleep(30);
+
    if (!connection)
       connection = new cDbConnection();

    damit der VDR mit laufenden Aufnahmen (falls mal keine Daten vom CAM kommen) in keiner Restart-Schleife hängen bleibt.

    Denke, die Aufnahmenliste im scraper bleibt zu lange gelockt. Immer wenn das gute Stück nicht auf die Fernbedienung reagiert, ist epg2vdr/scraper2vdr beschäftigt. Leider hab ich so adhoc keinen Weg gefunden, die Aufnahmen-Liste nur Scrap-für-Scrap zu locken. Insbesondere bei vielen Aufnahmen und / oder langsamen SQL-Servern geht das dann schief.


    Stefan

  • SPDIF/TOS Ausgabe von zwei Applikationen mit ALSA

    Hallo zusammen,


    wo wir gerade dabei sind:

    Wäre es mit Vaapidevice / ALSA möglich, den AC3/PCM Ton auf HDMI und gleichzeitig ein 2-Kanal Downmix (oder halt auch 2xPCM bei Stereo-Quelle) auf S/PDIF zu schaufeln?

    Das wäre die Ideallösung für die Hörgeschädigte im Haushalt - dann wäre der Rest des Bluetooth-LL-Delays zum Haupton auch noch verschwunden. :)


    Grüße,

    Stefan

  • UKW-Hörern droht Zwangsabschaltung

    Zitat von wirbel

    Bitrate kostet Geld. CD-nahe Quali ist mit AAC LC machbar, das hängt von der Sendestation ab

    Das ist natürlich insbesondere bei unserer Zwangs-Pensionskasse mit angehängtem Sendebetrieb bei 8 Mrd € / Jahr Etat Argument Nr. 1.


    Zitat von wirbel

    Dürfen schon, brauchen nur nicht.

    Digitale Modulationen wie DVB-T/T2 oder DAB(+) nutzen mehrere Sender im Gleichwellennetz. UKW kann das nicht und muss mit mehr Pegel störende Nachbarsender wegdrücken. Und ebenso brauchen DAB - Empfänger weniger Signal als eine UKW Ausstrahlung.

    Nun, wir sehen ja, wie aus der ehemaligen 99% Abdeckung mit UKW und analogem VHF/UHF TV schon mit DVB-T1 ein Flickenteppich entstand, der bei DAB([.+]) ebenso vorhanden ist.


    Offenbar reicht die Leistung eben *nicht*.


    Und - vielleicht liegts am Alter - ich sehe auch nicht ein, warum ich einen Radio-Stream für Hintergrundberieselung durch die IP-Leitung prügeln soll (nein, keine Sorge 100 MBit Downstream), den ich erst mühsam aus dem unüberschaubaren Angebot fischen soll. Irgendwas nervt da doch immer.


    Daher läuft hier stationär "der eigene Sender", direkt per Bitstream an die Verstärker, in FLAC Qualtität. Und der ist auch, wie UKW ganz ohne externe Anbindung verfügbar. Nur Strom braucht er.


    Bis 1993(?) ging es hier vor Ort zwar auch mit etwa einer Dachrinne (1593 kHz, 800 kW EIRP), aber da war die Senderwahl irgendwie blöd - da war UKW schon besser. ;)


    Stefan

  • epgd / epg2vdr / scraper2vdr

    Auf dem rpi mit vdr-2.2 gibts mit dem aktuellen Git wieder Probleme:



    Grüße,

    Stefan


    PS: Auf 2.3.8 funktionierts ...

  • Probleme mit Technotrend S2-4200 bzw. DVBSky S952 v3

    Habe die DVBSky 952 V3 und TT-4200 auf einem 64 Bit Kernel 4.14.10 (die aktuellen Patche... warten wir noch etwas) problemfrei im Einsatz. Eigentlich laufen die, seit die Treiber im Kernel sind, stabil.


    Eventuell ist eher das LNB tot / braucht zuviel Stom? Dann löst die Polyfuse aus... Lost Lock...


    Stefan


  • SoftHDDevice mit AMD oder Intel, Qualität PP/Deinterlacing, Alternativen mit Onboard?

    Zu Spectre/Meltdown:
    Bei einem reinem Solo VDR braucht man da sicher nicht in Panik ausbrechen.

    Sollte z.B. Kodi darauf laufen, und ins Netz können, sieht die Sache vielleicht schon anders aus. Z.B. könnten ja Server-Verzeichnisse / WLAN verbunden sein, o.ä., deren Passwörter u.U. angreifbar wären.

    Es kommt halt immer darauf an, wie die Umgebung ausschaut. Aber Primärziel dürfte jede Art von VM sein, was bei einem VDR ja eher ein ungewöhnliches Setup ist.


    Stefan

  • SoftHDDevice mit AMD oder Intel, Qualität PP/Deinterlacing, Alternativen mit Onboard?

    Mal davon abgesehen, daß alle "aktuelleren" Intel-CPUs by Design kaputt sind - auch bei den Atom's funktionieren die Sleep-States.


    Läßt man die "Tiefen" an, riskiert man halt TS Folgefehler in Aufnahmen, wenn die dösige DVB-Hardware die Daten wegen zu kleiner Puffer nicht schnell genug los wird. Hat also weniger mit der CPU, als mehr der Tuner-Karte zu tun (hier DVB-Sky). Abschalten verändert weder die Systemtemperatur noch die Leistungsaufnahme signifikant, daher ist es halt jetzt aus.


    Stefan

  • SoftHDDevice mit AMD oder Intel, Qualität PP/Deinterlacing, Alternativen mit Onboard?

    Also mein Asrock J3160-ITX läuft derzeit stabiler und stressfreier als die vorhandenen NVidia-Systeme, zumal man nicht bei jedem dritten Kernel-Update mit dem *piiep* DKMS Binärtreiber (... did not build) rumhampelt.

    De-Interlace ist kein Problem und arbeitet sauber:


    Auch auf den HD und SD Kanälen, die erst durch ein CAM müssen...

    Das einzige, was man nicht vergessen darf, ist die CPU-Sleep States

    (C6, C7) im BIOS zu deaktivieren, sowie nach einem ACPI Timerstart per


    Code
    echo "0" > /sys/class/rtc/rtc0/wakealarm


    den Alarm zurückzusetzen, sonst stören "kernel: hpet1: lost 9601 rtc interrupts".


    Stefan