Beiträge von TomJoad

    Ich konnte das nachstellen, weiss aber nicht ob es das einzige Szenario ist:

    Der Client setzt schnell hintereinander MODT Kommandos ab

    Es kann passieren, dass nachdem das Kommando am Server angekommen ist, aber bevor sich die CmdLSTT den WRITE_LOCK holt,

    die Mainloop am Server ein LSTT ID zum Client schickt. Dieses Kommando bleibt beim Client hängen (weil dort das Modifizieren des Timers den Lock schon hat.

    Am Server bleibt CmdLSTT hängen weil in der main Loop vor dem GetRemoteTimers und LSTT ein Lock geholt wird.

    !! Also ein systemübergreifender Deadlock, der aber durch die Timeouts wieder aufgelöst wird !!

    Klaus hat für das Problem schon eine Korrektur von mir bekommen. Die schnellste Lösung, soweit ich mir erinnere: in den vdr-Einstellungen "Alte EPG-Daten anzeigen" die Zeit hochzudrehen, wenn die z.B. auf 0 steht, dann ist der Nachlauf 0 Minuten, auch wenn das running-Flag noch an ist. Eine Zeit von 30 Minuten sollte i. d. Regel greifen.

    Das Problem ist erst mit der 2.3 reingekommen. Ich persönlich nehme immer mit VPS auf.

    Im Patch war noch ein Fehler, wenn die Anfangszeit vor Mitternacht liegt. Das Problem mit Timern, die am Sonntag zwischen 02:00 und 03:00 beginnen, wird schwer lösbar sein, weil die Zeit nicht eindeutig ist. Dann müsste schon in den Timer-Einträgen in timers.conf die Länge mit abgespeichert werden. Korrigierter Patch (bezogen auf Originalvdr : winterzeit.diff


    Mit VPS gibt es kein Problem. Ohne VPS gibt ti->StopTime() die falsche Zeit aus, wenn zwischen Beginn und Ende der Sendung eine Zeitumstellung liegt.


    Wenn epgsearch einen Timer zum Anlegen findet (hier Doctor Who mit Anfangszeit 01:20 und Endezeit 03:30),

    wird überprüft, ob es schon einen entsprechenden Timer gibt. Im epg-Event stehen Anfangszeit und Länge der Sendung. Daraus ergibt sich die Endezeit (die sollte immer richtig sein, auch wenn zwischendrin die Zeit umgestellt wird, weil es sich um Sekunden seit 1.1.1970 handelt). Dieser Event wird verglichen mit bereits angelegten Timern über deren Start- und Stopzeiten aus ti->StartTime() und ti->StopTime() (wenn kein VPS eingeschaltet ist).

    Bei den bereits angelegten Timern gibt vdr als als Ende 02:30 aus und dieser Timer wird von epgsearch nicht dem Event zugeordnet.

    vdr speichert einen Timer mit seinen Anfangs- und Endezeiten als Uhrzeiten ab (timers.conf).

    in Matches (timers.c) wird aus den Uhrzeiten die Länge berechnet und damit aus der Anfangszeit die stopTime.

    Das geht schief, wenn wie hier die Zeitumstellung dazwischen kommt.


    Ohne Gewähr auf irgendwelche Nebenwirkungen eine Änderung in timers.c ( entfernt auch alle fälschlicherweise zusätzlich angelegten Timer beim nächsten epgsearch-update-Lauf)

    Meiner Einschätzung nach kann es nur damit zusammenhängen, dass der Timer in die Zeitumstellung fällt und vom main vdr anders abgespeichert wird als er im epg gefunden wird. Deshalb gibt es dann keine Übereinstimmung und er wird immer wieder neu eingetragen.

    Es wäre schön, wenn jmd in vdr-developer.org entsprechende Links setzen könnte, wenn man über projects.vdr-developer.org/projects einsteigt und zu den Plugins verzweigt, bei epgsearch wird man auf winni.vdr-developer.org geführt, wo kein aktuelles git mehr ist.

    Der Wert 40 ist mal zur Beschränkung eingeführt worden, weil der vdr das auch hatte. Allerdings gibt es das im main-vdr seit 2.0 nicht mehr, sondern ist ersetzt durch --dirnames.

    Das alte --vfat setzt immer noch die Verzeichnislänge auf 40. Ich denke, langsam sollte das obsolet sein, auch exfat kann 255 Zeichen.

    Da epgsearch die Aufrufparameter von vdr nicht auslesen kann, es aber weiter sinnvoll ist, die Werte zu synchronisieren, gibt es mehrere Möglichkeiten

    - die Distributionen setzen PLUGIN_EPGSEARCH_MAX_SUBTITLE_LENGTH passend zu dirnames

    - es gibt einen neuen Aufrufparameter für epgsearch oder eine Setup-Option

    - epgsearch setzt den Default auf 255 und nur wo das nicht passt, muss eingegriffen werden.

    Danke für die ausführlichen Antworten, ich wollte auch nicht demotivieren.

    Ich kann jetzt nicht verschiedene Distributionen untersuchen. In der man-page von depmod steht

    Code
    1. By default, depmod will give a higher priority to a directory
    2. with the name updates using this built-in search string: "updates
    3. built-in" but more complex arrangements are possible and are used
    4. in several popular distributions

    Wenn Distributionen das komplett über den Haufen werfen, sollten sie auch über dkms nachdenken. Ich wollte nur zum Ausdruck bringen, dass ich die Anpassungen an die älteren Kernelversionen für das drängendere Problem halte, wenn das Paket allgemeingültig sein soll - oder man muss doch eine Grenze setzen.

    Übrigens läuft auch lirc_serial nicht mit dem neuen rc_core wegen nicht passender Abhängigkeiten, so dass man genauso auf eine nötige Änderung gestossen wird, wie wenn es fehlen würde. Eigentlich sollte es bei Querverbindungen von alten und neuen Modulen nicht zu Problemen kommen, wenn alle Schnittstellen befriedigt werden und die Module sich laden lassen. Darauf verlässt man sich ja auch bei den Kernel-Schnittstellen.

    Version 0004 sieht bei mir erstmal gut aus. Fernbedienung läuft mit den Konfigurationsänderungen die Paulaner oben verlinkt hat und dddvb hat auch keine Auffälligkeiten (ausser dass das femon-plugin keine Signalstärken mehr anzeigt).

    Lasse ich aber mal über alle neuen Module ein modprobe laufen, gibt es diverse, die sich nicht laden lassen und die vielleicht jmd. anders braucht.

    Ich weiss nicht, ob das Entfernen der Originalmodule eine gute Idee ist. Normalerweise sorgt die Priorisierung der Module unter updates dafür, dass das gewünschte geladen wird - und wenn man das dkms entfernt, hat man wieder den vorigen Zustand.

    Problematischer ist es, wenn Module umbenannt worden sind, weil dann i.d.R. wie bei lirc_serial Konfigurationsarbeiten notwendig sind, oder wenn sich Parameter geändert haben. Da wäre etwas mehr Hilfestellung wünschenswert (passende Changelog oder so)

    Ich habe mal die kernel-sourcen von 3.13 und 4.4 verglichen, und in 4.4 ist in time.c ein

    "EXPORT_SYMBOL_GPL(nsecs_to_jiffies);"

    welches in 3.13 fehlt, obwohl die Funktion durchaus vorhanden wäre.