Prinzipiell funktioniert damit "Wiederholung vermeiden" nicht, kein so großer Beinbruch, besser als Episoden zu verpassen ...
Finde ich nicht. Das ist eine Katastrophe 
! Gerade wenn man Serien aufnimmt, die ständig wiederholt werden und wenn dann eine neue und eine alte Folge ausgestrahlt werden. Bei meinen ~200 Suchtimern ein Unding!
Jetzt mach Dich mal locker Das ganze heißt Developer Version, was impliziert das einige Sachen evtl. noch nicht 100% rund laufen. Wenn Du es stable und zuverlässig haben möchtest, go for VDR 2.2.0 + epgsearch 2.2.0 ...
Es ist sehr wohl besser das eine Grundfunktion von epgsearch immer noch zuverlässig funktioniert, nämlich das Finden von definierten Sendungen. Für "Wiederholung vermeiden" findet sicher ein talentierter vdr-portal.de Nutzer eine Lösung ...
Regards
fnu
Zur grossen Beruhigung:
Da jetzt wieder ein benutzbarer Git-Stand da ist, habe ich meine Änderungen rausgekramt. Mit "revert separate status thread" funktioniert auch epgsearchdone.dat wieder (danke an kamel5 für den schubser!)
Bevor das ganze im Git landet, bitte intensiv testen!
Muss leider noch einen Patch hinterherschieben, damit es wieder mit vdr < 2.3 kompiliert.
damit es wieder mit vdr < 2.3 kompiliert.
Hmm, wozu, es gibt einen Branch der stabil mit VDR 2.2.0 funktioniert und wo keine Funktionalität fehlt? Dieser ist im GIT auch entsprechend getaggt ...
In den Branch vdr-2.2.x würde ich nur noch sinnvolle funktionale Erweiterungen "cherry_pick"'en, ansonsten belassen. Er funktioniert auf breiter Basis und ist jahrelang genutzt/getestet, also genau das was man als stable bezeichnet.
Alle neueren Patches im master Branch zielen auf die Verwendbarkeit mit VDR 2.3x ab, was ja am Ende auch die Zukunft ist, auf was man sich konzentrieren könnte, neue Funktionen sind ja auch nicht dazu gekommen.
In master würde ich in Zukunft auch mal dem geäusserten Wunsch nachkommen die "if VDRVERSNUM" Abfragen aufzulösen.
Regards
fnu
PS.: Ansonsten laufen Deine 4 neuen Patches hier, morgen sehe ich ob epgsearchdone.data geschrieben wurde ...
Zu den Aufhängern:
Mir ist schon mit VDR 2.0.x aufgefallen, dass epgsearch mitten im Suchtimer-Update anscheinend etwa eine Minute Pause mache. So sah es anhand er Logfile zumindest aus.
Bedienbar ist der VDR während dessen aber noch.
Es könnte sich also um ein älteres Problem handeln, was sich erst jetzt auswirkt, weil epgsearch während des Päuschens noch einen der neuen Locks hält.
Vielleicht hilft die Beobachtung ja bei der Fehlersuche.
Mit "revert separate status thread" funktioniert auch epgsearchdone.dat wieder (danke an kamel5 für den schubser!)
morgen sehe ich ob epgsearchdone.data geschrieben wurde ...
Sieht soweit gut aus hier, die getätigte Aufnahmen werden wieder in der Datei vermerkt.
Die Zuverlässigkeit muss jetzt ein etwas längerer Test zeigen. Mit einem funktionierenden epgsearch und auch xmltv2vdr werde ich mal einen Nutz-VDR mit VDR 2.3.4 ausstatten.
Regards
fnu
In master würde ich in Zukunft auch mal dem geäusserten Wunsch nachkommen die "if VDRVERSNUM" Abfragen aufzulösen.
Ich weiss nicht, ob die Automatismen aller Distributionen damit schon klar kommen, im git ist es ja sauber zu trennen.
Es ist jetzt nicht schwierig, ein unifdef -DVDRVERSNUM=20304 über die Sourcen laufen zu lassen. Ich würde auch gerne ein indent durchführen, weil mit den Einrückungen einiges durcheinandergeraten ist.
Zu den Pausen kann ich nur nochmal sagen, dass die Betroffenen das epgsearch-Logging einschalten sollten. Im Coding zum Durchlaufen der epgsearchdone.data hat sich z.B. nichts geändert.
Hi,
ich hatte auch mal versucht ein Log zu erstellen, nutze die runvdr.extreme und habe dazu epgsearch so starten lassen
# The next two lines must be present:
# Plugin name: epgsearch
# Default priority: 50
AddPlugin epgsearch -f /usr/local/bin/svdrpsend -l /var/log/epgsearch.log -v 3
In var/log kam aber nie was an.
Das war mitlerweile auch sicherlich schon mein 3. oder 4. Versuch auf vdr 2.3.x umzusteigen. Die Probleme die damit, zumindest bei mir, immer wieder auftreten haben mich mal wieder dazu veranlasst, den VDR in der Version 2.2.0 wieder zu aktivieren. 
Habe die epgsearchdone.data dazu auch wieder ins entsprechende Verzeichnis kopiert, und alles läuft wieder ohne Wartezeiten. Ich nutze den VDR seit über 10 Jahren, bis auf die Anfangszeit mit Linvdr immer selbst compilierte Developer-Versionen, und habe in der Zeit viel dazu gelernt, aber solch Probleme wie mit den Versionen 2.3.x hatte ich noch nie. Noch dazu die zähe Entwicklung und immer mehr Developer die sich abwenden oder zurück ziehen lassen langsam den Spass am VDR schwinden. Sorry das ich das hier OT in diesem Threat schreibe, aber VDR ohne ein funktionierendes epgsearch ist für mich nicht denkbar. 
Gruss
Stefan
Ich weiss nicht, ob die Automatismen aller Distributionen damit schon klar kommen, im git ist es ja sauber zu trennen.
Nun, dann muss man das halt anpassen. Es gibt zwei Branches, einen für stable VDR 2.2.0, lang geprüft und getestet, und einen master (=developer), eben nun angelehnt an VDR 2.3.x.
Ich werde die VDRVERSNUM & APIVERSNUM Abfragen auch im vdr-2.2.x Branch rausnehmen, VDR 1.5.x, 1.7.x oder 2.1.x verwendet heute niemand mehr.
Welche Patches hast Du in Deinem selbstkompilierten VDR drin?
Regards
fnu
MainMenuHooks-v1_0_3.diff
pin_vdr-2.3.1.diff
vdr-2.2.0_source_dependent_new_channel_insertion.diff
04_plugin_missing.patch
opt-37-x_menuorg.patch
vdr-2.3.2_zapcockpit.patch
vdr-2.3.3-editrecording.patch
vdr-2.3.3-resumereset.patchNimm mal bitte den zapcockpit Patch raus, wenn Du nochmal Muße hast einen Test zu machen.
Was macht der "vdr-2.2.0_source_dependent_new_channel_insertion.diff" Patch? Ist der auch in VDR 2.3.4 drin?
Du nimmst schon den letzten GIT Stand epgsearch bei VDR 2.3.4 evtl. zzgl. der 4 letzte TomJoad Patches?
Regards
fnu
vdr-2.2.0_source_dependent_new_channel_insertion.diff sortiert neu gefundene Channels in Channelgruppen die nach der Quelle benannt sind also z.B. New Channels 19,2E, New Channels 13,0E usw. und ich habe ihn auch auf vdr2.3.4 angewandt.
Und ja, nehme den Stand so wie von dir beschrieben.
So zapcockpit Patch habe ich rausgenommen und VDR-2.3.4 nur mit softhddevice und epgsearch von Hand gestartet. Leider keine Veränderung 48 Sekunden Pause, bis ich den VDR bedienen kann.
Beim manuellen Start wird auch ein Log von epgsearch erstellt. Das poste ich aber nicht, da stehen logischerweise sämtliche Timer und mein kompletter Festplatteninhalt sämtlicher Aufnahmen drinnen. Dann sieht die Snowden-Fraktion ja, dass ich 97% FSK 18-Filmchen aufzeichne. 
Hi TomJoad,
das hatte ich schonmal gemacht, zumindest im Log nach Pausen gesucht und nichts gefunden.
Nun habe ich einmal vdr-2.2.0 und einmal 2.3.4 gestartet und die Logs direkt verglichen. Sie sind fast aufs Byte identisch. Die Zeitstempel unterscheiden sich natürlich, und die erste Zeile (EPGSearch log started (verbose level 3, version 1.0.1.beta5) zu Sa. 06.05.2017 18:18:36: EPGSearch log started (verbose level 3, version 2.3.1)). Sonst alles gleich !
Wenn das Problem bei den Meissten nicht auftritt, ich den VDR nur mit softhddevice und epgsearch starte, wo kann den da noch das Problem liegen ? Ich compiliere gleich noch den VDR vanilla und gucke dann !
Habe nun den VDR-2.3.4 vanilla compiliert und nur mit softhddevice und epgsearch gestartet. Ergebnis: wie gehabt, fast 1 minute Pause beim Start. Nun habe ich keine Ideen mehr.
(verbose level 3, version 1.0.1.beta5)
Ist jetzt epgsearch Version 2.2.0 ...
Es werden in der Suchtimer-Update-Routine zwar oft Locks angefordert (was es so in der 2.2 nicht gab), aber ich sehe keine lang gehaltenen Locks. Deshalb verstehe ich die Unbedienbarkeit nicht.
Man könnte noch das Lock-Debugging des vdr scharf machen, das gibt sehr viel Output. - Oder man müsste in der Situation einen crash erzwingen (gdb auf den vdr-Prozess und generate-core-file als gdb-Kommando) . Dieses liesse sich weiter analysieren mit gdb und dort 'thread apply all bt'.
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!
