Unter arch bereits installiert, problemlos
[markad] überarbeiteter Decoder
-
-
Hatte das debian-Verzeichnis aus Bequemlichkeit aus dem normalen alten Markad kopiert...
Das ist wohl auch nicht der übliche Weg. Bitte wie in INSTALL beschrieben verfahren, oder warten bis es als Packet in deiner Distribution verfügbar ist.
-
Das INSTALL Verfahren zerschießt dann das Paket-Management, keine gute Idee.
Aber ich hab mal den Paketbauer für die vdr-Pakete getreten. Also mich.
Der hat dann das rules File mal aufgeräumt.
Das "MAKE_OPTIONS = VDRDIR=/usr/include/vdr" konnte ja nur verunglücken...
Stefan
-
Das INSTALL Verfahren zerschießt dann das Paket-Management, keine gute Idee.
Warum ? Du überschreibst das, durch das Packet installierte markad, mit der neuen selbst gebauten Version. Das bekommt das Paket-Management gar nicht mit (ok, wenn man das "zerschießt" nennen will). Zurück geht es mit apt-get install --reinstall vdr-plugin-markad-ng. Mit dem nächsten regulärem Update wird die selbst gebaute Version wieder durch das Paket (mit dann gleichem Inhalt) überschrieben und alles ist wieder normal. So mache ich das auf meinem produktiven yavdr System immer, da ich die neue markad Version zeitlich immer vor seahawk1986 habe
-
Frohes neues Jahr.
Und natürlich gibt es dazu auch eine neue Version:
Version 2.5.1 ist auf vdr-plugin-markad verfügbar.
Sie bereinigt ein paar kleinere Fehler bei der Erkennung von Überschneidungen vor und nach der Werbung.
-
Eine neue Version 2.5.2 ist auf vdr-plugin-markad verfügbar.
Diese Version enthält kleinere Optimierungen im Bereich der Erkennung von Stellen ohne Ton, sowie (mal wieder) eine Optimierung für "drehende Logos".
-
Auf Sport1 funktioniert die auto. Logoerkennung nicht.
-
Ups, das sieht aber komisch aus. Grundsätzlich geht der Sender, bei meiner Testaufnahme funktioniert es.
Bei deiner Aufnahme werden zwei potentielle Logos erkannt, unten links und unten rechts. Beide werden aber verworfen, weil sie nicht den üblichen Logo Größen entsprechen. Oben links, wo eigentlich das Logo sein sollte, wird gar nichts gefunden.
Poste mir mal einen Screenshot als PM.
-
Ich habe mir das jetzt mal im Detail angeschaut. Die Aufnahme ist schon sehr speziell, eine Tischtennis Live Aufnahme hat sehr oft vor und nach der Werbung die gleiche Bildeinstellung: Zwei Leute und eine Tischtennisplatte. Da schlägt die Überschneidungserkennung zu und macht dir die Marken falsch. Die Erkennung musst du mit dem zusätzlichen Parameter markad "--pass1only" ausschalten. Dann wird es wesentlich besser, wenn auch noch nicht ganz perfekt.
Falsch bleiben:
CodeVon 21 Marken in dem 2:12h Teil Video bleiben folgende sehr ungenau: 0:14:38.11 detected logo stop (21960) Hintergrund für Logo Erkennung zu hell (11s zu spät) 1:02:04.23 detected logo stop (93122) Logo wird durch Vorschau Text überdeckt (12s zu früh) 1:45:10.07 detected logo stop (157756) Logo wird durch Vorschau Text überdeckt (50s zu früh)
An dem Thema von temporären Logo Überdeckungen oder Änderungen arbeite ich gerade, das wird voraussichtlich in 2.6 drin sein. Wird dir aber bei deiner Aufnahme nichts nützen, weil du das mit --pass1only wieder ausschalten würdest.
Ich hoffe mal, du kannst so damit leben.
-
Wenn neue Erkenntnisse dadurch gewonnen wurden, lebe ich damit schon mal besser .
Danke für's anschauen.
-
Hallo kfb77,
im meinem Server sind 8 GB RAM und 4GB Swapfile vorhanden. Der Proz ist ein I5 5th Generation. Also eigentlich genug Power/Resourcen.
Der emergency exit vom VDR passierte meist dann, wenn >2 Aufnahmen zeitgleich stattfinden und wenigstens eine davon auf einem Kanal ohne vorhandenes Logo stattfand. Dabei handelt es sich um verschlüsselte Kanäle in HD
Das Plugin ist auf "während" eingestellt, da ich meist im Timeshift schaue und die Marks gerne nutze.
Nach einem emergency exit des VDR wurde alles noch schlimmer, da die Aufnahmen immer wieder neu gestartet wurden und jedes mal markad mitgespielt hat
Jetzt mit --autologo=1 klappts mit den Aufnahmen (können auch schon mal 5 parallel sein) Für mich ist das so erstmal ok, auch wenn eine schnellere marks Erstellung bei Timeshift schon besser wäre.
Gerne können wir auf dem markad treath weitermachen.
Hast Recht, besser hier weiter.
Speicher sollte locker reichen, CPU erst Recht, da habe ich selbst nur einen I3 und ich lasse bei Programmtest ca. 500 Aufnahmen in 8 Stunden schneiden. Und parallel laufen auch mal 6 oder mehr Aufnahmen (nein, ich schaue nicht alles an, manches ist auch nur zum markad testen). Also so im Schnitt eine Minute pro Aufnahme.
Das darf so nicht sein und das kann ich mir gerne mal näher untersuchen. Bei mir tritt das Problem nicht auf, da ich markad nicht aus dem VDR raus starte, sondern über ein Script, das stündlich läuft und fertige Aufnahme schneidet. Ich schaue nie im Timeshift.
Poste mir mal bitte die Markad.log mit --loglevel=3 von:
1. --autologo=1
2 --autologo=2 ohne VDR crash
3. --autologo=2 und VDR crash
Muss nicht die gleiche Aufnahme sein.
Und schaue mal ins Syslog zum Zeitpunkt des Crashs, ob du davor ring buffer overflows vom VDR siehst.
Und noch die Ausgaben von
cat /sys/block/sdX/queue/scheduler
smartctl -a /dev/sdX
von der Aufnahmeplatte.
Ich habe den Verdacht, dass die Platte überlastet wird und der VDR die Daten nicht mehr weg schreiben kann. Und mit autologo=1 bremst du trotz leistungsfähiger CPU markad so weit aus, dass der Platten I/O für den VDR wieder reicht. Nur so ein erster Verdacht ...
-
Ich habe den Verdacht, dass die Platte überlastet wird und der VDR die Daten nicht mehr weg schreiben kann. Und mit autologo=1 bremst du trotz leistungsfähiger CPU markad so weit aus, dass der Platten I/O für den VDR wieder reicht. Nur so ein erster Verdacht ...
Das klingt plausibel. Zumal bei "nur SD" Aufnahmen das Problem nicht aufgetreten ist.
Wenn dann noch markad I/O intensiv arbeitet ....
Die Aufnahmeplatte ist ein Raid5 mit 30 TB
hdparm -tT /dev/sda
/dev/sda:
Timing cached reads: 20734 MB in 1.99 seconds = 10412.15 MB/sec
SG_IO: bad/missing sense data, sb[]: 70 00 05 00 00 00 00 0a 00 00 00 00 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Timing buffered disk reads: 1986 MB in 3.00 seconds = 661.96 MB/sec
Ich werde mal testweise eine SSD als Aufnahmeplatte einsetzen.Weitere Infos, nach Tests folgen.
=== START OF INFORMATION SECTION ===
Vendor: ASR8805
Product: Raid
Revision: V1.0
User Capacity: 29.989.598.658.560 bytes [29,9 TB]
Logical block size: 512 bytes
Physical block size: 2048 bytes
Lowest aligned LBA: 435
Logical block provisioning enabled, LBPRZ=1
Logical Unit id: 0x3055334e00d00000
Serial number: 4E335530
Device type: disk
Local Time is: Fri Jan 15 11:46:42 2021 CET
SMART support is: Available - device has SMART capability.
SMART support is: Enabled
Temperature Warning: Disabled or Not Supported
=== START OF READ SMART DATA SECTION ===
SMART Health Status: OK
Current Drive Temperature: 0 C
Drive Trip Temperature: 0 C
Error Counter logging not supported
arcconf getconfig 1 LD
Controllers found: 1
----------------------------------------------------------------------
Logical device information
----------------------------------------------------------------------
Logical Device number 0
Logical Device name : Raid
Block Size of member drives : 512 Bytes
RAID level : 5
Unique Identifier : 4E335530
Status of Logical Device : Optimal
Additional details : Quick initialized
Size : 28600310 MB
Parity space : 9533440 MB
Stripe-unit size : 256 KB
Interface Type : Serial ATA
Device Type : HDD
Read-cache setting : Enabled
Read-cache status : On
Write-cache setting : On when protected by battery/ZMM
Write-cache status : On
Partitioned : Yes
Protected by Hot-Spare : No
Bootable : Yes
Failed stripes : No
Power settings : Disabled
--------------------------------------------------------
Logical Device segment information
--------------------------------------------------------
Segment 0 : Present (9537536MB, SATA, HDD, Connector:0, Device:0) ZA2AG41B
Segment 1 : Present (9537536MB, SATA, HDD, Connector:0, Device:1) ZA2AG48S
Segment 2 : Present (9537536MB, SATA, HDD, Connector:0, Device:2) ZA2AG49T
Segment 3 : Present (9537536MB, SATA, HDD, Connector:0, Device:3) ZA2AG460
-
RAID5 mit 30TB ? Das Thema hatten wir ja schon mal, ist nicht wirklich sinnvoll. Hat aber mit dem Problem nichts zu tun.
Poste mal
cat /sys/block/sdX/queue/scheduler
von /dev/mdX und von den Platten aus dem Raid.
-
Quote
RAID5 mit 30TB ? Das Thema hatten wir ja schon mal, ist nicht wirklich sinnvoll.
Für mich schon
Ich möchte alle aufgenommenen Filme im ständigen Zugriff bereit halten, was mit einer NAS o.ä. nicht möglich ist. Aber das ist ein anderes Thema.
QuotePoste mal
cat /sys/block/sdX/queue/scheduler
von /dev/mdX und von den Platten aus dem Raid.
Es handelt sich hierbei um ein Hardware Raid mit Adaptec Controller, da gibt es kein mdX. In Ubuntu wird das Raid als sda benutzt.
Disk /dev/sda: 27,28 TiB, 29989598658560 bytes, 58573434880 sectors
Disk model: Raid
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: CE3BC269-557D-4C08-A4B8-062A22FFC01A
Device Start End Sectors Size Type
/dev/sda1 2048 58573432831 58573430784 27,3T Linux filesystem
Klar, ein Software Raid 5 wäre definitiv nicht performant genug für meine Anforderung.
Die Frage ist halt, ob es am Durchsatz liegt - obwohl die Werte eigentlich ganz gut aussehen.
Timing cached reads: 20734 MB in 1.99 seconds = 10412.15 MB/sec
Timing buffered disk reads: 1986 MB in 3.00 seconds = 661.96 MB/sec
-
Dann eben bitte den Output von
cat /sys/block/sda/queue/scheduler
-
cat /sys/block/sda/queue/scheduler
[mq-deadline] none
-
Das habe ich vermutet. Da machen sich die Programmierer Mühe und berücksichtigen I/O Prioritäten und der Default im Debian Universum ignoriert die. Egal wie schnell dein RAID ist, ein Programm, dass im wesentlichen I/O macht, zusammen mit einer schnellen CPU, wird die Platten an die Grenzen bringen. Vor allem dann, wenn du markad noch mehrfach laufen hast. Wenn du jetzt noch ring buffer overflows vom VDR im Syslog vor dem Crash hast, dann ist die Ursache klar: falscher Disk Scheduler.
Falls ja, dann versuche mal:
sudo bash
modprobe bfq
echo bfq > /sys/block/sda/queue/scheduler
Das ist nicht boot-fest, falls das die Lösung ist, musst du es nach jedem booten ausführen (z.B. aus systemd oder rc.local als quick and dirty)
-
Ah, ok wieder was gelernt
Danke für Deine Hilfe
nach
modprobe bfq
echo bfq > /sys/block/sda/queue/scheduler
habe ich
cat /sys/block/sda/queue/scheduler
mq-deadline [bfq] none
Denke das ist so in Ordnung ?
Ich packe das dann in mein Start-Script und teste das mal mit --autologo=2
Hat eigentlich --autologo=2 einen positiven Effekt bei der Timeshift Wiedergabe und der Einstellung "Ausführung während"? Ich vermute die Marks werden schneller ermittelt und bereitgestellt ?
-
cat /sys/block/sda/queue/scheduler
mq-deadline [bfq] none
passt
Hat eigentlich --autologo=2 einen positiven Effekt bei der Timeshift Wiedergabe und der Einstellung "Ausführung während"? Ich vermute die Marks werden schneller ermittelt und bereitgestellt ?
Grundsätzlich schon, aber auf deiner I5 wird der Unterschied vermutlich nicht sehr groß sein. Um das Logo in der Aufnahme zu finden, brauche ich mindestens 1000 iFrames + den Timer Vorlauf. Bei einer HD Aufnahme sind die iFrames seltener und somit dauert das schon ein paar Minuten, bis genug Frames da sind. Wenn dir wichtig ist, dass das schneller geht, hilft nur die Logos in den Cache zu legen.
-
Eine neue Version 2.5.3 ist auf vdr-plugin-markad verfügbar.
Sie behebt einen Bug, dass markad in eine endlos Schleife gehen kann, wenn die Erkennung der Stillen Teile zwischen Sendung und Werbung zufällig genau auf eine Dateigrenze fällt. Scheint bis jetzt glücklicherweise noch keinen getroffen zu haben, sonst wären hier wohl Beschwerden gekommen.
-
Participate now!
Don’t have an account yet? Register yourself now and be a part of our community!