Kann das markad prüfen und eventuell ins Log schreiben?
Nein, weil damit hätte ich Abhängigkeiten zur Distribution, auf der es läuft, die ich nicht möchte.
[markad] überarbeiteter Decoder
-
Hm.. sieht so aus, als ob bei Ubuntu das gar nicht geht:
Display MoreCode- arkwing@vdr01:~$ grep "" /sys/block/*/queue/scheduler
- /sys/block/loop0/queue/scheduler:[mq-deadline] none
- /sys/block/loop1/queue/scheduler:[mq-deadline] none
- /sys/block/loop2/queue/scheduler:[mq-deadline] none
- /sys/block/loop3/queue/scheduler:[mq-deadline] none
- /sys/block/loop4/queue/scheduler:[mq-deadline] none
- /sys/block/loop5/queue/scheduler:[mq-deadline] none
- /sys/block/loop6/queue/scheduler:[mq-deadline] none
- /sys/block/loop7/queue/scheduler:[mq-deadline] none
- /sys/block/loop8/queue/scheduler:[mq-deadline] none
- /sys/block/sda/queue/scheduler:[mq-deadline] none
- /sys/block/sdb/queue/scheduler:[mq-deadline] none
-
Ich habe mir eine udev-Regel erstellt:
Display MoreCode- # The process to change I/O scheduler, depending on whether the disk is rotating or not
- # can be automated and persist across reboots. For example the udev rule below sets the
- # scheduler to none for NVMe, mq-deadline for SSD/eMMC, and bfq for rotational drives
- #/etc/udev/rules.d/60-ioschedulers.rules
- # set scheduler for NVMe
- ACTION=="add|change", KERNEL=="nvme[0-9]n[0-9]", ATTR{queue/scheduler}="none"
- # set scheduler for SSD and eMMC
- ACTION=="add|change", KERNEL=="sd[a-z]*|mmcblk[0-9]*", ATTR{queue/rotational}=="0", ATTR{queue/scheduler}="mq-deadline"
- # set scheduler for rotating disks
- ACTION=="add|change", KERNEL=="sd[a-z]*", ATTR{queue/rotational}=="1", ATTR{queue/scheduler}="bfq"
Mal schauen...
-
Hm.. sieht so aus, als ob bei Ubuntu das gar nicht geht:
Das wage ich zu beweifeln, ich mache das seit Jahren.
Du must das Kernel Module zuerst laden ("modprobe bfq").
Ausgabe von "grep "" /sys/block/*/queue/scheduler" gekürzt auf Video Raid und deren Disks:
Code- /sys/block/md1/queue/scheduler:none
- /sys/block/sdc/queue/scheduler:mq-deadline [bfq] none
- /sys/block/sde/queue/scheduler:mq-deadline [bfq] none
- /sys/block/sdf/queue/scheduler:mq-deadline [bfq] none
- /sys/block/sdi/queue/scheduler:mq-deadline [bfq] none
- /sys/block/sdj/queue/scheduler:mq-deadline [bfq] none
- /sys/block/sdk/queue/scheduler:mq-deadline [bfq] none
-
-
Hallo,
sieht so aus als ob ich bei dem Problem mit dem "push_back" auf meiner Platform doch richtig lag:
Mit dem neusten Git Stand selbes Ergebnis.
Ich denke das Problem ist weder in der class vector noch im Compiler zu suchen.
Beides sind zu fundamentale Funktionen.
Sieht für mich eher danach aus, das der heap vorher corrupted wird und es nur den vector bzw. die recordingIndex reference trifft.
Gibt es kein Analysetool mit dem man solche Fehler sucht?
Ich hatte hier auch mit den letzten Fixes immer wieder noch Aufnahmen bei denen das markad crashed allerdings an anderer Stelle.
Die Probleme resultieren aus nicht ganz sauberer Parameterversorgung/vorbereitung für die Funktionen getline und sscanf was dann
zu korrupten Hauptspeicher führt.
Im Anhang ist ein Patch der das fixed.
Jetzt funktioniert auch das push_back bei mir ohne das man vorher ein reserve macht.
-
Ich hab die Senderlogos für markad aus dem alten Projekt zu markad kopiert.
Gibt es für aktuelle Logos vieleicht eine bessere Quelle?
-
Hi,
Ja, selber scannen jdes Mal. So wird es ja jetzt empfohlen.
MfG Stefan
-
Hi,
Ja, selber scannen jdes Mal. So wird es ja jetzt empfohlen.
MfG Stefan
Danke. Die Option --autologo=2 ist da wohl mein Freund.
-
So wird es ja jetzt empfohlen.
Ich habe das Thema mal zum Anlass genommen, die Erklärung auch ins Wiki aufzunehmen.
