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.
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.
Hm.. sieht so aus, als ob bei Ubuntu das gar nicht geht:
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
Display More
Ich habe mir eine udev-Regel erstellt:
# 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"
Display More
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:
/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.
Die Version 3.0.25 ist auf vdr-plugin-markad verfügbar.
- change svdrp default port to 6419
- declare option --saveinfo as depreciated
- some minor bug fixes and optimizations, see git
Die Option --saveinfo wird in der nächsten Version entfernt werden, weil sie gegen meinen Grundsatz verstößt, keine VDR Dateien zu ändern. Seit VDR 2.6 löscht die Option die Fehlerinformation, die VDR in die Info Datei speichert. Er wird somit dringend empfohlen, jetzt schon die Option nicht mehr zu verwenden.
Die Version 3.0.26 ist auf vdr-plugin-markad verfügbar.
- remove option --saveinfo
- add make option NO_VDR
- fix memory leak (thx to wirbel-at-vdr-portal for reporting)
- remove definition of unused variable (thx to wirbel-at-vdr-portal for reporting)
- fix check for user root (thx to wirbel-at-vdr-portal for reporting)
- some minor bug fixes and optimizations, see git
Nochmals vielen Dank an wirbel , der die Downtime des Forums genutzt hat, mir einige Issues im Github einzustellen.
Display MoreHallo,
sieht so aus als ob ich bei dem Problem mit dem "push_back" auf meiner Platform doch richtig lag:
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.
Der Patch ist aber offenbar nicht im 3.0.26 ?
Es hat sich aber leider erst nach den damaligen Tests im praktischen Betrieb gezeigt dass die damals gefundene Lösungen nicht wirklich die Ursachen
der Probleme behoben haben.
Tatsächlich sind noch memory leaks im code vorhanden die mit dem von mir bereitgestellten patch beseitigt werden.
Wäre schön wenn du den nocht integrierst.
Post #966
Den Post habe ich irgendwie komplett übersehen, sorry.
Ein erster Blick zeigt, dass ein Teil des Patches auf die SaveInfo Funktion zeigt, die inzwischen entfernt wurde. Den Rest schaue ich mir an.
Warum diese Änderung ? Das macht doch das gleiche über zwischen-Variablen und ändert nicht wirklich was, oder ?
@@ -3677,9 +3677,13 @@ time_t cMarkAdStandalone::GetRecordingStart(time_t start, int fd) {
time_t now = time(NULL);
struct tm tm_r;
struct tm t = *localtime_r(&now, &tm_r); // init timezone
- if (sscanf(timestr, "%4d-%02d-%02d.%02d%*c%02d", &t.tm_year, &t.tm_mon, &t.tm_mday, &t.tm_hour, & t.tm_min)==5) {
- t.tm_year -= 1900;
- t.tm_mon--;
+ int y, mo, d, h, mi;
+ if (sscanf(timestr, "%4d-%02d-%02d.%02d%*c%02d", &y, &mo, &d, &h, &mi)==5) {
+ t.tm_year = y - 1900;
+ t.tm_mon = mo - 1;
+ t.tm_mday = d;
+ t.tm_hour = h;
+ t.tm_min = mi;
t.tm_sec = 0;
t.tm_isdst = -1;
isyslog("getting recording start from directory (can be wrong!)");
Display More
In den man pages zu localtime hab ich die vollständige Beschreibung zur struct tm jetzt auch gesehen.
Die members sind alle als type int dokumentiert und damit die Änderung wirklich nicht notwendig.
Kannst du raus lassen.
Don’t have an account yet? Register yourself now and be a part of our community!